From ozgur.ozaslan at kulturturizm.gov.tr  Wed Jan  4 15:51:15 2012
From: ozgur.ozaslan at kulturturizm.gov.tr (=?ISO-8859-1?Q?=D6zgur_=D6zaslan?=)
Date: Wed, 4 Jan 2012 22:51:15 +0200
Subject: Hello
Message-ID: <9D4D3B6015F14044832A7C27DD3DEC74457F9B@turizmdc.kultur.gov.tr>



Hello
I am Dr Mathew Zoro, the manager of Accounts/Operations Department of our bank here in Abidjan Cote D'Ivoire.
I have a Proposal for you. will furnish you the details on your response.
Reply me Via (matthewzoro at mail.com)
Mathew Zoro



From kumagai-atsushi at mxc.nes.nec.co.jp  Thu Jan  5 20:45:01 2012
From: kumagai-atsushi at mxc.nes.nec.co.jp (Atsushi Kumagai)
Date: Fri, 6 Jan 2012 10:45:01 +0900
Subject: makedumpfile-1.4.1: Support for Fujitsu stand-alone dump format.
Message-ID: <20120106104501.010db891.kumagai-atsushi@mxc.nes.nec.co.jp>

Hi,

makedumpfile version 1.4.1 is released.
Your comments/patches are welcome.

Daisuke Hatayama made a lot of effort to implement "Fujitsu stand-alone
dump format support" feature. Thanks, Hatayama-san.

o The explanation about a new feature "Fujitsu stand-alone dump format support":
  Fujitsu stand-alone dump (sadump) format is the original format used by Fujitsu.
  The sadump format is similar to diskdump format.

  This feature convert sadump-related format into kdump-compressed format.
  When converting sadump-related format, -x option is definitely necessary.
  Because, VMCORE created by sadump has NO debug information including VMCOREINFO.

  This feature tested on only x86 and x86_64.

  Ex. Convert multiple VMCOREs in a single commandline input.

    # makedumpfile [OPTION] -x VMLINUX --diskset=VMCORE1 --diskset=VMCORE2 DUMPFILE


Changelog:
o New feature
  Commits related to "Fujitsu stand-alone dump format support"
    - [PATCH v2 01/14] Add sadump module header file (by HATAYAMA Daisuke) c00d65c
    - [PATCH v2 02/14] Extend DumpInfo structure (by HATAYAMA Daisuke) 9a068b5
    - [PATCH v2 03/14] Implement command-line processing (by HATAYAMA Daisuke) 3964c98
    - [PATCH v2 04/14] Verify and read VMCORE(s) in sadump-related formats (by HATAYAMA Daisuke) ff19f9f
    - [PATCH v2 05/14] Export helpers for bitmap table handling (by HATAYAMA Daisuke) eda6066
    - [PATCH v2 06/14] Initialize internal data according to sadump-related formats (by HATAYAMA Daisuke) 0819b77
    - [PATCH v2 07/14] Initialize debug information for ELF note extraction (by HATAYAMA Daisuke) 7890646
    - [PATCH v2 08/14] Implement readmem() interface on sadump-related formats (by HATAYAMA Daisuke) 9c0e854
    - [PATCH v2 09/14] Estimate phys_base based on linux_banner position (by HATAYAMA Daisuke) 5054dd8
    - [PATCH v2 10/14] Generate and save VMCOREINFO and ELF note information (by HATAYAMA Daisuke) ef2832f
    - [PATCH v2 11/14] Process CPUs based on online ones (by HATAYAMA Daisuke) 13dd70a
    - [PATCH v2 12/14] Read kexec backup region (by HATAYAMA Daisuke) fc655b4
    - [PATCH v2 13/14] Add description of sadump-related formats in usage information (by HATAYAMA Daisuke) d6259de
    - [PATCH v2 14/14] Add description of sadump-related formats in manual page (by HATAYAMA Daisuke) c28ac15

o Bugfix
    - [PATCH] Fix off-by-one bug in page_to_pfn() (by Wen Congyang) 8ef4f34
    - [PATCH] s390x: Obtain the vmalloc_start value from high_memory for s390x arch. (by Mahesh Salgaonkar) ff1e067
    - [PATCH] Fix spelling mistakes in error messages. (by Atsushi Kumagai) a7282dd
    - [PATCH] Fix man page section number of makedumpfile.conf. (by Atsushi Kumagai) 98af7d5

o Code Cleanup
    - [PATCH] Cleanup: Fix description of DUMP levels. (by Atsushi Kumagai) 101c563
      (Based on "[PATCH]: fix makedumpfile cache page exclusion dump levels." by Thayumanavar S)
    - [PATCH] Cleanup: Add description of analysis tools in man page. (by Atsushi Kumagai) 2df7a4a
    - [PATCH] Cleanup: Convert multiple spaces to tabs. (by Atsushi Kumagai) 3bcc1d5
    - [PATCH] Cleanup: Delete unnecessary include "elf_info.h". (by Atsushi Kumagai) a296d8e
    - [PATCH] Cleanup: Fix some comments for "#endif". (by Atsushi Kumagai) c06b20e


Explanation of makedumpfile:
  To shorten the size of the dumpfile and the time of creating the
  dumpfile, makedumpfile copies only the necessary pages for analysis
  to the dumpfile from /proc/vmcore. You can specify the kind of
  unnecessary pages with dump_level. If you want to shorten the size
  further, enable the compression of the page data.

Download:
  You can download the latest makedumpfile from the following URL.
  Details of the change are written on the git page of the following site.
  https://sourceforge.net/projects/makedumpfile/

Method of installation:
  You can compile the makedumpfile command as follows;
  1. "tar -zxvf makedumpfile-x.y.z.tar.gz"
  2. "cd makedumpfile-x.y.z"
  3. "make; make install"

Usage:
  makedumpfile [-c] [-E] [-d dump_level] [-x vmlinux] dump_mem dump_file

Example:
  If you want to exclude pages filled by zero, cache pages, user pages
  and free pages and to enable compression, please execute the following
  command.

  # makedumpfile -c -d 31 -x vmlinux /proc/vmcore dumpfile


Thanks
Atsushi Kumagai


From hanpt at linux.vnet.ibm.com  Mon Jan  9 05:02:30 2012
From: hanpt at linux.vnet.ibm.com (Han Pingtian)
Date: Mon, 9 Jan 2012 18:02:30 +0800
Subject: [PATCH] Correct magic varible of function name in debug code
Message-ID: <20120109100230.GA29322@hpt.localdomain>

The magic varible of function name should be uppercase.

Signed-off-by: Han Pingtian <hanpt at linux.vnet.ibm.com>
---
 kexec/crashdump.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kexec/crashdump.c b/kexec/crashdump.c
index e7ac42c..847d080 100644
--- a/kexec/crashdump.c
+++ b/kexec/crashdump.c
@@ -103,7 +103,7 @@ int get_crash_notes_per_cpu(int cpu, uint64_t *addr, uint64_t *len)
 	*addr = (uint64_t) temp;
 	*len = MAX_NOTE_BYTES; /* we should get this from the kernel instead */
 #ifdef DEBUG
-	printf("%s: crash_notes addr = %Lx\n", __function__, *addr);
+	printf("%s: crash_notes addr = %Lx\n", __FUNCTION__, *addr);
 #endif
 
 	fclose(fp);
-- 
1.7.6.5



From dyoung at redhat.com  Mon Jan  9 05:13:06 2012
From: dyoung at redhat.com (Dave Young)
Date: Mon, 09 Jan 2012 18:13:06 +0800
Subject: [PATCH] Correct magic varible of function name in debug code
In-Reply-To: <20120109100230.GA29322@hpt.localdomain>
References: <20120109100230.GA29322@hpt.localdomain>
Message-ID: <4F0ABDB2.9010200@redhat.com>

On 01/09/2012 06:02 PM, Han Pingtian wrote:

> The magic varible of function name should be uppercase.
> 
> Signed-off-by: Han Pingtian <hanpt at linux.vnet.ibm.com>
> ---
>  kexec/crashdump.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/kexec/crashdump.c b/kexec/crashdump.c
> index e7ac42c..847d080 100644
> --- a/kexec/crashdump.c
> +++ b/kexec/crashdump.c
> @@ -103,7 +103,7 @@ int get_crash_notes_per_cpu(int cpu, uint64_t *addr, uint64_t *len)
>  	*addr = (uint64_t) temp;
>  	*len = MAX_NOTE_BYTES; /* we should get this from the kernel instead */
>  #ifdef DEBUG
> -	printf("%s: crash_notes addr = %Lx\n", __function__, *addr);
> +	printf("%s: crash_notes addr = %Lx\n", __FUNCTION__, *addr);
>  #endif
>  
>  	fclose(fp);



Hi, Han

Glad to see you here.

I post a similar fix for this issue, please see:
http://lists.infradead.org/pipermail/kexec/2011-December/005889.html

-- 
Thanks
Dave


From hanpt at linux.vnet.ibm.com  Mon Jan  9 05:26:26 2012
From: hanpt at linux.vnet.ibm.com (Han Pingtian)
Date: Mon, 9 Jan 2012 18:26:26 +0800
Subject: [PATCH] Correct magic varible of function name in debug code
In-Reply-To: <4F0ABDB2.9010200@redhat.com>
References: <20120109100230.GA29322@hpt.localdomain>
 <4F0ABDB2.9010200@redhat.com>
Message-ID: <20120109102626.GB2563@hpt.localdomain>

On Mon, Jan 09, 2012 at 06:13:06PM +0800, Dave Young wrote:
> On 01/09/2012 06:02 PM, Han Pingtian wrote:
> 
> > The magic varible of function name should be uppercase.
> > 
> > Signed-off-by: Han Pingtian <hanpt at linux.vnet.ibm.com>
> > ---
> >  kexec/crashdump.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/kexec/crashdump.c b/kexec/crashdump.c
> > index e7ac42c..847d080 100644
> > --- a/kexec/crashdump.c
> > +++ b/kexec/crashdump.c
> > @@ -103,7 +103,7 @@ int get_crash_notes_per_cpu(int cpu, uint64_t *addr, uint64_t *len)
> >  	*addr = (uint64_t) temp;
> >  	*len = MAX_NOTE_BYTES; /* we should get this from the kernel instead */
> >  #ifdef DEBUG
> > -	printf("%s: crash_notes addr = %Lx\n", __function__, *addr);
> > +	printf("%s: crash_notes addr = %Lx\n", __FUNCTION__, *addr);
> >  #endif
> >  
> >  	fclose(fp);
> 
> 
> 
> Hi, Han
> 
> Glad to see you here.
> 
Thanks.
> I post a similar fix for this issue, please see:
> http://lists.infradead.org/pipermail/kexec/2011-December/005889.html
Great. I'm not very familiar with that, just want to point out there 
is a problem. Hope it can be fixed soon :) 
> 
> -- 
> Thanks
> Dave



From peter.chubb at nicta.com.au  Mon Jan  9 17:02:19 2012
From: peter.chubb at nicta.com.au (Peter Chubb)
Date: Tue, 10 Jan 2012 09:02:19 +1100
Subject: USB Host port inoperative after kexec on Beagleboard
Message-ID: <w4y5tgwn4k.wl%peter@chubb.wattle.id.au>


Hi Will,
   Thanks for the fixes to kexec for ARM that went into mainline this
   week.  Mostly things work now.

   One issue: the USB EHCI port on the (rev C2) beagleboard doesn't
   work after a kexec.  During boot after kexec, the host device is
   detected and initialised, but nothing plugged in works, even when
   everything was working corectly before the kexec.  Das U-boot
   must set up something that is then undone during the kexec reboot.

   I've traced all calls to clk_enable() and clk_disable(), and
   everything looks all right --- in particular I can't see 
   anything explicitly disabled during kexec that isn't reenabled
   during boot of the subsequent kernel.

   Voltages that I can measure look correct on the port.

   Do you have any suggestions as to what else could be wrong?
--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
http://www.ertos.nicta.com.au           ERTOS within National ICT Australia


From horms at verge.net.au  Mon Jan  9 17:40:47 2012
From: horms at verge.net.au (Simon Horman)
Date: Tue, 10 Jan 2012 07:40:47 +0900
Subject: [PATCH] Correct magic varible of function name in debug code
In-Reply-To: <20120109100230.GA29322@hpt.localdomain>
References: <20120109100230.GA29322@hpt.localdomain>
Message-ID: <20120109224047.GC28220@verge.net.au>

On Mon, Jan 09, 2012 at 06:02:30PM +0800, Han Pingtian wrote:
> The magic varible of function name should be uppercase.

Thanks, applied.


From will.deacon at arm.com  Mon Jan  9 17:54:03 2012
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 9 Jan 2012 22:54:03 +0000
Subject: USB Host port inoperative after kexec on Beagleboard
In-Reply-To: <w4wr90wmrx.wl%peter@chubb.wattle.id.au>
References: <w4wr90wmrx.wl%peter@chubb.wattle.id.au>
Message-ID: <20120109225403.GB23090@mudshark.cambridge.arm.com>

On Mon, Jan 09, 2012 at 10:09:54PM +0000, Peter Chubb wrote:
> 
> Hi Will,

Hi Peter [adding linux-arm-kernel],

>    Thanks for the fixes to kexec for ARM that went into mainline this
>    week.  Mostly things work now.

Great, that's good to hear!

>    One issue: the USB EHCI port on the (rev C2) beagleboard doesn't
>    work after a kexec.  During boot after kexec, the host device is
>    detected and initialised, but nothing plugged in works, even when
>    everything was working corectly before the kexec.  Das U-boot
>    must set up something that is then undone during the kexec reboot.

Ouch. Have you had a chance to look at the u-boot sources to see what it
does?

>    I've traced all calls to clk_enable() and clk_disable(), and
>    everything looks all right --- in particular I can't see 
>    anything explicitly disabled during kexec that isn't reenabled
>    during boot of the subsequent kernel.
> 
>    Voltages that I can measure look correct on the port.
> 
>    Do you have any suggestions as to what else could be wrong?

I'm afraid I'm not familiar with the Beagleboard, so I can't begin to guess.
Have you tried re-initialising the host controller in the new kernel
manually (perhaps my building the driver as a module and {un}loading it a
few times?). It could be that some hardware state persists across the kexec
and it just needs resetting.

Will


From will.deacon at arm.com  Mon Jan  9 18:03:31 2012
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 9 Jan 2012 23:03:31 +0000
Subject: USB Host port inoperative after kexec on Beagleboard
In-Reply-To: <20120109225403.GB23090@mudshark.cambridge.arm.com>
References: <w4wr90wmrx.wl%peter@chubb.wattle.id.au>
 <20120109225403.GB23090@mudshark.cambridge.arm.com>
Message-ID: <20120109230331.GA23308@mudshark.cambridge.arm.com>

On Mon, Jan 09, 2012 at 10:54:03PM +0000, Will Deacon wrote:
> On Mon, Jan 09, 2012 at 10:09:54PM +0000, Peter Chubb wrote:
> > 
> > Hi Will,
> 
> Hi Peter [adding linux-arm-kernel],

*Actually* adding linux-arm-kernel this time...

> 
> >    Thanks for the fixes to kexec for ARM that went into mainline this
> >    week.  Mostly things work now.
> 
> Great, that's good to hear!
> 
> >    One issue: the USB EHCI port on the (rev C2) beagleboard doesn't
> >    work after a kexec.  During boot after kexec, the host device is
> >    detected and initialised, but nothing plugged in works, even when
> >    everything was working corectly before the kexec.  Das U-boot
> >    must set up something that is then undone during the kexec reboot.
> 
> Ouch. Have you had a chance to look at the u-boot sources to see what it
> does?
> 
> >    I've traced all calls to clk_enable() and clk_disable(), and
> >    everything looks all right --- in particular I can't see 
> >    anything explicitly disabled during kexec that isn't reenabled
> >    during boot of the subsequent kernel.
> > 
> >    Voltages that I can measure look correct on the port.
> > 
> >    Do you have any suggestions as to what else could be wrong?
> 
> I'm afraid I'm not familiar with the Beagleboard, so I can't begin to guess.
> Have you tried re-initialising the host controller in the new kernel
> manually (perhaps my building the driver as a module and {un}loading it a
> few times?). It could be that some hardware state persists across the kexec
> and it just needs resetting.
> 
> Will


From joe.lorenz at plexxi.com  Mon Jan  9 19:18:20 2012
From: joe.lorenz at plexxi.com (Joe Lorenz)
Date: Mon, 09 Jan 2012 19:18:20 -0500
Subject: kexec x86_64 - Unhandled rela relocation: R_X86_64_PLT32
Message-ID: <4F0B83CC.6010007@plexxi.com>

Help needed, please:

Sandy Bridge.
2.6.27.21 kernel
x86_64 toolchain built from crosstools-ng.
Using relocatable bzImage as first kernel as well as crash kernel.

# cat /proc/cmdline
rw root=/dev/sda3 rootwait console=ttyS0,38400 crashkernel=128M at 16M

# kexec -l /boot/bzImage --reuse-cmdline
Unhandled rela relocation: R_X86_64_PLT32

Why??


I fooled around in kexec-elf-rel-x86_64.c and noticed there's no case for that 
r_type, so I added it as a fall-through to one of the existing ones. Then I got 
this:

# kexec -l /boot/bzImage --reuse-cmdline
Unhandled rela relocation: R_X86_64_GOTPCREL

Strange.
So I added that to the fallthrough, and then suddenly it seemed as if the crash 
kernel was getting loaded OK (no error messages anymore).

But then I tried:

# kexec -l /boot/bzImage --reuse-cmdline
# kexec -e
[  952.817842] md: stopping all md devices.
[  953.818808] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  953.961590] igb 0000:02:00.0: PME# enabled
[  953.962395] igb 0000:02:00.0: PME# enabled
[  953.976468] Starting new kernel

After several seconds pause, it ended up back at GRUB, which I didn't expect.

Any help would be most appreciated - thanks.



From mail at ck.org.ua  Tue Jan 10 10:13:53 2012
From: mail at ck.org.ua (Jennifer Indurayne)
Date: Tue, 10 Jan 2012 15:13:53 +0000
Subject: Permission Request for 'Kexec...'
Message-ID: <14dae93408c58da48504b62df6f3@google.com>

Hello,

I've known you website for ages, strictly speaking from year 2010. I found  
interesting your publication "Kexec" which I googled on  
http://horms.net/projects/kexec/#presentation ! I'd love to use it in a  
project I'm involved with called "Geek Science", so I'm seeking your  
permission for translation to Basque language. "Geek Science" is a  
freemium-model non-English language orientated startup with collection of  
scientific articles, personal notes etc. in several languages that is  
collaboratively edited by volunteers from around the world since 1999.  
Young and old, students and professors - even your neighbor could be a  
volunteer member.

If you agree, we will credit you for your work in the resulting  
translation's references by stating that it was based on your work and is  
used with your permission, and by mentioning the name of my project "Geek  
Science" back to:
http://horms.net/projects/kexec/#presentation

Thank you for your time and patience.
I look forward to your response next week.

---
Best wishes for 2012,
Jennifer Indurayne
San Sebasti?n, Spain
(GMT +2)
Translation for Education FAQ - http://goo.gl/uE2RH

From jy0922.shim at samsung.com  Wed Jan 11 03:35:41 2012
From: jy0922.shim at samsung.com (Joonyoung Shim)
Date: Wed, 11 Jan 2012 17:35:41 +0900
Subject: ARM kexec SMP problem using exynos4210
Message-ID: <4F0D49DD.80305@samsung.com>

Hi,

I have tested kexec to Nuri board using Exynos4210(Dual-core ARM
Cortex-A9) on the latest mainline kernel but i am facing one problem.

The kernel enabled SMP, kernel_kexec() calls machine_shutdown to stop
all cpus except current cpu and jumps to the new kernel but the kernel
is hanged soon.

I used cpu_down(1) to make disabled cpu1 instead of smp_send_stop of
machine_shutdown and it is booted successfully to new kernel.

Any ideas?

Thanks.


From jy0922.shim at samsung.com  Wed Jan 11 03:45:47 2012
From: jy0922.shim at samsung.com (Joonyoung Shim)
Date: Wed, 11 Jan 2012 17:45:47 +0900
Subject: ARM kexec SMP problem using exynos4210
Message-ID: <4F0D4C3B.80208@samsung.com>

Hi,

I have tested kexec to Nuri board using Exynos4210(Dual-core ARM
Cortex-A9) on the latest mainline kernel but i am facing one problem.

The kernel enabled SMP, kernel_kexec() calls machine_shutdown to stop
all cpus except current cpu and jumps to the new kernel but the kernel
is hanged soon.

I used cpu_down(1) to make disabled cpu1 instead of smp_send_stop of
machine_shutdown and it is booted successfully to new kernel.

Any ideas?

Thanks.


From will.deacon at arm.com  Wed Jan 11 05:06:23 2012
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 11 Jan 2012 10:06:23 +0000
Subject: ARM kexec SMP problem using exynos4210
In-Reply-To: <4F0D49DD.80305@samsung.com>
References: <4F0D49DD.80305@samsung.com>
Message-ID: <20120111100623.GA27887@mudshark.cambridge.arm.com>

On Wed, Jan 11, 2012 at 08:35:41AM +0000, Joonyoung Shim wrote:
> Hi,

Hello [adding linux-arm-kernel],

> I have tested kexec to Nuri board using Exynos4210(Dual-core ARM
> Cortex-A9) on the latest mainline kernel but i am facing one problem.
> 
> The kernel enabled SMP, kernel_kexec() calls machine_shutdown to stop
> all cpus except current cpu and jumps to the new kernel but the kernel
> is hanged soon.
> 
> I used cpu_down(1) to make disabled cpu1 instead of smp_send_stop of
> machine_shutdown and it is booted successfully to new kernel.
> 
> Any ideas?

I suspect that the secondary CPUs are not being parked correctly in the first
kernel. For this, you need to implement platform_cpu_kill for your platform.

Given that exynos just does:

int platform_cpu_kill(unsigned int cpu)
{
	return 1;
}

then I'm not surprised it doesn't work. Try adding something in there which puts
the CPU into a state where it can be booted by the next kernel.

I considered adding a purely software mechanism for doing this (in fact, I
prototyped something up on vexpress) but after discussions with some board
maintainers it became clear that most SMP SoCs have hardware assists for
hotplug, and the software approach is really only need for things like the
ARM development boards.

Will


From jy0922.shim at samsung.com  Wed Jan 11 05:23:18 2012
From: jy0922.shim at samsung.com (Joonyoung Shim)
Date: Wed, 11 Jan 2012 19:23:18 +0900
Subject: ARM kexec SMP problem using exynos4210
In-Reply-To: <20120111100623.GA27887@mudshark.cambridge.arm.com>
References: <4F0D49DD.80305@samsung.com>
 <20120111100623.GA27887@mudshark.cambridge.arm.com>
Message-ID: <4F0D6316.4090800@samsung.com>

On 01/11/2012 07:06 PM, Will Deacon wrote:
> On Wed, Jan 11, 2012 at 08:35:41AM +0000, Joonyoung Shim wrote:
>> Hi,
> Hello [adding linux-arm-kernel],
>
>> I have tested kexec to Nuri board using Exynos4210(Dual-core ARM
>> Cortex-A9) on the latest mainline kernel but i am facing one problem.
>>
>> The kernel enabled SMP, kernel_kexec() calls machine_shutdown to stop
>> all cpus except current cpu and jumps to the new kernel but the kernel
>> is hanged soon.
>>
>> I used cpu_down(1) to make disabled cpu1 instead of smp_send_stop of
>> machine_shutdown and it is booted successfully to new kernel.
>>
>> Any ideas?
> I suspect that the secondary CPUs are not being parked correctly in the first
> kernel. For this, you need to implement platform_cpu_kill for your platform.
>
> Given that exynos just does:
>
> int platform_cpu_kill(unsigned int cpu)
> {
> 	return 1;
> }
>
> then I'm not surprised it doesn't work. Try adding something in there which puts
> the CPU into a state where it can be booted by the next kernel.
Thanks, i will try it.

One more question, generally boot cpu is first cpu(cpu0). If current
cpu is secondary cpu(cpu1), smp_send_stop of machine_shutdown will stop
first cpu and next kernel will try to boot on secondary cpu. Is it
possible?

> I considered adding a purely software mechanism for doing this (in fact, I
> prototyped something up on vexpress) but after discussions with some board
> maintainers it became clear that most SMP SoCs have hardware assists for
> hotplug, and the software approach is really only need for things like the
> ARM development boards.
>
> Will
>


From will.deacon at arm.com  Wed Jan 11 06:03:20 2012
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 11 Jan 2012 11:03:20 +0000
Subject: ARM kexec SMP problem using exynos4210
In-Reply-To: <4F0D6316.4090800@samsung.com>
References: <4F0D49DD.80305@samsung.com>
 <20120111100623.GA27887@mudshark.cambridge.arm.com>
 <4F0D6316.4090800@samsung.com>
Message-ID: <20120111110319.GB27887@mudshark.cambridge.arm.com>

On Wed, Jan 11, 2012 at 10:23:18AM +0000, Joonyoung Shim wrote:
> One more question, generally boot cpu is first cpu(cpu0). If current
> cpu is secondary cpu(cpu1), smp_send_stop of machine_shutdown will stop
> first cpu and next kernel will try to boot on secondary cpu. Is it
> possible?

I added the cpu_logical_map stuff for this, so the kernel can handle it.
That said, your platform may have restrictions about the boot CPU so if it
doesn't work, you'll need to taskset the kexec command to CPU 0.

Will


From holzheu at linux.vnet.ibm.com  Wed Jan 11 06:30:12 2012
From: holzheu at linux.vnet.ibm.com (Michael Holzheu)
Date: Wed, 11 Jan 2012 12:30:12 +0100
Subject: [PATCH] kdump: Define KEXEC_NOTE_BYTES arch specific for s390x
Message-ID: <1326281412.2819.3.camel@br98xy6r>

From: Michael Holzheu <holzheu at linux.vnet.ibm.com>

kdump only allocates memory for the prstatus ELF note. For s390x,
besides of prstatus multiple ELF notes for various different register
types are stored. Therefore the currently allocated memory is not
sufficient. With this patch the KEXEC_NOTE_BYTES macro can be
defined by architecture code and for s390x it is set to the correct
size now.

Signed-off-by: Michael Holzheu <holzheu at linux.vnet.ibm.com>
---
 arch/s390/include/asm/kexec.h |   18 ++++++++++++++++++
 include/linux/kexec.h         |    2 ++
 2 files changed, 20 insertions(+)

--- a/arch/s390/include/asm/kexec.h
+++ b/arch/s390/include/asm/kexec.h
@@ -42,6 +42,24 @@
 /* The native architecture */
 #define KEXEC_ARCH KEXEC_ARCH_S390
 
+/*
+ * Size for s390x ELF notes per CPU
+ *
+ * Seven notes plus zero note at the end: prstatus, fpregset, timer,
+ * tod_cmp, tod_reg, control regs, and prefix
+ */
+#define KEXEC_NOTE_BYTES \
+	(ALIGN(sizeof(struct elf_note), 4) * 8 + \
+	 ALIGN(sizeof("CORE"), 4) * 7 + \
+	 ALIGN(sizeof(struct elf_prstatus), 4) + \
+	 ALIGN(sizeof(elf_fpregset_t), 4) + \
+	 ALIGN(sizeof(u64), 4) + \
+	 ALIGN(sizeof(u64), 4) + \
+	 ALIGN(sizeof(u32), 4) + \
+	 ALIGN(sizeof(u64) * 16, 4) + \
+	 ALIGN(sizeof(u32), 4) \
+	)
+
 /* Provide a dummy definition to avoid build failures. */
 static inline void crash_setup_regs(struct pt_regs *newregs,
 					struct pt_regs *oldregs) { }
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -50,9 +50,11 @@
  * note header.  For kdump, the code in vmcore.c runs in the context
  * of the second kernel to combine them into one note.
  */
+#ifndef KEXEC_NOTE_BYTES
 #define KEXEC_NOTE_BYTES ( (KEXEC_NOTE_HEAD_BYTES * 2) +		\
 			    KEXEC_CORE_NOTE_NAME_BYTES +		\
 			    KEXEC_CORE_NOTE_DESC_BYTES )
+#endif
 
 /*
  * This structure is used to hold the arguments that are used when loading




From B29882 at freescale.com  Wed Jan 11 12:20:43 2012
From: B29882 at freescale.com (McClintock Matthew-B29882)
Date: Wed, 11 Jan 2012 17:20:43 +0000
Subject: ARM kexec SMP problem using exynos4210
In-Reply-To: <20120111110319.GB27887@mudshark.cambridge.arm.com>
References: <4F0D49DD.80305@samsung.com>
 <20120111100623.GA27887@mudshark.cambridge.arm.com>
 <4F0D6316.4090800@samsung.com>
 <20120111110319.GB27887@mudshark.cambridge.arm.com>
Message-ID: <CAEsOVNfWdHfy3XinAd836RqUpj6hF+7B8Af-3+vX14XuDV1niQ@mail.gmail.com>

On Wed, Jan 11, 2012 at 5:03 AM, Will Deacon <will.deacon at arm.com> wrote:
> On Wed, Jan 11, 2012 at 10:23:18AM +0000, Joonyoung Shim wrote:
>> One more question, generally boot cpu is first cpu(cpu0). If current
>> cpu is secondary cpu(cpu1), smp_send_stop of machine_shutdown will stop
>> first cpu and next kernel will try to boot on secondary cpu. Is it
>> possible?
>
> I added the cpu_logical_map stuff for this, so the kernel can handle it.
> That said, your platform may have restrictions about the boot CPU so if it
> doesn't work, you'll need to taskset the kexec command to CPU 0.

Would this negatively effect kdump though where you might not be able
to switch back to cpu0? I think It's best to be able to boot on any
core.

-M


From will.deacon at arm.com  Wed Jan 11 12:42:06 2012
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 11 Jan 2012 17:42:06 +0000
Subject: ARM kexec SMP problem using exynos4210
In-Reply-To: <CAEsOVNfWdHfy3XinAd836RqUpj6hF+7B8Af-3+vX14XuDV1niQ@mail.gmail.com>
References: <4F0D49DD.80305@samsung.com>
 <20120111100623.GA27887@mudshark.cambridge.arm.com>
 <4F0D6316.4090800@samsung.com>
 <20120111110319.GB27887@mudshark.cambridge.arm.com>
 <CAEsOVNfWdHfy3XinAd836RqUpj6hF+7B8Af-3+vX14XuDV1niQ@mail.gmail.com>
Message-ID: <20120111174206.GD29015@mudshark.cambridge.arm.com>

On Wed, Jan 11, 2012 at 05:20:43PM +0000, McClintock Matthew-B29882 wrote:
> On Wed, Jan 11, 2012 at 5:03 AM, Will Deacon <will.deacon at arm.com> wrote:
> > On Wed, Jan 11, 2012 at 10:23:18AM +0000, Joonyoung Shim wrote:
> >> One more question, generally boot cpu is first cpu(cpu0). If current
> >> cpu is secondary cpu(cpu1), smp_send_stop of machine_shutdown will stop
> >> first cpu and next kernel will try to boot on secondary cpu. Is it
> >> possible?
> >
> > I added the cpu_logical_map stuff for this, so the kernel can handle it.
> > That said, your platform may have restrictions about the boot CPU so if it
> > doesn't work, you'll need to taskset the kexec command to CPU 0.
> 
> Would this negatively effect kdump though where you might not be able
> to switch back to cpu0? I think It's best to be able to boot on any
> core.

Ideally, we would boot on any core. That's what the logical map is for. The
problem is that you may have hardware restrictions that prevent this (for
example, the secure monitor on OMAP4 is, I believe, only present on CPU 0).

Will


From horms at verge.net.au  Wed Jan 11 15:45:39 2012
From: horms at verge.net.au (Simon Horman)
Date: Thu, 12 Jan 2012 05:45:39 +0900
Subject: [PATCH] kdump: Define KEXEC_NOTE_BYTES arch specific for s390x
In-Reply-To: <1326281412.2819.3.camel@br98xy6r>
References: <1326281412.2819.3.camel@br98xy6r>
Message-ID: <20120111204539.GB23752@verge.net.au>

On Wed, Jan 11, 2012 at 12:30:12PM +0100, Michael Holzheu wrote:
> From: Michael Holzheu <holzheu at linux.vnet.ibm.com>
> 
> kdump only allocates memory for the prstatus ELF note. For s390x,
> besides of prstatus multiple ELF notes for various different register
> types are stored. Therefore the currently allocated memory is not
> sufficient. With this patch the KEXEC_NOTE_BYTES macro can be
> defined by architecture code and for s390x it is set to the correct
> size now.
> 
> Signed-off-by: Michael Holzheu <holzheu at linux.vnet.ibm.com>

This seems reasonable to me.

Reviewed-by: Simon Horman <horms at verge.net.au>


From kumagai-atsushi at mxc.nes.nec.co.jp  Thu Jan 12 03:16:06 2012
From: kumagai-atsushi at mxc.nes.nec.co.jp (Atsushi Kumagai)
Date: Thu, 12 Jan 2012 17:16:06 +0900
Subject: [Crash-utility] x86 remap allocator in kernel 3.0
In-Reply-To: <201201101914.33226.ptesarik@suse.cz>
References: <201201101914.33226.ptesarik@suse.cz>
Message-ID: <20120112171606.c8959bfb.kumagai-atsushi@mxc.nes.nec.co.jp>

Hello Petr,

On Tue, 10 Jan 2012 19:14:32 +0100
Petr Tesarik <ptesarik at suse.cz> wrote:

> Ken'ichi Ohmichi, please note that makedumpfile is also affected by this 
> deficiency. On my test system, it will fail to produce any output if I set 
> dump level to anything greater than zero:
> 
> makedumpfile -c -d 31 -x vmlinux-3.0.13-0.5-pae.debug vmcore kdump.31
> readmem: Can't convert a physical address(34a012b4) to offset.
> readmem: type_addr: 0, addr:f4a012b4, size:4
> get_mm_discontigmem: Can't get node_start_pfn.
> 
> makedumpfile Failed.
> 
> However, fixing this for makedumpfile is harder, and it will most likely 
> require a few more lines in VMCOREINFO, because debug symbols may not be 
> available at dump time, and I can't see any alternative method to locate the 
> remapped regions.

Thank you for your indication.

Could you send me your kernel configuration so that I can reproduce the issue ?

Thanks
Atsushi Kumagai


From ptesarik at suse.cz  Thu Jan 12 05:40:08 2012
From: ptesarik at suse.cz (Petr Tesarik)
Date: Thu, 12 Jan 2012 11:40:08 +0100
Subject: [Crash-utility] x86 remap allocator in kernel 3.0
In-Reply-To: <20120112171606.c8959bfb.kumagai-atsushi@mxc.nes.nec.co.jp>
References: <201201101914.33226.ptesarik@suse.cz>
 <20120112171606.c8959bfb.kumagai-atsushi@mxc.nes.nec.co.jp>
Message-ID: <201201121140.09221.ptesarik@suse.cz>

Dne ?t 12. ledna 2012 09:16:06 Atsushi Kumagai napsal(a):
> Hello Petr,
> 
> On Tue, 10 Jan 2012 19:14:32 +0100
> 
> Petr Tesarik <ptesarik at suse.cz> wrote:
> > Ken'ichi Ohmichi, please note that makedumpfile is also affected by this
> > deficiency. On my test system, it will fail to produce any output if I
> > set dump level to anything greater than zero:
> > 
> > makedumpfile -c -d 31 -x vmlinux-3.0.13-0.5-pae.debug vmcore kdump.31
> > readmem: Can't convert a physical address(34a012b4) to offset.
> > readmem: type_addr: 0, addr:f4a012b4, size:4
> > get_mm_discontigmem: Can't get node_start_pfn.
> > 
> > makedumpfile Failed.
> > 
> > However, fixing this for makedumpfile is harder, and it will most likely
> > require a few more lines in VMCOREINFO, because debug symbols may not be
> > available at dump time, and I can't see any alternative method to locate
> > the remapped regions.
> 
> Thank you for your indication.
> 
> Could you send me your kernel configuration so that I can reproduce the
> issue ?

Attached. The most important settings are:

CONFIG_X86_32=y
CONFIG_DISCONTIGMEM_MANUAL=y

This also depends on CONFIG_NUMA=y

FYI my test system runs 3.0.15 (because that's used for SLES11 SP2), but the 
same issue also exists in any later version.

Petr Tesarik
SUSE Linux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config
Type: text/x-mpsub
Size: 131629 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/kexec/attachments/20120112/cc301c86/attachment-0001.bin>

From holzheu at linux.vnet.ibm.com  Thu Jan 12 10:12:34 2012
From: holzheu at linux.vnet.ibm.com (Michael Holzheu)
Date: Thu, 12 Jan 2012 16:12:34 +0100
Subject: [PATCH] makedumpfile: Compile fix
Message-ID: <1326381154.2729.1.camel@br98xy6r>

From: Michael Holzheu <holzheu at linux.vnet.ibm.com>

When compiling makedumpfile git head or 1.4.1 on s390x, I get the following
gcc error:

 # gcc -g -O2 -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
 -D_LARGEFILE64_SOURCE -DVERSION='"1.4.1"' -DRELEASE_DATE='"6 January 2012"'
 -D__s390__  print_info.o dwarf_info.o elf_info.o erase_info.o sadump_info.o
 arch/arm.o arch/x86.o arch/x86_64.o arch/ia64.o arch/ppc64.o arch/s390x.o -o
 makedumpfile makedumpfile.c -static -ldw -lbz2 -lebl -ldl -lelf -lz
 In file included from makedumpfile.c:21:0:
 sadump_info.h:86:1: error: expected identifier or '(' before '{' token
 sadump_info.h:85:19: warning: 'sadump_num_online_cpus' used but never defined

The attached patch fixes this problem.

Signed-off-by: Michael Holzheu <holzheu at linux.vnet.ibm.com>
---
 sadump_info.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sadump_info.h
+++ b/sadump_info.h
@@ -82,7 +82,7 @@ static inline int sadump_initialize_bitm
 	return FALSE;
 }
 
-static inline int sadump_num_online_cpus(void);
+static inline int sadump_num_online_cpus(void)
 {
 	return 0;
 }




From tachibana at mxm.nes.nec.co.jp  Thu Jan 12 21:27:27 2012
From: tachibana at mxm.nes.nec.co.jp (tachibana at mxm.nes.nec.co.jp)
Date: Fri, 13 Jan 2012 11:27:27 +0900
Subject: [PATCH] makedumpfile: Compile fix
In-Reply-To: <1326381154.2729.1.camel@br98xy6r>
References: <1326381154.2729.1.camel@br98xy6r>
Message-ID: <20120113112727tachibana@mail.jp.nec.com>

Hi Michael,

On 2012/01/12 16:12:34 +0100, Michael Holzheu <holzheu at linux.vnet.ibm.com> wrote:
> From: Michael Holzheu <holzheu at linux.vnet.ibm.com>
> 
> When compiling makedumpfile git head or 1.4.1 on s390x, I get the following
> gcc error:

Thank you for the fix and sorry for our insufficient tests.
We will release a fixed version next week.

Thanks.
tachibana


> 
>  # gcc -g -O2 -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
>  -D_LARGEFILE64_SOURCE -DVERSION='"1.4.1"' -DRELEASE_DATE='"6 January 2012"'
>  -D__s390__  print_info.o dwarf_info.o elf_info.o erase_info.o sadump_info.o
>  arch/arm.o arch/x86.o arch/x86_64.o arch/ia64.o arch/ppc64.o arch/s390x.o -o
>  makedumpfile makedumpfile.c -static -ldw -lbz2 -lebl -ldl -lelf -lz
>  In file included from makedumpfile.c:21:0:
>  sadump_info.h:86:1: error: expected identifier or '(' before '{' token
>  sadump_info.h:85:19: warning: 'sadump_num_online_cpus' used but never defined
> 
> The attached patch fixes this problem.
> 
> Signed-off-by: Michael Holzheu <holzheu at linux.vnet.ibm.com>
> ---
>  sadump_info.h |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/sadump_info.h
> +++ b/sadump_info.h
> @@ -82,7 +82,7 @@ static inline int sadump_initialize_bitm
>  	return FALSE;
>  }
>  
> -static inline int sadump_num_online_cpus(void);
> +static inline int sadump_num_online_cpus(void)
>  {
>  	return 0;
>  }
> 
> 
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec


From tachibana at mxm.nes.nec.co.jp  Thu Jan 12 22:22:50 2012
From: tachibana at mxm.nes.nec.co.jp (tachibana at mxm.nes.nec.co.jp)
Date: Fri, 13 Jan 2012 12:22:50 +0900
Subject: [Crash-utility] x86 remap allocator in kernel 3.0
In-Reply-To: <201201121140.09221.ptesarik@suse.cz>
References: <201201121140.09221.ptesarik@suse.cz>
Message-ID: <20120113122250tachibana@mail.jp.nec.com>

Hi Petr,

On 2012/01/12 11:40:08 +0100, Petr Tesarik <ptesarik at suse.cz> wrote:
> Dne ?t 12. ledna 2012 09:16:06 Atsushi Kumagai napsal(a):
> > Hello Petr,
> > 
> > On Tue, 10 Jan 2012 19:14:32 +0100
> > 
> > Petr Tesarik <ptesarik at suse.cz> wrote:
> > > Ken'ichi Ohmichi, please note that makedumpfile is also affected by this
> > > deficiency. On my test system, it will fail to produce any output if I
> > > set dump level to anything greater than zero:
> > > 
> > > makedumpfile -c -d 31 -x vmlinux-3.0.13-0.5-pae.debug vmcore kdump.31
> > > readmem: Can't convert a physical address(34a012b4) to offset.
> > > readmem: type_addr: 0, addr:f4a012b4, size:4
> > > get_mm_discontigmem: Can't get node_start_pfn.
> > > 
> > > makedumpfile Failed.
> > > 
> > > However, fixing this for makedumpfile is harder, and it will most likely
> > > require a few more lines in VMCOREINFO, because debug symbols may not be
> > > available at dump time, and I can't see any alternative method to locate
> > > the remapped regions.
> > 
> > Thank you for your indication.
> > 
> > Could you send me your kernel configuration so that I can reproduce the
> > issue ?
> 
> Attached. The most important settings are:
> 
> CONFIG_X86_32=y
> CONFIG_DISCONTIGMEM_MANUAL=y
> 
> This also depends on CONFIG_NUMA=y
> 
> FYI my test system runs 3.0.15 (because that's used for SLES11 SP2), but the 
> same issue also exists in any later version.
> 
> Petr Tesarik
> SUSE Linux

Thank you for the config. I will fix makedumpfile. However it will take time 
to solve various issues because I've never run makedumpfile on 3.0.X.

Thanks.
tachibana

---------------------------------------------------------------------

> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
> 


From suzuki at in.ibm.com  Fri Jan 13 01:57:50 2012
From: suzuki at in.ibm.com (Suzuki K. Poulose)
Date: Fri, 13 Jan 2012 12:27:50 +0530
Subject: [PATCH][makedumpfile] Fix compilation error in sadump_info.h
Message-ID: <20120113065726.13214.80477.stgit@suzukikp.in.ibm.com>

While compiling the makedumpfile-1.4.1 I got the following error :

In file included from makedumpfile.c:21:
sadump_info.h:86: error: expected identifier or ?(? before ?{? token


This patch fixes the compilation error in sadump_info.h

Signed-off-by: Suzuki K. Poulose <suzuki at in.ibm.com>
---

 sadump_info.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/sadump_info.h b/sadump_info.h
index 1f74ee5..c4824be 100644
--- a/sadump_info.h
+++ b/sadump_info.h
@@ -82,7 +82,7 @@ static inline int sadump_initialize_bitmap_memory(void)
 	return FALSE;
 }
 
-static inline int sadump_num_online_cpus(void);
+static inline int sadump_num_online_cpus(void)
 {
 	return 0;
 }



From tachibana at mxm.nes.nec.co.jp  Fri Jan 13 03:08:46 2012
From: tachibana at mxm.nes.nec.co.jp (tachibana at mxm.nes.nec.co.jp)
Date: Fri, 13 Jan 2012 17:08:46 +0900
Subject: [PATCH][makedumpfile] Fix compilation error in sadump_info.h
In-Reply-To: <20120113065726.13214.80477.stgit@suzukikp.in.ibm.com>
References: <20120113065726.13214.80477.stgit@suzukikp.in.ibm.com>
Message-ID: <20120113170846tachibana@mail.jp.nec.com>

Hi Poulose,

On 2012/01/13 12:27:50 +0530, "Suzuki K. Poulose" <suzuki at in.ibm.com> wrote:
> While compiling the makedumpfile-1.4.1 I got the following error :

Thank you for the fix.
I got the same report from Michael Holzheu.

<http://lists.infradead.org/pipermail/kexec/2012-January/005940.html>


Thanks.
tachibana

> 
> In file included from makedumpfile.c:21:
> sadump_info.h:86: error: expected identifier or ?(? before ?{? token
> 
> 
> This patch fixes the compilation error in sadump_info.h
> 
> Signed-off-by: Suzuki K. Poulose <suzuki at in.ibm.com>
> ---
> 
>  sadump_info.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/sadump_info.h b/sadump_info.h
> index 1f74ee5..c4824be 100644
> --- a/sadump_info.h
> +++ b/sadump_info.h
> @@ -82,7 +82,7 @@ static inline int sadump_initialize_bitmap_memory(void)
>  	return FALSE;
>  }
>  
> -static inline int sadump_num_online_cpus(void);
> +static inline int sadump_num_online_cpus(void)
>  {
>  	return 0;
>  }
> 


From ptesarik at suse.cz  Fri Jan 13 07:06:56 2012
From: ptesarik at suse.cz (Petr Tesarik)
Date: Fri, 13 Jan 2012 13:06:56 +0100
Subject: [Crash-utility] x86 remap allocator in kernel 3.0
In-Reply-To: <20120113122250tachibana@mail.jp.nec.com>
References: <201201121140.09221.ptesarik@suse.cz>
 <20120113122250tachibana@mail.jp.nec.com>
Message-ID: <201201131306.56772.ptesarik@suse.cz>

Dne P? 13. ledna 2012 04:22:50 tachibana at mxm.nes.nec.co.jp napsal(a):
> Hi Petr,
> 
> On 2012/01/12 11:40:08 +0100, Petr Tesarik <ptesarik at suse.cz> wrote:
> > Dne ?t 12. ledna 2012 09:16:06 Atsushi Kumagai napsal(a):
> > > Hello Petr,
> > > 
> > > On Tue, 10 Jan 2012 19:14:32 +0100
> > > 
> > > Petr Tesarik <ptesarik at suse.cz> wrote:
> > > > Ken'ichi Ohmichi, please note that makedumpfile is also affected by
> > > > this deficiency. On my test system, it will fail to produce any
> > > > output if I set dump level to anything greater than zero:
> > > > 
> > > > makedumpfile -c -d 31 -x vmlinux-3.0.13-0.5-pae.debug vmcore kdump.31
> > > > readmem: Can't convert a physical address(34a012b4) to offset.
> > > > readmem: type_addr: 0, addr:f4a012b4, size:4
> > > > get_mm_discontigmem: Can't get node_start_pfn.
> > > > 
> > > > makedumpfile Failed.
> > > > 
> > > > However, fixing this for makedumpfile is harder, and it will most
> > > > likely require a few more lines in VMCOREINFO, because debug symbols
> > > > may not be available at dump time, and I can't see any alternative
> > > > method to locate the remapped regions.
> > > 
> > > Thank you for your indication.
> > > 
> > > Could you send me your kernel configuration so that I can reproduce the
> > > issue ?
> > 
> > Attached. The most important settings are:
> > 
> > CONFIG_X86_32=y
> > CONFIG_DISCONTIGMEM_MANUAL=y
> > 
> > This also depends on CONFIG_NUMA=y
> > 
> > FYI my test system runs 3.0.15 (because that's used for SLES11 SP2), but
> > the same issue also exists in any later version.
> > 
> > Petr Tesarik
> > SUSE Linux
> 
> Thank you for the config. I will fix makedumpfile. However it will take
> time to solve various issues because I've never run makedumpfile on 3.0.X.

(crash-utility ML removed from CC.)

I should add something here. I wondered why makedumpfile didn't failed while 
saving /proc/vmcore. After some futile attempts to recreate the failure, I 
realized that the ELF dump above had been saved with "makedumpfile -d 1" by 
mistake. Now, since the remapped area was unused by the kernel, it was all 
zeroes, so makedumpfile created a hole in the ELF dump.

Under normal conditions, it won't fail to read node_start_pfn, but it will 
incorrectly read it as zero, so no filtering will take place.

Petr Tesarik
SUSE Linux


From ptesarik at suse.cz  Fri Jan 13 09:39:03 2012
From: ptesarik at suse.cz (Petr Tesarik)
Date: Fri, 13 Jan 2012 15:39:03 +0100
Subject: x86 remap allocator in kernel 3.0
In-Reply-To: <20120113122250tachibana@mail.jp.nec.com>
References: <201201121140.09221.ptesarik@suse.cz>
 <20120113122250tachibana@mail.jp.nec.com>
Message-ID: <201201131539.03316.ptesarik@suse.cz>

Dne Pa 13. ledna 2012 04:22:50 tachibana at mxm.nes.nec.co.jp napsal(a):
> Hi Petr,
> 
> On 2012/01/12 11:40:08 +0100, Petr Tesarik <ptesarik at suse.cz> wrote:
> > Dne ?t 12. ledna 2012 09:16:06 Atsushi Kumagai napsal(a):
> > > Hello Petr,
> > > 
> > > On Tue, 10 Jan 2012 19:14:32 +0100
> > > 
> > > Petr Tesarik <ptesarik at suse.cz> wrote:
> > > > Ken'ichi Ohmichi, please note that makedumpfile is also affected by
> > > > this deficiency. On my test system, it will fail to produce any
> > > > output if I set dump level to anything greater than zero:
> > > > 
> > > > makedumpfile -c -d 31 -x vmlinux-3.0.13-0.5-pae.debug vmcore kdump.31
> > > > readmem: Can't convert a physical address(34a012b4) to offset.
> > > > readmem: type_addr: 0, addr:f4a012b4, size:4
> > > > get_mm_discontigmem: Can't get node_start_pfn.
> > > > 
> > > > makedumpfile Failed.
> > > > 
> > > > However, fixing this for makedumpfile is harder, and it will most
> > > > likely require a few more lines in VMCOREINFO, because debug symbols
> > > > may not be available at dump time, and I can't see any alternative
> > > > method to locate the remapped regions.
> > > 
> > > Thank you for your indication.
> > > 
> > > Could you send me your kernel configuration so that I can reproduce the
> > > issue ?
> > 
> > Attached. The most important settings are:
> > 
> > CONFIG_X86_32=y
> > CONFIG_DISCONTIGMEM_MANUAL=y
> > 
> > This also depends on CONFIG_NUMA=y
> > 
> > FYI my test system runs 3.0.15 (because that's used for SLES11 SP2), but
> > the same issue also exists in any later version.
> > 
> > Petr Tesarik
> > SUSE Linux
> 
> Thank you for the config. I will fix makedumpfile. However it will take
> time to solve various issues because I've never run makedumpfile on 3.0.X.

This patch works for me, at least when using the "-x" command-line switch. To 
make it perfect, we'll also need an accompanying patch to the kernel to store 
the appropriate values in VMCOREINFO.

Signed-off-by: Petr Tesarik <ptesarik at suse.cz>

---
 arch/x86.c     |   65 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 makedumpfile.c |   16 ++++++++++++++
 makedumpfile.h |    4 +++
 3 files changed, 85 insertions(+)

--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -831,6 +831,9 @@ get_symbol_info(void)
 	if (SYMBOL(cpu_online_mask) == NOT_FOUND_SYMBOL)
 		SYMBOL_INIT(cpu_online_mask, "cpu_online_map");
 	SYMBOL_INIT(kexec_crash_image, "kexec_crash_image");
+	SYMBOL_INIT(node_remap_start_vaddr, "node_remap_start_vaddr");
+	SYMBOL_INIT(node_remap_end_vaddr, "node_remap_end_vaddr");
+	SYMBOL_INIT(node_remap_start_pfn, "node_remap_start_pfn");
 
 	if (SYMBOL(node_data) != NOT_FOUND_SYMBOL)
 		SYMBOL_ARRAY_TYPE_INIT(node_data, "node_data");
@@ -842,6 +845,9 @@ get_symbol_info(void)
 		SYMBOL_ARRAY_LENGTH_INIT(node_memblk, "node_memblk");
 	if (SYMBOL(__per_cpu_offset) != NOT_FOUND_SYMBOL)
 		SYMBOL_ARRAY_LENGTH_INIT(__per_cpu_offset, "__per_cpu_offset");
+	if (SYMBOL(node_remap_start_pfn) != NOT_FOUND_SYMBOL)
+		SYMBOL_ARRAY_LENGTH_INIT(node_remap_start_pfn,
+					"node_remap_start_pfn");
 
 	return TRUE;
 }
@@ -1290,6 +1296,9 @@ write_vmcoreinfo_data(void)
 	WRITE_SYMBOL("log_end", log_end);
 	WRITE_SYMBOL("max_pfn", max_pfn);
 	WRITE_SYMBOL("high_memory", high_memory);
+	WRITE_SYMBOL("node_remap_start_vaddr", node_remap_start_vaddr);
+	WRITE_SYMBOL("node_remap_end_vaddr", node_remap_end_vaddr);
+	WRITE_SYMBOL("node_remap_start_pfn", node_remap_start_pfn);
 
 	/*
 	 * write the structure size of 1st kernel
@@ -1341,6 +1350,9 @@ write_vmcoreinfo_data(void)
 		WRITE_ARRAY_LENGTH("mem_section", mem_section);
 	if (SYMBOL(node_memblk) != NOT_FOUND_SYMBOL)
 		WRITE_ARRAY_LENGTH("node_memblk", node_memblk);
+	if (SYMBOL(node_remap_start_pfn) != NOT_FOUND_SYMBOL)
+		WRITE_ARRAY_LENGTH("node_remap_start_pfn",
+				   node_remap_start_pfn);
 
 	WRITE_ARRAY_LENGTH("zone.free_area", zone.free_area);
 	WRITE_ARRAY_LENGTH("free_area.free_list", free_area.free_list);
@@ -1586,6 +1598,9 @@ read_vmcoreinfo(void)
 	READ_SYMBOL("log_end", log_end);
 	READ_SYMBOL("max_pfn", max_pfn);
 	READ_SYMBOL("high_memory", high_memory);
+	READ_SYMBOL("node_remap_start_vaddr", node_remap_start_vaddr);
+	READ_SYMBOL("node_remap_end_vaddr", node_remap_end_vaddr);
+	READ_SYMBOL("node_remap_start_pfn", node_remap_start_pfn);
 
 	READ_STRUCTURE_SIZE("page", page);
 	READ_STRUCTURE_SIZE("mem_section", mem_section);
@@ -1628,6 +1643,7 @@ read_vmcoreinfo(void)
 	READ_ARRAY_LENGTH("node_memblk", node_memblk);
 	READ_ARRAY_LENGTH("zone.free_area", zone.free_area);
 	READ_ARRAY_LENGTH("free_area.free_list", free_area.free_list);
+	READ_ARRAY_LENGTH("node_remap_start_pfn", node_remap_start_pfn);
 
 	READ_NUMBER("NR_FREE_PAGES", NR_FREE_PAGES);
 	READ_NUMBER("N_ONLINE", N_ONLINE);
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -961,6 +961,9 @@ struct symbol_table {
 	unsigned long long	log_buf_len;
 	unsigned long long	log_end;
 	unsigned long long	max_pfn;
+	unsigned long long	node_remap_start_vaddr;
+	unsigned long long	node_remap_end_vaddr;
+	unsigned long long	node_remap_start_pfn;
 
 	/*
 	 * for Xen extraction
@@ -1179,6 +1182,7 @@ struct array_table {
 	long	mem_section;
 	long	node_memblk;
 	long	__per_cpu_offset;
+	long	node_remap_start_pfn;
 
 	/*
 	 * Structure
--- a/arch/x86.c
+++ b/arch/x86.c
@@ -19,6 +19,53 @@
 #include "../elf_info.h"
 #include "../makedumpfile.h"
 
+static int max_numnodes;
+static unsigned long *remap_start_vaddr;
+static unsigned long *remap_end_vaddr;
+static unsigned long *remap_start_pfn;
+
+static int
+remap_init(void)
+{
+	int n;
+
+	if (SYMBOL(node_remap_start_vaddr) == NOT_FOUND_SYMBOL)
+		return TRUE;
+	if (SYMBOL(node_remap_end_vaddr) == NOT_FOUND_SYMBOL)
+		return TRUE;
+	if (SYMBOL(node_remap_start_pfn) == NOT_FOUND_SYMBOL)
+		return TRUE;
+	if (ARRAY_LENGTH(node_remap_start_pfn) == NOT_FOUND_STRUCTURE)
+		return TRUE;
+
+	n = ARRAY_LENGTH(node_remap_start_pfn);
+	remap_start_vaddr = calloc(3 * n, sizeof(unsigned long));
+	if (!remap_start_vaddr) {
+		ERRMSG("Can't allocate remap allocator info.\n");
+		return FALSE;
+	}
+	remap_end_vaddr = remap_start_vaddr + n;
+	remap_start_pfn = remap_end_vaddr + n;
+
+	if (!readmem(VADDR, SYMBOL(node_remap_start_vaddr), remap_start_vaddr,
+		     n * sizeof(unsigned long))) {
+		ERRMSG("Can't get node_remap_start_vaddr.\n");
+		return FALSE;
+	}
+	if (!readmem(VADDR, SYMBOL(node_remap_end_vaddr), remap_end_vaddr,
+		     n * sizeof(unsigned long))) {
+		ERRMSG("Can't get node_remap_end_vaddr.\n");
+		return FALSE;
+	}
+	if (!readmem(VADDR, SYMBOL(node_remap_start_pfn), remap_start_pfn,
+		     n * sizeof(unsigned long))) {
+		ERRMSG("Can't get node_remap_start_pfn.\n");
+		return FALSE;
+	}
+
+	max_numnodes = n;
+}
+
 int
 get_machdep_info_x86(void)
 {
@@ -48,6 +95,9 @@ get_machdep_info_x86(void)
 	info->kernel_start = SYMBOL(_stext) & ~KVBASE_MASK;
 	DEBUG_MSG("kernel_start : %lx\n", info->kernel_start);
 
+	if (!remap_init())
+		return FALSE;
+
 	/*
 	 * For the compatibility, makedumpfile should run without the symbol
 	 * vmlist and the offset of vm_struct.addr if they are not necessary.
@@ -90,6 +140,18 @@ get_versiondep_info_x86(void)
 }
 
 unsigned long long
+vtop_x86_remap(unsigned long vaddr)
+{
+	int i;
+	for (i = 0; i < max_numnodes; ++i)
+		if (vaddr >= remap_start_vaddr[i] &&
+		    vaddr < remap_end_vaddr[i])
+			return pfn_to_paddr(remap_start_pfn[i]) +
+				vaddr - remap_start_vaddr[i];
+	return NOT_PADDR;
+}
+
+unsigned long long
 vtop_x86_PAE(unsigned long vaddr)
 {
 	unsigned long long page_dir, pgd_pte, pmd_paddr, pmd_pte;
@@ -152,6 +214,9 @@ vaddr_to_paddr_x86(unsigned long vaddr)
 {
 	unsigned long long paddr;
 
+	if ((paddr = vtop_x86_remap(vaddr)) != NOT_PADDR)
+		return paddr;
+
 	if ((paddr = vaddr_to_paddr_general(vaddr)) != NOT_PADDR)
 		return paddr;
 


From horms at verge.net.au  Sun Jan 15 17:46:27 2012
From: horms at verge.net.au (Simon Horman)
Date: Mon, 16 Jan 2012 09:46:27 +1100
Subject: [ANNOUNCE] kexec-tools 2.0.3
Message-ID: <20120115224626.GA27180@verge.net.au>

Hi all,

I am happy to announce the release of kexec-tools 2.0.3.

The release can be downloaded from kernel.org:

	http://kernel.org/pub/linux/utils/kernel/kexec/kexec-tools-2.0.3.tar.xz
	http://kernel.org/pub/linux/utils/kernel/kexec/

I have also tagged it in git:

	git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git

kexec-tools is finally back on kernel.org after somewhat of a hiatus.



From kumagai-atsushi at mxc.nes.nec.co.jp  Mon Jan 16 03:07:47 2012
From: kumagai-atsushi at mxc.nes.nec.co.jp (Atsushi Kumagai)
Date: Mon, 16 Jan 2012 17:07:47 +0900
Subject: x86 remap allocator in kernel 3.0
In-Reply-To: <201201131539.03316.ptesarik@suse.cz>
References: <201201121140.09221.ptesarik@suse.cz>
 <20120113122250tachibana@mail.jp.nec.com>
 <201201131539.03316.ptesarik@suse.cz>
Message-ID: <20120116170747.d79ae1b7.kumagai-atsushi@mxc.nes.nec.co.jp>

Hi Petr,

On Fri, 13 Jan 2012 15:39:03 +0100
Petr Tesarik <ptesarik at suse.cz> wrote:

> Dne Pa 13. ledna 2012 04:22:50 tachibana at mxm.nes.nec.co.jp napsal(a):
> > Hi Petr,
> > 
> > On 2012/01/12 11:40:08 +0100, Petr Tesarik <ptesarik at suse.cz> wrote:
> > > Dne ?t 12. ledna 2012 09:16:06 Atsushi Kumagai napsal(a):
> > > > Hello Petr,
> > > > 
> > > > On Tue, 10 Jan 2012 19:14:32 +0100
> > > > 
> > > > Petr Tesarik <ptesarik at suse.cz> wrote:
> > > > > Ken'ichi Ohmichi, please note that makedumpfile is also affected by
> > > > > this deficiency. On my test system, it will fail to produce any
> > > > > output if I set dump level to anything greater than zero:
> > > > > 
> > > > > makedumpfile -c -d 31 -x vmlinux-3.0.13-0.5-pae.debug vmcore kdump.31
> > > > > readmem: Can't convert a physical address(34a012b4) to offset.
> > > > > readmem: type_addr: 0, addr:f4a012b4, size:4
> > > > > get_mm_discontigmem: Can't get node_start_pfn.
> > > > > 
> > > > > makedumpfile Failed.
> > > > > 
> > > > > However, fixing this for makedumpfile is harder, and it will most
> > > > > likely require a few more lines in VMCOREINFO, because debug symbols
> > > > > may not be available at dump time, and I can't see any alternative
> > > > > method to locate the remapped regions.
> > > > 
> > > > Thank you for your indication.
> > > > 
> > > > Could you send me your kernel configuration so that I can reproduce the
> > > > issue ?
> > > 
> > > Attached. The most important settings are:
> > > 
> > > CONFIG_X86_32=y
> > > CONFIG_DISCONTIGMEM_MANUAL=y
> > > 
> > > This also depends on CONFIG_NUMA=y
> > > 
> > > FYI my test system runs 3.0.15 (because that's used for SLES11 SP2), but
> > > the same issue also exists in any later version.
> > > 
> > > Petr Tesarik
> > > SUSE Linux
> > 
> > Thank you for the config. I will fix makedumpfile. However it will take
> > time to solve various issues because I've never run makedumpfile on 3.0.X.
> 
> This patch works for me, at least when using the "-x" command-line switch. To 
> make it perfect, we'll also need an accompanying patch to the kernel to store 
> the appropriate values in VMCOREINFO.
> 
> Signed-off-by: Petr Tesarik <ptesarik at suse.cz>

Thank you for the patch. I will review it.

Thanks
Atsushi Kumagai


From kumagai-atsushi at mxc.nes.nec.co.jp  Mon Jan 16 23:40:04 2012
From: kumagai-atsushi at mxc.nes.nec.co.jp (Atsushi Kumagai)
Date: Tue, 17 Jan 2012 13:40:04 +0900
Subject: [PATCH] makedumpfile: s390x: Auto-detect the correct
 MAX_PHYSMEM_BITSusedin vmcore being analyzed.
In-Reply-To: <20111221214809tachibana@mail.jp.nec.com>
References: <4EF1B019.3030201@linux.vnet.ibm.com>
 <20111221214809tachibana@mail.jp.nec.com>
Message-ID: <20120117134004.25264f9f.kumagai-atsushi@mxc.nes.nec.co.jp>

Hi Mahesh,

On Wed, 21 Dec 2011 21:48:09 +0900
tachibana at mxm.nes.nec.co.jp wrote:

> Hi Mahesh,
> 
> On 2011/12/21 15:38:25 +0530, Mahesh Jagannath Salgaonkar <mahesh at linux.vnet.ibm.com> wrote:
> > On 12/21/2011 11:41 AM, tachibana at mxm.nes.nec.co.jp wrote:
> > > Hi Mahesh,
> > > 
> > > Thank you for the patch.
> > > I will review it.
> > > However I have never dumped 1 terabyte or more data using makedumpfile.
> > > Has anyone ever dumped it successfully?
> > > 
> > 
> > I have seen makedumpfile successfully compressing vmcore generated on
> > system with 1TB memory.
> 
> Thank you for your information.

I will merge your patch with renaming macros as:

  _MAX_PHYSMEM_BITS_OLD  ->  _MAX_PHYSMEM_BITS_ORIG 
  _MAX_PHYSMEM_BITS_NEW	 ->  _MAX_PHYSMEM_BITS_3_3

So, attached patch queued for makedumpfile-1.4.2.

Thanks
Atsushi Kumagai


From: Mahesh Salgaonkar <mahesh at linux.vnet.ibm.com>

So far s390x kernel was using 42 bits for MAX_PHYSMEM_BITS that use to
support maximum of 4TB of memory. In order to support bigger systems,
the newer s390x kernel will now use 46 bits for MAX_PHYSMEM_BITS to support
maximum of 64TB of memory.

This patch auto-detects the correct value to use for MAX_PHYSMEM_BITS by
examining the mem_section array size from the vmcore being analyzed.

Signed-off-by: Mahesh Salgaonkar <mahesh at linux.vnet.ibm.com>

Rename _MAX_PHYSMEM_BITS_OLD to _MAX_PHYSMEM_BITS_ORIG
and _MAX_PHYSMEM_BITS_NEW to _MAX_PHYSMEM_BITS_3_3.

Signed-off-by: Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp>
---
 arch/s390x.c   |   27 ++++++++++++++++++++++++++-
 makedumpfile.h |    3 ++-
 2 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/arch/s390x.c b/arch/s390x.c
index 9237eaa..02b9e63 100644
--- a/arch/s390x.c
+++ b/arch/s390x.c
@@ -60,6 +60,28 @@
 #define pte_offset(x)		(pte_index(x) * sizeof(unsigned long))
 
 int
+set_s390x_max_physmem_bits(void)
+{
+	long array_len = ARRAY_LENGTH(mem_section);
+	/*
+	 * The older s390x kernels uses _MAX_PHYSMEM_BITS as 42 and the
+	 * newer kernels uses 46 bits.
+	 */
+
+	info->max_physmem_bits  = _MAX_PHYSMEM_BITS_ORIG ;
+	if ((array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT_EXTREME()))
+		|| (array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT())))
+		return TRUE;
+
+	info->max_physmem_bits  = _MAX_PHYSMEM_BITS_3_3;
+	if ((array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT_EXTREME()))
+		|| (array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT())))
+		return TRUE;
+
+	return FALSE;
+}
+
+int
 get_machdep_info_s390x(void)
 {
 	unsigned long vmalloc_start;
@@ -70,7 +92,10 @@ get_machdep_info_s390x(void)
 		flag_ignore_r_char = 1;
 
 	info->section_size_bits = _SECTION_SIZE_BITS;
-	info->max_physmem_bits  = _MAX_PHYSMEM_BITS;
+	if (!set_s390x_max_physmem_bits()) {
+		ERRMSG("Can't detect max_physmem_bits.\n");
+		return FALSE;
+	}
 	info->page_offset = __PAGE_OFFSET;
 
 	if (SYMBOL(_stext) == NOT_FOUND_SYMBOL) {
diff --git a/makedumpfile.h b/makedumpfile.h
index 4b4a58b..ebb8929 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -535,7 +535,8 @@ do { \
 #define KERNELBASE		(0)
 #define KVBASE			KERNELBASE
 #define _SECTION_SIZE_BITS	(28)
-#define _MAX_PHYSMEM_BITS	(42)
+#define _MAX_PHYSMEM_BITS_ORIG          (42)
+#define _MAX_PHYSMEM_BITS_3_3           (46)
 
 /* Bits in the segment/region table address-space-control-element */
 #define _ASCE_TYPE_MASK		0x0c
-- 
1.6.5.3


From xiyou.wangcong at gmail.com  Tue Jan 17 11:36:07 2012
From: xiyou.wangcong at gmail.com (Cong Wang)
Date: Wed, 18 Jan 2012 00:36:07 +0800
Subject: makedumpfile can't build on Fedora 16
Message-ID: <4F15A377.3090302@gmail.com>

Hello, Atsushi,

I can't build the latest makedumpfile on Fedora 16,

[wangcong at cr0]~/makedumpfile% make
...
gcc -g -O2 -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-D_LARGEFILE64_SOURCE -DVERSION='"1.4.1"' -DRELEASE_DATE='"6 January 
2012"' -D__x86_64__  print_info.o dwarf_info.o elf_info.o erase_info.o 
sadump_info.o arch/arm.o arch/x86.o arch/x86_64.o arch/ia64.o 
arch/ppc64.o arch/s390x.o -o makedumpfile makedumpfile.c -static -ldw 
-lbz2 -lebl -ldl -lelf -lz
makedumpfile.c: In function ?__exclude_unnecessary_pages?:
makedumpfile.c:3625:15: warning: variable ?_count? set but not used 
[-Wunused-but-set-variable]
/usr/bin/ld: cannot find -lbz2
/usr/bin/ld: cannot find -ldl
/usr/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
make: *** [makedumpfile] Error 1

[wangcong at cr0]~/makedumpfile% rpm -ql bzip2-libs
/lib64/libbz2.so.1
/lib64/libbz2.so.1.0.6
/usr/share/doc/bzip2-libs-1.0.6
/usr/share/doc/bzip2-libs-1.0.6/LICENSE

So, I don't know why ld can't find libbz2 and libc... Any hints?

Thanks!


From wency at cn.fujitsu.com  Tue Jan 17 19:35:24 2012
From: wency at cn.fujitsu.com (Wen Congyang)
Date: Wed, 18 Jan 2012 08:35:24 +0800
Subject: makedumpfile can't build on Fedora 16
In-Reply-To: <4F15A377.3090302@gmail.com>
References: <4F15A377.3090302@gmail.com>
Message-ID: <4F1613CC.9040405@cn.fujitsu.com>

At 01/18/2012 12:36 AM, Cong Wang Wrote:
> Hello, Atsushi,
> 
> I can't build the latest makedumpfile on Fedora 16,
> 
> [wangcong at cr0]~/makedumpfile% make
> ...
> gcc -g -O2 -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> -D_LARGEFILE64_SOURCE -DVERSION='"1.4.1"' -DRELEASE_DATE='"6 January
> 2012"' -D__x86_64__  print_info.o dwarf_info.o elf_info.o erase_info.o
> sadump_info.o arch/arm.o arch/x86.o arch/x86_64.o arch/ia64.o
> arch/ppc64.o arch/s390x.o -o makedumpfile makedumpfile.c -static -ldw
> -lbz2 -lebl -ldl -lelf -lz

The parameter has -static, so you need libc.a, libdw.a and ...
Or you can remove -static, but you should ensure that there are these
dynamic librarys in the second os.

Thanks
Wen Congyang

> makedumpfile.c: In function ?__exclude_unnecessary_pages?:
> makedumpfile.c:3625:15: warning: variable ?_count? set but not used
> [-Wunused-but-set-variable]
> /usr/bin/ld: cannot find -lbz2
> /usr/bin/ld: cannot find -ldl
> /usr/bin/ld: cannot find -lc
> collect2: ld returned 1 exit status
> make: *** [makedumpfile] Error 1
> 
> [wangcong at cr0]~/makedumpfile% rpm -ql bzip2-libs
> /lib64/libbz2.so.1
> /lib64/libbz2.so.1.0.6
> /usr/share/doc/bzip2-libs-1.0.6
> /usr/share/doc/bzip2-libs-1.0.6/LICENSE
> 
> So, I don't know why ld can't find libbz2 and libc... Any hints?
> 
> Thanks!
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 



From oomichi at mxs.nes.nec.co.jp  Tue Jan 17 19:40:55 2012
From: oomichi at mxs.nes.nec.co.jp (Ken'ichi Ohmichi)
Date: Wed, 18 Jan 2012 09:40:55 +0900
Subject: makedumpfile can't build on Fedora 16
In-Reply-To: <4F1613CC.9040405@cn.fujitsu.com>
References: <4F15A377.3090302@gmail.com>
	<4F1613CC.9040405@cn.fujitsu.com>
Message-ID: <20120118094055.239c362d.oomichi@mxs.nes.nec.co.jp>


Hi,

On Wed, 18 Jan 2012 08:35:24 +0800
Wen Congyang <wency at cn.fujitsu.com> wrote:
> At 01/18/2012 12:36 AM, Cong Wang Wrote:
> > Hello, Atsushi,
> > 
> > I can't build the latest makedumpfile on Fedora 16,
> > 
> > [wangcong at cr0]~/makedumpfile% make
> > ...
> > gcc -g -O2 -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> > -D_LARGEFILE64_SOURCE -DVERSION='"1.4.1"' -DRELEASE_DATE='"6 January
> > 2012"' -D__x86_64__  print_info.o dwarf_info.o elf_info.o erase_info.o
> > sadump_info.o arch/arm.o arch/x86.o arch/x86_64.o arch/ia64.o
> > arch/ppc64.o arch/s390x.o -o makedumpfile makedumpfile.c -static -ldw
> > -lbz2 -lebl -ldl -lelf -lz
> 
> The parameter has -static, so you need libc.a, libdw.a and ...
> Or you can remove -static, but you should ensure that there are these
> dynamic librarys in the second os.

That's right.
It has been written in README file of makedumpfile:

  002: makedumpfile is compiled with -static option, because the command should
       run while the second kernel, which may not mount root filesystem and may
       not contain dynamic library files, is running.
       If the dynamic library files, which are needed by makedumpfile, exist
       while the second kernel is running, we can remove -static option from
       Makefile. This is a workaround for some linux distributions which does
       not contain static library files needed by makedumpfile.


Thanks
Ken'ichi Ohmichi

> > makedumpfile.c: In function ?__exclude_unnecessary_pages?:
> > makedumpfile.c:3625:15: warning: variable ?_count? set but not used
> > [-Wunused-but-set-variable]
> > /usr/bin/ld: cannot find -lbz2
> > /usr/bin/ld: cannot find -ldl
> > /usr/bin/ld: cannot find -lc
> > collect2: ld returned 1 exit status
> > make: *** [makedumpfile] Error 1
> > 
> > [wangcong at cr0]~/makedumpfile% rpm -ql bzip2-libs
> > /lib64/libbz2.so.1
> > /lib64/libbz2.so.1.0.6
> > /usr/share/doc/bzip2-libs-1.0.6
> > /usr/share/doc/bzip2-libs-1.0.6/LICENSE
> > 
> > So, I don't know why ld can't find libbz2 and libc... Any hints?
> > 
> > Thanks!
> > 
> > _______________________________________________
> > kexec mailing list
> > kexec at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/kexec
> > 
> 
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec


From suzuki at in.ibm.com  Wed Jan 18 05:07:49 2012
From: suzuki at in.ibm.com (Suzuki K. Poulose)
Date: Wed, 18 Jan 2012 15:37:49 +0530
Subject: [PATCH v1 0/3][makedumpfile]Add support for  PPC32
Message-ID: <20120118100510.29422.93587.stgit@suzukikp.in.ibm.com>

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

-- 
Suzuki Poulose



From suzuki at in.ibm.com  Wed Jan 18 05:09:14 2012
From: suzuki at in.ibm.com (Suzuki K. Poulose)
Date: Wed, 18 Jan 2012 15:39:14 +0530
Subject: [PATCH v1 1/3] [makedumpfile] Support for cross building 
In-Reply-To: <20120118100510.29422.93587.stgit@suzukikp.in.ibm.com>
References: <20120118100510.29422.93587.stgit@suzukikp.in.ibm.com>
Message-ID: <20120118100755.29422.5803.stgit@suzukikp.in.ibm.com>

Support cross building of makedumpfile. This would be useful for building
the makedumpfile for embedded PPC boards. Support for PPC32 would be added
in the later patches.

Use TARGET variable to set the arch to build for. Also honour the value of
CC if set.

Signed-off-by: Suzuki K. Poulose <suzuki at in.ibm.com>
---

 Makefile |   12 +++++++++++-
 README   |    5 +++++
 2 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index 9afbe1c..174a0d9 100644
--- a/Makefile
+++ b/Makefile
@@ -3,7 +3,11 @@
 VERSION=1.4.1
 DATE=6 January 2012
 
+# Honour the environment variable CC
+ifeq ($(strip $CC),)
 CC	= gcc
+endif
+
 CFLAGS = -g -O2 -Wall -D_FILE_OFFSET_BITS=64 \
 	  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE \
 	  -DVERSION='"$(VERSION)"' -DRELEASE_DATE='"$(DATE)"'
@@ -11,7 +15,13 @@ CFLAGS_ARCH	= -g -O2 -Wall -D_FILE_OFFSET_BITS=64 \
 		    -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
 # LDFLAGS = -L/usr/local/lib -I/usr/local/include
 
-ARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/sun4u/sparc64/ \
+# Use TARGET as the target architecture if specified.
+# Defaults to uname -m
+ifeq ($(strip($TARGET)),)
+TARGET := $(shell uname -m)
+endif
+
+ARCH := $(shell echo ${TARGET}  | sed -e s/i.86/x86/ -e s/sun4u/sparc64/ \
 			       -e s/arm.*/arm/ -e s/sa110/arm/ \
 			       -e s/s390x/s390/ -e s/parisc64/parisc/ \
 			       -e s/ppc64/powerpc/ )
diff --git a/README b/README
index 8aa4ab3..595b446 100644
--- a/README
+++ b/README
@@ -37,6 +37,11 @@
     # cd makedumpfile-x.y.z
   4.Build, and install:
     # make; make install
+  5.Build for a different architecture than the host :
+    # make TARGET=<arch> ; make install
+    where <arch> is the 'uname -m' of the target architecture. 
+    The user has to set the environment variable CC to appropriate
+    compiler for the target architecture.
 
 * SUPPORTED KERNELS
   This makedumpfile supports the following kernels.



From suzuki at in.ibm.com  Wed Jan 18 05:09:44 2012
From: suzuki at in.ibm.com (Suzuki K. Poulose)
Date: Wed, 18 Jan 2012 15:39:44 +0530
Subject: [PATCH v1 2/3][makedumpfile][ppc64] Rename the __powerpc__ macro to
 __powerpc64__ for PPC64
In-Reply-To: <20120118100510.29422.93587.stgit@suzukikp.in.ibm.com>
References: <20120118100510.29422.93587.stgit@suzukikp.in.ibm.com>
Message-ID: <20120118100921.29422.90156.stgit@suzukikp.in.ibm.com>

Makedumpfile uses __powerpc__ as the value of ARCH to control the PPC64
specfic definitions. Rename this to __powerpc64__ for a better readability
of the code as the support for ppc32 will be introduced in the later series.
We could use __powerpc32__ for PPC32.

Signed-off-by: Suzuki Poulose <suzuki at in.ibm.com>
---

 Makefile       |    5 +++--
 makedumpfile.c |    2 +-
 makedumpfile.h |   10 +++++-----
 3 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/Makefile b/Makefile
index 174a0d9..04e267f 100644
--- a/Makefile
+++ b/Makefile
@@ -24,11 +24,12 @@ endif
 ARCH := $(shell echo ${TARGET}  | sed -e s/i.86/x86/ -e s/sun4u/sparc64/ \
 			       -e s/arm.*/arm/ -e s/sa110/arm/ \
 			       -e s/s390x/s390/ -e s/parisc64/parisc/ \
-			       -e s/ppc64/powerpc/ )
+			       -e s/ppc64/powerpc64/ )
+
 CFLAGS += -D__$(ARCH)__
 CFLAGS_ARCH += -D__$(ARCH)__
 
-ifeq ($(ARCH), powerpc)
+ifeq ($(ARCH), powerpc64)
 CFLAGS += -m64
 CFLAGS_ARCH += -m64
 endif
diff --git a/makedumpfile.c b/makedumpfile.c
index c51fda3..101f8b5 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -5691,7 +5691,7 @@ initial_xen(void)
 	off_t offset;
 	unsigned long size;
 
-#ifdef __powerpc__
+#ifdef __powerpc64__
 	MSG("\n");
 	MSG("ppc64 xen is not supported.\n");
 	return FALSE;
diff --git a/makedumpfile.h b/makedumpfile.h
index 4b4a58b..efa325f 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -521,7 +521,7 @@ do { \
 
 #endif /* x86_64 */
 
-#ifdef __powerpc__
+#ifdef __powerpc64__
 #define __PAGE_OFFSET		(0xc000000000000000)
 #define KERNELBASE		PAGE_OFFSET
 #define VMALLOCBASE     	(0xD000000000000000)
@@ -658,14 +658,14 @@ unsigned long long vaddr_to_paddr_x86_64(unsigned long vaddr);
 #define vaddr_to_paddr(X)	vaddr_to_paddr_x86_64(X)
 #endif /* x86_64 */
 
-#ifdef __powerpc__ /* powerpc */
+#ifdef __powerpc64__ /* powerpc64 */
 int get_machdep_info_ppc64(void);
 unsigned long long vaddr_to_paddr_ppc64(unsigned long vaddr);
 #define get_phys_base()		TRUE
 #define get_machdep_info()	get_machdep_info_ppc64()
 #define get_versiondep_info()	TRUE
 #define vaddr_to_paddr(X)	vaddr_to_paddr_ppc64(X)
-#endif          /* powerpc */
+#endif          /* powerpc64 */
 
 #ifdef __s390x__ /* s390x */
 int get_machdep_info_s390x(void);
@@ -1332,10 +1332,10 @@ int get_xen_info_ia64(void);
 
 #endif	/* __ia64 */
 
-#ifdef __powerpc__ /* powerpc */
+#ifdef __powerpc64__ /* powerpc64 */
 #define kvtop_xen(X)	FALSE
 #define get_xen_info_arch(X) FALSE
-#endif	/* powerpc */
+#endif	/* powerpc64 */
 
 #ifdef __s390x__ /* s390x */
 #define kvtop_xen(X)	FALSE



From suzuki at in.ibm.com  Wed Jan 18 05:10:03 2012
From: suzuki at in.ibm.com (Suzuki K. Poulose)
Date: Wed, 18 Jan 2012 15:40:03 +0530
Subject: [PATCH v1 3/3] [makedumpfile] Add support for PPC32
In-Reply-To: <20120118100510.29422.93587.stgit@suzukikp.in.ibm.com>
References: <20120118100510.29422.93587.stgit@suzukikp.in.ibm.com>
Message-ID: <20120118100949.29422.17463.stgit@suzukikp.in.ibm.com>

Mostly a copy of ppc64 with renaming to _ppc variants.

Signed-off-by: Suzuki K. Poulose <suzuki at in.ibm.com>
---

 Makefile       |   11 ++++--
 arch/ppc.c     |  101 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 makedumpfile.c |    4 +-
 makedumpfile.h |   24 ++++++++++++-
 4 files changed, 133 insertions(+), 7 deletions(-)
 create mode 100644 arch/ppc.c

diff --git a/Makefile b/Makefile
index 04e267f..677cc8c 100644
--- a/Makefile
+++ b/Makefile
@@ -24,7 +24,7 @@ endif
 ARCH := $(shell echo ${TARGET}  | sed -e s/i.86/x86/ -e s/sun4u/sparc64/ \
 			       -e s/arm.*/arm/ -e s/sa110/arm/ \
 			       -e s/s390x/s390/ -e s/parisc64/parisc/ \
-			       -e s/ppc64/powerpc64/ )
+			       -e s/ppc64/powerpc64/ -e s/ppc/powerpc32/)
 
 CFLAGS += -D__$(ARCH)__
 CFLAGS_ARCH += -D__$(ARCH)__
@@ -34,11 +34,16 @@ CFLAGS += -m64
 CFLAGS_ARCH += -m64
 endif
 
+ifeq ($(ARCH), powerpc32)
+CFLAGS += -m32
+CFLAGS_ARCH += -m32
+endif
+
 SRC	= makedumpfile.c makedumpfile.h diskdump_mod.h sadump_mod.h sadump_info.h
 SRC_PART = print_info.c dwarf_info.c elf_info.c erase_info.c sadump_info.c
 OBJ_PART = print_info.o dwarf_info.o elf_info.o erase_info.o sadump_info.o
-SRC_ARCH = arch/arm.c arch/x86.c arch/x86_64.c arch/ia64.c arch/ppc64.c arch/s390x.c
-OBJ_ARCH = arch/arm.o arch/x86.o arch/x86_64.o arch/ia64.o arch/ppc64.o arch/s390x.o
+SRC_ARCH = arch/arm.c arch/x86.c arch/x86_64.c arch/ia64.c arch/ppc64.c arch/s390x.c arch/ppc.c
+OBJ_ARCH = arch/arm.o arch/x86.o arch/x86_64.o arch/ia64.o arch/ppc64.o arch/s390x.o arch/ppc.o
 
 all: makedumpfile
 
diff --git a/arch/ppc.c b/arch/ppc.c
new file mode 100644
index 0000000..2bc8d5f
--- /dev/null
+++ b/arch/ppc.c
@@ -0,0 +1,101 @@
+/*
+ * ppc.c
+ *
+ * Created by: Suzuki K. Poulose <suzuki at in.ibm.com>
+ *  - Based on ppc64 implementation
+ * Copyright (C) IBM Corporation, 2012. All rights reserved
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation (version 2 of the License).
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifdef __powerpc32__
+
+#include "../print_info.h"
+#include "../elf_info.h"
+#include "../makedumpfile.h"
+
+int
+get_machdep_info_ppc(void)
+{
+	unsigned long vmlist, vmalloc_start;
+
+	info->section_size_bits = _SECTION_SIZE_BITS;
+	info->max_physmem_bits  = _MAX_PHYSMEM_BITS;
+	info->page_offset = __PAGE_OFFSET;
+
+	if (SYMBOL(_stext) != NOT_FOUND_SYMBOL)
+		info->kernel_start = SYMBOL(_stext);
+	else {
+		ERRMSG("Can't get the symbol of _stext.\n");
+		return FALSE;
+	}
+		
+	DEBUG_MSG("kernel_start : %lx\n", info->kernel_start);
+
+	/*
+	 * For the compatibility, makedumpfile should run without the symbol
+	 * vmlist and the offset of vm_struct.addr if they are not necessary.
+	 */
+	if ((SYMBOL(vmlist) == NOT_FOUND_SYMBOL)
+	    || (OFFSET(vm_struct.addr) == NOT_FOUND_STRUCTURE)) {
+		return TRUE;
+	}
+	if (!readmem(VADDR, SYMBOL(vmlist), &vmlist, sizeof(vmlist))) {
+		ERRMSG("Can't get vmlist.\n");
+		return FALSE;
+	}
+	if (!readmem(VADDR, vmlist + OFFSET(vm_struct.addr), &vmalloc_start,
+	    sizeof(vmalloc_start))) {
+		ERRMSG("Can't get vmalloc_start.\n");
+		return FALSE;
+	}
+	info->vmalloc_start = vmalloc_start;
+	DEBUG_MSG("vmalloc_start: %lx\n", vmalloc_start);
+
+	return TRUE;
+}
+
+int
+is_vmalloc_addr_ppc(unsigned long vaddr)
+{
+	return (info->vmalloc_start && vaddr >= info->vmalloc_start);
+}
+
+unsigned long long
+vaddr_to_paddr_ppc(unsigned long vaddr)
+{
+	unsigned long *pgd, *pmd;
+	unsigned long long pte;
+	unsigned long long paddr;
+
+	paddr = vaddr_to_paddr_general(vaddr);
+	if (paddr != NOT_PADDR)
+		return paddr;
+
+	if ((SYMBOL(vmlist) == NOT_FOUND_SYMBOL)
+	    || (OFFSET(vm_struct.addr) == NOT_FOUND_STRUCTURE)) {
+		ERRMSG("Can't get necessary information for vmalloc translation.\n");
+		return NOT_PADDR;
+	}
+	if (!is_vmalloc_addr_ppc(vaddr))
+		return (vaddr - info->kernel_start);
+
+	/*
+	 * TODO: Support vmalloc translation.
+	 */
+	ERRMSG("This makedumpfile does not support vmalloc translation.\n");
+	return NOT_PADDR;
+}
+
+#endif /* powerpc32 */
diff --git a/makedumpfile.c b/makedumpfile.c
index 101f8b5..cefb7cf 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -5691,9 +5691,9 @@ initial_xen(void)
 	off_t offset;
 	unsigned long size;
 
-#ifdef __powerpc64__
+#if defined(__powerpc64__) || defined(__powerpc32__)
 	MSG("\n");
-	MSG("ppc64 xen is not supported.\n");
+	MSG("xen is not supported on powerpc.\n");
 	return FALSE;
 #else
 	if(!info->flag_elf_dumpfile) {
diff --git a/makedumpfile.h b/makedumpfile.h
index efa325f..1329271 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -530,6 +530,17 @@ do { \
 #define _MAX_PHYSMEM_BITS	(44)
 #endif
 
+#ifdef __powerpc32__
+
+#define __PAGE_OFFSET		(0xc0000000)
+#define KERNELBASE		PAGE_OFFSET
+#define VMALL_START     	(info->vmalloc_start)
+#define KVBASE			(SYMBOL(_stext))
+#define _SECTION_SIZE_BITS	(24)
+#define _MAX_PHYSMEM_BITS	(44)
+
+#endif
+
 #ifdef __s390x__
 #define __PAGE_OFFSET		(info->page_size - 1)
 #define KERNELBASE		(0)
@@ -667,6 +678,15 @@ unsigned long long vaddr_to_paddr_ppc64(unsigned long vaddr);
 #define vaddr_to_paddr(X)	vaddr_to_paddr_ppc64(X)
 #endif          /* powerpc64 */
 
+#ifdef __powerpc32__ /* powerpc32 */
+int get_machdep_info_ppc(void);
+unsigned long long vaddr_to_paddr_ppc(unsigned long vaddr);
+#define get_phys_base()		TRUE
+#define get_machdep_info()	get_machdep_info_ppc()
+#define get_versiondep_info()	TRUE
+#define vaddr_to_paddr(X)	vaddr_to_paddr_ppc(X)
+#endif          /* powerpc */
+
 #ifdef __s390x__ /* s390x */
 int get_machdep_info_s390x(void);
 unsigned long long vaddr_to_paddr_s390x(unsigned long vaddr);
@@ -1332,10 +1352,10 @@ int get_xen_info_ia64(void);
 
 #endif	/* __ia64 */
 
-#ifdef __powerpc64__ /* powerpc64 */
+#if defined(__powerpc64__) || defined(__powerpc32__) /* powerpcXX */
 #define kvtop_xen(X)	FALSE
 #define get_xen_info_arch(X) FALSE
-#endif	/* powerpc64 */
+#endif	/* powerpcXX */
 
 #ifdef __s390x__ /* s390x */
 #define kvtop_xen(X)	FALSE



From xiyou.wangcong at gmail.com  Wed Jan 18 08:45:09 2012
From: xiyou.wangcong at gmail.com (Cong Wang)
Date: Wed, 18 Jan 2012 21:45:09 +0800
Subject: makedumpfile can't build on Fedora 16
In-Reply-To: <20120118094055.239c362d.oomichi@mxs.nes.nec.co.jp>
References: <4F15A377.3090302@gmail.com> <4F1613CC.9040405@cn.fujitsu.com>
 <20120118094055.239c362d.oomichi@mxs.nes.nec.co.jp>
Message-ID: <4F16CCE5.1060500@gmail.com>

On 01/18/2012 08:40 AM, Ken'ichi Ohmichi wrote:
> 
> Hi,
> 
> On Wed, 18 Jan 2012 08:35:24 +0800
> Wen Congyang<wency at cn.fujitsu.com>  wrote:
>> At 01/18/2012 12:36 AM, Cong Wang Wrote:
>>> Hello, Atsushi,
>>>
>>> I can't build the latest makedumpfile on Fedora 16,
>>>
>>> [wangcong at cr0]~/makedumpfile% make
>>> ...
>>> gcc -g -O2 -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
>>> -D_LARGEFILE64_SOURCE -DVERSION='"1.4.1"' -DRELEASE_DATE='"6 January
>>> 2012"' -D__x86_64__  print_info.o dwarf_info.o elf_info.o erase_info.o
>>> sadump_info.o arch/arm.o arch/x86.o arch/x86_64.o arch/ia64.o
>>> arch/ppc64.o arch/s390x.o -o makedumpfile makedumpfile.c -static -ldw
>>> -lbz2 -lebl -ldl -lelf -lz
>>
>> The parameter has -static, so you need libc.a, libdw.a and ...
>> Or you can remove -static, but you should ensure that there are these
>> dynamic librarys in the second os.
> 
> That's right.
> It has been written in README file of makedumpfile:

Hey,

This means we have to patch the source code by ourselves, why not
improve it? Something like below?

diff --git a/Makefile b/Makefile
index 9afbe1c..1361700 100644
--- a/Makefile
+++ b/Makefile
@@ -28,6 +28,11 @@ SRC_PART = print_info.c dwarf_info.c elf_info.c
erase_info.c sadump_info.c
 OBJ_PART = print_info.o dwarf_info.o elf_info.o erase_info.o sadump_info.o
 SRC_ARCH = arch/arm.c arch/x86.c arch/x86_64.c arch/ia64.c arch/ppc64.c
arch/s390x.c
 OBJ_ARCH = arch/arm.o arch/x86.o arch/x86_64.o arch/ia64.o arch/ppc64.o
arch/s390x.o
+LIBS := $(shell if $(CC) -static -ldw -lbz2 -lebl -ldl -lelf -lz
>&/dev/null; then \
+       echo "-static -ldw -lbz2 -lebl -ldl -lelf -lz"; \
+       else \
+       echo "-ldw -lbz2 -lebl -ldl -lelf -lz"; \
+       fi)

 all: makedumpfile

@@ -38,7 +43,7 @@ $(OBJ_ARCH): $(SRC_ARCH)
        $(CC) $(CFLAGS_ARCH) -c -o ./$@ ./$(@:.o=.c)

 makedumpfile: $(SRC) $(OBJ_PART) $(OBJ_ARCH)
-       $(CC) $(CFLAGS) $(LDFLAGS) $(OBJ_PART) $(OBJ_ARCH) -o $@ $<
-static -ldw -lbz2 -lebl -ldl -lelf -lz
+       $(CC) $(CFLAGS) $(LDFLAGS) $(OBJ_PART) $(OBJ_ARCH) -o $@ $< $(LIBS)
        echo .TH MAKEDUMPFILE 8 \"$(DATE)\" \"makedumpfile v$(VERSION)\"
\"Linux System Administrator\'s Manual\" > temp.8
        grep -v "^.TH MAKEDUMPFILE 8" makedumpfile.8 >> temp.8
        mv temp.8 makedumpfile.8


From jlan at sgi.com  Wed Jan 18 21:42:54 2012
From: jlan at sgi.com (Jay Lan)
Date: Wed, 18 Jan 2012 18:42:54 -0800
Subject: kdump kernel tried to load modules not included in the kdump initrd?
Message-ID: <4F17832E.9080102@sgi.com>

Hi,

I have a 2.6.32-131.6.1.el6 kernel, and kexec-tools-2.0.0-145.el6.x86_64
rpm on a cent6 machine.

When i forced a kdump by 'echo c > /proc/sysrq-trigger',
the kdump kernel panicked during the boot. Surprisingly,
it tried to load lustre modules that should not be part of
the initrd and panicked!

The syslog showed the --initrd specified a kdump.img
when kdump was started. I dumped out the kdump.img
and verified that no lustre module was included in the
initrd image.

So, how this have happened?

Thanks,
Jay



From kumagai-atsushi at mxc.nes.nec.co.jp  Wed Jan 18 21:58:52 2012
From: kumagai-atsushi at mxc.nes.nec.co.jp (Atsushi Kumagai)
Date: Thu, 19 Jan 2012 11:58:52 +0900
Subject: [PATCH v1 0/3][makedumpfile]Add support for  PPC32
In-Reply-To: <20120118100510.29422.93587.stgit@suzukikp.in.ibm.com>
References: <20120118100510.29422.93587.stgit@suzukikp.in.ibm.com>
Message-ID: <20120119115852.588bf8bb.kumagai-atsushi@mxc.nes.nec.co.jp>

Hi Suzuki,

On Wed, 18 Jan 2012 15:37:49 +0530
"Suzuki K. Poulose" <suzuki at in.ibm.com> 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
> 
> -- 
> Suzuki Poulose

Thank you for your patches.
I will review them.

Thanks
Atsushi Kumagai


From jay.zen.lan at gmail.com  Thu Jan 19 02:46:57 2012
From: jay.zen.lan at gmail.com (Jay Lan)
Date: Wed, 18 Jan 2012 23:46:57 -0800
Subject: kdump kernel tried to load modules not included in the kdump initrd?
Message-ID: <4F17CA71.6040405@gmail.com>

Hi,

I have a 2.6.32-131.6.1.el6 kernel, and kexec-tools-2.0.0-145.el6.x86_64
rpm on a cent6 machine.

When i forced a kdump by 'echo c > /proc/sysrq-trigger',
the kdump kernel panicked during the boot. Surprisingly,
it tried to load lustre modules that should not be part of
the initrd and panicked!

The syslog showed the --initrd specified a kdump.img
when kdump was started. I dumped out the kdump.img
(with zcat) and verified that no lustre module was included
in the initrd image.

So, how did this have happened?

Thanks,
Jay


From oomichi at mxs.nes.nec.co.jp  Thu Jan 19 02:58:16 2012
From: oomichi at mxs.nes.nec.co.jp (Ken'ichi Ohmichi)
Date: Thu, 19 Jan 2012 16:58:16 +0900
Subject: makedumpfile can't build on Fedora 16
In-Reply-To: <4F16CCE5.1060500@gmail.com>
References: <4F15A377.3090302@gmail.com> <4F1613CC.9040405@cn.fujitsu.com>
 <20120118094055.239c362d.oomichi@mxs.nes.nec.co.jp>
 <4F16CCE5.1060500@gmail.com>
Message-ID: <20120119165816.125f11b0.oomichi@mxs.nes.nec.co.jp>


Hi,

On Wed, 18 Jan 2012 21:45:09 +0800
Cong Wang <xiyou.wangcong at gmail.com> wrote:
> >>> ...
> >>> gcc -g -O2 -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> >>> -D_LARGEFILE64_SOURCE -DVERSION='"1.4.1"' -DRELEASE_DATE='"6 January
> >>> 2012"' -D__x86_64__  print_info.o dwarf_info.o elf_info.o erase_info.o
> >>> sadump_info.o arch/arm.o arch/x86.o arch/x86_64.o arch/ia64.o
> >>> arch/ppc64.o arch/s390x.o -o makedumpfile makedumpfile.c -static -ldw
> >>> -lbz2 -lebl -ldl -lelf -lz
> >>
> >> The parameter has -static, so you need libc.a, libdw.a and ...
> >> Or you can remove -static, but you should ensure that there are these
> >> dynamic librarys in the second os.
> > 
> > That's right.
> > It has been written in README file of makedumpfile:
> 
> Hey,
> 
> This means we have to patch the source code by ourselves, why not
> improve it? Something like below?

I guess someone will send "makedumpfile can't run on ..." even if
your patch is merged, because these dynamic libraries should be
included in the second os and it is easy to forget that.
The compiling error is an easy way to notice it, I feel.
What do you think, Kumagai-san ?


Thanks
Ken'ichi Ohmichi

---
> diff --git a/Makefile b/Makefile
> index 9afbe1c..1361700 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -28,6 +28,11 @@ SRC_PART = print_info.c dwarf_info.c elf_info.c
> erase_info.c sadump_info.c
>  OBJ_PART = print_info.o dwarf_info.o elf_info.o erase_info.o sadump_info.o
>  SRC_ARCH = arch/arm.c arch/x86.c arch/x86_64.c arch/ia64.c arch/ppc64.c
> arch/s390x.c
>  OBJ_ARCH = arch/arm.o arch/x86.o arch/x86_64.o arch/ia64.o arch/ppc64.o
> arch/s390x.o
> +LIBS := $(shell if $(CC) -static -ldw -lbz2 -lebl -ldl -lelf -lz
> >&/dev/null; then \
> +       echo "-static -ldw -lbz2 -lebl -ldl -lelf -lz"; \
> +       else \
> +       echo "-ldw -lbz2 -lebl -ldl -lelf -lz"; \
> +       fi)
> 
>  all: makedumpfile
> 
> @@ -38,7 +43,7 @@ $(OBJ_ARCH): $(SRC_ARCH)
>         $(CC) $(CFLAGS_ARCH) -c -o ./$@ ./$(@:.o=.c)
> 
>  makedumpfile: $(SRC) $(OBJ_PART) $(OBJ_ARCH)
> -       $(CC) $(CFLAGS) $(LDFLAGS) $(OBJ_PART) $(OBJ_ARCH) -o $@ $<
> -static -ldw -lbz2 -lebl -ldl -lelf -lz
> +       $(CC) $(CFLAGS) $(LDFLAGS) $(OBJ_PART) $(OBJ_ARCH) -o $@ $< $(LIBS)
>         echo .TH MAKEDUMPFILE 8 \"$(DATE)\" \"makedumpfile v$(VERSION)\"
> \"Linux System Administrator\'s Manual\" > temp.8
>         grep -v "^.TH MAKEDUMPFILE 8" makedumpfile.8 >> temp.8
>         mv temp.8 makedumpfile.8


From xiyou.wangcong at gmail.com  Thu Jan 19 07:26:06 2012
From: xiyou.wangcong at gmail.com (Cong Wang)
Date: Thu, 19 Jan 2012 12:26:06 +0000 (UTC)
Subject: kdump kernel tried to load modules not included in the kdump
 initrd?
References: <4F17CA71.6040405@gmail.com>
Message-ID: <jf924s$rn1$1@dough.gmane.org>

On Thu, 19 Jan 2012 at 07:46 GMT, Jay Lan <jay.zen.lan at gmail.com> wrote:
> Hi,
>

Hi, Jay,

This mailing list is not proper for reporting problems of distro's
mkdumprd, please file a bug in bugzilla of centos.

> I have a 2.6.32-131.6.1.el6 kernel, and kexec-tools-2.0.0-145.el6.x86_64
> rpm on a cent6 machine.
>
> When i forced a kdump by 'echo c > /proc/sysrq-trigger',
> the kdump kernel panicked during the boot. Surprisingly,
> it tried to load lustre modules that should not be part of
> the initrd and panicked!
>
> The syslog showed the --initrd specified a kdump.img
> when kdump was started. I dumped out the kdump.img
> (with zcat) and verified that no lustre module was included
> in the initrd image.

lsinitrd can do that too.

>
> So, how did this have happened?
>

Odd, el6 mkdumprd picks all modules listed by lsmod in your *first
kernel*, so it is not surprised mkdumprd picks it. But if it is not
picked into kdump initrd, it is almost impossible that it will be
loaded in the second kernel.




From jay.zen.lan at gmail.com  Thu Jan 19 19:30:39 2012
From: jay.zen.lan at gmail.com (Jay Lan)
Date: Thu, 19 Jan 2012 16:30:39 -0800
Subject: kdump kernel tried to load modules not included in the kdump
 initrd?
In-Reply-To: <jf924s$rn1$1@dough.gmane.org>
References: <4F17CA71.6040405@gmail.com> <jf924s$rn1$1@dough.gmane.org>
Message-ID: <4F18B5AF.3040107@gmail.com>

Hi Cong,

Thanks for your reply. It is good to know about lsinitrd. :)

I noticed that I ran out of memory during booting of 2nd kernel.
After I increased the crashkernel=xxx to 512M, it worked
correctly. Maybe OOM killed some processes and
things got confused... Anyway, it works now.

Thanks,
Jay


On 01/19/2012 04:26 AM, Cong Wang wrote:
> On Thu, 19 Jan 2012 at 07:46 GMT, Jay Lan<jay.zen.lan at gmail.com>  wrote:
>> Hi,
>>
> Hi, Jay,
>
> This mailing list is not proper for reporting problems of distro's
> mkdumprd, please file a bug in bugzilla of centos.
>
>> I have a 2.6.32-131.6.1.el6 kernel, and kexec-tools-2.0.0-145.el6.x86_64
>> rpm on a cent6 machine.
>>
>> When i forced a kdump by 'echo c>  /proc/sysrq-trigger',
>> the kdump kernel panicked during the boot. Surprisingly,
>> it tried to load lustre modules that should not be part of
>> the initrd and panicked!
>>
>> The syslog showed the --initrd specified a kdump.img
>> when kdump was started. I dumped out the kdump.img
>> (with zcat) and verified that no lustre module was included
>> in the initrd image.
> lsinitrd can do that too.
>
>> So, how did this have happened?
>>
> Odd, el6 mkdumprd picks all modules listed by lsmod in your *first
> kernel*, so it is not surprised mkdumprd picks it. But if it is not
> picked into kdump initrd, it is almost impossible that it will be
> loaded in the second kernel.
>
>
>
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec



From kumagai-atsushi at mxc.nes.nec.co.jp  Fri Jan 20 02:03:22 2012
From: kumagai-atsushi at mxc.nes.nec.co.jp (Atsushi Kumagai)
Date: Fri, 20 Jan 2012 16:03:22 +0900
Subject: makedumpfile can't build on Fedora 16
In-Reply-To: <20120119165816.125f11b0.oomichi@mxs.nes.nec.co.jp>
References: <4F15A377.3090302@gmail.com> <4F1613CC.9040405@cn.fujitsu.com>
 <20120118094055.239c362d.oomichi@mxs.nes.nec.co.jp>
 <4F16CCE5.1060500@gmail.com>
 <20120119165816.125f11b0.oomichi@mxs.nes.nec.co.jp>
Message-ID: <20120120160322.d5dbd362.kumagai-atsushi@mxc.nes.nec.co.jp>

Hi,

On Thu, 19 Jan 2012 16:58:16 +0900
Ken'ichi Ohmichi <oomichi at mxs.nes.nec.co.jp> wrote:

> 
> Hi,
> 
> On Wed, 18 Jan 2012 21:45:09 +0800
> Cong Wang <xiyou.wangcong at gmail.com> wrote:
> > >>> ...
> > >>> gcc -g -O2 -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> > >>> -D_LARGEFILE64_SOURCE -DVERSION='"1.4.1"' -DRELEASE_DATE='"6 January
> > >>> 2012"' -D__x86_64__  print_info.o dwarf_info.o elf_info.o erase_info.o
> > >>> sadump_info.o arch/arm.o arch/x86.o arch/x86_64.o arch/ia64.o
> > >>> arch/ppc64.o arch/s390x.o -o makedumpfile makedumpfile.c -static -ldw
> > >>> -lbz2 -lebl -ldl -lelf -lz
> > >>
> > >> The parameter has -static, so you need libc.a, libdw.a and ...
> > >> Or you can remove -static, but you should ensure that there are these
> > >> dynamic librarys in the second os.
> > > 
> > > That's right.
> > > It has been written in README file of makedumpfile:
> > 
> > Hey,
> > 
> > This means we have to patch the source code by ourselves, why not
> > improve it? Something like below?
> 
> I guess someone will send "makedumpfile can't run on ..." even if
> your patch is merged, because these dynamic libraries should be
> included in the second os and it is easy to forget that.
> The compiling error is an easy way to notice it, I feel.
> What do you think, Kumagai-san ?
> 
> 
> Thanks
> Ken'ichi Ohmichi

Thank you for your explanation, Ohmichi-san, I agree with you.

I think that makedumpfile should be compiled with -static option,
because it must be executable in many environment as possible, e.g. even if
there are no dynamic libraries in 2nd kernel environment. (as written in README)

But I've got some requests to build it using dynamic libraries,
so I will change the Makefile as attached patch. 
 
If you want to build makedumpfile using dynamic libraries,
you need "LINKTYPE=dynamic"(see below).

How to build:
  a) linking static libraries (default)
    $ make
    ...
    $ ldd makedumpfile
        not a dynamic executable
  
  b) linking dynamic libraries
    $ make LINKTYPE=dynamic
    ...
    $ ldd makedumpfile
        libdw.so.1 => /usr/lib64/libdw.so.1 (0x0000003ca2800000)
        libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x000000394b200000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00000031a5a00000)
        libelf.so.1 => /usr/lib64/libelf.so.1 (0x0000003ca2400000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x00000031a6200000)
        libc.so.6 => /lib64/libc.so.6 (0x00000031a5200000)
        /lib64/ld-linux-x86-64.so.2 (0x00000031a4e00000)

What do you think, Cong?

Thanks
Atsushi Kumagai


diff --git a/Makefile b/Makefile
index 9afbe1c..b14f09c 100644
--- a/Makefile
+++ b/Makefile
@@ -29,6 +29,12 @@ OBJ_PART = print_info.o dwarf_info.o elf_info.o erase_info.o sadump_info.o
 SRC_ARCH = arch/arm.c arch/x86.c arch/x86_64.c arch/ia64.c arch/ppc64.c arch/s390x.c
 OBJ_ARCH = arch/arm.o arch/x86.o arch/x86_64.o arch/ia64.o arch/ppc64.o arch/s390x.o

+ifeq ($(LINKTYPE), dynamic)
+LIBS = -ldw -lbz2 -lebl -ldl -lelf -lz
+else
+LIBS = -static -ldw -lbz2 -lebl -ldl -lelf -lz
+endif
+
 all: makedumpfile

 $(OBJ_PART): $(SRC_PART)
@@ -38,7 +44,7 @@ $(OBJ_ARCH): $(SRC_ARCH)
        $(CC) $(CFLAGS_ARCH) -c -o ./$@ ./$(@:.o=.c)

 makedumpfile: $(SRC) $(OBJ_PART) $(OBJ_ARCH)
-       $(CC) $(CFLAGS) $(LDFLAGS) $(OBJ_PART) $(OBJ_ARCH) -o $@ $< -static -ldw -lbz2 -lebl -ldl -lelf -lz
+       $(CC) $(CFLAGS) $(LDFLAGS) $(OBJ_PART) $(OBJ_ARCH) -o $@ $< $(LIBS)
        echo .TH MAKEDUMPFILE 8 \"$(DATE)\" \"makedumpfile v$(VERSION)\" \"Linux System Administrator\'s Manual\" > temp.8
        grep -v "^.TH MAKEDUMPFILE 8" makedumpfile.8 >> temp.8
        mv temp.8 makedumpfile.8


From xiyou.wangcong at gmail.com  Fri Jan 20 02:19:24 2012
From: xiyou.wangcong at gmail.com (Cong Wang)
Date: Fri, 20 Jan 2012 15:19:24 +0800
Subject: makedumpfile can't build on Fedora 16
In-Reply-To: <20120120160322.d5dbd362.kumagai-atsushi@mxc.nes.nec.co.jp>
References: <4F15A377.3090302@gmail.com> <4F1613CC.9040405@cn.fujitsu.com>
 <20120118094055.239c362d.oomichi@mxs.nes.nec.co.jp>
 <4F16CCE5.1060500@gmail.com>
 <20120119165816.125f11b0.oomichi@mxs.nes.nec.co.jp>
 <20120120160322.d5dbd362.kumagai-atsushi@mxc.nes.nec.co.jp>
Message-ID: <4F19157C.3090809@gmail.com>

On 01/20/2012 03:03 PM, Atsushi Kumagai wrote:
> Hi,

Hi, Kumagai-san,

> I think that makedumpfile should be compiled with -static option,
> because it must be executable in many environment as possible, e.g. even if
> there are no dynamic libraries in 2nd kernel environment. (as written in README)
>
> But I've got some requests to build it using dynamic libraries,
> so I will change the Makefile as attached patch.
>
> If you want to build makedumpfile using dynamic libraries,
> you need "LINKTYPE=dynamic"(see below).
>
> How to build:
>    a) linking static libraries (default)
>      $ make
>      ...
>      $ ldd makedumpfile
>          not a dynamic executable
>
>    b) linking dynamic libraries
>      $ make LINKTYPE=dynamic
>      ...
>      $ ldd makedumpfile
>          libdw.so.1 =>  /usr/lib64/libdw.so.1 (0x0000003ca2800000)
>          libbz2.so.1 =>  /usr/lib64/libbz2.so.1 (0x000000394b200000)
>          libdl.so.2 =>  /lib64/libdl.so.2 (0x00000031a5a00000)
>          libelf.so.1 =>  /usr/lib64/libelf.so.1 (0x0000003ca2400000)
>          libz.so.1 =>  /usr/lib64/libz.so.1 (0x00000031a6200000)
>          libc.so.6 =>  /lib64/libc.so.6 (0x00000031a5200000)
>          /lib64/ld-linux-x86-64.so.2 (0x00000031a4e00000)
>
> What do you think, Cong?

This also works for me! Thanks for your patch!

BTW, we also need to update README. ;)


From kumagai-atsushi at mxc.nes.nec.co.jp  Fri Jan 20 03:02:44 2012
From: kumagai-atsushi at mxc.nes.nec.co.jp (Atsushi Kumagai)
Date: Fri, 20 Jan 2012 17:02:44 +0900
Subject: makedumpfile can't build on Fedora 16
In-Reply-To: <4F19157C.3090809@gmail.com>
References: <4F15A377.3090302@gmail.com> <4F1613CC.9040405@cn.fujitsu.com>
 <20120118094055.239c362d.oomichi@mxs.nes.nec.co.jp>
 <4F16CCE5.1060500@gmail.com>
 <20120119165816.125f11b0.oomichi@mxs.nes.nec.co.jp>
 <20120120160322.d5dbd362.kumagai-atsushi@mxc.nes.nec.co.jp>
 <4F19157C.3090809@gmail.com>
Message-ID: <20120120170244.c84c4050.kumagai-atsushi@mxc.nes.nec.co.jp>

Hi, Cong

On Fri, 20 Jan 2012 15:19:24 +0800
Cong Wang <xiyou.wangcong at gmail.com> wrote:

> On 01/20/2012 03:03 PM, Atsushi Kumagai wrote:
> > Hi,
> 
> Hi, Kumagai-san,
> 
> > I think that makedumpfile should be compiled with -static option,
> > because it must be executable in many environment as possible, e.g. even if
> > there are no dynamic libraries in 2nd kernel environment. (as written in README)
> >
> > But I've got some requests to build it using dynamic libraries,
> > so I will change the Makefile as attached patch.
> >
> > If you want to build makedumpfile using dynamic libraries,
> > you need "LINKTYPE=dynamic"(see below).
> >
> > How to build:
> >    a) linking static libraries (default)
> >      $ make
> >      ...
> >      $ ldd makedumpfile
> >          not a dynamic executable
> >
> >    b) linking dynamic libraries
> >      $ make LINKTYPE=dynamic
> >      ...
> >      $ ldd makedumpfile
> >          libdw.so.1 =>  /usr/lib64/libdw.so.1 (0x0000003ca2800000)
> >          libbz2.so.1 =>  /usr/lib64/libbz2.so.1 (0x000000394b200000)
> >          libdl.so.2 =>  /lib64/libdl.so.2 (0x00000031a5a00000)
> >          libelf.so.1 =>  /usr/lib64/libelf.so.1 (0x0000003ca2400000)
> >          libz.so.1 =>  /usr/lib64/libz.so.1 (0x00000031a6200000)
> >          libc.so.6 =>  /lib64/libc.so.6 (0x00000031a5200000)
> >          /lib64/ld-linux-x86-64.so.2 (0x00000031a4e00000)
> >
> > What do you think, Cong?
> 
> This also works for me! Thanks for your patch!
> 
> BTW, we also need to update README. ;)

Thank you for your notice.
I will update Makefile and README at v1.4.2.

Thanks
Atsushi Kumagai


From oomichi at mxs.nes.nec.co.jp  Fri Jan 20 02:35:05 2012
From: oomichi at mxs.nes.nec.co.jp (Ken'ichi Ohmichi)
Date: Fri, 20 Jan 2012 16:35:05 +0900
Subject: makedumpfile can't build on Fedora 16
In-Reply-To: <20120120160322.d5dbd362.kumagai-atsushi@mxc.nes.nec.co.jp>
References: <4F15A377.3090302@gmail.com> <4F1613CC.9040405@cn.fujitsu.com>
 <20120118094055.239c362d.oomichi@mxs.nes.nec.co.jp>
 <4F16CCE5.1060500@gmail.com>
 <20120119165816.125f11b0.oomichi@mxs.nes.nec.co.jp>
 <20120120160322.d5dbd362.kumagai-atsushi@mxc.nes.nec.co.jp>
Message-ID: <20120120163505.7ca68741.oomichi@mxs.nes.nec.co.jp>


Hi,

On Fri, 20 Jan 2012 16:03:22 +0900
Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp> wrote:
> > 
> > On Wed, 18 Jan 2012 21:45:09 +0800
> > Cong Wang <xiyou.wangcong at gmail.com> wrote:
> > > >>> ...
> > > >>> gcc -g -O2 -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> > > >>> -D_LARGEFILE64_SOURCE -DVERSION='"1.4.1"' -DRELEASE_DATE='"6 January
> > > >>> 2012"' -D__x86_64__  print_info.o dwarf_info.o elf_info.o erase_info.o
> > > >>> sadump_info.o arch/arm.o arch/x86.o arch/x86_64.o arch/ia64.o
> > > >>> arch/ppc64.o arch/s390x.o -o makedumpfile makedumpfile.c -static -ldw
> > > >>> -lbz2 -lebl -ldl -lelf -lz
> > > >>
> > > >> The parameter has -static, so you need libc.a, libdw.a and ...
> > > >> Or you can remove -static, but you should ensure that there are these
> > > >> dynamic librarys in the second os.
> > > > 
> > > > That's right.
> > > > It has been written in README file of makedumpfile:
> > > 
> > > Hey,
> > > 
> > > This means we have to patch the source code by ourselves, why not
> > > improve it? Something like below?
> > 
> > I guess someone will send "makedumpfile can't run on ..." even if
> > your patch is merged, because these dynamic libraries should be
> > included in the second os and it is easy to forget that.
> > The compiling error is an easy way to notice it, I feel.
> > What do you think, Kumagai-san ?
> > 
> > 
> > Thanks
> > Ken'ichi Ohmichi
> 
> Thank you for your explanation, Ohmichi-san, I agree with you.
> 
> I think that makedumpfile should be compiled with -static option,
> because it must be executable in many environment as possible, e.g. even if
> there are no dynamic libraries in 2nd kernel environment. (as written in README)
> 
> But I've got some requests to build it using dynamic libraries,
> so I will change the Makefile as attached patch. 
>  
> If you want to build makedumpfile using dynamic libraries,
> you need "LINKTYPE=dynamic"(see below).

I like it. good idea :-)


Thanks
Ken'ichi Ohmichi

> How to build:
>   a) linking static libraries (default)
>     $ make
>     ...
>     $ ldd makedumpfile
>         not a dynamic executable
>   
>   b) linking dynamic libraries
>     $ make LINKTYPE=dynamic
>     ...
>     $ ldd makedumpfile
>         libdw.so.1 => /usr/lib64/libdw.so.1 (0x0000003ca2800000)
>         libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x000000394b200000)
>         libdl.so.2 => /lib64/libdl.so.2 (0x00000031a5a00000)
>         libelf.so.1 => /usr/lib64/libelf.so.1 (0x0000003ca2400000)
>         libz.so.1 => /usr/lib64/libz.so.1 (0x00000031a6200000)
>         libc.so.6 => /lib64/libc.so.6 (0x00000031a5200000)
>         /lib64/ld-linux-x86-64.so.2 (0x00000031a4e00000)
> 
> What do you think, Cong?
> 
> Thanks
> Atsushi Kumagai
> 
> 
> diff --git a/Makefile b/Makefile
> index 9afbe1c..b14f09c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -29,6 +29,12 @@ OBJ_PART = print_info.o dwarf_info.o elf_info.o erase_info.o sadump_info.o
>  SRC_ARCH = arch/arm.c arch/x86.c arch/x86_64.c arch/ia64.c arch/ppc64.c arch/s390x.c
>  OBJ_ARCH = arch/arm.o arch/x86.o arch/x86_64.o arch/ia64.o arch/ppc64.o arch/s390x.o
> 
> +ifeq ($(LINKTYPE), dynamic)
> +LIBS = -ldw -lbz2 -lebl -ldl -lelf -lz
> +else
> +LIBS = -static -ldw -lbz2 -lebl -ldl -lelf -lz
> +endif
> +
>  all: makedumpfile
> 
>  $(OBJ_PART): $(SRC_PART)
> @@ -38,7 +44,7 @@ $(OBJ_ARCH): $(SRC_ARCH)
>         $(CC) $(CFLAGS_ARCH) -c -o ./$@ ./$(@:.o=.c)
> 
>  makedumpfile: $(SRC) $(OBJ_PART) $(OBJ_ARCH)
> -       $(CC) $(CFLAGS) $(LDFLAGS) $(OBJ_PART) $(OBJ_ARCH) -o $@ $< -static -ldw -lbz2 -lebl -ldl -lelf -lz
> +       $(CC) $(CFLAGS) $(LDFLAGS) $(OBJ_PART) $(OBJ_ARCH) -o $@ $< $(LIBS)
>         echo .TH MAKEDUMPFILE 8 \"$(DATE)\" \"makedumpfile v$(VERSION)\" \"Linux System Administrator\'s Manual\" > temp.8
>         grep -v "^.TH MAKEDUMPFILE 8" makedumpfile.8 >> temp.8
>         mv temp.8 makedumpfile.8


From pkharche at inmage.com  Sat Jan 21 13:21:17 2012
From: pkharche at inmage.com (Prashant Dinkar Kharche)
Date: Sat, 21 Jan 2012 10:21:17 -0800
Subject: kdump not working Intel S5520UR motherboards with Xeon processor
In-Reply-To: <4EA9D09E.800@draigBrady.com>
References: <20111027203029.GR3452@redhat.com> <4EA9D09E.800@draigBrady.com>
Message-ID: <7967B71B602AF546971AB6303361B1A561AC86E1E8@mbe.inside.abhaisystems.com>

Hi,

I have been trying to get kdump working on Intel S5520 chipset with Xeon processor on RHEL 5 update 5  or update 6, but it appears that when I trigger a crash dump, system reboots abruptly right after loading the kdump kernel. Key observation during this experiment was that when I turn off acpi interrupt handling (acpi=off), crash has worked on RHEL 5 update 5. I have captured output of lspci and cpuinfo  below for reference.

Whereas, on RHEL 6 kdump works fine on this hardware. Could someone please help me identify the patches for RHEL 5 update 5 kernel that might be required for this issue?

00:00.0 Host bridge: Intel Corporation 5520 I/O Hub to ESI Port (rev 22)
00:01.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 1 (rev 22)
00:03.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 3 (rev 22)
00:05.0 PCI bridge: Intel Corporation 5520/X58 I/O Hub PCI Express Root Port 5 (rev 22)
00:07.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 7 (rev 22)
00:09.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 9 (rev 22)
00:0a.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 10 (rev 22)
00:10.0 PIC: Intel Corporation 5520/5500/X58 Physical and Link Layer Registers Port 0 (rev 22)
00:10.1 PIC: Intel Corporation 5520/5500/X58 Routing and Protocol Layer Registers Port 0 (rev 22)
00:11.0 PIC: Intel Corporation 5520/5500 Physical and Link Layer Registers Port 1 (rev 22)
00:11.1 PIC: Intel Corporation 5520/5500 Routing & Protocol Layer Register Port 1 (rev 22)
00:13.0 PIC: Intel Corporation 5520/5500/X58 I/O Hub I/OxAPIC Interrupt Controller (rev 22)
00:14.0 PIC: Intel Corporation 5520/5500/X58 I/O Hub System Management Registers (rev 22)
00:14.1 PIC: Intel Corporation 5520/5500/X58 I/O Hub GPIO and Scratch Pad Registers (rev 22)
00:14.2 PIC: Intel Corporation 5520/5500/X58 I/O Hub Control Status and RAS Registers (rev 22)
00:14.3 PIC: Intel Corporation 5520/5500/X58 I/O Hub Throttle Registers (rev 22)
00:15.0 PIC: Intel Corporation 5520/5500/X58 Trusted Execution Technology Registers (rev 22)
00:16.0 System peripheral: Intel Corporation 5520/5500/X58 Chipset QuickData Technology Device (rev 22)
00:16.1 System peripheral: Intel Corporation 5520/5500/X58 Chipset QuickData Technology Device (rev 22)
00:16.2 System peripheral: Intel Corporation 5520/5500/X58 Chipset QuickData Technology Device (rev 22)
00:16.3 System peripheral: Intel Corporation 5520/5500/X58 Chipset QuickData Technology Device (rev 22)
00:16.4 System peripheral: Intel Corporation 5520/5500/X58 Chipset QuickData Technology Device (rev 22)
00:16.5 System peripheral: Intel Corporation 5520/5500/X58 Chipset QuickData Technology Device (rev 22)
00:16.6 System peripheral: Intel Corporation 5520/5500/X58 Chipset QuickData Technology Device (rev 22)
00:16.7 System peripheral: Intel Corporation 5520/5500/X58 Chipset QuickData Technology Device (rev 22)
00:1a.0 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #4
00:1a.1 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #5
00:1a.2 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #6
00:1a.7 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #2
00:1c.0 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 1
00:1c.4 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 5
00:1c.5 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 6
00:1d.0 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #1
00:1d.1 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #2
00:1d.2 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #3
00:1d.7 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #1
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 90)
00:1f.0 ISA bridge: Intel Corporation 82801JIR (ICH10R) LPC Interface Controller
00:1f.2 IDE interface: Intel Corporation 82801JI (ICH10 Family) 4 port SATA IDE Controller #1
00:1f.3 SMBus: Intel Corporation 82801JI (ICH10 Family) SMBus Controller
00:1f.5 IDE interface: Intel Corporation 82801JI (ICH10 Family) 2 port SATA IDE Controller #2
01:00.0 Ethernet controller: Intel Corporation 82575EB Gigabit Network Connection (rev 02)
01:00.1 Ethernet controller: Intel Corporation 82575EB Gigabit Network Connection (rev 02)
03:00.0 PCI bridge: Integrated Device Technology, Inc. PES24T3G2 PCI Express Gen2 Switch (rev 02)
04:02.0 PCI bridge: Integrated Device Technology, Inc. PES24T3G2 PCI Express Gen2 Switch (rev 02)
04:04.0 PCI bridge: Integrated Device Technology, Inc. PES24T3G2 PCI Express Gen2 Switch (rev 02)
05:00.0 PCI bridge: NEC Corporation Unknown device 014f (rev 02)
06:00.0 PCI bridge: NEC Corporation Unknown device 0150 (rev 02)
06:01.0 PCI bridge: NEC Corporation Unknown device 0151 (rev 02)
06:02.0 PCI bridge: NEC Corporation Unknown device 0152 (rev 02)
07:00.0 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 03)
07:00.1 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 03)
08:00.0 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 03)
08:00.1 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 03)
0b:00.0 PCI bridge: Integrated Device Technology, Inc. PES24T3G2 PCI Express Gen2 Switch (rev 02)
0c:02.0 PCI bridge: Integrated Device Technology, Inc. PES24T3G2 PCI Express Gen2 Switch (rev 02)
0c:04.0 PCI bridge: Integrated Device Technology, Inc. PES24T3G2 PCI Express Gen2 Switch (rev 02)
0e:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
0e:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
0f:00.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1064ET PCI-Express Fusion-MPT SAS (rev 08)
12:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200e [Pilot] ServerEngines (SEP1) (rev 02)

Total 16 cores on CPU --
processor       : 15
vendor_id       : GenuineIntel
cpu family      : 6
model           : 26
model name      : Intel(R) Xeon(R) CPU           E5540  @ 2.53GHz
stepping        : 5
cpu MHz         : 2527.364
cache size      : 8192 KB
physical id     : 1
siblings        : 8
core id         : 3
cpu cores       : 4
apicid          : 23
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc ida nonstop_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr sse4_1 sse4_2 popcnt lahf_lm
bogomips        : 5054.56
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: [8]

Thanking you in anticipation.

Regards,
Prashant


From mirna at medic.upm.edu.my  Sat Jan 21 15:19:02 2012
From: mirna at medic.upm.edu.my (Western Union?? Global Payment Services)
Date: Sun, 22 Jan 2012 04:19:02 +0800 (MYT)
Subject: You have $250,000 lodged in Western Union to be transferred to you.
Message-ID: <208f4681-1de2-44fa-a69e-39f4054f6163@mail>



western union
Respond for details


From levinsasha928 at gmail.com  Sun Jan 22 01:06:07 2012
From: levinsasha928 at gmail.com (Sasha Levin)
Date: Sun, 22 Jan 2012 01:06:07 -0500
Subject: BUG: unable to handle kernel paging request at ffffc7ff81000398
 (sys_kexec_load)
Message-ID: <1327212367.32115.4.camel@lappy>

Hi All,

I got the following BUG() while running trinity within KVM tool.

It looks like the result of a kexec_load(), but I couldn't find any mention of it in the logs - which is strange since logs are supposed to be flushed before actual syscall runs.

[ 3515.829231] BUG: unable to handle kernel paging request at ffffc7ff81000398
[ 3515.830041] IP: [<ffffffff81077281>] native_set_pte+0x1/0x10
[ 3515.830041] PGD 0 
[ 3515.830041] Oops: 0002 [#1] PREEMPT SMP 
[ 3515.830041] CPU 0 
[ 3515.830041] Pid: 17125, comm: trinity Not tainted 3.2.0-next-20120119-sasha-00001-gfaa12a9-dirty #129  
[ 3515.830041] RIP: 0010:[<ffffffff81077281>]  [<ffffffff81077281>] native_set_pte+0x1/0x10
[ 3515.830041] RSP: 0018:ffff8800066a7e48  EFLAGS: 00010282
[ 3515.830041] RAX: 00003ffffffff000 RBX: ffff880005deb040 RCX: 00003ffffffff000
[ 3515.830041] RDX: 00003fff81000000 RSI: 0000000006657163 RDI: ffffc7ff81000398
[ 3515.830041] RBP: ffff8800066a7ed8 R08: ffffea0000199de0 R09: ffff88000ff15140
[ 3515.830041] R10: 0000000005deb000 R11: 0000000000000001 R12: 0000000000000398
[ 3515.830041] R13: 0000000006657000 R14: 0000008000000000 R15: 0001000000000000
[ 3515.830041] FS:  00007fc64b475700(0000) GS:ffff880013a00000(0000) knlGS:0000000000000000
[ 3515.830041] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 3515.830041] CR2: ffffc7ff81000398 CR3: 0000000006749000 CR4: 00000000000406f0
[ 3515.830041] DR0: ffffffff810aaee0 DR1: 0000000000000000 DR2: 0000000000000000
[ 3515.830041] DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000600
[ 3515.830041] Process trinity (pid: 17125, threadinfo ffff8800066a6000, task ffff880005f90000)
[ 3515.830041] Stack:
[ 3515.830041]  ffff8800066a7ed8 ffffffff81071d06 ffff8800066a7e78 ffff88000ff15000
[ 3515.830041]  ffff88000b149000 ffff880006656000 ffff880006656008 0000008000000000
[ 3515.830041]  0000008000000000 0000000014000000 ffff88000ff15000 ffff88000b149008
[ 3515.830041] Call Trace:
[ 3515.830041]  [<ffffffff81071d06>] ? machine_kexec_prepare+0x636/0x820
[ 3515.830041]  [<ffffffff8111bb68>] ? sys_kexec_load+0x98/0x590
[ 3515.830041]  [<ffffffff8111bbd2>] sys_kexec_load+0x102/0x590
[ 3515.830041]  [<ffffffff82583d5d>] ? retint_swapgs+0x13/0x1b
[ 3515.830041]  [<ffffffff8183c29e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 3515.830041]  [<ffffffff82584639>] system_call_fastpath+0x16/0x1b
[ 3515.830041]  [<ffffffff81001001>] ? hypercall_page+0x1/0x1000
[ 3515.830041] Code: 66 2e 0f 1f 84 00 00 00 00 00 55 48 8b 46 18 48 89 e5 48 89 47 04 c9 c3 66 90 55 48 89 e5 0f 01 f8 c9 c3 0f 1f 80 00 00 00 00 55 <48> 89 37 48 89 e5 c9 c3 0f 1f 80 00 00 00 00 55 48 89 37 48 89 
[ 3515.830041] RIP  [<ffffffff81077281>] native_set_pte+0x1/0x10
[ 3515.830041]  RSP <ffff8800066a7e48>
[ 3515.830041] CR2: ffffc7ff81000398
[ 3515.830041] ---[ end trace 9813cf5a73b6d8b6 ]---
[ 3515.830041] BUG: sleeping function called from invalid context at kernel/rwsem.c:21
[ 3515.830041] in_atomic(): 0, irqs_disabled(): 1, pid: 17125, name: trinity
[ 3515.830041] INFO: lockdep is turned off.
[ 3515.830041] irq event stamp: 668
[ 3515.830041] hardirqs last  enabled at (667): [<ffffffff8116fb35>] get_page_from_freelist+0x465/0x8d0
[ 3515.830041] hardirqs last disabled at (668): [<ffffffff82584266>] error_sti+0x5/0x6
[ 3515.830041] softirqs last  enabled at (664): [<ffffffff810b3243>] __do_softirq+0x133/0x180
[ 3515.830041] softirqs last disabled at (641): [<ffffffff82585b6c>] call_softirq+0x1c/0x30
[ 3515.830041] Pid: 17125, comm: trinity Tainted: G      D      3.2.0-next-20120119-sasha-00001-gfaa12a9-dirty #129
[ 3515.830041] Call Trace:
[ 3515.830041]  [<ffffffff81109fc0>] ? print_irqtrace_events+0xd0/0xe0
[ 3515.830041]  [<ffffffff810e1e29>] __might_sleep+0x149/0x200
[ 3515.830041]  [<ffffffff82580ef5>] down_read+0x25/0x90
[ 3515.830041]  [<ffffffff810bfd6f>] exit_signals+0x1f/0x140
[ 3515.830041]  [<ffffffff810b0a8d>] do_exit+0xbd/0x950
[ 3515.830041]  [<ffffffff810ad8f7>] ? kmsg_dump+0x87/0x250
[ 3515.830041]  [<ffffffff8257f9dd>] ? printk+0x63/0x65
[ 3515.830041]  [<ffffffff8104eda2>] oops_end+0xc2/0x110
[ 3515.830041]  [<ffffffff8107cb92>] no_context+0x122/0x2e0
[ 3515.830041]  [<ffffffff8107ce7d>] __bad_area_nosemaphore+0x12d/0x230
[ 3515.830041]  [<ffffffff8107cf8e>] bad_area_nosemaphore+0xe/0x10
[ 3515.830041]  [<ffffffff8107dc0f>] do_page_fault+0x41f/0x4d0
[ 3515.830041]  [<ffffffff8117081e>] ? __alloc_pages_nodemask+0x14e/0x910
[ 3515.830041]  [<ffffffff81076d11>] do_async_page_fault+0x31/0x90
[ 3515.830041]  [<ffffffff82584055>] async_page_fault+0x25/0x30
[ 3515.830041]  [<ffffffff81077281>] ? native_set_pte+0x1/0x10
[ 3515.830041]  [<ffffffff81071d06>] ? machine_kexec_prepare+0x636/0x820
[ 3515.830041]  [<ffffffff8111bb68>] ? sys_kexec_load+0x98/0x590
[ 3515.830041]  [<ffffffff8111bbd2>] sys_kexec_load+0x102/0x590
[ 3515.830041]  [<ffffffff82583d5d>] ? retint_swapgs+0x13/0x1b
[ 3515.830041]  [<ffffffff8183c29e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 3515.830041]  [<ffffffff82584639>] system_call_fastpath+0x16/0x1b
[ 3515.830041]  [<ffffffff81001001>] ? hypercall_page+0x1/0x1000

-- 

Sasha.



From ebiederm at xmission.com  Sat Jan 21 23:49:26 2012
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Sat, 21 Jan 2012 20:49:26 -0800
Subject: BUG: unable to handle kernel paging request at ffffc7ff81000398
 (sys_kexec_load)
In-Reply-To: <1327212367.32115.4.camel@lappy> (Sasha Levin's message of "Sun, 
 22 Jan 2012 01:06:07 -0500")
References: <1327212367.32115.4.camel@lappy>
Message-ID: <m1lip0s5nt.fsf@fess.ebiederm.org>

Sasha Levin <levinsasha928 at gmail.com> writes:

> Hi All,
>
> I got the following BUG() while running trinity within KVM tool.
>
> It looks like the result of a kexec_load(), but I couldn't find any
> mention of it in the logs - which is strange since logs are supposed
> to be flushed before actual syscall runs.

Interesting.

The fact that this happens in native_set_pte would suggest that we are
trying to write to a page table that does not exist.  So this might
be a layer below kexec_load that has the problem.

Do you have the kernel you were testing?    A disassembly of the
native_set_pte, machine_kexec_prepare and sys_kexec_load
would be interesting, for attempting to trace this back to what went
wrong.

Eric


> [ 3515.829231] BUG: unable to handle kernel paging request at ffffc7ff81000398
> [ 3515.830041] IP: [<ffffffff81077281>] native_set_pte+0x1/0x10
> [ 3515.830041] PGD 0 
> [ 3515.830041] Oops: 0002 [#1] PREEMPT SMP 
> [ 3515.830041] CPU 0 
> [ 3515.830041] Pid: 17125, comm: trinity Not tainted 3.2.0-next-20120119-sasha-00001-gfaa12a9-dirty #129  
> [ 3515.830041] RIP: 0010:[<ffffffff81077281>]  [<ffffffff81077281>] native_set_pte+0x1/0x10
> [ 3515.830041] RSP: 0018:ffff8800066a7e48  EFLAGS: 00010282
> [ 3515.830041] RAX: 00003ffffffff000 RBX: ffff880005deb040 RCX: 00003ffffffff000
> [ 3515.830041] RDX: 00003fff81000000 RSI: 0000000006657163 RDI: ffffc7ff81000398
> [ 3515.830041] RBP: ffff8800066a7ed8 R08: ffffea0000199de0 R09: ffff88000ff15140
> [ 3515.830041] R10: 0000000005deb000 R11: 0000000000000001 R12: 0000000000000398
> [ 3515.830041] R13: 0000000006657000 R14: 0000008000000000 R15: 0001000000000000
> [ 3515.830041] FS:  00007fc64b475700(0000) GS:ffff880013a00000(0000) knlGS:0000000000000000
> [ 3515.830041] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 3515.830041] CR2: ffffc7ff81000398 CR3: 0000000006749000 CR4: 00000000000406f0
> [ 3515.830041] DR0: ffffffff810aaee0 DR1: 0000000000000000 DR2: 0000000000000000
> [ 3515.830041] DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000600
> [ 3515.830041] Process trinity (pid: 17125, threadinfo ffff8800066a6000, task ffff880005f90000)
> [ 3515.830041] Stack:
> [ 3515.830041]  ffff8800066a7ed8 ffffffff81071d06 ffff8800066a7e78 ffff88000ff15000
> [ 3515.830041]  ffff88000b149000 ffff880006656000 ffff880006656008 0000008000000000
> [ 3515.830041]  0000008000000000 0000000014000000 ffff88000ff15000 ffff88000b149008
> [ 3515.830041] Call Trace:
> [ 3515.830041]  [<ffffffff81071d06>] ? machine_kexec_prepare+0x636/0x820
> [ 3515.830041]  [<ffffffff8111bb68>] ? sys_kexec_load+0x98/0x590
> [ 3515.830041]  [<ffffffff8111bbd2>] sys_kexec_load+0x102/0x590
> [ 3515.830041]  [<ffffffff82583d5d>] ? retint_swapgs+0x13/0x1b
> [ 3515.830041]  [<ffffffff8183c29e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [ 3515.830041]  [<ffffffff82584639>] system_call_fastpath+0x16/0x1b
> [ 3515.830041]  [<ffffffff81001001>] ? hypercall_page+0x1/0x1000
> [ 3515.830041] Code: 66 2e 0f 1f 84 00 00 00 00 00 55 48 8b 46 18 48 89 e5 48 89 47 04 c9 c3 66 90 55 48 89 e5 0f 01 f8 c9 c3 0f 1f 80 00 00 00 00 55 <48> 89 37 48 89 e5 c9 c3 0f 1f 80 00 00 00 00 55 48 89 37 48 89 
> [ 3515.830041] RIP  [<ffffffff81077281>] native_set_pte+0x1/0x10
> [ 3515.830041]  RSP <ffff8800066a7e48>
> [ 3515.830041] CR2: ffffc7ff81000398
> [ 3515.830041] ---[ end trace 9813cf5a73b6d8b6 ]---
> [ 3515.830041] BUG: sleeping function called from invalid context at kernel/rwsem.c:21
> [ 3515.830041] in_atomic(): 0, irqs_disabled(): 1, pid: 17125, name: trinity
> [ 3515.830041] INFO: lockdep is turned off.
> [ 3515.830041] irq event stamp: 668
> [ 3515.830041] hardirqs last  enabled at (667): [<ffffffff8116fb35>] get_page_from_freelist+0x465/0x8d0
> [ 3515.830041] hardirqs last disabled at (668): [<ffffffff82584266>] error_sti+0x5/0x6
> [ 3515.830041] softirqs last  enabled at (664): [<ffffffff810b3243>] __do_softirq+0x133/0x180
> [ 3515.830041] softirqs last disabled at (641): [<ffffffff82585b6c>] call_softirq+0x1c/0x30
> [ 3515.830041] Pid: 17125, comm: trinity Tainted: G      D      3.2.0-next-20120119-sasha-00001-gfaa12a9-dirty #129
> [ 3515.830041] Call Trace:
> [ 3515.830041]  [<ffffffff81109fc0>] ? print_irqtrace_events+0xd0/0xe0
> [ 3515.830041]  [<ffffffff810e1e29>] __might_sleep+0x149/0x200
> [ 3515.830041]  [<ffffffff82580ef5>] down_read+0x25/0x90
> [ 3515.830041]  [<ffffffff810bfd6f>] exit_signals+0x1f/0x140
> [ 3515.830041]  [<ffffffff810b0a8d>] do_exit+0xbd/0x950
> [ 3515.830041]  [<ffffffff810ad8f7>] ? kmsg_dump+0x87/0x250
> [ 3515.830041]  [<ffffffff8257f9dd>] ? printk+0x63/0x65
> [ 3515.830041]  [<ffffffff8104eda2>] oops_end+0xc2/0x110
> [ 3515.830041]  [<ffffffff8107cb92>] no_context+0x122/0x2e0
> [ 3515.830041]  [<ffffffff8107ce7d>] __bad_area_nosemaphore+0x12d/0x230
> [ 3515.830041]  [<ffffffff8107cf8e>] bad_area_nosemaphore+0xe/0x10
> [ 3515.830041]  [<ffffffff8107dc0f>] do_page_fault+0x41f/0x4d0
> [ 3515.830041]  [<ffffffff8117081e>] ? __alloc_pages_nodemask+0x14e/0x910
> [ 3515.830041]  [<ffffffff81076d11>] do_async_page_fault+0x31/0x90
> [ 3515.830041]  [<ffffffff82584055>] async_page_fault+0x25/0x30
> [ 3515.830041]  [<ffffffff81077281>] ? native_set_pte+0x1/0x10
> [ 3515.830041]  [<ffffffff81071d06>] ? machine_kexec_prepare+0x636/0x820
> [ 3515.830041]  [<ffffffff8111bb68>] ? sys_kexec_load+0x98/0x590
> [ 3515.830041]  [<ffffffff8111bbd2>] sys_kexec_load+0x102/0x590
> [ 3515.830041]  [<ffffffff82583d5d>] ? retint_swapgs+0x13/0x1b
> [ 3515.830041]  [<ffffffff8183c29e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [ 3515.830041]  [<ffffffff82584639>] system_call_fastpath+0x16/0x1b
> [ 3515.830041]  [<ffffffff81001001>] ? hypercall_page+0x1/0x1000


From levinsasha928 at gmail.com  Sun Jan 22 02:18:45 2012
From: levinsasha928 at gmail.com (Sasha Levin)
Date: Sun, 22 Jan 2012 02:18:45 -0500
Subject: BUG: unable to handle kernel paging request at ffffc7ff81000398
 (sys_kexec_load)
In-Reply-To: <m1lip0s5nt.fsf@fess.ebiederm.org>
References: <1327212367.32115.4.camel@lappy> <m1lip0s5nt.fsf@fess.ebiederm.org>
Message-ID: <1327216725.32115.7.camel@lappy>

On Sat, 2012-01-21 at 20:49 -0800, Eric W. Biederman wrote:
> Sasha Levin <levinsasha928 at gmail.com> writes:
> 
> > Hi All,
> >
> > I got the following BUG() while running trinity within KVM tool.
> >
> > It looks like the result of a kexec_load(), but I couldn't find any
> > mention of it in the logs - which is strange since logs are supposed
> > to be flushed before actual syscall runs.
> 
> Interesting.
> 
> The fact that this happens in native_set_pte would suggest that we are
> trying to write to a page table that does not exist.  So this might
> be a layer below kexec_load that has the problem.
> 
> Do you have the kernel you were testing?    A disassembly of the
> native_set_pte, machine_kexec_prepare and sys_kexec_load
> would be interesting, for attempting to trace this back to what went
> wrong.

Yup, It's a pretty simple build of linux-next from today.

>From what I gather, native_set_pte is a simple short function, it also
gets inlined so the disassembly is pretty trivial. I've attached
disassembly of other two functions.

-- 

Sasha.
-------------- next part --------------
0000000000000c00 <sys_kexec_load>:
     c00:	55                   	push   %rbp
     c01:	48 89 e5             	mov    %rsp,%rbp
     c04:	48 81 ec 90 00 00 00 	sub    $0x90,%rsp
     c0b:	48 89 5d d8          	mov    %rbx,-0x28(%rbp)
     c0f:	4c 89 6d e8          	mov    %r13,-0x18(%rbp)
     c13:	4c 89 75 f0          	mov    %r14,-0x10(%rbp)
     c17:	4c 89 7d f8          	mov    %r15,-0x8(%rbp)
     c1b:	4c 89 65 e0          	mov    %r12,-0x20(%rbp)
     c1f:	49 89 d7             	mov    %rdx,%r15
     c22:	49 89 fe             	mov    %rdi,%r14
     c25:	48 89 f3             	mov    %rsi,%rbx
     c28:	49 89 cd             	mov    %rcx,%r13
     c2b:	bf 16 00 00 00       	mov    $0x16,%edi
     c30:	e8 00 00 00 00       	callq  c35 <sys_kexec_load+0x35>
     c35:	89 c2                	mov    %eax,%edx
     c37:	48 c7 c0 ff ff ff ff 	mov    $0xffffffffffffffff,%rax
     c3e:	84 d2                	test   %dl,%dl
     c40:	75 1e                	jne    c60 <sys_kexec_load+0x60>
     c42:	48 8b 5d d8          	mov    -0x28(%rbp),%rbx
     c46:	4c 8b 65 e0          	mov    -0x20(%rbp),%r12
     c4a:	4c 8b 6d e8          	mov    -0x18(%rbp),%r13
     c4e:	4c 8b 75 f0          	mov    -0x10(%rbp),%r14
     c52:	4c 8b 7d f8          	mov    -0x8(%rbp),%r15
     c56:	c9                   	leaveq 
     c57:	c3                   	retq   
     c58:	0f 1f 84 00 00 00 00 	nopl   0x0(%rax,%rax,1)
     c5f:	00 
     c60:	b0 ea                	mov    $0xea,%al
     c62:	41 f7 c5 fc ff 00 00 	test   $0xfffc,%r13d
     c69:	75 d7                	jne    c42 <sys_kexec_load+0x42>
     c6b:	4c 89 ea             	mov    %r13,%rdx
     c6e:	81 e2 00 00 ff ff    	and    $0xffff0000,%edx
     c74:	74 09                	je     c7f <sys_kexec_load+0x7f>
     c76:	48 81 fa 00 00 3e 00 	cmp    $0x3e0000,%rdx
     c7d:	75 c3                	jne    c42 <sys_kexec_load+0x42>
     c7f:	48 c7 c0 ea ff ff ff 	mov    $0xffffffffffffffea,%rax
     c86:	48 83 fb 10          	cmp    $0x10,%rbx
     c8a:	77 b6                	ja     c42 <sys_kexec_load+0x42>
     c8c:	48 c7 c7 00 00 00 00 	mov    $0x0,%rdi
     c93:	e8 00 00 00 00       	callq  c98 <sys_kexec_load+0x98>
     c98:	89 c2                	mov    %eax,%edx
     c9a:	48 c7 c0 f0 ff ff ff 	mov    $0xfffffffffffffff0,%rax
     ca1:	85 d2                	test   %edx,%edx
     ca3:	74 9d                	je     c42 <sys_kexec_load+0x42>
     ca5:	48 c7 45 a0 00 00 00 	movq   $0x0,-0x60(%rbp)
     cac:	00 
     cad:	44 89 e8             	mov    %r13d,%eax
     cb0:	83 e0 01             	and    $0x1,%eax
     cb3:	89 45 94             	mov    %eax,-0x6c(%rbp)
     cb6:	48 c7 c0 00 00 00 00 	mov    $0x0,%rax
     cbd:	48 0f 44 45 a0       	cmove  -0x60(%rbp),%rax
     cc2:	45 31 e4             	xor    %r12d,%r12d
     cc5:	48 89 45 a0          	mov    %rax,-0x60(%rbp)
     cc9:	48 85 db             	test   %rbx,%rbx
     ccc:	0f 84 04 03 00 00    	je     fd6 <sys_kexec_load+0x3d6>
     cd2:	41 f6 c5 01          	test   $0x1,%r13b
     cd6:	0f 84 fd 03 00 00    	je     10d9 <sys_kexec_load+0x4d9>
     cdc:	31 c0                	xor    %eax,%eax
     cde:	83 7d 94 00          	cmpl   $0x0,-0x6c(%rbp)
     ce2:	0f 85 75 01 00 00    	jne    e5d <sys_kexec_load+0x25d>
     ce8:	49 89 c4             	mov    %rax,%r12
     ceb:	41 80 e5 02          	and    $0x2,%r13b
     cef:	74 09                	je     cfa <sys_kexec_load+0xfa>
     cf1:	41 80 8c 24 78 02 00 	orb    $0x2,0x278(%r12)
     cf8:	00 02 
     cfa:	4c 89 e7             	mov    %r12,%rdi
     cfd:	e8 00 00 00 00       	callq  d02 <sys_kexec_load+0x102>
     d02:	85 c0                	test   %eax,%eax
     d04:	0f 85 95 01 00 00    	jne    e9f <sys_kexec_load+0x29f>
     d0a:	4d 89 e5             	mov    %r12,%r13
     d0d:	48 c7 45 98 00 00 00 	movq   $0x0,-0x68(%rbp)
     d14:	00 
     d15:	48 89 5d 80          	mov    %rbx,-0x80(%rbp)
     d19:	41 f6 84 24 78 02 00 	testb  $0x1,0x278(%r12)
     d20:	00 01 
     d22:	0f 85 bc 02 00 00    	jne    fe4 <sys_kexec_load+0x3e4>
     d28:	49 8b 45 40          	mov    0x40(%r13),%rax
     d2c:	4c 89 e7             	mov    %r12,%rdi
     d2f:	48 89 45 b8          	mov    %rax,-0x48(%rbp)
     d33:	49 8b 45 48          	mov    0x48(%r13),%rax
     d37:	48 89 45 b0          	mov    %rax,-0x50(%rbp)
     d3b:	4d 8b 75 50          	mov    0x50(%r13),%r14
     d3f:	4d 8b 7d 58          	mov    0x58(%r13),%r15
     d43:	4c 89 f3             	mov    %r14,%rbx
     d46:	48 81 e3 00 f0 ff ff 	and    $0xfffffffffffff000,%rbx
     d4d:	48 89 de             	mov    %rbx,%rsi
     d50:	48 83 ce 01          	or     $0x1,%rsi
     d54:	e8 c7 f8 ff ff       	callq  620 <kimage_add_entry>
     d59:	83 f8 00             	cmp    $0x0,%eax
     d5c:	0f 85 15 04 00 00    	jne    1177 <sys_kexec_load+0x577>
     d62:	49 89 5c 24 18       	mov    %rbx,0x18(%r12)
     d67:	4c 89 6d a8          	mov    %r13,-0x58(%rbp)
     d6b:	4d 85 ff             	test   %r15,%r15
     d6e:	0f 84 1a 02 00 00    	je     f8e <sys_kexec_load+0x38e>
     d74:	4c 89 f2             	mov    %r14,%rdx
     d77:	be d2 00 02 00       	mov    $0x200d2,%esi
     d7c:	4c 89 e7             	mov    %r12,%rdi
     d7f:	e8 dc f5 ff ff       	callq  360 <kimage_alloc_page>
     d84:	48 85 c0             	test   %rax,%rax
     d87:	0f 84 39 03 00 00    	je     10c6 <sys_kexec_load+0x4c6>
     d8d:	48 bb 00 00 00 00 00 	movabs $0x160000000000,%rbx
     d94:	16 00 00 
     d97:	4c 89 e7             	mov    %r12,%rdi
     d9a:	48 8d 1c 18          	lea    (%rax,%rbx,1),%rbx
     d9e:	48 c1 fb 06          	sar    $0x6,%rbx
     da2:	48 c1 e3 0c          	shl    $0xc,%rbx
     da6:	48 89 de             	mov    %rbx,%rsi
     da9:	48 83 ce 08          	or     $0x8,%rsi
     dad:	e8 6e f8 ff ff       	callq  620 <kimage_add_entry>
     db2:	83 f8 00             	cmp    $0x0,%eax
     db5:	0f 85 cd 01 00 00    	jne    f88 <sys_kexec_load+0x388>
     dbb:	49 81 44 24 18 00 10 	addq   $0x1000,0x18(%r12)
     dc2:	00 00 
     dc4:	31 d2                	xor    %edx,%edx
     dc6:	be 32 00 00 00       	mov    $0x32,%esi
     dcb:	48 c7 c7 00 00 00 00 	mov    $0x0,%rdi
     dd2:	e8 00 00 00 00       	callq  dd7 <sys_kexec_load+0x1d7>
     dd7:	48 b8 00 00 00 00 00 	movabs $0xffff880000000000,%rax
     dde:	88 ff ff 
     de1:	48 8d 04 03          	lea    (%rbx,%rax,1),%rax
     de5:	bb 00 10 00 00       	mov    $0x1000,%ebx
     dea:	48 89 c7             	mov    %rax,%rdi
     ded:	48 89 85 78 ff ff ff 	mov    %rax,-0x88(%rbp)
     df4:	e8 00 00 00 00       	callq  df9 <sys_kexec_load+0x1f9>
     df9:	4c 8b 6d b0          	mov    -0x50(%rbp),%r13
     dfd:	4c 89 f7             	mov    %r14,%rdi
     e00:	81 e7 ff 0f 00 00    	and    $0xfff,%edi
     e06:	48 29 fb             	sub    %rdi,%rbx
     e09:	48 89 bd 70 ff ff ff 	mov    %rdi,-0x90(%rbp)
     e10:	4c 39 fb             	cmp    %r15,%rbx
     e13:	49 0f 47 df          	cmova  %r15,%rbx
     e17:	48 3b 5d b0          	cmp    -0x50(%rbp),%rbx
     e1b:	4c 0f 46 eb          	cmovbe %rbx,%r13
     e1f:	e8 00 00 00 00       	callq  e24 <sys_kexec_load+0x224>
     e24:	48 8b 85 78 ff ff ff 	mov    -0x88(%rbp),%rax
     e2b:	48 8b bd 70 ff ff ff 	mov    -0x90(%rbp),%rdi
     e32:	44 89 ea             	mov    %r13d,%edx
     e35:	48 8d 3c 38          	lea    (%rax,%rdi,1),%rdi
     e39:	48 8b 75 b8          	mov    -0x48(%rbp),%rsi
     e3d:	e8 00 00 00 00       	callq  e42 <sys_kexec_load+0x242>
     e42:	85 c0                	test   %eax,%eax
     e44:	0f 85 12 01 00 00    	jne    f5c <sys_kexec_load+0x35c>
     e4a:	4c 29 6d b0          	sub    %r13,-0x50(%rbp)
     e4e:	49 01 de             	add    %rbx,%r14
     e51:	48 01 5d b8          	add    %rbx,-0x48(%rbp)
     e55:	49 29 df             	sub    %rbx,%r15
     e58:	e9 0e ff ff ff       	jmpq   d6b <sys_kexec_load+0x16b>
     e5d:	4c 89 e7             	mov    %r12,%rdi
     e60:	48 87 3d 00 00 00 00 	xchg   %rdi,0x0(%rip)        # e67 <sys_kexec_load+0x267>
     e67:	e8 f4 f3 ff ff       	callq  260 <kimage_free>
     e6c:	48 c7 45 c8 00 00 00 	movq   $0x0,-0x38(%rbp)
     e73:	00 
     e74:	b8 9d ff ff ff       	mov    $0xffffff9d,%eax
     e79:	4c 3b 35 00 00 00 00 	cmp    0x0(%rip),%r14        # e80 <sys_kexec_load+0x280>
     e80:	73 44                	jae    ec6 <sys_kexec_load+0x2c6>
     e82:	89 85 78 ff ff ff    	mov    %eax,-0x88(%rbp)
     e88:	48 8b 7d c8          	mov    -0x38(%rbp),%rdi
     e8c:	45 31 e4             	xor    %r12d,%r12d
     e8f:	e8 00 00 00 00       	callq  e94 <sys_kexec_load+0x294>
     e94:	e8 00 00 00 00       	callq  e99 <sys_kexec_load+0x299>
     e99:	8b 85 78 ff ff ff    	mov    -0x88(%rbp),%eax
     e9f:	89 85 78 ff ff ff    	mov    %eax,-0x88(%rbp)
     ea5:	48 c7 c7 00 00 00 00 	mov    $0x0,%rdi
     eac:	e8 00 00 00 00       	callq  eb1 <sys_kexec_load+0x2b1>
     eb1:	4c 89 e7             	mov    %r12,%rdi
     eb4:	e8 a7 f3 ff ff       	callq  260 <kimage_free>
     eb9:	8b 85 78 ff ff ff    	mov    -0x88(%rbp),%eax
     ebf:	48 98                	cltq   
     ec1:	e9 7c fd ff ff       	jmpq   c42 <sys_kexec_load+0x42>
     ec6:	4c 3b 35 00 00 00 00 	cmp    0x0(%rip),%r14        # ecd <sys_kexec_load+0x2cd>
     ecd:	77 b3                	ja     e82 <sys_kexec_load+0x282>
     ecf:	48 8d 7d c8          	lea    -0x38(%rbp),%rdi
     ed3:	4c 89 f9             	mov    %r15,%rcx
     ed6:	48 89 da             	mov    %rbx,%rdx
     ed9:	4c 89 f6             	mov    %r14,%rsi
     edc:	e8 1f f8 ff ff       	callq  700 <do_kimage_alloc>
     ee1:	85 c0                	test   %eax,%eax
     ee3:	75 9d                	jne    e82 <sys_kexec_load+0x282>
     ee5:	4c 8b 65 c8          	mov    -0x38(%rbp),%r12
     ee9:	48 8b 0d 00 00 00 00 	mov    0x0(%rip),%rcx        # ef0 <sys_kexec_load+0x2f0>
     ef0:	4c 89 e0             	mov    %r12,%rax
     ef3:	41 80 8c 24 78 02 00 	orb    $0x1,0x278(%r12)
     efa:	00 01 
     efc:	49 89 8c 24 70 02 00 	mov    %rcx,0x270(%r12)
     f03:	00 
     f04:	48 8b 3d 00 00 00 00 	mov    0x0(%rip),%rdi        # f0b <sys_kexec_load+0x30b>
     f0b:	31 d2                	xor    %edx,%edx
     f0d:	48 8b 70 50          	mov    0x50(%rax),%rsi
     f11:	4c 8b 40 58          	mov    0x58(%rax),%r8
     f15:	48 39 f1             	cmp    %rsi,%rcx
     f18:	77 4c                	ja     f66 <sys_kexec_load+0x366>
     f1a:	4a 8d 74 06 ff       	lea    -0x1(%rsi,%r8,1),%rsi
     f1f:	48 39 fe             	cmp    %rdi,%rsi
     f22:	77 42                	ja     f66 <sys_kexec_load+0x366>
     f24:	48 ff c2             	inc    %rdx
     f27:	48 83 c0 20          	add    $0x20,%rax
     f2b:	48 39 d3             	cmp    %rdx,%rbx
     f2e:	77 dd                	ja     f0d <sys_kexec_load+0x30d>
     f30:	4c 89 e7             	mov    %r12,%rdi
     f33:	be 01 00 00 00       	mov    $0x1,%esi
     f38:	e8 00 00 00 00       	callq  f3d <sys_kexec_load+0x33d>
     f3d:	49 89 44 24 28       	mov    %rax,0x28(%r12)
     f42:	4c 8b 65 c8          	mov    -0x38(%rbp),%r12
     f46:	49 83 7c 24 28 00    	cmpq   $0x0,0x28(%r12)
     f4c:	74 22                	je     f70 <sys_kexec_load+0x370>
     f4e:	e8 00 00 00 00       	callq  f53 <sys_kexec_load+0x353>
     f53:	e9 93 fd ff ff       	jmpq   ceb <sys_kexec_load+0xeb>
     f58:	4c 8b 65 a8          	mov    -0x58(%rbp),%r12
     f5c:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
     f61:	e9 39 ff ff ff       	jmpq   e9f <sys_kexec_load+0x29f>
     f66:	b8 9d ff ff ff       	mov    $0xffffff9d,%eax
     f6b:	e9 12 ff ff ff       	jmpq   e82 <sys_kexec_load+0x282>
     f70:	48 c7 c7 00 00 00 00 	mov    $0x0,%rdi
     f77:	31 c0                	xor    %eax,%eax
     f79:	e8 00 00 00 00       	callq  f7e <sys_kexec_load+0x37e>
     f7e:	b8 f4 ff ff ff       	mov    $0xfffffff4,%eax
     f83:	e9 fa fe ff ff       	jmpq   e82 <sys_kexec_load+0x282>
     f88:	0f 8d 36 fe ff ff    	jge    dc4 <sys_kexec_load+0x1c4>
     f8e:	4c 8b 6d a8          	mov    -0x58(%rbp),%r13
     f92:	85 c0                	test   %eax,%eax
     f94:	0f 85 05 ff ff ff    	jne    e9f <sys_kexec_load+0x29f>
     f9a:	48 ff 45 98          	incq   -0x68(%rbp)
     f9e:	49 83 c5 20          	add    $0x20,%r13
     fa2:	48 8b 45 98          	mov    -0x68(%rbp),%rax
     fa6:	48 39 45 80          	cmp    %rax,-0x80(%rbp)
     faa:	0f 87 69 fd ff ff    	ja     d19 <sys_kexec_load+0x119>
     fb0:	49 8b 44 24 08       	mov    0x8(%r12),%rax
     fb5:	48 83 38 00          	cmpq   $0x0,(%rax)
     fb9:	74 09                	je     fc4 <sys_kexec_load+0x3c4>
     fbb:	48 83 c0 08          	add    $0x8,%rax
     fbf:	49 89 44 24 08       	mov    %rax,0x8(%r12)
     fc4:	48 c7 00 04 00 00 00 	movq   $0x4,(%rax)
     fcb:	83 7d 94 00          	cmpl   $0x0,-0x6c(%rbp)
     fcf:	74 05                	je     fd6 <sys_kexec_load+0x3d6>
     fd1:	e8 00 00 00 00       	callq  fd6 <sys_kexec_load+0x3d6>
     fd6:	48 8b 45 a0          	mov    -0x60(%rbp),%rax
     fda:	4c 87 20             	xchg   %r12,(%rax)
     fdd:	31 c0                	xor    %eax,%eax
     fdf:	e9 bb fe ff ff       	jmpq   e9f <sys_kexec_load+0x29f>
     fe4:	49 8b 45 40          	mov    0x40(%r13),%rax
     fe8:	48 89 45 b0          	mov    %rax,-0x50(%rbp)
     fec:	4d 8b 75 48          	mov    0x48(%r13),%r14
     ff0:	49 8b 5d 58          	mov    0x58(%r13),%rbx
     ff4:	49 8b 45 50          	mov    0x50(%r13),%rax
     ff8:	4c 89 65 a8          	mov    %r12,-0x58(%rbp)
     ffc:	48 89 45 b8          	mov    %rax,-0x48(%rbp)
    1000:	48 85 db             	test   %rbx,%rbx
    1003:	0f 84 c7 00 00 00    	je     10d0 <sys_kexec_load+0x4d0>
    1009:	4c 8b 65 b8          	mov    -0x48(%rbp),%r12
    100d:	48 b8 00 00 00 00 00 	movabs $0xffffea0000000000,%rax
    1014:	ea ff ff 
    1017:	49 c1 ec 0c          	shr    $0xc,%r12
    101b:	49 c1 e4 06          	shl    $0x6,%r12
    101f:	49 8d 04 04          	lea    (%r12,%rax,1),%rax
    1023:	48 85 c0             	test   %rax,%rax
    1026:	0f 84 96 00 00 00    	je     10c2 <sys_kexec_load+0x4c2>
    102c:	31 d2                	xor    %edx,%edx
    102e:	be 32 00 00 00       	mov    $0x32,%esi
    1033:	48 c7 c7 00 00 00 00 	mov    $0x0,%rdi
    103a:	41 bf 00 10 00 00    	mov    $0x1000,%r15d
    1040:	e8 00 00 00 00       	callq  1045 <sys_kexec_load+0x445>
    1045:	4c 89 e2             	mov    %r12,%rdx
    1048:	48 b8 00 00 00 00 00 	movabs $0xffff880000000000,%rax
    104f:	88 ff ff 
    1052:	48 c1 e2 06          	shl    $0x6,%rdx
    1056:	48 01 c2             	add    %rax,%rdx
    1059:	48 8b 45 b8          	mov    -0x48(%rbp),%rax
    105d:	25 ff 0f 00 00       	and    $0xfff,%eax
    1062:	48 01 c2             	add    %rax,%rdx
    1065:	49 29 c7             	sub    %rax,%r15
    1068:	48 89 55 88          	mov    %rdx,-0x78(%rbp)
    106c:	49 39 df             	cmp    %rbx,%r15
    106f:	4c 0f 47 fb          	cmova  %rbx,%r15
    1073:	4d 89 fc             	mov    %r15,%r12
    1076:	4d 39 f7             	cmp    %r14,%r15
    1079:	76 17                	jbe    1092 <sys_kexec_load+0x492>
    107b:	48 8b 7d 88          	mov    -0x78(%rbp),%rdi
    107f:	4c 89 fa             	mov    %r15,%rdx
    1082:	4c 01 f7             	add    %r14,%rdi
    1085:	4c 29 f2             	sub    %r14,%rdx
    1088:	31 f6                	xor    %esi,%esi
    108a:	4d 89 f4             	mov    %r14,%r12
    108d:	e8 00 00 00 00       	callq  1092 <sys_kexec_load+0x492>
    1092:	e8 00 00 00 00       	callq  1097 <sys_kexec_load+0x497>
    1097:	44 89 e2             	mov    %r12d,%edx
    109a:	48 8b 75 b0          	mov    -0x50(%rbp),%rsi
    109e:	48 8b 7d 88          	mov    -0x78(%rbp),%rdi
    10a2:	e8 00 00 00 00       	callq  10a7 <sys_kexec_load+0x4a7>
    10a7:	85 c0                	test   %eax,%eax
    10a9:	0f 85 a9 fe ff ff    	jne    f58 <sys_kexec_load+0x358>
    10af:	4d 29 e6             	sub    %r12,%r14
    10b2:	4c 01 7d b8          	add    %r15,-0x48(%rbp)
    10b6:	4c 01 7d b0          	add    %r15,-0x50(%rbp)
    10ba:	4c 29 fb             	sub    %r15,%rbx
    10bd:	e9 3e ff ff ff       	jmpq   1000 <sys_kexec_load+0x400>
    10c2:	4c 8b 65 a8          	mov    -0x58(%rbp),%r12
    10c6:	b8 f4 ff ff ff       	mov    $0xfffffff4,%eax
    10cb:	e9 cf fd ff ff       	jmpq   e9f <sys_kexec_load+0x29f>
    10d0:	4c 8b 65 a8          	mov    -0x58(%rbp),%r12
    10d4:	e9 c1 fe ff ff       	jmpq   f9a <sys_kexec_load+0x39a>
    10d9:	48 c7 45 c8 00 00 00 	movq   $0x0,-0x38(%rbp)
    10e0:	00 
    10e1:	48 8d 7d c8          	lea    -0x38(%rbp),%rdi
    10e5:	4c 89 f9             	mov    %r15,%rcx
    10e8:	48 89 da             	mov    %rbx,%rdx
    10eb:	4c 89 f6             	mov    %r14,%rsi
    10ee:	e8 0d f6 ff ff       	callq  700 <do_kimage_alloc>
    10f3:	85 c0                	test   %eax,%eax
    10f5:	75 51                	jne    1148 <sys_kexec_load+0x548>
    10f7:	4c 8b 65 c8          	mov    -0x38(%rbp),%r12
    10fb:	be 01 00 00 00       	mov    $0x1,%esi
    1100:	4c 89 e7             	mov    %r12,%rdi
    1103:	e8 00 00 00 00       	callq  1108 <sys_kexec_load+0x508>
    1108:	49 89 44 24 28       	mov    %rax,0x28(%r12)
    110d:	4c 8b 75 c8          	mov    -0x38(%rbp),%r14
    1111:	49 83 7e 28 00       	cmpq   $0x0,0x28(%r14)
    1116:	74 4a                	je     1162 <sys_kexec_load+0x562>
    1118:	31 f6                	xor    %esi,%esi
    111a:	4c 89 f7             	mov    %r14,%rdi
    111d:	e8 00 00 00 00       	callq  1122 <sys_kexec_load+0x522>
    1122:	49 89 46 30          	mov    %rax,0x30(%r14)
    1126:	48 8b 45 c8          	mov    -0x38(%rbp),%rax
    112a:	48 83 78 30 00       	cmpq   $0x0,0x30(%rax)
    112f:	0f 85 b3 fb ff ff    	jne    ce8 <sys_kexec_load+0xe8>
    1135:	48 c7 c7 00 00 00 00 	mov    $0x0,%rdi
    113c:	31 c0                	xor    %eax,%eax
    113e:	e8 00 00 00 00       	callq  1143 <sys_kexec_load+0x543>
    1143:	b8 f4 ff ff ff       	mov    $0xfffffff4,%eax
    1148:	89 85 78 ff ff ff    	mov    %eax,-0x88(%rbp)
    114e:	48 8b 7d c8          	mov    -0x38(%rbp),%rdi
    1152:	e8 00 00 00 00       	callq  1157 <sys_kexec_load+0x557>
    1157:	8b 85 78 ff ff ff    	mov    -0x88(%rbp),%eax
    115d:	e9 3d fd ff ff       	jmpq   e9f <sys_kexec_load+0x29f>
    1162:	48 c7 c7 00 00 00 00 	mov    $0x0,%rdi
    1169:	31 c0                	xor    %eax,%eax
    116b:	e8 00 00 00 00       	callq  1170 <sys_kexec_load+0x570>
    1170:	b8 f4 ff ff ff       	mov    $0xfffffff4,%eax
    1175:	eb d1                	jmp    1148 <sys_kexec_load+0x548>
    1177:	0f 8d ea fb ff ff    	jge    d67 <sys_kexec_load+0x167>
    117d:	0f 1f 00             	nopl   (%rax)
    1180:	e9 0d fe ff ff       	jmpq   f92 <sys_kexec_load+0x392>
    1185:	66 66 2e 0f 1f 84 00 	data32 nopw %cs:0x0(%rax,%rax,1)
    118c:	00 00 00 00 

0000000000000040 <machine_kexec_prepare>:
  40:	55                   	push   %rbp
  41:	48 b9 00 00 00 00 00 	movabs $0x160000000000,%rcx
  48:	16 00 00 
  4b:	48 89 e5             	mov    %rsp,%rbp
  4e:	48 89 c8             	mov    %rcx,%rax
  51:	41 57                	push   %r15
  53:	48 ba 00 00 00 00 00 	movabs $0xffff880000000000,%rdx
  5a:	88 ff ff 
  5d:	41 56                	push   %r14
  5f:	41 55                	push   %r13
  61:	41 54                	push   %r12
  63:	53                   	push   %rbx
  64:	48 83 ec 58          	sub    $0x58,%rsp
  68:	48 89 7d c0          	mov    %rdi,-0x40(%rbp)
  6c:	48 03 47 28          	add    0x28(%rdi),%rax
  70:	48 c1 f8 06          	sar    $0x6,%rax
  74:	48 c1 e0 0c          	shl    $0xc,%rax
  78:	48 01 d0             	add    %rdx,%rax
  7b:	48 89 45 98          	mov    %rax,-0x68(%rbp)
  7f:	48 8b 05 00 00 00 00 	mov    0x0(%rip),%rax        # 86 <machine_kexec_prepare+0x46>
  86:	48 c1 e0 0c          	shl    $0xc,%rax
  8a:	48 89 45 b8          	mov    %rax,-0x48(%rbp)
  8e:	48 85 c0             	test   %rax,%rax
  91:	0f 84 b1 07 00 00    	je     848 <machine_kexec_prepare+0x808>
  97:	48 8b 7d 98          	mov    -0x68(%rbp),%rdi
  9b:	48 c7 45 a8 00 00 00 	movq   $0x0,-0x58(%rbp)
  a2:	00 
  a3:	48 89 7d a0          	mov    %rdi,-0x60(%rbp)
  a7:	31 f6                	xor    %esi,%esi
  a9:	48 8b 7d c0          	mov    -0x40(%rbp),%rdi
  ad:	e8 00 00 00 00       	callq  b2 <machine_kexec_prepare+0x72>
  b2:	48 85 c0             	test   %rax,%rax
  b5:	0f 84 c1 05 00 00    	je     67c <machine_kexec_prepare+0x63c>
  bb:	48 ba 00 00 00 00 00 	movabs $0x160000000000,%rdx
  c2:	16 00 00 
  c5:	48 bf 00 00 00 00 00 	movabs $0xffff880000000000,%rdi
  cc:	88 ff ff 
  cf:	48 01 d0             	add    %rdx,%rax
  d2:	4c 8b 75 a8          	mov    -0x58(%rbp),%r14
  d6:	48 c1 f8 06          	sar    $0x6,%rax
  da:	49 81 e6 00 f0 ff ff 	and    $0xfffffffffffff000,%r14
  e1:	48 c1 e0 0c          	shl    $0xc,%rax
  e5:	48 01 c7             	add    %rax,%rdi
  e8:	48 b8 00 00 00 00 80 	movabs $0x8000000000,%rax
  ef:	00 00 00 
  f2:	48 89 7d 90          	mov    %rdi,-0x70(%rbp)
  f6:	4c 01 f0             	add    %r14,%rax
  f9:	48 89 7d c8          	mov    %rdi,-0x38(%rbp)
  fd:	48 89 45 b0          	mov    %rax,-0x50(%rbp)
 101:	49 39 c6             	cmp    %rax,%r14
 104:	0f 83 22 01 00 00    	jae    22c <machine_kexec_prepare+0x1ec>
 10a:	66 0f 1f 44 00 00    	nopw   0x0(%rax,%rax,1)
 110:	4c 39 75 b8          	cmp    %r14,-0x48(%rbp)
 114:	0f 86 12 01 00 00    	jbe    22c <machine_kexec_prepare+0x1ec>
 11a:	31 f6                	xor    %esi,%esi
 11c:	48 8b 7d c0          	mov    -0x40(%rbp),%rdi
 120:	e8 00 00 00 00       	callq  125 <machine_kexec_prepare+0xe5>
 125:	48 85 c0             	test   %rax,%rax
 128:	0f 84 4e 05 00 00    	je     67c <machine_kexec_prepare+0x63c>
 12e:	49 bf 00 00 00 00 00 	movabs $0x160000000000,%r15
 135:	16 00 00 
 138:	48 ba 00 00 00 00 00 	movabs $0xffff880000000000,%rdx
 13f:	88 ff ff 
 142:	4e 8d 3c 38          	lea    (%rax,%r15,1),%r15
 146:	4c 89 f3             	mov    %r14,%rbx
 149:	49 c1 ff 06          	sar    $0x6,%r15
 14d:	48 81 e3 00 f0 ff ff 	and    $0xfffffffffffff000,%rbx
 154:	49 c1 e7 0c          	shl    $0xc,%r15
 158:	4c 8d ab 00 00 00 40 	lea    0x40000000(%rbx),%r13
 15f:	49 01 d7             	add    %rdx,%r15
 162:	4c 39 eb             	cmp    %r13,%rbx
 165:	73 6b                	jae    1d2 <machine_kexec_prepare+0x192>
 167:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 16f <machine_kexec_prepare+0x12f>
 16e:	00 
 16f:	0f 84 1b 05 00 00    	je     690 <machine_kexec_prepare+0x650>
 175:	48 89 df             	mov    %rbx,%rdi
 178:	4d 89 fc             	mov    %r15,%r12
 17b:	48 81 cf e3 01 00 00 	or     $0x1e3,%rdi
 182:	eb 20                	jmp    1a4 <machine_kexec_prepare+0x164>
 184:	0f 1f 40 00          	nopl   0x0(%rax)
 188:	49 83 c4 08          	add    $0x8,%r12
 18c:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 194 <machine_kexec_prepare+0x154>
 193:	00 
 194:	0f 84 f6 04 00 00    	je     690 <machine_kexec_prepare+0x650>
 19a:	48 89 df             	mov    %rbx,%rdi
 19d:	48 81 cf e3 01 00 00 	or     $0x1e3,%rdi
 1a4:	ff 14 25 00 00 00 00 	callq  *0x0
 1ab:	48 89 c6             	mov    %rax,%rsi
 1ae:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 1b6 <machine_kexec_prepare+0x176>
 1b5:	00 
 1b6:	0f 84 d6 04 00 00    	je     692 <machine_kexec_prepare+0x652>
 1bc:	4c 89 e7             	mov    %r12,%rdi
 1bf:	ff 14 25 00 00 00 00 	callq  *0x0
 1c6:	48 81 c3 00 00 20 00 	add    $0x200000,%rbx
 1cd:	49 39 dd             	cmp    %rbx,%r13
 1d0:	77 b6                	ja     188 <machine_kexec_prepare+0x148>
 1d2:	4c 89 ff             	mov    %r15,%rdi
 1d5:	e8 00 00 00 00       	callq  1da <machine_kexec_prepare+0x19a>
 1da:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 1e2 <machine_kexec_prepare+0x1a2>
 1e1:	00 
 1e2:	0f 84 5e 06 00 00    	je     846 <machine_kexec_prepare+0x806>
 1e8:	48 89 c7             	mov    %rax,%rdi
 1eb:	48 83 cf 63          	or     $0x63,%rdi
 1ef:	ff 14 25 00 00 00 00 	callq  *0x0
 1f6:	48 89 c6             	mov    %rax,%rsi
 1f9:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 201 <machine_kexec_prepare+0x1c1>
 200:	00 
 201:	0f 84 28 06 00 00    	je     82f <machine_kexec_prepare+0x7ef>
 207:	48 83 45 c8 08       	addq   $0x8,-0x38(%rbp)
 20c:	48 8b 7d c8          	mov    -0x38(%rbp),%rdi
 210:	48 83 ef 08          	sub    $0x8,%rdi
 214:	ff 14 25 00 00 00 00 	callq  *0x0
 21b:	49 81 c6 00 00 00 40 	add    $0x40000000,%r14
 222:	4c 39 75 b0          	cmp    %r14,-0x50(%rbp)
 226:	0f 87 e4 fe ff ff    	ja     110 <machine_kexec_prepare+0xd0>
 22c:	4c 39 75 b0          	cmp    %r14,-0x50(%rbp)
 230:	76 65                	jbe    297 <machine_kexec_prepare+0x257>
 232:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 23a <machine_kexec_prepare+0x1fa>
 239:	00 
 23a:	0f 84 06 06 00 00    	je     846 <machine_kexec_prepare+0x806>
 240:	48 8b 5d c8          	mov    -0x38(%rbp),%rbx
 244:	48 8b 55 c8          	mov    -0x38(%rbp),%rdx
 248:	48 83 c3 08          	add    $0x8,%rbx
 24c:	4c 8b 65 b0          	mov    -0x50(%rbp),%r12
 250:	eb 15                	jmp    267 <machine_kexec_prepare+0x227>
 252:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 25a <machine_kexec_prepare+0x21a>
 259:	00 
 25a:	0f 84 e6 05 00 00    	je     846 <machine_kexec_prepare+0x806>
 260:	48 89 da             	mov    %rbx,%rdx
 263:	48 83 c3 08          	add    $0x8,%rbx
 267:	31 ff                	xor    %edi,%edi
 269:	ff 14 25 00 00 00 00 	callq  *0x0
 270:	48 89 c6             	mov    %rax,%rsi
 273:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 27b <machine_kexec_prepare+0x23b>
 27a:	00 
 27b:	0f 84 ae 05 00 00    	je     82f <machine_kexec_prepare+0x7ef>
 281:	48 89 d7             	mov    %rdx,%rdi
 284:	ff 14 25 00 00 00 00 	callq  *0x0
 28b:	49 81 c6 00 00 00 40 	add    $0x40000000,%r14
 292:	4d 39 f4             	cmp    %r14,%r12
 295:	77 bb                	ja     252 <machine_kexec_prepare+0x212>
 297:	48 8b 7d 90          	mov    -0x70(%rbp),%rdi
 29b:	e8 00 00 00 00       	callq  2a0 <machine_kexec_prepare+0x260>
 2a0:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 2a8 <machine_kexec_prepare+0x268>
 2a7:	00 
 2a8:	0f 84 96 05 00 00    	je     844 <machine_kexec_prepare+0x804>
 2ae:	48 89 c6             	mov    %rax,%rsi
 2b1:	48 83 ce 63          	or     $0x63,%rsi
 2b5:	48 89 f7             	mov    %rsi,%rdi
 2b8:	ff 14 25 00 00 00 00 	callq  *0x0
 2bf:	48 89 c6             	mov    %rax,%rsi
 2c2:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 2ca <machine_kexec_prepare+0x28a>
 2c9:	00 
 2ca:	0f 84 8d 05 00 00    	je     85d <machine_kexec_prepare+0x81d>
 2d0:	48 83 45 a0 08       	addq   $0x8,-0x60(%rbp)
 2d5:	48 8b 7d a0          	mov    -0x60(%rbp),%rdi
 2d9:	48 83 ef 08          	sub    $0x8,%rdi
 2dd:	ff 14 25 00 00 00 00 	callq  *0x0
 2e4:	48 b8 00 00 00 00 80 	movabs $0x8000000000,%rax
 2eb:	00 00 00 
 2ee:	48 ba ff ff ff ff ff 	movabs $0xffffffffffff,%rdx
 2f5:	ff 00 00 
 2f8:	48 01 45 a8          	add    %rax,-0x58(%rbp)
 2fc:	48 39 55 a8          	cmp    %rdx,-0x58(%rbp)
 300:	77 0e                	ja     310 <machine_kexec_prepare+0x2d0>
 302:	48 8b 7d a8          	mov    -0x58(%rbp),%rdi
 306:	48 39 7d b8          	cmp    %rdi,-0x48(%rbp)
 30a:	0f 87 97 fd ff ff    	ja     a7 <machine_kexec_prepare+0x67>
 310:	48 8b 5d a0          	mov    -0x60(%rbp),%rbx
 314:	49 bd ff ff ff ff ff 	movabs $0xffffffffffff,%r13
 31b:	ff 00 00 
 31e:	45 31 e4             	xor    %r12d,%r12d
 321:	49 be 00 00 00 00 80 	movabs $0x8000000000,%r14
 328:	00 00 00 
 32b:	4c 8b 7d a8          	mov    -0x58(%rbp),%r15
 32f:	eb 3a                	jmp    36b <machine_kexec_prepare+0x32b>
 331:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 339 <machine_kexec_prepare+0x2f9>
 338:	00 
 339:	0f 84 05 05 00 00    	je     844 <machine_kexec_prepare+0x804>
 33f:	4c 89 e7             	mov    %r12,%rdi
 342:	ff 14 25 00 00 00 00 	callq  *0x0
 349:	48 89 c6             	mov    %rax,%rsi
 34c:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 354 <machine_kexec_prepare+0x314>
 353:	00 
 354:	0f 84 03 05 00 00    	je     85d <machine_kexec_prepare+0x81d>
 35a:	48 89 df             	mov    %rbx,%rdi
 35d:	ff 14 25 00 00 00 00 	callq  *0x0
 364:	4d 01 f7             	add    %r14,%r15
 367:	48 83 c3 08          	add    $0x8,%rbx
 36b:	4d 39 ef             	cmp    %r13,%r15
 36e:	76 c1                	jbe    331 <machine_kexec_prepare+0x2f1>
 370:	48 8b 45 c0          	mov    -0x40(%rbp),%rax
 374:	48 8b 58 20          	mov    0x20(%rax),%rbx
 378:	48 81 e3 00 00 e0 ff 	and    $0xffffffffffe00000,%rbx
 37f:	49 89 dc             	mov    %rbx,%r12
 382:	49 c1 ec 24          	shr    $0x24,%r12
 386:	41 81 e4 f8 0f 00 00 	and    $0xff8,%r12d
 38d:	4c 03 65 98          	add    -0x68(%rbp),%r12
 391:	41 f6 04 24 01       	testb  $0x1,(%r12)
 396:	0f 84 16 04 00 00    	je     7b2 <machine_kexec_prepare+0x772>
 39c:	49 8b 04 24          	mov    (%r12),%rax
 3a0:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 3a8 <machine_kexec_prepare+0x368>
 3a7:	00 
 3a8:	0f 84 02 04 00 00    	je     7b0 <machine_kexec_prepare+0x770>
 3ae:	48 89 c7             	mov    %rax,%rdi
 3b1:	ff 14 25 00 00 00 00 	callq  *0x0
 3b8:	49 bd 00 00 00 00 00 	movabs $0xffff880000000000,%r13
 3bf:	88 ff ff 
 3c2:	48 89 da             	mov    %rbx,%rdx
 3c5:	48 b9 00 f0 ff ff ff 	movabs $0x3ffffffff000,%rcx
 3cc:	3f 00 00 
 3cf:	48 c1 ea 1b          	shr    $0x1b,%rdx
 3d3:	48 21 c8             	and    %rcx,%rax
 3d6:	81 e2 f8 0f 00 00    	and    $0xff8,%edx
 3dc:	4c 01 ea             	add    %r13,%rdx
 3df:	4c 8d 24 02          	lea    (%rdx,%rax,1),%r12
 3e3:	41 f6 04 24 01       	testb  $0x1,(%r12)
 3e8:	0f 84 46 03 00 00    	je     734 <machine_kexec_prepare+0x6f4>
 3ee:	49 8b 04 24          	mov    (%r12),%rax
 3f2:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 3fa <machine_kexec_prepare+0x3ba>
 3f9:	00 
 3fa:	0f 84 32 03 00 00    	je     732 <machine_kexec_prepare+0x6f2>
 400:	48 89 c7             	mov    %rax,%rdi
 403:	ff 14 25 00 00 00 00 	callq  *0x0
 40a:	48 b9 00 00 00 00 00 	movabs $0xffff880000000000,%rcx
 411:	88 ff ff 
 414:	48 89 da             	mov    %rbx,%rdx
 417:	48 c1 ea 12          	shr    $0x12,%rdx
 41b:	81 e2 f8 0f 00 00    	and    $0xff8,%edx
 421:	48 01 ca             	add    %rcx,%rdx
 424:	48 b9 00 f0 ff ff ff 	movabs $0x3ffffffff000,%rcx
 42b:	3f 00 00 
 42e:	48 21 c8             	and    %rcx,%rax
 431:	48 01 c2             	add    %rax,%rdx
 434:	f6 02 01             	testb  $0x1,(%rdx)
 437:	0f 84 57 02 00 00    	je     694 <machine_kexec_prepare+0x654>
 43d:	48 8b 55 c0          	mov    -0x40(%rbp),%rdx
 441:	49 c7 c4 00 00 00 00 	mov    $0x0,%r12
 448:	48 b8 00 00 00 00 00 	movabs $0x160000000000,%rax
 44f:	16 00 00 
 452:	4c 89 e3             	mov    %r12,%rbx
 455:	48 03 42 28          	add    0x28(%rdx),%rax
 459:	48 c1 eb 24          	shr    $0x24,%rbx
 45d:	48 c1 f8 06          	sar    $0x6,%rax
 461:	48 ba 00 00 00 00 00 	movabs $0xffff880000000000,%rdx
 468:	88 ff ff 
 46b:	48 c1 e0 0c          	shl    $0xc,%rax
 46f:	81 e3 f8 0f 00 00    	and    $0xff8,%ebx
 475:	48 8d bc 10 00 10 00 	lea    0x1000(%rax,%rdx,1),%rdi
 47c:	00 
 47d:	e8 00 00 00 00       	callq  482 <machine_kexec_prepare+0x442>
 482:	48 03 5d 98          	add    -0x68(%rbp),%rbx
 486:	49 89 c5             	mov    %rax,%r13
 489:	f6 03 01             	testb  $0x1,(%rbx)
 48c:	75 60                	jne    4ee <machine_kexec_prepare+0x4ae>
 48e:	bf d0 00 00 00       	mov    $0xd0,%edi
 493:	e8 00 00 00 00       	callq  498 <machine_kexec_prepare+0x458>
 498:	48 85 c0             	test   %rax,%rax
 49b:	0f 84 90 03 00 00    	je     831 <machine_kexec_prepare+0x7f1>
 4a1:	48 8b 55 c0          	mov    -0x40(%rbp),%rdx
 4a5:	48 89 c7             	mov    %rax,%rdi
 4a8:	48 89 82 80 02 00 00 	mov    %rax,0x280(%rdx)
 4af:	e8 00 00 00 00       	callq  4b4 <machine_kexec_prepare+0x474>
 4b4:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 4bc <machine_kexec_prepare+0x47c>
 4bb:	00 
 4bc:	0f 84 82 03 00 00    	je     844 <machine_kexec_prepare+0x804>
 4c2:	48 89 c6             	mov    %rax,%rsi
 4c5:	48 83 ce 63          	or     $0x63,%rsi
 4c9:	48 89 f7             	mov    %rsi,%rdi
 4cc:	ff 14 25 00 00 00 00 	callq  *0x0
 4d3:	48 89 c6             	mov    %rax,%rsi
 4d6:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 4de <machine_kexec_prepare+0x49e>
 4dd:	00 
 4de:	0f 84 79 03 00 00    	je     85d <machine_kexec_prepare+0x81d>
 4e4:	48 89 df             	mov    %rbx,%rdi
 4e7:	ff 14 25 00 00 00 00 	callq  *0x0
 4ee:	48 8b 03             	mov    (%rbx),%rax
 4f1:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 4f9 <machine_kexec_prepare+0x4b9>
 4f8:	00 
 4f9:	0f 84 b1 02 00 00    	je     7b0 <machine_kexec_prepare+0x770>
 4ff:	48 89 c7             	mov    %rax,%rdi
 502:	ff 14 25 00 00 00 00 	callq  *0x0
 509:	48 b9 00 00 00 00 00 	movabs $0xffff880000000000,%rcx
 510:	88 ff ff 
 513:	4c 89 e2             	mov    %r12,%rdx
 516:	48 c1 ea 1b          	shr    $0x1b,%rdx
 51a:	81 e2 f8 0f 00 00    	and    $0xff8,%edx
 520:	48 01 ca             	add    %rcx,%rdx
 523:	48 b9 00 f0 ff ff ff 	movabs $0x3ffffffff000,%rcx
 52a:	3f 00 00 
 52d:	48 21 c8             	and    %rcx,%rax
 530:	48 8d 1c 02          	lea    (%rdx,%rax,1),%rbx
 534:	f6 03 01             	testb  $0x1,(%rbx)
 537:	75 60                	jne    599 <machine_kexec_prepare+0x559>
 539:	bf d0 00 00 00       	mov    $0xd0,%edi
 53e:	e8 00 00 00 00       	callq  543 <machine_kexec_prepare+0x503>
 543:	48 85 c0             	test   %rax,%rax
 546:	0f 84 e5 02 00 00    	je     831 <machine_kexec_prepare+0x7f1>
 54c:	48 8b 55 c0          	mov    -0x40(%rbp),%rdx
 550:	48 89 c7             	mov    %rax,%rdi
 553:	48 89 82 88 02 00 00 	mov    %rax,0x288(%rdx)
 55a:	e8 00 00 00 00       	callq  55f <machine_kexec_prepare+0x51f>
 55f:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 567 <machine_kexec_prepare+0x527>
 566:	00 
 567:	0f 84 d9 02 00 00    	je     846 <machine_kexec_prepare+0x806>
 56d:	48 89 c6             	mov    %rax,%rsi
 570:	48 83 ce 63          	or     $0x63,%rsi
 574:	48 89 f7             	mov    %rsi,%rdi
 577:	ff 14 25 00 00 00 00 	callq  *0x0
 57e:	48 89 c6             	mov    %rax,%rsi
 581:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 589 <machine_kexec_prepare+0x549>
 588:	00 
 589:	0f 84 a0 02 00 00    	je     82f <machine_kexec_prepare+0x7ef>
 58f:	48 89 df             	mov    %rbx,%rdi
 592:	ff 14 25 00 00 00 00 	callq  *0x0
 599:	48 8b 03             	mov    (%rbx),%rax
 59c:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 5a4 <machine_kexec_prepare+0x564>
 5a3:	00 
 5a4:	0f 84 88 01 00 00    	je     732 <machine_kexec_prepare+0x6f2>
 5aa:	48 89 c7             	mov    %rax,%rdi
 5ad:	ff 14 25 00 00 00 00 	callq  *0x0
 5b4:	48 b9 00 00 00 00 00 	movabs $0xffff880000000000,%rcx
 5bb:	88 ff ff 
 5be:	4c 89 e2             	mov    %r12,%rdx
 5c1:	48 c1 ea 12          	shr    $0x12,%rdx
 5c5:	81 e2 f8 0f 00 00    	and    $0xff8,%edx
 5cb:	48 01 ca             	add    %rcx,%rdx
 5ce:	48 b9 00 f0 ff ff ff 	movabs $0x3ffffffff000,%rcx
 5d5:	3f 00 00 
 5d8:	48 21 c8             	and    %rcx,%rax
 5db:	48 8d 1c 02          	lea    (%rdx,%rax,1),%rbx
 5df:	f6 03 01             	testb  $0x1,(%rbx)
 5e2:	0f 84 e9 00 00 00    	je     6d1 <machine_kexec_prepare+0x691>
 5e8:	48 8b 13             	mov    (%rbx),%rdx
 5eb:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 5f3 <machine_kexec_prepare+0x5b3>
 5f2:	00 
 5f3:	0f 84 d6 00 00 00    	je     6cf <machine_kexec_prepare+0x68f>
 5f9:	48 89 d7             	mov    %rdx,%rdi
 5fc:	ff 14 25 00 00 00 00 	callq  *0x0
 603:	48 89 c2             	mov    %rax,%rdx
 606:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 60e <machine_kexec_prepare+0x5ce>
 60d:	00 
 60e:	48 8b 05 00 00 00 00 	mov    0x0(%rip),%rax        # 615 <machine_kexec_prepare+0x5d5>
 615:	0f 84 b2 00 00 00    	je     6cd <machine_kexec_prepare+0x68d>
 61b:	4c 89 ee             	mov    %r13,%rsi
 61e:	25 63 01 00 00       	and    $0x163,%eax
 623:	48 81 e6 00 f0 ff ff 	and    $0xfffffffffffff000,%rsi
 62a:	48 09 c6             	or     %rax,%rsi
 62d:	48 89 f7             	mov    %rsi,%rdi
 630:	ff 14 25 00 00 00 00 	callq  *0x0
 637:	48 89 c6             	mov    %rax,%rsi
 63a:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 642 <machine_kexec_prepare+0x602>
 641:	00 
 642:	0f 84 83 00 00 00    	je     6cb <machine_kexec_prepare+0x68b>
 648:	49 c1 ec 09          	shr    $0x9,%r12
 64c:	48 b8 00 f0 ff ff ff 	movabs $0x3ffffffff000,%rax
 653:	3f 00 00 
 656:	41 81 e4 f8 0f 00 00 	and    $0xff8,%r12d
 65d:	48 21 c2             	and    %rax,%rdx
 660:	48 bf 00 00 00 00 00 	movabs $0xffff880000000000,%rdi
 667:	88 ff ff 
 66a:	49 8d 3c 3c          	lea    (%r12,%rdi,1),%rdi
 66e:	48 01 d7             	add    %rdx,%rdi
 671:	ff 14 25 00 00 00 00 	callq  *0x0
 678:	31 c0                	xor    %eax,%eax
 67a:	eb 05                	jmp    681 <machine_kexec_prepare+0x641>
 67c:	b8 f4 ff ff ff       	mov    $0xfffffff4,%eax
 681:	48 83 c4 58          	add    $0x58,%rsp
 685:	5b                   	pop    %rbx
 686:	41 5c                	pop    %r12
 688:	41 5d                	pop    %r13
 68a:	41 5e                	pop    %r14
 68c:	41 5f                	pop    %r15
 68e:	c9                   	leaveq 
 68f:	c3                   	retq   
 690:	0f 0b                	ud2    
 692:	0f 0b                	ud2    
 694:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 69c <machine_kexec_prepare+0x65c>
 69b:	00 
 69c:	74 f2                	je     690 <machine_kexec_prepare+0x650>
 69e:	48 81 cb e3 01 00 00 	or     $0x1e3,%rbx
 6a5:	48 89 df             	mov    %rbx,%rdi
 6a8:	ff 14 25 00 00 00 00 	callq  *0x0
 6af:	48 89 c6             	mov    %rax,%rsi
 6b2:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 6ba <machine_kexec_prepare+0x67a>
 6b9:	00 
 6ba:	74 d6                	je     692 <machine_kexec_prepare+0x652>
 6bc:	48 89 d7             	mov    %rdx,%rdi
 6bf:	ff 14 25 00 00 00 00 	callq  *0x0
 6c6:	e9 72 fd ff ff       	jmpq   43d <machine_kexec_prepare+0x3fd>
 6cb:	0f 0b                	ud2    
 6cd:	0f 0b                	ud2    
 6cf:	0f 0b                	ud2    
 6d1:	bf d0 00 00 00       	mov    $0xd0,%edi
 6d6:	e8 00 00 00 00       	callq  6db <machine_kexec_prepare+0x69b>
 6db:	48 85 c0             	test   %rax,%rax
 6de:	0f 84 4d 01 00 00    	je     831 <machine_kexec_prepare+0x7f1>
 6e4:	48 8b 55 c0          	mov    -0x40(%rbp),%rdx
 6e8:	48 89 c7             	mov    %rax,%rdi
 6eb:	48 89 82 90 02 00 00 	mov    %rax,0x290(%rdx)
 6f2:	e8 00 00 00 00       	callq  6f7 <machine_kexec_prepare+0x6b7>
 6f7:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 6ff <machine_kexec_prepare+0x6bf>
 6fe:	00 
 6ff:	74 8f                	je     690 <machine_kexec_prepare+0x650>
 701:	48 89 c6             	mov    %rax,%rsi
 704:	48 83 ce 63          	or     $0x63,%rsi
 708:	48 89 f7             	mov    %rsi,%rdi
 70b:	ff 14 25 00 00 00 00 	callq  *0x0
 712:	48 89 c6             	mov    %rax,%rsi
 715:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 71d <machine_kexec_prepare+0x6dd>
 71c:	00 
 71d:	0f 84 6f ff ff ff    	je     692 <machine_kexec_prepare+0x652>
 723:	48 89 df             	mov    %rbx,%rdi
 726:	ff 14 25 00 00 00 00 	callq  *0x0
 72d:	e9 b6 fe ff ff       	jmpq   5e8 <machine_kexec_prepare+0x5a8>
 732:	0f 0b                	ud2    
 734:	31 f6                	xor    %esi,%esi
 736:	48 8b 7d c0          	mov    -0x40(%rbp),%rdi
 73a:	e8 00 00 00 00       	callq  73f <machine_kexec_prepare+0x6ff>
 73f:	48 85 c0             	test   %rax,%rax
 742:	0f 84 34 ff ff ff    	je     67c <machine_kexec_prepare+0x63c>
 748:	48 ba 00 00 00 00 00 	movabs $0x160000000000,%rdx
 74f:	16 00 00 
 752:	48 01 d0             	add    %rdx,%rax
 755:	48 c1 f8 06          	sar    $0x6,%rax
 759:	48 c1 e0 0c          	shl    $0xc,%rax
 75d:	4e 8d 2c 28          	lea    (%rax,%r13,1),%r13
 761:	4c 89 ef             	mov    %r13,%rdi
 764:	e8 00 00 00 00       	callq  769 <machine_kexec_prepare+0x729>
 769:	4c 89 ef             	mov    %r13,%rdi
 76c:	e8 00 00 00 00       	callq  771 <machine_kexec_prepare+0x731>
 771:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 779 <machine_kexec_prepare+0x739>
 778:	00 
 779:	0f 84 c7 00 00 00    	je     846 <machine_kexec_prepare+0x806>
 77f:	48 89 c6             	mov    %rax,%rsi
 782:	48 83 ce 63          	or     $0x63,%rsi
 786:	48 89 f7             	mov    %rsi,%rdi
 789:	ff 14 25 00 00 00 00 	callq  *0x0
 790:	48 89 c6             	mov    %rax,%rsi
 793:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 79b <machine_kexec_prepare+0x75b>
 79a:	00 
 79b:	0f 84 8e 00 00 00    	je     82f <machine_kexec_prepare+0x7ef>
 7a1:	4c 89 e7             	mov    %r12,%rdi
 7a4:	ff 14 25 00 00 00 00 	callq  *0x0
 7ab:	e9 3e fc ff ff       	jmpq   3ee <machine_kexec_prepare+0x3ae>
 7b0:	0f 0b                	ud2    
 7b2:	31 f6                	xor    %esi,%esi
 7b4:	48 89 c7             	mov    %rax,%rdi
 7b7:	e8 00 00 00 00       	callq  7bc <machine_kexec_prepare+0x77c>
 7bc:	48 85 c0             	test   %rax,%rax
 7bf:	0f 84 b7 fe ff ff    	je     67c <machine_kexec_prepare+0x63c>
 7c5:	48 ba 00 00 00 00 00 	movabs $0x160000000000,%rdx
 7cc:	16 00 00 
 7cf:	49 bd 00 00 00 00 00 	movabs $0xffff880000000000,%r13
 7d6:	88 ff ff 
 7d9:	48 01 d0             	add    %rdx,%rax
 7dc:	48 c1 f8 06          	sar    $0x6,%rax
 7e0:	48 c1 e0 0c          	shl    $0xc,%rax
 7e4:	4e 8d 2c 28          	lea    (%rax,%r13,1),%r13
 7e8:	4c 89 ef             	mov    %r13,%rdi
 7eb:	e8 00 00 00 00       	callq  7f0 <machine_kexec_prepare+0x7b0>
 7f0:	4c 89 ef             	mov    %r13,%rdi
 7f3:	e8 00 00 00 00       	callq  7f8 <machine_kexec_prepare+0x7b8>
 7f8:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 800 <machine_kexec_prepare+0x7c0>
 7ff:	00 
 800:	74 42                	je     844 <machine_kexec_prepare+0x804>
 802:	48 89 c6             	mov    %rax,%rsi
 805:	48 83 ce 63          	or     $0x63,%rsi
 809:	48 89 f7             	mov    %rsi,%rdi
 80c:	ff 14 25 00 00 00 00 	callq  *0x0
 813:	48 89 c6             	mov    %rax,%rsi
 816:	48 83 3d 00 00 00 00 	cmpq   $0x0,0x0(%rip)        # 81e <machine_kexec_prepare+0x7de>
 81d:	00 
 81e:	74 3d                	je     85d <machine_kexec_prepare+0x81d>
 820:	4c 89 e7             	mov    %r12,%rdi
 823:	ff 14 25 00 00 00 00 	callq  *0x0
 82a:	e9 6d fb ff ff       	jmpq   39c <machine_kexec_prepare+0x35c>
 82f:	0f 0b                	ud2    
 831:	48 8b 7d c0          	mov    -0x40(%rbp),%rdi
 835:	e8 c6 f7 ff ff       	callq  0 <free_transition_pgtable>
 83a:	b8 f4 ff ff ff       	mov    $0xfffffff4,%eax
 83f:	e9 3d fe ff ff       	jmpq   681 <machine_kexec_prepare+0x641>
 844:	0f 0b                	ud2    
 846:	0f 0b                	ud2    
 848:	48 8b 45 98          	mov    -0x68(%rbp),%rax
 84c:	48 c7 45 a8 00 00 00 	movq   $0x0,-0x58(%rbp)
 853:	00 
 854:	48 89 45 a0          	mov    %rax,-0x60(%rbp)
 858:	e9 b3 fa ff ff       	jmpq   310 <machine_kexec_prepare+0x2d0>
 85d:	0f 0b                	ud2    
 85f:	90                   	nop


From dzickus at redhat.com  Mon Jan 23 10:18:54 2012
From: dzickus at redhat.com (Don Zickus)
Date: Mon, 23 Jan 2012 10:18:54 -0500
Subject: kdump not working Intel S5520UR motherboards with Xeon processor
In-Reply-To: <7967B71B602AF546971AB6303361B1A561AC86E1E8@mbe.inside.abhaisystems.com>
References: <20111027203029.GR3452@redhat.com> <4EA9D09E.800@draigBrady.com>
 <7967B71B602AF546971AB6303361B1A561AC86E1E8@mbe.inside.abhaisystems.com>
Message-ID: <20120123151854.GL5650@redhat.com>

On Sat, Jan 21, 2012 at 10:21:17AM -0800, Prashant Dinkar Kharche wrote:
> Hi,
> 
> I have been trying to get kdump working on Intel S5520 chipset with Xeon processor on RHEL 5 update 5  or update 6, but it appears that when I trigger a crash dump, system reboots abruptly right after loading the kdump kernel. Key observation during this experiment was that when I turn off acpi interrupt handling (acpi=off), crash has worked on RHEL 5 update 5. I have captured output of lspci and cpuinfo  below for reference.
> 
> Whereas, on RHEL 6 kdump works fine on this hardware. Could someone please help me identify the patches for RHEL 5 update 5 kernel that might be required for this issue?

This can only be done by Red Hat as they are the only ones that know what
patches are in their kernel.  Please file a bugzilla or work with your TAM
to bring attention to the problem at Red Hat.

Cheers,
Don


From horms at verge.net.au  Tue Jan 24 21:39:30 2012
From: horms at verge.net.au (Simon Horman)
Date: Wed, 25 Jan 2012 11:39:30 +0900
Subject: kexec 2.0.2 MIPS
In-Reply-To: <F9C551623D2CBB4C9488801D14F864C60E2D98@ex-mb1.corp.adtran.com>
References: <F9C551623D2CBB4C9488801D14F864C607154A@ex-mb1.corp.adtran.com>
 <20110920085133.GE15087@verge.net.au>
 <F9C551623D2CBB4C9488801D14F864C6072473@ex-mb1.corp.adtran.com>
 <20110921112837.GF17108@verge.net.au>
 <F9C551623D2CBB4C9488801D14F864C60E2D98@ex-mb1.corp.adtran.com>
Message-ID: <20120125023929.GK11038@verge.net.au>

Hi,

sorry for the extensive delay in responding to this.
I am now back from Christmas, New Year, holidays and
attending LCA 2012.

On Fri, Dec 16, 2011 at 05:27:31AM +0000, ANDY KENNEDY wrote:
> Simon/All,
> 
> After two months, I'm back working on this again.  After 3 hours
> tonight, I have the final result of what you told me to do.  Looks like,
> based on the comment:
> 
>     - remove kexec/arch/mips/mips-setup-simple.S which prepares cmdline for
>       new kernel, it is better to move this work to kernel code. BTW this code was
>       compilable only on o32 because of t4 is not defined on 64-64 or n32 MIPS ABIs.
> 
> The problem is that my 2.6.36.2 apparently doesn't have whatever Maxim
> is talking about.  Therefore, the newer versions must not be backwards
> compatible.  Perhaps this is okay with you guys.  If so, I'll just make
> sure to include a patch to BuildRoot that clearly states that the v2.0.1
> is the only version that works with *some* versions of MIPS.  If you
> guys were expecting this to be backwards compatible, I'll gladly work
> with you to test whatever you need checked out.  Just let me know.

It is not apparent to me that the kernel code Maxim makes mention of
exists in any released kernel. I think that the best option at this
stage would be to revert that portion of his change.

Maxim, do you have any thoughts on this?

Andy, could you prepare a patch to do that?
At the very least it ought to be useful to you.

> There are build errors that I would like (if it hasn't already) to
> be fixed
> 1) in purgatory/Makefile, Near line 71
> 
> $(PURGATORY): LDFLAGS=$($(ARCH)_PURGATORY_EXTRA_CFLAGS)\
>                         --no-undefined -nostartfiles -nostdlib -nodefaultlibs \
>                         -e purgatory_start -r
> 
> 
> The newer gcc's don't like --no-undefined.  I think a fix is
> -Wl,--no-undefined.

Thanks, there is a fix for that in git and 2.0.3.

> 2) In the newer version of the kexec/arch/mips/Makefile, there is
> a -Werror in the CFLAGS.  This causes the build to fail if using a
> newer version of gcc, as many more warnings are available.

Thanks, there is a fix for that in git and 2.0.3.

Due to some quirks in the kexec build system
-Werror was effecting all architectures.

> Now, here is the result of the bisect:
> 
> root at akennedy_lin:~/src/kexec/kexec-tools# git bisect good
> 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17 is the first bad commit
> commit 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17
> Author: Maxim Uvarov <muvarov at gmail.com>
> Date:   Wed Mar 3 14:05:53 2010 +0300
> 
>     some kexec MIPS improvements
>     
>     -  using simple   mips* ) in configure.ac to make it compilable on mips2
>        and mips64
>     - remove kexec/arch/mips/mips-setup-simple.S which prepares cmdline for
>       new kernel, it is better to move this work to kernel code. BTW this code was
>       compilable only on o32 because of t4 is not defined on 64-64 or n32 MIPS ABIs.
>     - simple put cmdline as string, kernel code should catch cmdline like this
>     
>     int board_kexec_prepare(struct kimage *image)
>     {
>         int i;
>         char *bootloader = "kexec";
>         board_boot_desc_ptr->argc = 0;
>         for(i=0;i<image->nr_segments;i++)
>         {
>             printk("segment %d
>             if (!strncmp(bootloader, (char*)image->segment[i].buf,
>                     strlen(bootloader)))
>             {
>                 /*
>                  * convert command line string to array
>                  * of parameters (as bootloader does).
>                  */
>                 int argc = 0, offt;
>                 char *str = (char *)image->segment[i].buf;
>                 char *ptr = strchr(str, ' ');
>                 while (ptr && (ARGV_MAX_ARGS > argc)) {
>                     *ptr = '\0';
>                     if (ptr[1] != ' ') {
>                         offt = (int)(ptr - str + 1);
>                         boot_desc_ptr->argv[argc] =
>                             image->segment[i].mem + offt;
>                         argc++;
>                     }
>                     ptr = strchr(ptr + 1, ' ');
>                 }
>                 boot_desc_ptr->argc = argc;
>                 break;
>             }
>         }
>        Keep it as string make code simple and more readable.
>     
>     - add crashdump support
>     - do not redefine syscalls numbers if they defined in system
>       remove fixups for /proc/iomem. If your board provides wrong /proc/iomem please
>       fix kernel, or at least you local version of kexec. No need to support it in
>       main line. At least add option --fake-iomem
>     - some minor fixes
>     
>     Signed-off-by: Maxim Uvarov <muvarov at gmail.com>
>     Signed-off-by: Simon Horman <horms at verge.net.au>
> 
> :100644 100644 a911f8ad03c5321faeba93069924fa79aceeba9c 88d2e0bb2479ecd956d0ec31c571d2472fef7721 M      configure.ac
> :040000 040000 4dcef15024daa7ccc62bd6983e127cb87f036c5d 69204c980286b2e08308d4a10eb2bf2775d9d962 M      kexec
> 
> Andy
> 
> > -----Original Message-----
> > From: ANDY KENNEDY
> > Sent: Thursday, September 29, 2011 1:07 PM
> > To: 'Simon Horman'
> > Cc: kexec at lists.infradead.org; Matt Evans; Maxim Uvarov
> > Subject: RE: kexec 2.0.2 MIPS
> > 
> > > My bad, yes the idea is to check between 2.0.1 and 2.0.2.
> > > I will explain git bisect further down. However, it looking at
> > the
> > > logs
> > > it strikes me that there was only one significant MIPS change
> > > between
> > > 2.0.1 and 2.0.2. So that seems like a likely culprit.
> > >
> > > Could you try the following?
> > >
> > > $ git clone git://github.com/horms/kexec-tools.git
> > > $ cd kexec-tools
> > > $ git checkout 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17^
> > 
> > Works.
> > 
> > >
> > > Build and see if it works. If so could you then try?
> > >
> > > $ git checkout 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17
> > 
> > Works.
> > 
> > >
> > > Build and see if it works. If it does not then
> > > revision 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17 starts to smell
> > > a lot like the cause of the problem you have observed.
> > >
> > >
> > > Git Bisect
> > > ----------
> > >
> > > A git bisection works by doing a binary search over a set of
> > > commits
> > > in order to (hopefully) isolate which commit introduces a
> > > regression.
> > >
> > > To this, the git commands are something along these lines:
> > >
> > > $ git clone git://github.com/horms/kexec-tools.git
> > > $ cd kexec-tools
> > > $ git checkout v2.0.1
> > 
> > root at akennedy_lin:~/src/kexec/kexec-tools# git checkout v2.0.1
> > error: pathspec 'v2.0.1' did not match any file(s) known to git.
> > (yes, I run as root.  Have since 1994, so, please no holy wars.)
> > 
> > >
> > > Build and confirm that it does work
> > >
> > > $ git checkout v2.0.2
> > >
> > > Build and confirm that it does not work.
> > >
> > > Now we actually start the bisect
> > >
> > > $ git bisect start
> > > $ git bisect bad v2.0.2
> > > $ git bisect good v2.0.1
> > >
> > > Git should now select a revision between v2.0.1 and v2.0.2
> > > Test it and see if it works or not. If it does run
> > >
> > > $ git bisect good
> > > If not run
> > >
> > > $ git bisect bad
> > >
> > > Git will now select another revision for you to test...
> > 
> > I have some time right now to test, so, when you can get
> > back to me I'll be able to continue.
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 


From muvarov at gmail.com  Wed Jan 25 01:35:42 2012
From: muvarov at gmail.com (Maxim Uvarov)
Date: Tue, 24 Jan 2012 22:35:42 -0800
Subject: kexec 2.0.2 MIPS
In-Reply-To: <20120125023929.GK11038@verge.net.au>
References: <F9C551623D2CBB4C9488801D14F864C607154A@ex-mb1.corp.adtran.com>
 <20110920085133.GE15087@verge.net.au>
 <F9C551623D2CBB4C9488801D14F864C6072473@ex-mb1.corp.adtran.com>
 <20110921112837.GF17108@verge.net.au>
 <F9C551623D2CBB4C9488801D14F864C60E2D98@ex-mb1.corp.adtran.com>
 <20120125023929.GK11038@verge.net.au>
Message-ID: <CAJGZr0LShFy2rcPi4+ywDuavovxRH5jNJuRtQb3PGGzt1mfy_Q@mail.gmail.com>

2012/1/24 Simon Horman <horms at verge.net.au>:
> Hi,
>
> sorry for the extensive delay in responding to this.
> I am now back from Christmas, New Year, holidays and
> attending LCA 2012.
>
> On Fri, Dec 16, 2011 at 05:27:31AM +0000, ANDY KENNEDY wrote:
>> Simon/All,
>>
>> After two months, I'm back working on this again. ?After 3 hours
>> tonight, I have the final result of what you told me to do. ?Looks like,
>> based on the comment:
>>
>> ? ? - remove kexec/arch/mips/mips-setup-simple.S which prepares cmdline for
>> ? ? ? new kernel, it is better to move this work to kernel code. BTW this code was
>> ? ? ? compilable only on o32 because of t4 is not defined on 64-64 or n32 MIPS ABIs.
>>
>> The problem is that my 2.6.36.2 apparently doesn't have whatever Maxim
>> is talking about. ?Therefore, the newer versions must not be backwards
>> compatible. ?Perhaps this is okay with you guys. ?If so, I'll just make
>> sure to include a patch to BuildRoot that clearly states that the v2.0.1
>> is the only version that works with *some* versions of MIPS. ?If you
>> guys were expecting this to be backwards compatible, I'll gladly work
>> with you to test whatever you need checked out. ?Just let me know.
>
> It is not apparent to me that the kernel code Maxim makes mention of
> exists in any released kernel. I think that the best option at this
> stage would be to revert that portion of his change.
>
> Maxim, do you have any thoughts on this?
>

Yes, kernel patches were not accepted and looks like stuck linux-mips@
queue forever.
Reverting this patches it ok for me especially if somebody going to
work on them. As I remember
the was problem with supporting all mips ABIs (o32, n32, 32-64). It's
mostly related to asm purgatory
code. It will be nice if somebody can synchronize kernel and user land
parts and make mips kexec code
board independent. I think at this time it should be much easy since
mips supports device tree.

Maxim.

> Andy, could you prepare a patch to do that?
> At the very least it ought to be useful to you.
>
>> There are build errors that I would like (if it hasn't already) to
>> be fixed
>> 1) in purgatory/Makefile, Near line 71
>>
>> $(PURGATORY): LDFLAGS=$($(ARCH)_PURGATORY_EXTRA_CFLAGS)\
>> ? ? ? ? ? ? ? ? ? ? ? ? --no-undefined -nostartfiles -nostdlib -nodefaultlibs \
>> ? ? ? ? ? ? ? ? ? ? ? ? -e purgatory_start -r
>>
>>
>> The newer gcc's don't like --no-undefined. ?I think a fix is
>> -Wl,--no-undefined.
>
> Thanks, there is a fix for that in git and 2.0.3.
>
>> 2) In the newer version of the kexec/arch/mips/Makefile, there is
>> a -Werror in the CFLAGS. ?This causes the build to fail if using a
>> newer version of gcc, as many more warnings are available.
>
> Thanks, there is a fix for that in git and 2.0.3.
>
> Due to some quirks in the kexec build system
> -Werror was effecting all architectures.
>
>> Now, here is the result of the bisect:
>>
>> root at akennedy_lin:~/src/kexec/kexec-tools# git bisect good
>> 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17 is the first bad commit
>> commit 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17
>> Author: Maxim Uvarov <muvarov at gmail.com>
>> Date: ? Wed Mar 3 14:05:53 2010 +0300
>>
>> ? ? some kexec MIPS improvements
>>
>> ? ? - ?using simple ? mips* ) in configure.ac to make it compilable on mips2
>> ? ? ? ?and mips64
>> ? ? - remove kexec/arch/mips/mips-setup-simple.S which prepares cmdline for
>> ? ? ? new kernel, it is better to move this work to kernel code. BTW this code was
>> ? ? ? compilable only on o32 because of t4 is not defined on 64-64 or n32 MIPS ABIs.
>> ? ? - simple put cmdline as string, kernel code should catch cmdline like this
>>
>> ? ? int board_kexec_prepare(struct kimage *image)
>> ? ? {
>> ? ? ? ? int i;
>> ? ? ? ? char *bootloader = "kexec";
>> ? ? ? ? board_boot_desc_ptr->argc = 0;
>> ? ? ? ? for(i=0;i<image->nr_segments;i++)
>> ? ? ? ? {
>> ? ? ? ? ? ? printk("segment %d
>> ? ? ? ? ? ? if (!strncmp(bootloader, (char*)image->segment[i].buf,
>> ? ? ? ? ? ? ? ? ? ? strlen(bootloader)))
>> ? ? ? ? ? ? {
>> ? ? ? ? ? ? ? ? /*
>> ? ? ? ? ? ? ? ? ?* convert command line string to array
>> ? ? ? ? ? ? ? ? ?* of parameters (as bootloader does).
>> ? ? ? ? ? ? ? ? ?*/
>> ? ? ? ? ? ? ? ? int argc = 0, offt;
>> ? ? ? ? ? ? ? ? char *str = (char *)image->segment[i].buf;
>> ? ? ? ? ? ? ? ? char *ptr = strchr(str, ' ');
>> ? ? ? ? ? ? ? ? while (ptr && (ARGV_MAX_ARGS > argc)) {
>> ? ? ? ? ? ? ? ? ? ? *ptr = '\0';
>> ? ? ? ? ? ? ? ? ? ? if (ptr[1] != ' ') {
>> ? ? ? ? ? ? ? ? ? ? ? ? offt = (int)(ptr - str + 1);
>> ? ? ? ? ? ? ? ? ? ? ? ? boot_desc_ptr->argv[argc] =
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? image->segment[i].mem + offt;
>> ? ? ? ? ? ? ? ? ? ? ? ? argc++;
>> ? ? ? ? ? ? ? ? ? ? }
>> ? ? ? ? ? ? ? ? ? ? ptr = strchr(ptr + 1, ' ');
>> ? ? ? ? ? ? ? ? }
>> ? ? ? ? ? ? ? ? boot_desc_ptr->argc = argc;
>> ? ? ? ? ? ? ? ? break;
>> ? ? ? ? ? ? }
>> ? ? ? ? }
>> ? ? ? ?Keep it as string make code simple and more readable.
>>
>> ? ? - add crashdump support
>> ? ? - do not redefine syscalls numbers if they defined in system
>> ? ? ? remove fixups for /proc/iomem. If your board provides wrong /proc/iomem please
>> ? ? ? fix kernel, or at least you local version of kexec. No need to support it in
>> ? ? ? main line. At least add option --fake-iomem
>> ? ? - some minor fixes
>>
>> ? ? Signed-off-by: Maxim Uvarov <muvarov at gmail.com>
>> ? ? Signed-off-by: Simon Horman <horms at verge.net.au>
>>
>> :100644 100644 a911f8ad03c5321faeba93069924fa79aceeba9c 88d2e0bb2479ecd956d0ec31c571d2472fef7721 M ? ? ?configure.ac
>> :040000 040000 4dcef15024daa7ccc62bd6983e127cb87f036c5d 69204c980286b2e08308d4a10eb2bf2775d9d962 M ? ? ?kexec
>>
>> Andy
>>
>> > -----Original Message-----
>> > From: ANDY KENNEDY
>> > Sent: Thursday, September 29, 2011 1:07 PM
>> > To: 'Simon Horman'
>> > Cc: kexec at lists.infradead.org; Matt Evans; Maxim Uvarov
>> > Subject: RE: kexec 2.0.2 MIPS
>> >
>> > > My bad, yes the idea is to check between 2.0.1 and 2.0.2.
>> > > I will explain git bisect further down. However, it looking at
>> > the
>> > > logs
>> > > it strikes me that there was only one significant MIPS change
>> > > between
>> > > 2.0.1 and 2.0.2. So that seems like a likely culprit.
>> > >
>> > > Could you try the following?
>> > >
>> > > $ git clone git://github.com/horms/kexec-tools.git
>> > > $ cd kexec-tools
>> > > $ git checkout 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17^
>> >
>> > Works.
>> >
>> > >
>> > > Build and see if it works. If so could you then try?
>> > >
>> > > $ git checkout 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17
>> >
>> > Works.
>> >
>> > >
>> > > Build and see if it works. If it does not then
>> > > revision 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17 starts to smell
>> > > a lot like the cause of the problem you have observed.
>> > >
>> > >
>> > > Git Bisect
>> > > ----------
>> > >
>> > > A git bisection works by doing a binary search over a set of
>> > > commits
>> > > in order to (hopefully) isolate which commit introduces a
>> > > regression.
>> > >
>> > > To this, the git commands are something along these lines:
>> > >
>> > > $ git clone git://github.com/horms/kexec-tools.git
>> > > $ cd kexec-tools
>> > > $ git checkout v2.0.1
>> >
>> > root at akennedy_lin:~/src/kexec/kexec-tools# git checkout v2.0.1
>> > error: pathspec 'v2.0.1' did not match any file(s) known to git.
>> > (yes, I run as root. ?Have since 1994, so, please no holy wars.)
>> >
>> > >
>> > > Build and confirm that it does work
>> > >
>> > > $ git checkout v2.0.2
>> > >
>> > > Build and confirm that it does not work.
>> > >
>> > > Now we actually start the bisect
>> > >
>> > > $ git bisect start
>> > > $ git bisect bad v2.0.2
>> > > $ git bisect good v2.0.1
>> > >
>> > > Git should now select a revision between v2.0.1 and v2.0.2
>> > > Test it and see if it works or not. If it does run
>> > >
>> > > $ git bisect good
>> > > If not run
>> > >
>> > > $ git bisect bad
>> > >
>> > > Git will now select another revision for you to test...
>> >
>> > I have some time right now to test, so, when you can get
>> > back to me I'll be able to continue.
>>
>> _______________________________________________
>> kexec mailing list
>> kexec at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
>>



-- 
Best regards,
Maxim Uvarov


From horms at verge.net.au  Wed Jan 25 01:57:08 2012
From: horms at verge.net.au (Simon Horman)
Date: Wed, 25 Jan 2012 15:57:08 +0900
Subject: kexec 2.0.2 MIPS
In-Reply-To: <CAJGZr0LShFy2rcPi4+ywDuavovxRH5jNJuRtQb3PGGzt1mfy_Q@mail.gmail.com>
References: <F9C551623D2CBB4C9488801D14F864C607154A@ex-mb1.corp.adtran.com>
 <20110920085133.GE15087@verge.net.au>
 <F9C551623D2CBB4C9488801D14F864C6072473@ex-mb1.corp.adtran.com>
 <20110921112837.GF17108@verge.net.au>
 <F9C551623D2CBB4C9488801D14F864C60E2D98@ex-mb1.corp.adtran.com>
 <20120125023929.GK11038@verge.net.au>
 <CAJGZr0LShFy2rcPi4+ywDuavovxRH5jNJuRtQb3PGGzt1mfy_Q@mail.gmail.com>
Message-ID: <20120125065708.GB18345@verge.net.au>

On Tue, Jan 24, 2012 at 10:35:42PM -0800, Maxim Uvarov wrote:
> 2012/1/24 Simon Horman <horms at verge.net.au>:
> > Hi,
> >
> > sorry for the extensive delay in responding to this.
> > I am now back from Christmas, New Year, holidays and
> > attending LCA 2012.
> >
> > On Fri, Dec 16, 2011 at 05:27:31AM +0000, ANDY KENNEDY wrote:
> >> Simon/All,
> >>
> >> After two months, I'm back working on this again. ?After 3 hours
> >> tonight, I have the final result of what you told me to do. ?Looks like,
> >> based on the comment:
> >>
> >> ? ? - remove kexec/arch/mips/mips-setup-simple.S which prepares cmdline for
> >> ? ? ? new kernel, it is better to move this work to kernel code. BTW this code was
> >> ? ? ? compilable only on o32 because of t4 is not defined on 64-64 or n32 MIPS ABIs.
> >>
> >> The problem is that my 2.6.36.2 apparently doesn't have whatever Maxim
> >> is talking about. ?Therefore, the newer versions must not be backwards
> >> compatible. ?Perhaps this is okay with you guys. ?If so, I'll just make
> >> sure to include a patch to BuildRoot that clearly states that the v2.0.1
> >> is the only version that works with *some* versions of MIPS. ?If you
> >> guys were expecting this to be backwards compatible, I'll gladly work
> >> with you to test whatever you need checked out. ?Just let me know.
> >
> > It is not apparent to me that the kernel code Maxim makes mention of
> > exists in any released kernel. I think that the best option at this
> > stage would be to revert that portion of his change.
> >
> > Maxim, do you have any thoughts on this?
> >
> 
> Yes, kernel patches were not accepted and looks like stuck linux-mips@
> queue forever.
> Reverting this patches it ok for me especially if somebody going to
> work on them. As I remember
> the was problem with supporting all mips ABIs (o32, n32, 32-64). It's
> mostly related to asm purgatory
> code. It will be nice if somebody can synchronize kernel and user land
> parts and make mips kexec code
> board independent. I think at this time it should be much easy since
> mips supports device tree.

Thanks Maxim.

Andy can you prepare a patch to revert the problematic portion
of the change?


From xiyou.wangcong at gmail.com  Wed Jan 25 05:50:07 2012
From: xiyou.wangcong at gmail.com (Cong Wang)
Date: Wed, 25 Jan 2012 18:50:07 +0800
Subject: Makedumpfile 1.4.2 release
Message-ID: <4F1FDE5F.5080403@gmail.com>

Hello, Kumagai-san,

I saw you released 1.4.2:

commit 7ccf93312266eb4b2e4f9ac701875eb926a861f3
Author: Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp>
Date:   Mon Jan 23 10:44:07 2012 +0900

     [v1.4.2] Update version

     This patch updates makedumpfile to version 1.4.2.

     Signed-off-by: Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp>


but forgot to push it to sourceforge.net? I saw:

Looking for the latest version? Download makedumpfile-1.4.1.tar.gz 
(114.9 kB)


Thanks.


From xiyou.wangcong at gmail.com  Wed Jan 25 05:54:10 2012
From: xiyou.wangcong at gmail.com (Cong Wang)
Date: Wed, 25 Jan 2012 18:54:10 +0800
Subject: Makedumpfile 1.4.2 release
In-Reply-To: <4F1FDE5F.5080403@gmail.com>
References: <4F1FDE5F.5080403@gmail.com>
Message-ID: <4F1FDF52.8050301@gmail.com>

On 01/25/2012 06:50 PM, Cong Wang wrote:
> Hello, Kumagai-san,
>
> I saw you released 1.4.2:
>

By the way, the latest kernel supported by makedumpfile 1.4.2 is still
2.6.36.

makedumpfile.h
383:#define LATEST_VERSION		KERNEL_VERSION(2, 6, 36)/* linux-2.6.36 */

The latest stable kernel is already 3.2.1. :) So, what prevents 
makedumpfile supporting newer kernels?

Thanks.


From ANDY.KENNEDY at adtran.com  Wed Jan 25 09:21:15 2012
From: ANDY.KENNEDY at adtran.com (ANDY KENNEDY)
Date: Wed, 25 Jan 2012 14:21:15 +0000
Subject: kexec 2.0.2 MIPS
In-Reply-To: <20120125065708.GB18345@verge.net.au>
References: <F9C551623D2CBB4C9488801D14F864C607154A@ex-mb1.corp.adtran.com>
 <20110920085133.GE15087@verge.net.au>
 <F9C551623D2CBB4C9488801D14F864C6072473@ex-mb1.corp.adtran.com>
 <20110921112837.GF17108@verge.net.au>
 <F9C551623D2CBB4C9488801D14F864C60E2D98@ex-mb1.corp.adtran.com>
 <20120125023929.GK11038@verge.net.au>
 <CAJGZr0LShFy2rcPi4+ywDuavovxRH5jNJuRtQb3PGGzt1mfy_Q@mail.gmail.com>
 <20120125065708.GB18345@verge.net.au>
Message-ID: <F9C551623D2CBB4C9488801D14F864C60F8F15@ex-mb1.corp.adtran.com>



> -----Original Message-----
> From: Simon Horman [mailto:horms at verge.net.au]
> Sent: Wednesday, January 25, 2012 12:57 AM
> To: Maxim Uvarov
> Cc: ANDY KENNEDY; kexec at lists.infradead.org; Matt Evans
> Subject: Re: kexec 2.0.2 MIPS
> 
> On Tue, Jan 24, 2012 at 10:35:42PM -0800, Maxim Uvarov wrote:
> > 2012/1/24 Simon Horman <horms at verge.net.au>:
> > > Hi,
> > >
> > > sorry for the extensive delay in responding to this.
> > > I am now back from Christmas, New Year, holidays and
> > > attending LCA 2012.
> > >
> > > On Fri, Dec 16, 2011 at 05:27:31AM +0000, ANDY KENNEDY wrote:
> > >> Simon/All,
> > >>
> > >> After two months, I'm back working on this again. ?After 3 hours
> > >> tonight, I have the final result of what you told me to do. ?Looks like,
> > >> based on the comment:
> > >>
> > >> ? ? - remove kexec/arch/mips/mips-setup-simple.S which prepares cmdline for
> > >> ? ? ? new kernel, it is better to move this work to kernel code. BTW this code was
> > >> ? ? ? compilable only on o32 because of t4 is not defined on 64-64 or n32 MIPS ABIs.
> > >>
> > >> The problem is that my 2.6.36.2 apparently doesn't have whatever Maxim
> > >> is talking about. ?Therefore, the newer versions must not be backwards
> > >> compatible. ?Perhaps this is okay with you guys. ?If so, I'll just make
> > >> sure to include a patch to BuildRoot that clearly states that the v2.0.1
> > >> is the only version that works with *some* versions of MIPS. ?If you
> > >> guys were expecting this to be backwards compatible, I'll gladly work
> > >> with you to test whatever you need checked out. ?Just let me know.
> > >
> > > It is not apparent to me that the kernel code Maxim makes mention of
> > > exists in any released kernel. I think that the best option at this
> > > stage would be to revert that portion of his change.
> > >
> > > Maxim, do you have any thoughts on this?
> > >
> >
> > Yes, kernel patches were not accepted and looks like stuck linux-mips@
> > queue forever.
> > Reverting this patches it ok for me especially if somebody going to
> > work on them. As I remember
> > the was problem with supporting all mips ABIs (o32, n32, 32-64). It's
> > mostly related to asm purgatory
> > code. It will be nice if somebody can synchronize kernel and user land
> > parts and make mips kexec code
> > board independent. I think at this time it should be much easy since
> > mips supports device tree.
> 
> Thanks Maxim.
> 
> Andy can you prepare a patch to revert the problematic portion
> of the change?

I'll do my best.  I don?t know when I'll be able to get to it, given
that I've had scope change on my project 3 times in the last week.

Andy

From ANDY.KENNEDY at adtran.com  Wed Jan 25 13:54:47 2012
From: ANDY.KENNEDY at adtran.com (ANDY KENNEDY)
Date: Wed, 25 Jan 2012 18:54:47 +0000
Subject: kexec 2.0.2 MIPS
In-Reply-To: <F9C551623D2CBB4C9488801D14F864C60F8F15@ex-mb1.corp.adtran.com>
References: <F9C551623D2CBB4C9488801D14F864C607154A@ex-mb1.corp.adtran.com>
 <20110920085133.GE15087@verge.net.au>
 <F9C551623D2CBB4C9488801D14F864C6072473@ex-mb1.corp.adtran.com>
 <20110921112837.GF17108@verge.net.au>
 <F9C551623D2CBB4C9488801D14F864C60E2D98@ex-mb1.corp.adtran.com>
 <20120125023929.GK11038@verge.net.au>
 <CAJGZr0LShFy2rcPi4+ywDuavovxRH5jNJuRtQb3PGGzt1mfy_Q@mail.gmail.com>
 <20120125065708.GB18345@verge.net.au>
 <F9C551623D2CBB4C9488801D14F864C60F8F15@ex-mb1.corp.adtran.com>
Message-ID: <F9C551623D2CBB4C9488801D14F864C60F91DB@ex-mb1.corp.adtran.com>

> -----Original Message-----
> From: kexec-bounces at lists.infradead.org [mailto:kexec-bounces at lists.infradead.org] On Behalf Of ANDY
> KENNEDY
> Sent: Wednesday, January 25, 2012 8:21 AM
> To: Simon Horman; Maxim Uvarov
> Cc: kexec at lists.infradead.org; Matt Evans
> Subject: RE: kexec 2.0.2 MIPS
> > -----Original Message-----
> > From: Simon Horman [mailto:horms at verge.net.au]
> > Sent: Wednesday, January 25, 2012 12:57 AM
> > To: Maxim Uvarov
> > Cc: ANDY KENNEDY; kexec at lists.infradead.org; Matt Evans
> > Subject: Re: kexec 2.0.2 MIPS
> >
> > On Tue, Jan 24, 2012 at 10:35:42PM -0800, Maxim Uvarov wrote:
> > > 2012/1/24 Simon Horman <horms at verge.net.au>:
> > > > Hi,
> > > >
> > > > sorry for the extensive delay in responding to this.
> > > > I am now back from Christmas, New Year, holidays and
> > > > attending LCA 2012.
> > > >
> > > > On Fri, Dec 16, 2011 at 05:27:31AM +0000, ANDY KENNEDY wrote:
> > > >> Simon/All,
> > > >>
> > > >> After two months, I'm back working on this again. ?After 3 hours
> > > >> tonight, I have the final result of what you told me to do. ?Looks like,
> > > >> based on the comment:
> > > >>
> > > >> ? ? - remove kexec/arch/mips/mips-setup-simple.S which prepares cmdline for
> > > >> ? ? ? new kernel, it is better to move this work to kernel code. BTW this code was
> > > >> ? ? ? compilable only on o32 because of t4 is not defined on 64-64 or n32 MIPS ABIs.
> > > >>
> > > >> The problem is that my 2.6.36.2 apparently doesn't have whatever Maxim
> > > >> is talking about. ?Therefore, the newer versions must not be backwards
> > > >> compatible. ?Perhaps this is okay with you guys. ?If so, I'll just make
> > > >> sure to include a patch to BuildRoot that clearly states that the v2.0.1
> > > >> is the only version that works with *some* versions of MIPS. ?If you
> > > >> guys were expecting this to be backwards compatible, I'll gladly work
> > > >> with you to test whatever you need checked out. ?Just let me know.
> > > >
> > > > It is not apparent to me that the kernel code Maxim makes mention of
> > > > exists in any released kernel. I think that the best option at this
> > > > stage would be to revert that portion of his change.
> > > >
> > > > Maxim, do you have any thoughts on this?
> > > >
> > >
> > > Yes, kernel patches were not accepted and looks like stuck linux-mips@
> > > queue forever.
> > > Reverting this patches it ok for me especially if somebody going to
> > > work on them. As I remember
> > > the was problem with supporting all mips ABIs (o32, n32, 32-64). It's
> > > mostly related to asm purgatory
> > > code. It will be nice if somebody can synchronize kernel and user land
> > > parts and make mips kexec code
> > > board independent. I think at this time it should be much easy since
> > > mips supports device tree.
> >
> > Thanks Maxim.
> >
> > Andy can you prepare a patch to revert the problematic portion
> > of the change?
> 
> I'll do my best.  I don?t know when I'll be able to get to it, given
> that I've had scope change on my project 3 times in the last week.

What a world.  Today I was told "Never mind" on that scope
change from yesterday.

I'll try to get to it this week or next ;).

Andy

From kumagai-atsushi at mxc.nes.nec.co.jp  Wed Jan 25 20:09:25 2012
From: kumagai-atsushi at mxc.nes.nec.co.jp (Atsushi Kumagai)
Date: Thu, 26 Jan 2012 10:09:25 +0900
Subject: Makedumpfile 1.4.2 release
In-Reply-To: <4F1FDE5F.5080403@gmail.com>
References: <4F1FDE5F.5080403@gmail.com>
Message-ID: <20120126100925.febb6a24.kumagai-atsushi@mxc.nes.nec.co.jp>

Hello Cong,

sourceforge.net had a problem yesterday and I couldn't upload 
the newest version. Please refer to the ticket below.

http://sourceforge.net/apps/trac/sourceforge/ticket/23920

The newest version is already uploaded now and I will 
announce the release of v1.4.2 soon.

Thanks
Atsushi Kumagai

On Wed, 25 Jan 2012 18:50:07 +0800
Cong Wang <xiyou.wangcong at gmail.com> wrote:

> Hello, Kumagai-san,
> 
> I saw you released 1.4.2:
> 
> commit 7ccf93312266eb4b2e4f9ac701875eb926a861f3
> Author: Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp>
> Date:   Mon Jan 23 10:44:07 2012 +0900
> 
>      [v1.4.2] Update version
> 
>      This patch updates makedumpfile to version 1.4.2.
> 
>      Signed-off-by: Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp>
> 
> 
> but forgot to push it to sourceforge.net? I saw:
> 
> Looking for the latest version? Download makedumpfile-1.4.1.tar.gz 
> (114.9 kB)
> 
> 
> Thanks.


From kumagai-atsushi at mxc.nes.nec.co.jp  Wed Jan 25 20:52:45 2012
From: kumagai-atsushi at mxc.nes.nec.co.jp (Atsushi Kumagai)
Date: Thu, 26 Jan 2012 10:52:45 +0900
Subject: makedumpfile-1.4.2: Fix compilation error for some architectures.
Message-ID: <20120126105245.114df17b.kumagai-atsushi@mxc.nes.nec.co.jp>

Hi,

makedumpfile version 1.4.2 is released.
Your comments/patches are welcome.

This version is released earlier than usual because 1.4.1 has 
compilation error in some architectures.

Changelog:
o New feature
    - [PATCH] s390x: Auto-detect the correct MAX_PHYSMEM_BITS used in vmcore being analyzed.
      (for s390x 64TB memory by Mahesh Salgaonkar) 440ed48

o Bugfix
    - [PATCH] Fix compilation error in sadump_info.h. (by Michael Holzheu) 25ae552

o Code Cleanup
    - [PATCH] Add Makefile parameter to use dynamic libraries. (by Atsushi Kumagai) 67b2be2


Explanation of makedumpfile:
  To shorten the size of the dumpfile and the time of creating the
  dumpfile, makedumpfile copies only the necessary pages for analysis
  to the dumpfile from /proc/vmcore. You can specify the kind of
  unnecessary pages with dump_level. If you want to shorten the size
  further, enable the compression of the page data.

Download:
  You can download the latest makedumpfile from the following URL.
  Details of the change are written on the git page of the following site.
  https://sourceforge.net/projects/makedumpfile/

Method of installation:
  You can compile the makedumpfile command as follows;
  1. "tar -zxvf makedumpfile-x.y.z.tar.gz"
  2. "cd makedumpfile-x.y.z"
  3. "make; make install"

Usage:
  makedumpfile [-c] [-E] [-d dump_level] [-x vmlinux] dump_mem dump_file

Example:
  If you want to exclude pages filled by zero, cache pages, user pages
  and free pages and to enable compression, please execute the following
  command.

  # makedumpfile -c -d 31 -x vmlinux /proc/vmcore dumpfile


Thanks
Atsushi Kumagai


From xiyou.wangcong at gmail.com  Wed Jan 25 22:21:57 2012
From: xiyou.wangcong at gmail.com (Cong Wang)
Date: Thu, 26 Jan 2012 11:21:57 +0800
Subject: Makedumpfile 1.4.2 release
In-Reply-To: <20120126100925.febb6a24.kumagai-atsushi@mxc.nes.nec.co.jp>
References: <4F1FDE5F.5080403@gmail.com>
 <20120126100925.febb6a24.kumagai-atsushi@mxc.nes.nec.co.jp>
Message-ID: <4F20C6D5.9060603@gmail.com>

On 01/26/2012 09:09 AM, Atsushi Kumagai wrote:
> Hello Cong,
>
> sourceforge.net had a problem yesterday and I couldn't upload
> the newest version. Please refer to the ticket below.
>
> http://sourceforge.net/apps/trac/sourceforge/ticket/23920
>
> The newest version is already uploaded now and I will
> announce the release of v1.4.2 soon.
>

Yeah, it works now.

Thanks.



From kumagai-atsushi at mxc.nes.nec.co.jp  Thu Jan 26 00:43:43 2012
From: kumagai-atsushi at mxc.nes.nec.co.jp (Atsushi Kumagai)
Date: Thu, 26 Jan 2012 14:43:43 +0900
Subject: Makedumpfile 1.4.2 release
In-Reply-To: <4F1FDF52.8050301@gmail.com>
References: <4F1FDE5F.5080403@gmail.com>
	<4F1FDF52.8050301@gmail.com>
Message-ID: <20120126144343.4b4969a3.kumagai-atsushi@mxc.nes.nec.co.jp>

Hi Cong,

> By the way, the latest kernel supported by makedumpfile 1.4.2 is still
> 2.6.36.
> 
> makedumpfile.h
> 383:#define LATEST_VERSION		KERNEL_VERSION(2, 6, 36)/* linux-2.6.36 */
> 
> The latest stable kernel is already 3.2.1. :) So, what prevents 
> makedumpfile supporting newer kernels?

Sorry for inconvenience.
We have postponed supporting newer kernels because we were busy
at other developments.

Now we will support newer kernels step by step.
Please give us a little more time.


Thanks
Atsushi Kumagai


From xiyou.wangcong at gmail.com  Thu Jan 26 05:54:55 2012
From: xiyou.wangcong at gmail.com (Cong Wang)
Date: Thu, 26 Jan 2012 18:54:55 +0800
Subject: Makedumpfile 1.4.2 release
In-Reply-To: <20120126144343.4b4969a3.kumagai-atsushi@mxc.nes.nec.co.jp>
References: <4F1FDE5F.5080403@gmail.com> <4F1FDF52.8050301@gmail.com>
 <20120126144343.4b4969a3.kumagai-atsushi@mxc.nes.nec.co.jp>
Message-ID: <4F2130FF.6030406@gmail.com>

On 01/26/2012 01:43 PM, Atsushi Kumagai wrote:
> Hi Cong,
>
>> By the way, the latest kernel supported by makedumpfile 1.4.2 is still
>> 2.6.36.
>>
>> makedumpfile.h
>> 383:#define LATEST_VERSION		KERNEL_VERSION(2, 6, 36)/* linux-2.6.36 */
>>
>> The latest stable kernel is already 3.2.1. :) So, what prevents
>> makedumpfile supporting newer kernels?
>
> Sorry for inconvenience.
> We have postponed supporting newer kernels because we were busy
> at other developments.
>
> Now we will support newer kernels step by step.
> Please give us a little more time.

Yeah, sure, I was just wondering if anything I can help. ;)


From levinsasha928 at gmail.com  Sat Jan 28 10:11:30 2012
From: levinsasha928 at gmail.com (Sasha Levin)
Date: Sat, 28 Jan 2012 10:11:30 -0500
Subject: BUG: unable to handle kernel paging request at ffffc7ff81000398
 (sys_kexec_load)
In-Reply-To: <m1lip0s5nt.fsf@fess.ebiederm.org>
References: <1327212367.32115.4.camel@lappy> <m1lip0s5nt.fsf@fess.ebiederm.org>
Message-ID: <1327763490.16907.1.camel@lappy>

On Sat, 2012-01-21 at 20:49 -0800, Eric W. Biederman wrote:
> Interesting.
> 
> The fact that this happens in native_set_pte would suggest that we are
> trying to write to a page table that does not exist.  So this might
> be a layer below kexec_load that has the problem.
> 
> Do you have the kernel you were testing?    A disassembly of the
> native_set_pte, machine_kexec_prepare and sys_kexec_load
> would be interesting, for attempting to trace this back to what went
> wrong.

I did some work into investigating it today, looks like it's simple to trigger it using the following code:

	#include <fcntl.h>
	int main(void)
	{
		char dummy[4096] = {0};
		syscall(246, 0xffffffff81008000, 1, dummy, 2);
		return 0;
	}

I'll continue trying to figure out whats wrong, but hopefully this lead will help in reproducing it easily.

-- 

Sasha.



From ebiederm at xmission.com  Sat Jan 28 15:54:43 2012
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Sat, 28 Jan 2012 12:54:43 -0800
Subject: BUG: unable to handle kernel paging request at ffffc7ff81000398
 (sys_kexec_load)
In-Reply-To: <1327763490.16907.1.camel@lappy> (Sasha Levin's message of "Sat, 
 28 Jan 2012 10:11:30 -0500")
References: <1327212367.32115.4.camel@lappy>
 <m1lip0s5nt.fsf@fess.ebiederm.org> <1327763490.16907.1.camel@lappy>
Message-ID: <m1y5sro8do.fsf@fess.ebiederm.org>

Sasha Levin <levinsasha928 at gmail.com> writes:

> On Sat, 2012-01-21 at 20:49 -0800, Eric W. Biederman wrote:
>> Interesting.
>> 
>> The fact that this happens in native_set_pte would suggest that we are
>> trying to write to a page table that does not exist.  So this might
>> be a layer below kexec_load that has the problem.
>> 
>> Do you have the kernel you were testing?    A disassembly of the
>> native_set_pte, machine_kexec_prepare and sys_kexec_load
>> would be interesting, for attempting to trace this back to what went
>> wrong.
>
> I did some work into investigating it today, looks like it's simple to trigger it using the following code:
>
> 	#include <fcntl.h>
> 	int main(void)
> 	{
> 		char dummy[4096] = {0};
> 		syscall(246, 0xffffffff81008000, 1, dummy, 2);
> 		return 0;
> 	}
>
> I'll continue trying to figure out whats wrong, but hopefully this
> lead will help in reproducing it easily.

Yes that helps, and that matches the backtrace.

So the question becomes why does a strange entry point address cause problems.

Eric


From xiyou.wangcong at gmail.com  Tue Jan 31 01:58:09 2012
From: xiyou.wangcong at gmail.com (Cong Wang)
Date: Tue, 31 Jan 2012 14:58:09 +0800
Subject: [Patch] kexec: make some functions static
Message-ID: <1327993089-23630-1-git-send-email-xiyou.wangcong@gmail.com>

The following functions/variables can become static.

Signed-off-by: WANG Cong <xiyou.wangcong at gmail.com>

---
diff --git a/kexec/kexec.c b/kexec/kexec.c
index abbe940..89e725e 100644
--- a/kexec/kexec.c
+++ b/kexec/kexec.c
@@ -49,7 +49,7 @@
 
 unsigned long long mem_min = 0;
 unsigned long long mem_max = ULONG_MAX;
-unsigned long kexec_flags = 0;
+static unsigned long kexec_flags = 0;
 
 void die(char *fmt, ...)
 {
@@ -62,7 +62,7 @@ void die(char *fmt, ...)
 	exit(1);
 }
 
-char *xstrdup(const char *str)
+static char *xstrdup(const char *str)
 {
 	char *new = strdup(str);
 	if (!new)
@@ -765,7 +765,7 @@ static int my_load(const char *type, int fileind, int argc, char **argv,
 	return result;
 }
 
-int k_unload (unsigned long kexec_flags)
+static int k_unload (unsigned long kexec_flags)
 {
 	int result;
 	long native_arch;
@@ -1006,7 +1006,7 @@ char *get_command_line(void)
 }
 
 /* check we retained the initrd */
-void check_reuse_initrd(void)
+static void check_reuse_initrd(void)
 {
 	char *line = get_command_line();
 


From aruna at linux.vnet.ibm.com  Tue Jan 31 05:26:33 2012
From: aruna at linux.vnet.ibm.com (Aruna Balakrishnaiah)
Date: Tue, 31 Jan 2012 15:56:33 +0530
Subject: [PATCH] Fix segmentation fault for makedumpfile -x/--split
Message-ID: <20120131102456.17966.37854.stgit@aruna-ThinkPad-T420>


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 at linux.vnet.ibm.com>
---
 dwarf_info.c |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/dwarf_info.c b/dwarf_info.c
index 46dcd8e..515455d 100644
--- a/dwarf_info.c
+++ b/dwarf_info.c
@@ -204,6 +204,16 @@ search_module_debuginfo(char *os_release)
 	return FALSE;
 }
 
+static int
+dwarf_no_debuginfo_found(Dwfl_Module *mod, void **userdata,
+			const char *modname, Dwarf_Addr base,
+			const char *file_name,
+			const char *debuglink_file, GElf_Word debuglink_crc,
+			char **debuginfo_file_name)
+{
+	return -1;
+}
+
 /*
  * Initialize the dwarf info.
  * Linux kernel module debuginfo are of ET_REL (relocatable) type.
@@ -219,6 +229,21 @@ init_dwarf_info(void)
 	int dwfl_fd = -1;
 	static const Dwfl_Callbacks callbacks = {
 		.section_address = dwfl_offline_section_address,
+	/*
+	 * By the time init_dwarf_info() function is called, we already
+	 * know absolute path of debuginfo either resolved through
+	 * search_module_debuginfo() call OR user specified vmlinux
+	 * debuginfo through '-x' option. In which case .find_debuginfo
+	 * callback is never invoked.
+	 * But we can not deny a situation where user may pass invalid
+	 * file name through '-x' option, where .find_debuginfo gets
+	 * invoked to find a valid vmlinux debuginfo and hence we run
+	 * into seg fault issue. Hence, set .find_debuginfo to a
+	 * funtion pointer that returns -1 to avoid seg fault and let
+	 * the makedumpfile throw error messages against the invalid
+	 * vmlinux file input.
+	 */
+		.find_debuginfo  = dwarf_no_debuginfo_found
 	};
 
 	dwarf_info.elfd = NULL;



From dzickus at redhat.com  Tue Jan 31 16:25:14 2012
From: dzickus at redhat.com (Don Zickus)
Date: Tue, 31 Jan 2012 16:25:14 -0500
Subject: [PATCH] x86, kdump, ioapic: Fix kdump race with migrating irq
Message-ID: <1328045114-4489-1-git-send-email-dzickus@redhat.com>

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
                              ---Infinite loop here---

The problem is that although kdump tries to shutdown minimal hardware,
it still needs to disable the IO APIC.  This requires spinlocks which
may be held by another cpu.  This other cpu is being held infinitely in
an NMI context by kdump in order to serialize the crashing path.  Instant
deadlock.

I attempted to resolve this by busting the spinlock in the kdump case only.
My justification was that kdump has already stopped the other cpus and it
is only clearing the io apic which shouldn't cause harm when overwriting
what the other cpu was doing.

I tested this by loading a dummy module that grabs the ioapic_lock and then
on another cpu, run 'echo c > /proc/sysrq-trigger'.  The deadlock was detected
and fixed with the patch below.

Signed-off-by: Don Zickus <dzickus at redhat.com>
---
 arch/x86/kernel/apic/io_apic.c     |   18 +++++++++++++++++-
 arch/x86/kernel/crash.c            |    2 +-
 arch/x86/kernel/machine_kexec_32.c |    2 +-
 arch/x86/kernel/machine_kexec_64.c |    2 +-
 arch/x86/kernel/reboot.c           |    2 +-
 5 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index fb07275..5fe4423 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1991,9 +1991,25 @@ void __init enable_IO_APIC(void)
 /*
  * Not an __init, needed by the reboot code
  */
-void disable_IO_APIC(void)
+void disable_IO_APIC(int force)
 {
 	/*
+	 * Use force to bust the io_apic spinlock
+	 *
+	 * There is a case where kdump can race with irq
+	 * migration such that kdump will inject an NMI
+	 * while another cpu holds the ioapic_lock to
+	 * migrate the irq.  This would cause a deadlock.
+	 *
+	 * Because kdump stops all the cpus, we can safely
+	 * bust the spinlock as we are just clearing the
+	 * io apic anyway.
+	 */
+	if (force && spin_is_locked(&ioapic_lock))
+		/* only one cpu should be running now */
+		spin_lock_init(&ioapic_lock);
+
+	/*
 	 * Clear the IO-APIC before rebooting:
 	 */
 	clear_IO_APIC();
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 13ad899..c8383b0 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -97,7 +97,7 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
 
 	lapic_shutdown();
 #if defined(CONFIG_X86_IO_APIC)
-	disable_IO_APIC();
+	disable_IO_APIC(1);
 #endif
 #ifdef CONFIG_HPET_TIMER
 	hpet_disable();
diff --git a/arch/x86/kernel/machine_kexec_32.c b/arch/x86/kernel/machine_kexec_32.c
index a3fa43b..3c60005 100644
--- a/arch/x86/kernel/machine_kexec_32.c
+++ b/arch/x86/kernel/machine_kexec_32.c
@@ -212,7 +212,7 @@ void machine_kexec(struct kimage *image)
 		 * one form or other. kexec jump path also need
 		 * one.
 		 */
-		disable_IO_APIC();
+		disable_IO_APIC(0);
 #endif
 	}
 
diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
index b3ea9db..ed94a6a 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -295,7 +295,7 @@ void machine_kexec(struct kimage *image)
 		 * one form or other. kexec jump path also need
 		 * one.
 		 */
-		disable_IO_APIC();
+		disable_IO_APIC(0);
 #endif
 	}
 
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 37a458b..766795c 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -652,7 +652,7 @@ void native_machine_shutdown(void)
 	lapic_shutdown();
 
 #ifdef CONFIG_X86_IO_APIC
-	disable_IO_APIC();
+	disable_IO_APIC(0);
 #endif
 
 #ifdef CONFIG_HPET_TIMER
-- 
1.7.7.5



From vgoyal at redhat.com  Tue Jan 31 16:37:13 2012
From: vgoyal at redhat.com (Vivek Goyal)
Date: Tue, 31 Jan 2012 16:37:13 -0500
Subject: [PATCH] x86, kdump, ioapic: Fix kdump race with migrating irq
In-Reply-To: <1328045114-4489-1-git-send-email-dzickus@redhat.com>
References: <1328045114-4489-1-git-send-email-dzickus@redhat.com>
Message-ID: <20120131213713.GC4378@redhat.com>

On Tue, Jan 31, 2012 at 04:25:14PM -0500, Don Zickus wrote:
> 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
>                               ---Infinite loop here---
> 
> The problem is that although kdump tries to shutdown minimal hardware,
> it still needs to disable the IO APIC.  This requires spinlocks which
> may be held by another cpu.  This other cpu is being held infinitely in
> an NMI context by kdump in order to serialize the crashing path.  Instant
> deadlock.
> 
> I attempted to resolve this by busting the spinlock in the kdump case only.
> My justification was that kdump has already stopped the other cpus and it
> is only clearing the io apic which shouldn't cause harm when overwriting
> what the other cpu was doing.
> 
> I tested this by loading a dummy module that grabs the ioapic_lock and then
> on another cpu, run 'echo c > /proc/sysrq-trigger'.  The deadlock was detected
> and fixed with the patch below.
> 
> Signed-off-by: Don Zickus <dzickus at redhat.com>

Sounds reasonable to me. 

Acked-by: Vivek Goyal <vgoyal at redhat.com>

Thanks
Vivek


From ebiederm at xmission.com  Tue Jan 31 17:08:29 2012
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Tue, 31 Jan 2012 14:08:29 -0800
Subject: [PATCH] x86, kdump, ioapic: Fix kdump race with migrating irq
In-Reply-To: <1328045114-4489-1-git-send-email-dzickus@redhat.com> (Don
 Zickus's message of "Tue, 31 Jan 2012 16:25:14 -0500")
References: <1328045114-4489-1-git-send-email-dzickus@redhat.com>
Message-ID: <m1ipjr4jaa.fsf@fess.ebiederm.org>

Don Zickus <dzickus at redhat.com> 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
>                            -> do_nmi
>                               -> crash_nmi_callback
>                               ---Infinite loop here---
>
> The problem is that although kdump tries to shutdown minimal hardware,
> it still needs to disable the IO APIC.  This requires spinlocks which
> may be held by another cpu.  This other cpu is being held infinitely in
> an NMI context by kdump in order to serialize the crashing path.  Instant
> deadlock.

Can you test to see if kexec on panic still needs to disable the IO
APIC.  Last I looked we were close if not all of the way there to not
needing to boot the kernel in pic mode?

If we can skip the ioapic disable entirely we should be much more
robust.

Eric


From dzickus at redhat.com  Tue Jan 31 17:20:27 2012
From: dzickus at redhat.com (Don Zickus)
Date: Tue, 31 Jan 2012 17:20:27 -0500
Subject: [PATCH v2] x86, kdump, ioapic: Fix kdump race with migrating irq
Message-ID: <1328048427-20838-1-git-send-email-dzickus@redhat.com>

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
                              ---Infinite loop here---

The problem is that although kdump tries to shutdown minimal hardware,
it still needs to disable the IO APIC.  This requires spinlocks which
may be held by another cpu.  This other cpu is being held infinitely in
an NMI context by kdump in order to serialize the crashing path.  Instant
deadlock.

I attempted to resolve this by busting the spinlock in the kdump case only.
My justification was that kdump has already stopped the other cpus and it
is only clearing the io apic which shouldn't cause harm when overwriting
what the other cpu was doing.

I tested this by loading a dummy module that grabs the ioapic_lock and then
on another cpu, run 'echo c > /proc/sysrq-trigger'.  The deadlock was detected
and fixed with the patch below.

v2:
In my haste, I somehow cut out hw_irq.h from the original patch
Compiling against latest tree with raw_spin_lock

Signed-off-by: Don Zickus <dzickus at redhat.com>
---
 arch/x86/include/asm/hw_irq.h      |    2 +-
 arch/x86/kernel/apic/io_apic.c     |   18 +++++++++++++++++-
 arch/x86/kernel/crash.c            |    2 +-
 arch/x86/kernel/machine_kexec_32.c |    2 +-
 arch/x86/kernel/machine_kexec_64.c |    2 +-
 arch/x86/kernel/reboot.c           |    2 +-
 6 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index eb92a6e..1741f7a 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -82,7 +82,7 @@ extern unsigned long io_apic_irqs;
 
 extern void init_VISWS_APIC_irqs(void);
 extern void setup_IO_APIC(void);
-extern void disable_IO_APIC(void);
+extern void disable_IO_APIC(int);
 
 struct io_apic_irq_attr {
 	int ioapic;
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index fb07275..96f1d46 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1991,9 +1991,25 @@ void __init enable_IO_APIC(void)
 /*
  * Not an __init, needed by the reboot code
  */
-void disable_IO_APIC(void)
+void disable_IO_APIC(int force)
 {
 	/*
+	 * Use force to bust the io_apic spinlock
+	 *
+	 * There is a case where kdump can race with irq
+	 * migration such that kdump will inject an NMI
+	 * while another cpu holds the ioapic_lock to
+	 * migrate the irq.  This would cause a deadlock.
+	 *
+	 * Because kdump stops all the cpus, we can safely
+	 * bust the spinlock as we are just clearing the
+	 * io apic anyway.
+	 */
+	if (force && raw_spin_is_locked(&ioapic_lock))
+		/* only one cpu should be running now */
+		raw_spin_lock_init(&ioapic_lock);
+
+	/*
 	 * Clear the IO-APIC before rebooting:
 	 */
 	clear_IO_APIC();
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 13ad899..c8383b0 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -97,7 +97,7 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
 
 	lapic_shutdown();
 #if defined(CONFIG_X86_IO_APIC)
-	disable_IO_APIC();
+	disable_IO_APIC(1);
 #endif
 #ifdef CONFIG_HPET_TIMER
 	hpet_disable();
diff --git a/arch/x86/kernel/machine_kexec_32.c b/arch/x86/kernel/machine_kexec_32.c
index a3fa43b..3c60005 100644
--- a/arch/x86/kernel/machine_kexec_32.c
+++ b/arch/x86/kernel/machine_kexec_32.c
@@ -212,7 +212,7 @@ void machine_kexec(struct kimage *image)
 		 * one form or other. kexec jump path also need
 		 * one.
 		 */
-		disable_IO_APIC();
+		disable_IO_APIC(0);
 #endif
 	}
 
diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
index b3ea9db..ed94a6a 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -295,7 +295,7 @@ void machine_kexec(struct kimage *image)
 		 * one form or other. kexec jump path also need
 		 * one.
 		 */
-		disable_IO_APIC();
+		disable_IO_APIC(0);
 #endif
 	}
 
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 37a458b..766795c 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -652,7 +652,7 @@ void native_machine_shutdown(void)
 	lapic_shutdown();
 
 #ifdef CONFIG_X86_IO_APIC
-	disable_IO_APIC();
+	disable_IO_APIC(0);
 #endif
 
 #ifdef CONFIG_HPET_TIMER
-- 
1.7.7.5



From dzickus at redhat.com  Tue Jan 31 17:27:51 2012
From: dzickus at redhat.com (Don Zickus)
Date: Tue, 31 Jan 2012 17:27:51 -0500
Subject: [PATCH] x86, kdump, ioapic: Fix kdump race with migrating irq
In-Reply-To: <m1ipjr4jaa.fsf@fess.ebiederm.org>
References: <1328045114-4489-1-git-send-email-dzickus@redhat.com>
 <m1ipjr4jaa.fsf@fess.ebiederm.org>
Message-ID: <20120131222751.GE5650@redhat.com>

On Tue, Jan 31, 2012 at 02:08:29PM -0800, Eric W. Biederman wrote:
> > The problem is that although kdump tries to shutdown minimal hardware,
> > it still needs to disable the IO APIC.  This requires spinlocks which
> > may be held by another cpu.  This other cpu is being held infinitely in
> > an NMI context by kdump in order to serialize the crashing path.  Instant
> > deadlock.
> 
> Can you test to see if kexec on panic still needs to disable the IO
> APIC.  Last I looked we were close if not all of the way there to not
> needing to boot the kernel in pic mode?

Ok, so you just blindly remove disable_IO_APIC from
native_machine_crash_shutdown and re-run some panic tests on various
machines?  What about the disable_IO_APIC path in native_machine_shutdown?

Also, where could I look to see if that work was done?  Is that in the
ioapic setup code?

> 
> If we can skip the ioapic disable entirely we should be much more
> robust.

Agreed.

Cheers,
Don


From ebiederm at xmission.com  Tue Jan 31 17:38:15 2012
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Tue, 31 Jan 2012 14:38:15 -0800
Subject: [PATCH] x86, kdump, ioapic: Fix kdump race with migrating irq
In-Reply-To: <20120131222751.GE5650@redhat.com> (Don Zickus's message of "Tue, 
 31 Jan 2012 17:27:51 -0500")
References: <1328045114-4489-1-git-send-email-dzickus@redhat.com>
 <m1ipjr4jaa.fsf@fess.ebiederm.org> <20120131222751.GE5650@redhat.com>
Message-ID: <m1vcnr33c8.fsf@fess.ebiederm.org>

Don Zickus <dzickus at redhat.com> writes:

> On Tue, Jan 31, 2012 at 02:08:29PM -0800, Eric W. Biederman wrote:
>> > The problem is that although kdump tries to shutdown minimal hardware,
>> > it still needs to disable the IO APIC.  This requires spinlocks which
>> > may be held by another cpu.  This other cpu is being held infinitely in
>> > an NMI context by kdump in order to serialize the crashing path.  Instant
>> > deadlock.
>> 
>> Can you test to see if kexec on panic still needs to disable the IO
>> APIC.  Last I looked we were close if not all of the way there to not
>> needing to boot the kernel in pic mode?
>
> Ok, so you just blindly remove disable_IO_APIC from
> native_machine_crash_shutdown and re-run some panic tests on various
> machines?  What about the disable_IO_APIC path in native_machine_shutdown?
>

Yes.  Just native_machine_crash_shutdown.

native_machine_shutdown is the case when all is good and we attempt to
put the hardware back the way we found it.

Any normal x86 machine that the kernel runs in ioapic mode should be
enough to get a first approximation.

> Also, where could I look to see if that work was done?  Is that in the
> ioapic setup code?

The primary question is do we call the ioapic setup code without calling
the pic setup code first.  On some embedded x86 platforms we certainly
do.  I don't know if that code has been generalized.

Historically the problem is that we started the pit timer in pic mode
and used that to calibrate the delay loop.

So what we are looking to verify is that the linux kernel boot skip
pic mode entirely.

Eric


From horms at verge.net.au  Tue Jan 31 18:46:42 2012
From: horms at verge.net.au (Simon Horman)
Date: Wed, 1 Feb 2012 08:46:42 +0900
Subject: [Patch] kexec: make some functions static
In-Reply-To: <1327993089-23630-1-git-send-email-xiyou.wangcong@gmail.com>
References: <1327993089-23630-1-git-send-email-xiyou.wangcong@gmail.com>
Message-ID: <20120131234641.GG15422@verge.net.au>

On Tue, Jan 31, 2012 at 02:58:09PM +0800, Cong Wang wrote:
> The following functions/variables can become static.

Thanks, applied.


From kumagai-atsushi at mxc.nes.nec.co.jp  Tue Jan 31 23:15:18 2012
From: kumagai-atsushi at mxc.nes.nec.co.jp (Atsushi Kumagai)
Date: Wed, 1 Feb 2012 13:15:18 +0900
Subject: [PATCH] Fix segmentation fault for makedumpfile -x/--split
In-Reply-To: <20120131102456.17966.37854.stgit@aruna-ThinkPad-T420>
References: <20120131102456.17966.37854.stgit@aruna-ThinkPad-T420>
Message-ID: <20120201131518.7764c710.kumagai-atsushi@mxc.nes.nec.co.jp>

Hi Aruna,

On Tue, 31 Jan 2012 15:56:33 +0530
Aruna Balakrishnaiah <aruna at linux.vnet.ibm.com> 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 at linux.vnet.ibm.com>
> ---
>  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
> @@ -204,6 +204,16 @@ search_module_debuginfo(char *os_release)
>  	return FALSE;
>  }
>  
> +static int
> +dwarf_no_debuginfo_found(Dwfl_Module *mod, void **userdata,
> +			const char *modname, Dwarf_Addr base,
> +			const char *file_name,
> +			const char *debuglink_file, GElf_Word debuglink_crc,
> +			char **debuginfo_file_name)
> +{
> +	return -1;
> +}
> +
>  /*
>   * Initialize the dwarf info.
>   * Linux kernel module debuginfo are of ET_REL (relocatable) type.
> @@ -219,6 +229,21 @@ init_dwarf_info(void)
>  	int dwfl_fd = -1;
>  	static const Dwfl_Callbacks callbacks = {
>  		.section_address = dwfl_offline_section_address,
> +	/*
> +	 * By the time init_dwarf_info() function is called, we already
> +	 * know absolute path of debuginfo either resolved through
> +	 * search_module_debuginfo() call OR user specified vmlinux
> +	 * debuginfo through '-x' option. In which case .find_debuginfo
> +	 * callback is never invoked.
> +	 * But we can not deny a situation where user may pass invalid
> +	 * file name through '-x' option, where .find_debuginfo gets
> +	 * invoked to find a valid vmlinux debuginfo and hence we run
> +	 * into seg fault issue. Hence, set .find_debuginfo to a
> +	 * funtion pointer that returns -1 to avoid seg fault and let
> +	 * the makedumpfile throw error messages against the invalid
> +	 * vmlinux file input.
> +	 */
> +		.find_debuginfo  = dwarf_no_debuginfo_found
>  	};
>  
>  	dwarf_info.elfd = NULL;
> 
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec


