headers
Atsushi Kumagai | 1 Feb 2012 05:15
Picon
Picon

Re: [PATCH] Fix segmentation fault for makedumpfile -x/--split

Hi Aruna,

On Tue, 31 Jan 2012 15:56:33 +0530
Aruna Balakrishnaiah <aruna@...> wrote:

> 
> The patch fixes the segmentation fault issue of makedumpfile when a
> user specifies an invalid file name with -x/--split option.
> The patch takes care of such a scenario by setting .find_debuginfo to
> a function pointer which returns -1 and throws error messages against
> invalid vmlinux file input. With a valid vmlinux file .find_debuginfo
> was never invoked since the absolute path of debuginfo was known by the
> time we call init_dwarf_info.
> 
> Signed-off-by: Aruna Balakrishnaiah <aruna@...>
> ---
>  dwarf_info.c |   25 +++++++++++++++++++++++++
>  1 files changed, 25 insertions(+), 0 deletions(-)

Thank you for your patch.
I will review it.

Thanks
Atsushi Kumagai

> diff --git a/dwarf_info.c b/dwarf_info.c
> index 46dcd8e..515455d 100644
> --- a/dwarf_info.c
> +++ b/dwarf_info.c
>  <at>  <at>  -204,6 +204,16  <at>  <at>  search_module_debuginfo(char *os_release)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Christian Frost | 1 Feb 2012 13:01
Picon

Kexec hangs when loading a SMP kernel

Hi all,

I have a problem when loading a SMP kernel using kexec. When i try to
load a similar kernel without SMP and ACPI enabled in the kernel
config, the kernel is loaded correctly. However, when enabled it hangs
after printing "Starting new kernel".

Do you have any suggestions? Please let me know if you need more information.

Regards,
Christian
Permalink | Reply | 0 comments |
headers
Don Zickus | 2 Feb 2012 16:33
Picon
Favicon

Re: [PATCH] x86, kdump, ioapic: Fix kdump race with migrating irq

On Wed, Feb 01, 2012 at 05:34:01PM -0800, Eric W. Biederman wrote:
> > Talking to folks here and trying to read the code it seems like the PIT
> > stuff is delayed until after the IOAPIC is configured using Fast TSC
> > calibration as a mechanism to work around the PIT??
> >
> > I attached the output of the Pentium4 when kdumping.  Not sure what to
> > really look for to verify the PIC is being skipped.  Perhaps you know?
> 
> The important part is the kexec on panic works without shutting down
> the ioapic.  There should be no corner case issues it should either
> work it should fail.
> 
> The problem used to be that we always would initialize the PIT interrupt
> in the 8259 interrupt controller before we would initialize the ioapics
> and that would kill the boot.
> 
> If I have read your testing correctly you are apparently booting in the
> kexec on panic case.  That seems to be successful to me.  So we should
> be able to just remove the ioapic shutdown code from
> machine_crash_shutdown as it is no longer needed.
> 
> Thank you for being careful and testing on a number of different
> platforms. 

No problem.  I was actually trying to find machines that did not have
ioapics to make sure they still worked (it's hard!).

So if I test on a couple more machines (hopefully one without an ioapic),
can I get your ack?  Or is there something else you would like me to do to
verify things are working correctly?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Don Zickus | 2 Feb 2012 19:12
Picon
Favicon

[PATCH] x86, kdump: No need to disable ioapic in crash path

A customer of ours noticed when their machine crashed, kdump did not
work but hung instead.  Using their firmware dumping solution they
grabbed a vmcore and decoded the stacks on the cpus.  What they
noticed seemed to be a rare deadlock with the ioapic_lock.

 CPU4:
 machine_crash_shutdown
 -> machine_ops.crash_shutdown
    -> native_machine_crash_shutdown
       -> kdump_nmi_shootdown_cpus ------> Send NMI to other CPUs
       -> disable_IO_APIC
          -> clear_IO_APIC
             -> clear_IO_APIC_pin
                -> ioapic_read_entry
                   -> spin_lock_irqsave(&ioapic_lock, flags)
                   ---Infinite loop here---

 CPU0:
 do_IRQ
 -> handle_irq
    -> handle_edge_irq
        -> ack_apic_edge
           -> move_native_irq
               -> mask_IO_APIC_irq
                  -> mask_IO_APIC_irq_desc
                     -> spin_lock_irqsave(&ioapic_lock, flags)
                     ---Receive NMI here after getting spinlock---
                        -> nmi
                           -> do_nmi
                              -> crash_nmi_callback
(Continue reading)

Permalink | Reply | 7 comments |
headers
Eric W. Biederman | 3 Feb 2012 00:24
Favicon

Re: [PATCH] x86, kdump: No need to disable ioapic in crash path

Don Zickus <dzickus@...> writes:

> A customer of ours noticed when their machine crashed, kdump did not
> work but hung instead.  Using their firmware dumping solution they
> grabbed a vmcore and decoded the stacks on the cpus.  What they
> noticed seemed to be a rare deadlock with the ioapic_lock.
>
>  CPU4:
>  machine_crash_shutdown
>  -> machine_ops.crash_shutdown
>     -> native_machine_crash_shutdown
>        -> kdump_nmi_shootdown_cpus ------> Send NMI to other CPUs
>        -> disable_IO_APIC
>           -> clear_IO_APIC
>              -> clear_IO_APIC_pin
>                 -> ioapic_read_entry
>                    -> spin_lock_irqsave(&ioapic_lock, flags)
>                    ---Infinite loop here---
>
>  CPU0:
>  do_IRQ
>  -> handle_irq
>     -> handle_edge_irq
>         -> ack_apic_edge
>            -> move_native_irq
>                -> mask_IO_APIC_irq
>                   -> mask_IO_APIC_irq_desc
>                      -> spin_lock_irqsave(&ioapic_lock, flags)
>                      ---Receive NMI here after getting spinlock---
>                         -> nmi
(Continue reading)

Permalink | Reply | 6 comments |
headers
Suzuki K. Poulose | 6 Feb 2012 10:07
Picon

Re: [PATCH v1 0/3][makedumpfile]Add support for PPC32

On 01/19/2012 08:28 AM, Atsushi Kumagai wrote:

Atsushi-San,

> Hi Suzuki,
>
> On Wed, 18 Jan 2012 15:37:49 +0530
> "Suzuki K. Poulose"<suzuki@...>  wrote:
>
>> The following series implements makedumpfile support for PPC32.
>>
>> The implementation is heavily based on PPC64. This also introduces
>> cross build support which is required for Embedded PPC Boards.
>>
>> ---
>>
>> Suzuki K. Poulose (3):
>>        [makedumpfile] Add support for PPC32
>>        [ppc64] Rename the __powerpc__ macro to __powerpc64__ for PPC64
>>        [makedumpfile] Support building for cross build
>>
>>
>>   Makefile       |   26 ++++++++++++--
>>   README         |    5 +++
>>   arch/ppc.c     |  101 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>   makedumpfile.c |    4 +-
>>   makedumpfile.h |   28 +++++++++++++---
>>   5 files changed, 153 insertions(+), 11 deletions(-)
>>   create mode 100644 arch/ppc.c
>>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Atsushi Kumagai | 7 Feb 2012 06:58
Picon
Picon

Re: [PATCH v1 0/3][makedumpfile]Add support for PPC32

Hi Suzuki,

On Mon, 06 Feb 2012 14:37:15 +0530
"Suzuki K. Poulose" <suzuki@...> wrote:

> On 01/19/2012 08:28 AM, Atsushi Kumagai wrote:
> 
> >
> > Thank you for your patches.
> > I will review them.
> 
> Did you get a chance to review my patches ?
> 
> Suzuki

I'm reviewing your patches now, and I will inform you
of the result in the course of this week.

Additionally, the followings are scheduled for v1.4.3.

 - Add support for PPC32
 - Fix VtoP method for x86 remap allocator
 - Fix segmentation fault for -x/--split options
 - Support newer kernels

v1.4.3 will be released before the end of this month
if all steps go smoothly.

Thanks
Atsushi Kumagai
(Continue reading)

Permalink | Reply | 0 comments |
headers
joyce dangote | 7 Feb 2012 21:59

Please My Dear I Need Your Help.

Hello Dear,

I am Miss.Joyce Dangote, 23 years old, a Sociology student,from Guinea
Bissau.My father of blessed memory by name late Mr. Paul Dangote who
was the former deputy minister of national security under the
leadership of president Kumba Yalla who is now facing judgement at the
international court of justice for war crime and abusing human
rights.I am constrained to contact you because of the maltreatment am
receiving from my step mother.She planned to take away all my fathers
treasury and assets from me since the unexpected death of my
Father.Meanwhile,I wanted to travell to Europe but she hid my
international passport and other valuable travelling documents,luckily
she couldn't discover where I kept my fathers file.

I am now writing you from Ouagadougou Burkina-Faso where I escaped to
through road, and now seeking hiding in a private charity organization
under St Johns Catholic Church here in Burkina-Faso.
So I am now in search of an honest and reliable person who will help
to relocate me in any of the western or any other place in the world,
for a better life and to continue my studies, I have chosen to contact
you after getting your email through a database, and I believe you are
a reliable person who will not let me down or betray my trust, I know
you may wonder why I am telling you about all this, even without
seeing or knowing you fully well, really something in me tells me that
you are a good person and I guess I am not wrong.

Briefly, I will like to disclose little more about myself to you and
see if you can help me to relocate to your country so as to continue
with my studies and have a new life, and please this is a little
secret and I plead with you to keep it to yourself alone until
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vivek Goyal | 7 Feb 2012 23:19
Picon
Favicon

Re: [PATCH] x86, kdump: No need to disable ioapic in crash path

On Tue, Feb 07, 2012 at 04:57:41PM -0500, Don Zickus wrote:
> On Thu, Feb 02, 2012 at 03:24:46PM -0800, Eric W. Biederman wrote:
> > > Eric, brought up a point that because the boot code was restructured we may
> > > not need to disable the io apic any more in the crash path.  The original
> > > concern that led to the development of disable_IO_APIC, was that the TSC
> > > calibration on boot up relied on the PIT timer for reference.  Access
> > > to the PIT required 8259 interrupts to be working.  This wouldn't work
> > > if the ioapic needed to be configured.  So on panic path, the ioapic was
> > > reconfigured to use virtual wire mode to allow the 8259 to passthrough.
> > 
> > A small clarification originally it was the jiffies calibration that
> > would fail if we could cause the PIT to generate interrupts through the
> > 8259.  The boot would then hang at calibrating jiffies.
> 
> Ok.  Thanks!

So now what has changed? Do we setup LAPIC and IOAPIC early enough to
receive PIT interrupts in regular mode (non-virtual wire mode) or
something else?

Thanks
Vivek
Permalink | Reply | 4 comments |
headers
Tyler Hall | 8 Feb 2012 00:50
Picon
Gravatar

[PATCH] Fix out-of-tree build

Use automatic variables for prerequisites when copying man pages and
include a makefile relative to $(srcdir).

Signed-off-by: Tyler Hall <tylerwhall@...>
---
 kdump/Makefile          |    2 +-
 kexec/Makefile          |    2 +-
 kexec/arch/ppc/Makefile |    2 +-
 vmcore-dmesg/Makefile   |    2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/kdump/Makefile b/kdump/Makefile
index 1e2b72c..5dfa928 100644
--- a/kdump/Makefile
+++ b/kdump/Makefile
 <at>  <at>  -22,7 +22,7  <at>  <at>  $(KDUMP): $(KDUMP_OBJS)

 $(KDUMP_MANPAGE): kdump/kdump.8
 	$(MKDIR) -p     $(MANDIR)/man8
-	cp kdump/kdump.8 $(KDUMP_MANPAGE)
+	cp $^ $(KDUMP_MANPAGE)
 echo::
 	 <at> echo "KDUMP_SRCS $(KDUMP_SRCS)"
 	 <at> echo "KDUMP_DEPS $(KDUMP_DEPS)"
diff --git a/kexec/Makefile b/kexec/Makefile
index 2137cab..8c815b5 100644
--- a/kexec/Makefile
+++ b/kexec/Makefile
 <at>  <at>  -82,7 +82,7  <at>  <at>  $(KEXEC): CPPFLAGS+=-I$(srcdir)/kexec/arch/$(ARCH)/include
(Continue reading)

Permalink | Reply | 1 comment |

Gmane