From cf at cfrost.dk  Wed Feb  1 07:01:31 2012
From: cf at cfrost.dk (Christian Frost)
Date: Wed, 1 Feb 2012 13:01:31 +0100
Subject: Kexec hangs when loading a SMP kernel
Message-ID: <CAA=oPahsrH7T=im0FZZvt-fzPPUcSVfJAW7ch108oALxJGJN0A@mail.gmail.com>

Hi all,

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

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

Regards,
Christian


From dzickus at redhat.com  Wed Feb  1 18:04:14 2012
From: dzickus at redhat.com (Don Zickus)
Date: Wed, 1 Feb 2012 18:04:14 -0500
Subject: [PATCH] x86, kdump, ioapic: Fix kdump race with migrating irq
In-Reply-To: <m1vcnr33c8.fsf@fess.ebiederm.org>
References: <1328045114-4489-1-git-send-email-dzickus@redhat.com>
 <m1ipjr4jaa.fsf@fess.ebiederm.org>
 <20120131222751.GE5650@redhat.com>
 <m1vcnr33c8.fsf@fess.ebiederm.org>
Message-ID: <20120201230414.GL5650@redhat.com>

On Tue, Jan 31, 2012 at 02:38:15PM -0800, Eric W. Biederman wrote:
> 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.

Ok.

> 
> 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.

It seems to boot fine on an Ivy Bridge machine and a single cpu Pentium4.
I will try and athlon3 and a nehalem tomorrow.

Talking to folks here and trying to read the code it seems like the PIT
stuff is delayed until after the IOAPIC is configured using Fast TSC
calibration as a mechanism to work around the PIT??

I attached the output of the Pentium4 when kdumping.  Not sure what to
really look for to verify the PIC is being skipped.  Perhaps you know?

Cheers,
Don

DMI 2.3 present.
last_pfn = 0x20000 max_arch_pfn = 0x1000000
x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106
found SMP MP-table at [c00fe710] fe710
init_memory_mapping: 0000000000000000-0000000020000000
RAMDISK: 1fab5000 - 1ff5f000
ACPI: RSDP 000fd560 00014 (v00 DELL  )
ACPI: RSDT 000fd574 00034 (v01 DELL    GX240   00000008 ASL  00000061)
ACPI: FACP 000fd5a8 00074 (v01 DELL    GX240   00000008 ASL  00000061)
ACPI: DSDT fffe3c22 02393 (v01   DELL    dt_ex 00001000 MSFT 0100000D)
ACPI: FACS 3ff77000 00040
ACPI: SSDT fffe5fb5 000A7 (v01   DELL    st_ex 00001000 MSFT 0100000D)
ACPI: APIC 000fd61c 0005C (v01 DELL    GX240   00000008 ASL  00000061)
ACPI: BOOT 000fd678 00028 (v01 DELL    GX240   00000008 ASL  00000061)
0MB HIGHMEM available.
512MB LOWMEM available.
  mapped low ram: 0 - 20000000
  low ram: 0 - 20000000
Zone PFN ranges:
  DMA      0x00000010 -> 0x00001000
  Normal   0x00001000 -> 0x00020000
  HighMem  empty
Movable zone start PFN for each node
Early memory PFN ranges
    0: 0x00000010 -> 0x000000a0
    0: 0x00018000 -> 0x0001ff6a
    0: 0x0001ff6b -> 0x0001ff6f
    0: 0x0001ffff -> 0x00020000
Using APIC driver default
ACPI: PM-Timer IO Port: 0x808
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] disabled)
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Using ACPI (MADT) for SMP configuration information
2 Processors exceeds NR_CPUS limit of 1
SMP: Allowing 1 CPUs, 0 hotplug CPUs
PM: Registered nosave memory: 00000000000a0000 - 00000000000f0000
PM: Registered nosave memory: 00000000000f0000 - 0000000000100000
PM: Registered nosave memory: 0000000000100000 - 0000000018000000
PM: Registered nosave memory: 000000001ff6a000 - 000000001ff6b000
PM: Registered nosave memory: 000000001ff6f000 - 000000001ffff000
Allocating PCI resources starting at 40000000 (gap: 40000000:bec00000)
Booting paravirtualized kernel on bare hardware
setup_percpu: NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:1 nr_node_ids:1
PERCPU: Embedded 13 pages/cpu @df400000 s32704 r0 d20544 u2097152
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 31743
Kernel command line: ro root=/dev/mapper/vg_dellgx24003-lv_root rd_NO_LUKS
LANG=en_US.UTF-8 rd_NO_MD KEYTABLE=us console=ttyS0,115200
rd_LVM_LV=vg_dellgx24003/lv_root rd_LVM_LV=vg_dellgx24003/lv_swap
SYSFONT=latarcyrheb-sun16 rd_NO_DM irqpoll nr_cpus=1 reset_devices
cgroup_disable=memory  memmap=exactmap memmap=64K$0K memmap=576K at 64K
memmap=64K$960K memmap=130472K at 393216K memmap=19K at 523689K
memmap=4K at 524284K memmap=8K#1048028K memmap=540K$1048036K
memmap=64K$4173824K memmap=64K$4175872K memmap=5120K$4189184K
elfcorehdr=523688K
Misrouted IRQ fixup and polling support enabled
This may significantly impact system performance
Disabling memory control group subsystem
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Initializing CPU#0
Initializing HighMem for node 0 (00000000:00000000)
Memory: 112876k/524288k available (4429k kernel code, 18192k reserved,
2305k data, 500k init, 0k highmem)
virtual kernel memory layout:
    fixmap  : 0xffa96000 - 0xfffff000   (5540 kB)
    pkmap   : 0xff600000 - 0xff800000   (2048 kB)
    vmalloc : 0xe0800000 - 0xff5fe000   ( 493 MB)
    lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
      .init : 0xd8a94000 - 0xd8b11000   ( 500 kB)
      .data : 0xd8853712 - 0xd8a93d80   (2305 kB)
      .text : 0xd8400000 - 0xd8853712   (4429 kB)
Checking if this processor honours the WP bit even in supervisor
mode...Ok.
Hierarchical RCU implementation.
NR_IRQS:2304 nr_irqs:256 16
Spurious LAPIC timer interrupt on cpu 0
do_IRQ: 0.89 No irq handler for vector (irq -1)
Console: colour VGA+ 80x25
console [ttyS0] enabled
Fast TSC calibration using PIT
Detected 1694.460 MHz processor.
Calibrating delay loop (skipped), value calculated using timer frequency..
3388.92 BogoMIPS (lpj=1694460)
pid_max: default: 32768 minimum: 301
Security Framework initialized
SELinux:  Initializing.
Mount-cache hash table entries: 512
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
Initializing cgroup subsys net_cls
Initializing cgroup subsys blkio
Initializing cgroup subsys perf_event
CPU0: Hyper-Threading is disabled
mce: CPU supports 4 MCE banks
SMP alternatives: switching to UP code
Freeing SMP alternatives: 20k freed
ACPI: Core revision 20120111
Enabling APIC mode:  Flat.  Using 1 I/O APICs
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
CPU0: Intel(R) Pentium(R) 4 CPU 1.70GHz stepping 02
Performance Events: Netburst events, Broken PMU hardware detected, using
software events only.
NMI watchdog disabled (cpu0): hardware events not enabled
Brought up 1 CPUs
Total of 1 processors activated (3388.92 BogoMIPS).
<snip>


From ebiederm at xmission.com  Wed Feb  1 20:34:01 2012
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Wed, 01 Feb 2012 17:34:01 -0800
Subject: [PATCH] x86, kdump, ioapic: Fix kdump race with migrating irq
In-Reply-To: <20120201230414.GL5650@redhat.com> (Don Zickus's message of "Wed, 
 1 Feb 2012 18:04:14 -0500")
References: <1328045114-4489-1-git-send-email-dzickus@redhat.com>
 <m1ipjr4jaa.fsf@fess.ebiederm.org> <20120131222751.GE5650@redhat.com>
 <m1vcnr33c8.fsf@fess.ebiederm.org> <20120201230414.GL5650@redhat.com>
Message-ID: <m1ehuevx12.fsf@fess.ebiederm.org>

Don Zickus <dzickus at redhat.com> writes:

> On Tue, Jan 31, 2012 at 02:38:15PM -0800, Eric W. Biederman wrote:
>> 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.
>
> Ok.
>
>> 
>> 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.
>
> It seems to boot fine on an Ivy Bridge machine and a single cpu Pentium4.
> I will try and athlon3 and a nehalem tomorrow.
>
> Talking to folks here and trying to read the code it seems like the PIT
> stuff is delayed until after the IOAPIC is configured using Fast TSC
> calibration as a mechanism to work around the PIT??
>
> I attached the output of the Pentium4 when kdumping.  Not sure what to
> really look for to verify the PIC is being skipped.  Perhaps you know?

The important part is the kexec on panic works without shutting down
the ioapic.  There should be no corner case issues it should either
work it should fail.

The problem used to be that we always would initialize the PIT interrupt
in the 8259 interrupt controller before we would initialize the ioapics
and that would kill the boot.

If I have read your testing correctly you are apparently booting in the
kexec on panic case.  That seems to be successful to me.  So we should
be able to just remove the ioapic shutdown code from
machine_crash_shutdown as it is no longer needed.

Thank you for being careful and testing on a number of different
platforms. 

The only case I can think that won't work without ioapic disables
is using a crash kernel that doesn't emable the ioapics.

Eric


From dzickus at redhat.com  Thu Feb  2 10:33:20 2012
From: dzickus at redhat.com (Don Zickus)
Date: Thu, 2 Feb 2012 10:33:20 -0500
Subject: [PATCH] x86, kdump, ioapic: Fix kdump race with migrating irq
In-Reply-To: <m1ehuevx12.fsf@fess.ebiederm.org>
References: <1328045114-4489-1-git-send-email-dzickus@redhat.com>
 <m1ipjr4jaa.fsf@fess.ebiederm.org>
 <20120131222751.GE5650@redhat.com>
 <m1vcnr33c8.fsf@fess.ebiederm.org>
 <20120201230414.GL5650@redhat.com>
 <m1ehuevx12.fsf@fess.ebiederm.org>
Message-ID: <20120202153320.GM5650@redhat.com>

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

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

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

I will also need your help writing the changelog such that people
understand why removing that line is safe now.

> 
> The only case I can think that won't work without ioapic disables
> is using a crash kernel that doesn't emable the ioapics.

Ok.  I can see that.  Would you agree that scenario is not a very sane
case? :-) Does not using the ioapic really save you anything?

Otherwise the alternative is to use my original patch.

Thanks for the help.

Cheers,
Don

> 
> Eric


From dzickus at redhat.com  Thu Feb  2 12:45:45 2012
From: dzickus at redhat.com (Don Zickus)
Date: Thu, 2 Feb 2012 12:45:45 -0500
Subject: [PATCH] x86, kdump, ioapic: Fix kdump race with migrating irq
In-Reply-To: <m1ehuevx12.fsf@fess.ebiederm.org>
References: <1328045114-4489-1-git-send-email-dzickus@redhat.com>
 <m1ipjr4jaa.fsf@fess.ebiederm.org>
 <20120131222751.GE5650@redhat.com>
 <m1vcnr33c8.fsf@fess.ebiederm.org>
 <20120201230414.GL5650@redhat.com>
 <m1ehuevx12.fsf@fess.ebiederm.org>
Message-ID: <20120202174545.GR5650@redhat.com>

On Wed, Feb 01, 2012 at 05:34:01PM -0800, Eric W. Biederman wrote:
> > I attached the output of the Pentium4 when kdumping.  Not sure what to
> > really look for to verify the PIC is being skipped.  Perhaps you know?
> 
> The important part is the kexec on panic works without shutting down
> the ioapic.  There should be no corner case issues it should either
> work it should fail.
> 
> The problem used to be that we always would initialize the PIT interrupt
> in the 8259 interrupt controller before we would initialize the ioapics
> and that would kill the boot.

So I dug up an old athlon (family 0x6, model 0x2) which didn't have an
ioapic and kdump seem to work fine.

I'll repost the patch with just the one line removed and come up with some
sort of explaination for it.

Thanks,
Don

----
here is the boot log for that kdump kernel in case it is of interest..

[root at athlon3 ~]# SysRq : Trigger a crash
BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [<c06873ef>] sysrq_handle_crash+0xf/0x20
*pdpt = 00000000326e6001 *pde = 0000000000000000
Oops: 0002 [#1] SMP
Modules linked in: sunrpc ipv6 ppdev floppy microcode pcspkr serio_raw
3c59x mii via686a i2c_viapro i2c_core sg parport_pc parport ext4 mbcache
jbd2 sr_mod cdrom sd_mod crc_t10dif pata_acpi ata_generic pata_via
dm_mirror dm_region_hash dm_log dm_mod [last unloaded: mperf]

Pid: 4748, comm: bash Not tainted 3.3.0-rc1nmi+ #1 System Manufacturer
System Name/<K7V-RM>
EIP: 0060:[<c06873ef>] EFLAGS: 00010086 CPU: 0
EIP is at sysrq_handle_crash+0xf/0x20
EAX: 00000063 EBX: 00000063 ECX: 00000000 EDX: 00000000
ESI: c0a6b760 EDI: 00000296 EBP: 00000000 ESP: f26dff24
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process bash (pid: 4748, ti=f26de000 task=f26665b0 task.ti=f26de000)
Stack:
 c0687a50 c098f07f c09e0b34 00000007 00000000 f26c8280 c0687ab0 fffffffb
 c0687aec 00000002 b77df000 f56f2920 c057334f f26dff9c 00000002 b77df000
 f26c8280 00000002 b77df000 c05732f0 c05274d0 f26dff9c f26671cc 00000000
Call Trace:
 [<c0687a50>] ? __handle_sysrq+0xf0/0x150
 [<c0687ab0>] ? __handle_sysrq+0x150/0x150
 [<c0687aec>] ? write_sysrq_trigger+0x3c/0x50
 [<c057334f>] ? proc_reg_write+0x5f/0x90
 [<c05732f0>] ? proc_reg_poll+0x80/0x80
 [<c05274d0>] ? vfs_write+0xa0/0x170
 [<c0527671>] ? sys_write+0x41/0x80
 [<c085241f>] ? sysenter_do_call+0x12/0x28
Code: a6 c0 01 0f b6 41 03 19 d2 f7 d2 83 e2 03 83 e0 8f c1 e2 04 09 d0 88
41 03 f3 c3 90 c7 05 10 76 b2 c0 01 00 00 00 f0 83 04 24 00 <c6> 05 00 00
00 00 01 c3 89 f6 8d bc 27 00 00 00 00 8d 50 d0 83
EIP: [<c06873ef>] sysrq_handle_crash+0xf/0x20 SS:ESP 0068:f26dff24
CR2: 0000000000000000
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 3.3.0-rc1nmi+ (dzickus at ihatethathostname.lab.bos.redhat.com)
(gcc version 4.4.4 20100726 (Red Hat 4.4.4-13) (GCC) ) #1 SMP Wed Feb 1
17:22:40 EST 2012
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000100 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000005fffc000 (usable)
 BIOS-e820: 000000005fffc000 - 000000005ffff000 (ACPI data)
 BIOS-e820: 000000005ffff000 - 0000000060000000 (ACPI NVS)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
last_pfn = 0x5fffc max_arch_pfn = 0x1000000
Notice: NX (Execute Disable) protection missing in CPU!
user-defined physical RAM map:
 user: 0000000000000000 - 0000000000010000 (reserved)
 user: 0000000000010000 - 00000000000a0000 (usable)
 user: 00000000000f0000 - 0000000000100000 (reserved)
 user: 0000000018000000 - 000000001ff6a000 (usable)
 user: 000000001ff6a400 - 000000001ff6f000 (usable)
 user: 000000001ffff000 - 0000000020000000 (usable)
 user: 000000005fffc000 - 0000000060000000 (ACPI data)
 user: 00000000ffff0000 - 0000000100000000 (reserved)
DMI 2.3 present.
last_pfn = 0x20000 max_arch_pfn = 0x1000000
x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106
init_memory_mapping: 0000000000000000-0000000020000000
RAMDISK: 1fb7e000 - 1ff5f000
crashkernel reservation failed - No suitable area found.
ACPI: RSDP 000f5c30 00014 (v00 ASUS  )
ACPI: RSDT 5fffc000 0002C (v01 ASUS   K7V-RM   30303031 MSFT 31313031)
ACPI: FACP 5fffc080 00074 (v01 ASUS   K7V-RM   30303031 MSFT 31313031)
ACPI: DSDT 5fffc100 0267F (v01   ASUS K7V-RM   00001000 MSFT 0100000B)
ACPI: FACS 5ffff000 00040
ACPI: BOOT 5fffc040 00028 (v01 ASUS   K7V-RM   30303031 MSFT 31313031)
0MB HIGHMEM available.
512MB LOWMEM available.
  mapped low ram: 0 - 20000000
  low ram: 0 - 20000000
Zone PFN ranges:
  DMA      0x00000010 -> 0x00001000
  Normal   0x00001000 -> 0x00020000
  HighMem  empty
Movable zone start PFN for each node
Early memory PFN ranges
    0: 0x00000010 -> 0x000000a0
    0: 0x00018000 -> 0x0001ff6a
    0: 0x0001ff6b -> 0x0001ff6f
    0: 0x0001ffff -> 0x00020000
Using APIC driver default
ACPI: PM-Timer IO Port: 0xe408
SMP: Allowing 1 CPUs, 0 hotplug CPUs
Local APIC disabled by BIOS -- you can enable it with "lapic"
APIC: disable apic facility
APIC: switched to apic NOOP
PM: Registered nosave memory: 00000000000a0000 - 00000000000f0000
PM: Registered nosave memory: 00000000000f0000 - 0000000000100000
PM: Registered nosave memory: 0000000000100000 - 0000000018000000
PM: Registered nosave memory: 000000001ff6a000 - 000000001ff6b000
PM: Registered nosave memory: 000000001ff6f000 - 000000001ffff000
Allocating PCI resources starting at 60000000 (gap: 60000000:9fff0000)
Booting paravirtualized kernel on bare hardware
setup_percpu: NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:1 nr_node_ids:1
PERCPU: Embedded 13 pages/cpu @df400000 s32704 r0 d20544 u2097152
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 31743
Kernel command line: ro root=/dev/mapper/vg_athlon3-lv_root rd_NO_LUKS
LANG=en_US.UTF-8 rd_LVM_LV=vg_athlon3/lv_swap rd_NO_MD KEYTABLE=us
console=ttyS0,115200 rd_LVM_LV=vg_athlon3/lv_root
SYSFONT=latarcyrheb-sun16 rd_NO_DM crashkernel=128M irqpoll nr_cpus=1
reset_devices cgroup_disable=memory  memmap=exactmap memmap=64K$0K
memmap=576K at 64K memmap=64K$960K memmap=130472K at 393216K memmap=19K at 523689K
memmap=4K at 524284K memmap=12K#1572848K memmap=4K#1572860K
memmap=64K$4194240K elfcorehdr=523688K
Misrouted IRQ fixup and polling support enabled
This may significantly impact system performance
Disabling memory control group subsystem
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Initializing CPU#0
Initializing HighMem for node 0 (00000000:00000000)
Memory: 113684k/524288k available (4429k kernel code, 17384k reserved,
2305k data, 500k init, 0k highmem)
virtual kernel memory layout:
    fixmap  : 0xffa96000 - 0xfffff000   (5540 kB)
    pkmap   : 0xff600000 - 0xff800000   (2048 kB)
    vmalloc : 0xe0800000 - 0xff5fe000   ( 493 MB)
    lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
      .init : 0xd8a94000 - 0xd8b11000   ( 500 kB)
      .data : 0xd8853712 - 0xd8a93d80   (2305 kB)
      .text : 0xd8400000 - 0xd8853712   (4429 kB)
Checking if this processor honours the WP bit even in supervisor
mode...Ok.
Hierarchical RCU implementation.
NR_IRQS:2304 nr_irqs:256 16
Console: colour VGA+ 80x25
console [ttyS0] enabled
Fast TSC calibration using PIT
Detected 700.010 MHz processor.
Calibrating delay loop (skipped), value calculated using timer frequency..
1400.02 BogoMIPS (lpj=700010)
pid_max: default: 32768 minimum: 301
Security Framework initialized
SELinux:  Initializing.
Mount-cache hash table entries: 512
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
Initializing cgroup subsys net_cls
Initializing cgroup subsys blkio
Initializing cgroup subsys perf_event
mce: CPU supports 4 MCE banks
SMP alternatives: switching to UP code
Freeing SMP alternatives: 20k freed
ACPI: Core revision 20120111
ACPI: setting ELCR to 0200 (from 0600)
weird, boot CPU (#0) not listed by the BIOS.
SMP motherboard not detected.
Local APIC not detected. Using dummy APIC emulation.
SMP disabled
Performance Events:
no APIC, boot with the "lapic" boot parameter to force-enable it.
no hardware sampling interrupt available.
AMD PMU driver.
... version:                0
... bit width:              48
... generic registers:      4
... value mask:             0000ffffffffffff
... max period:             00007fffffffffff
... fixed-purpose events:   0
... event mask:             000000000000000f
NMI watchdog disabled (cpu0): not supported (no LAPIC?)
Brought up 1 CPUs
Total of 1 processors activated (1400.02 BogoMIPS).
devtmpfs: initialized
print_constraints: dummy:
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xf08c0, last bus=1
PCI: Using configuration type 1 for base access
bio: create slab <bio-0> at 0
ACPI: Added _OSI(Module Device)
ACPI: Added _OSI(Processor Device)
ACPI: Added _OSI(3.0 _SCP Extensions)
ACPI: Added _OSI(Processor Aggregator Device)
ACPI: Interpreter enabled
ACPI: (supports S0 S1 S4 S5)
ACPI: Using PIC for interrupt routing
ACPI: No dock devices found.
PCI: Ignoring host bridge windows from ACPI; if necessary, use
"pci=use_crs" and report a bug
ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
<snip>


From dzickus at redhat.com  Thu Feb  2 13:12:03 2012
From: dzickus at redhat.com (Don Zickus)
Date: Thu,  2 Feb 2012 13:12:03 -0500
Subject: [PATCH] x86, kdump: No need to disable ioapic in crash path
Message-ID: <1328206323-25580-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.

Eric, brought up a point that because the boot code was restructured we may
not need to disable the io apic any more in the crash path.  The original
concern that led to the development of disable_IO_APIC, was that the TSC
calibration on boot up relied on the PIT timer for reference.  Access
to the PIT required 8259 interrupts to be working.  This wouldn't work
if the ioapic needed to be configured.  So on panic path, the ioapic was
reconfigured to use virtual wire mode to allow the 8259 to passthrough.

Those concerns don't hold true now, thanks to the fast TSC calibration code
not needing the PIT.  As a result, we can remove this call and simplify the
locking needed in the panic path.

I tested kdump on an Ivy Bridge platform, a Pentium4 and an old athlon that
did not have an ioapic.  All three were successful.

Cc: Eric W. Biederman <ebiederm at xmission.com>
Cc: Vivek Goyal <vgoyal at redhat.com>
Signed-off-by: Don Zickus <dzickus at redhat.com>

---
I will probably need some help with my explaination as to why this line is not
needed.  Any input is appreciated!
---
 arch/x86/kernel/crash.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 13ad899..b053cf9 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -96,9 +96,6 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
 	cpu_emergency_svm_disable();
 
 	lapic_shutdown();
-#if defined(CONFIG_X86_IO_APIC)
-	disable_IO_APIC();
-#endif
 #ifdef CONFIG_HPET_TIMER
 	hpet_disable();
 #endif
-- 
1.7.7.6



From ebiederm at xmission.com  Thu Feb  2 18:24:46 2012
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Thu, 02 Feb 2012 15:24:46 -0800
Subject: [PATCH] x86, kdump: No need to disable ioapic in crash path
In-Reply-To: <1328206323-25580-1-git-send-email-dzickus@redhat.com> (Don
 Zickus's message of "Thu, 2 Feb 2012 13:12:03 -0500")
References: <1328206323-25580-1-git-send-email-dzickus@redhat.com>
Message-ID: <m1r4ycsts1.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.
>
> Eric, brought up a point that because the boot code was restructured we may
> not need to disable the io apic any more in the crash path.  The original
> concern that led to the development of disable_IO_APIC, was that the TSC
> calibration on boot up relied on the PIT timer for reference.  Access
> to the PIT required 8259 interrupts to be working.  This wouldn't work
> if the ioapic needed to be configured.  So on panic path, the ioapic was
> reconfigured to use virtual wire mode to allow the 8259 to passthrough.

A small clarification originally it was the jiffies calibration that
would fail if we could cause the PIT to generate interrupts through the
8259.  The boot would then hang at calibrating jiffies.

> Those concerns don't hold true now, thanks to the fast TSC calibration code
> not needing the PIT.  As a result, we can remove this call and simplify the
> locking needed in the panic path.
>
> I tested kdump on an Ivy Bridge platform, a Pentium4 and an old athlon that
> did not have an ioapic.  All three were successful.
>
> Cc: Eric W. Biederman <ebiederm at xmission.com>
> Cc: Vivek Goyal <vgoyal at redhat.com>
> Signed-off-by: Don Zickus <dzickus at redhat.com>
>
> ---
> I will probably need some help with my explaination as to why this line is not
> needed.  Any input is appreciated!

Can you test and verify that we also do not need the lapic_shutdown()
call and the disable_local_APIC call on the other processors.  The same
reasoning that supports us not needing to disable the IO_APIC also
supports us not needing to disable local apic.

Removing disable_IO_APIC in and of itself and then booting isn't quite
sufficient as a practical test to prove this code always works.
Sometimes the IOAPIC was not hooked up to interesting interrupt sources
like the 8259.

Eric

> ---
>  arch/x86/kernel/crash.c |    3 ---
>  1 files changed, 0 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index 13ad899..b053cf9 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -96,9 +96,6 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
>  	cpu_emergency_svm_disable();
>  
>  	lapic_shutdown();
> -#if defined(CONFIG_X86_IO_APIC)
> -	disable_IO_APIC();
> -#endif
>  #ifdef CONFIG_HPET_TIMER
>  	hpet_disable();
>  #endif


From suzuki at in.ibm.com  Mon Feb  6 04:07:15 2012
From: suzuki at in.ibm.com (Suzuki K. Poulose)
Date: Mon, 06 Feb 2012 14:37:15 +0530
Subject: [PATCH v1 0/3][makedumpfile]Add support for  PPC32
In-Reply-To: <20120119115852.588bf8bb.kumagai-atsushi@mxc.nes.nec.co.jp>
References: <20120118100510.29422.93587.stgit@suzukikp.in.ibm.com>
 <20120119115852.588bf8bb.kumagai-atsushi@mxc.nes.nec.co.jp>
Message-ID: <4F2F9843.9000108@in.ibm.com>

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

Atsushi-San,

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

Did you get a chance to review my patches ?

Suzuki



From kumagai-atsushi at mxc.nes.nec.co.jp  Tue Feb  7 00:58:39 2012
From: kumagai-atsushi at mxc.nes.nec.co.jp (Atsushi Kumagai)
Date: Tue, 7 Feb 2012 14:58:39 +0900
Subject: [PATCH v1 0/3][makedumpfile]Add support for  PPC32
In-Reply-To: <4F2F9843.9000108@in.ibm.com>
References: <20120118100510.29422.93587.stgit@suzukikp.in.ibm.com>
 <20120119115852.588bf8bb.kumagai-atsushi@mxc.nes.nec.co.jp>
 <4F2F9843.9000108@in.ibm.com>
Message-ID: <20120207145839.f7e9fcfd.kumagai-atsushi@mxc.nes.nec.co.jp>

Hi Suzuki,

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

> On 01/19/2012 08:28 AM, Atsushi Kumagai wrote:
> 
> >
> > Thank you for your patches.
> > I will review them.
> 
> Did you get a chance to review my patches ?
> 
> Suzuki
 
I'm reviewing your patches now, and I will inform you
of the result in the course of this week.

Additionally, the followings are scheduled for v1.4.3.

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

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


Thanks
Atsushi Kumagai


From joycedangote23 at rajjmail.net  Tue Feb  7 15:59:53 2012
From: joycedangote23 at rajjmail.net (joyce dangote)
Date: Tue, 7 Feb 2012 20:59:53 +0000
Subject: Please My Dear I Need Your Help.
Message-ID: <CAFT1uM+cHPUfLst-doi1c4+JF3Sn2+Ti25KSebAoCXQ5ZtRMwg@mail.gmail.com>

Hello Dear,

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

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

Briefly, I will like to disclose little more about myself to you and
see if you can help me to relocate to your country so as to continue
with my studies and have a new life, and please this is a little
secret and I plead with you to keep it to yourself alone until
everything is properly arranged and executed, then I will come over to
join you in your country. I have the sum of $5.7Million as an
inheritance from my late father which I will like to invest in your
country with your help, the reason why I need your help is based on
the instruction my late father gave to the bank to release the fund to
me at the age of 23 and through a foreigner who can help me to invest
the fund wisely, I can not be
able to make this claim because of my refugee status. This fund is
deposited in my late father's bank account with one of the banks here
in Burkina-Faso and I am going to give you all the details / contact
because I want the money to be transferred to your account before I
come over to join you in your country, I need your urgent answer of
your ability to handle this for me so that I will tell you the next
step because I want to leave this refugee camp as soon as possible,
life here is to me a hell, no love, no affection and no amenities,
more importantly, I love my studies and here nothing is happening and
people here are not friendly,I am really suffering in this place, it
is too painful, but I hope with your help to transferring the fund in
your account,I will have a better life to live so kindly let me know
your readiness to help me and I promise to always be nice and faithful
to you I will send to you a copy of my photo as soon I receive your
positive respond .

Yours Sincerely,
Joyce Dangote.


From dzickus at redhat.com  Tue Feb  7 16:57:41 2012
From: dzickus at redhat.com (Don Zickus)
Date: Tue, 7 Feb 2012 16:57:41 -0500
Subject: [PATCH] x86, kdump: No need to disable ioapic in crash path
In-Reply-To: <m1r4ycsts1.fsf@fess.ebiederm.org>
References: <1328206323-25580-1-git-send-email-dzickus@redhat.com>
 <m1r4ycsts1.fsf@fess.ebiederm.org>
Message-ID: <20120207215741.GD5650@redhat.com>

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

Ok.  Thanks!

> 
> > Those concerns don't hold true now, thanks to the fast TSC calibration code
> > not needing the PIT.  As a result, we can remove this call and simplify the
> > locking needed in the panic path.
> >
> > I tested kdump on an Ivy Bridge platform, a Pentium4 and an old athlon that
> > did not have an ioapic.  All three were successful.
> >
> > Cc: Eric W. Biederman <ebiederm at xmission.com>
> > Cc: Vivek Goyal <vgoyal at redhat.com>
> > Signed-off-by: Don Zickus <dzickus at redhat.com>
> >
> > ---
> > I will probably need some help with my explaination as to why this line is not
> > needed.  Any input is appreciated!
> 
> Can you test and verify that we also do not need the lapic_shutdown()
> call and the disable_local_APIC call on the other processors.  The same
> reasoning that supports us not needing to disable the IO_APIC also
> supports us not needing to disable local apic.

I did that and it seemed to work on my Ivy Bridge and core2 quad systems.

> 
> Removing disable_IO_APIC in and of itself and then booting isn't quite
> sufficient as a practical test to prove this code always works.
> Sometimes the IOAPIC was not hooked up to interesting interrupt sources
> like the 8259.

So what systems should I look for to test?

Cheers,
Don


From vgoyal at redhat.com  Tue Feb  7 17:19:24 2012
From: vgoyal at redhat.com (Vivek Goyal)
Date: Tue, 7 Feb 2012 17:19:24 -0500
Subject: [PATCH] x86, kdump: No need to disable ioapic in crash path
In-Reply-To: <20120207215741.GD5650@redhat.com>
References: <1328206323-25580-1-git-send-email-dzickus@redhat.com>
 <m1r4ycsts1.fsf@fess.ebiederm.org>
 <20120207215741.GD5650@redhat.com>
Message-ID: <20120207221924.GH6346@redhat.com>

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

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

Thanks
Vivek


From ebiederm at xmission.com  Tue Feb  7 18:35:59 2012
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Tue, 07 Feb 2012 15:35:59 -0800
Subject: [PATCH] x86, kdump: No need to disable ioapic in crash path
In-Reply-To: <20120207221924.GH6346@redhat.com> (Vivek Goyal's message of
 "Tue, 7 Feb 2012 17:19:24 -0500")
References: <1328206323-25580-1-git-send-email-dzickus@redhat.com>
 <m1r4ycsts1.fsf@fess.ebiederm.org> <20120207215741.GD5650@redhat.com>
 <20120207221924.GH6346@redhat.com>
Message-ID: <m1r4y6i5cw.fsf@fess.ebiederm.org>

Vivek Goyal <vgoyal at redhat.com> writes:

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

Yes.  Part of the Moorstown work required that this be done because
moorsetown did not support legacy mode.  Last I looked the code hadn't
been generalized beyond Moorsetown but empirically it works now.

Don as to what to test the only case I can think of that might be spooky
is a screaming interrupt during the handover.  You might want to try
playing with lkcdtm to try some of the more exotic crash scenarios.  But
all I expect further testing might reveal are places where we are not
as robust in initializing the hardware as we might be.  Things that
might have been papered over by the ioapic shutdown.

I think we are good to remove my ancient hack of disabling the ioapics,
and putting the system into PIT during the crash kernel switchover.

Eric


From tylerwhall at gmail.com  Tue Feb  7 18:50:05 2012
From: tylerwhall at gmail.com (Tyler Hall)
Date: Tue,  7 Feb 2012 18:50:05 -0500
Subject: [PATCH] Fix out-of-tree build
Message-ID: <1328658605-25688-1-git-send-email-tylerwhall@gmail.com>

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

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

diff --git a/kdump/Makefile b/kdump/Makefile
index 1e2b72c..5dfa928 100644
--- a/kdump/Makefile
+++ b/kdump/Makefile
@@ -22,7 +22,7 @@ $(KDUMP): $(KDUMP_OBJS)
 
 $(KDUMP_MANPAGE): kdump/kdump.8
 	$(MKDIR) -p     $(MANDIR)/man8
-	cp kdump/kdump.8 $(KDUMP_MANPAGE)
+	cp $^ $(KDUMP_MANPAGE)
 echo::
 	@echo "KDUMP_SRCS $(KDUMP_SRCS)"
 	@echo "KDUMP_DEPS $(KDUMP_DEPS)"
diff --git a/kexec/Makefile b/kexec/Makefile
index 2137cab..8c815b5 100644
--- a/kexec/Makefile
+++ b/kexec/Makefile
@@ -82,7 +82,7 @@ $(KEXEC): CPPFLAGS+=-I$(srcdir)/kexec/arch/$(ARCH)/include
 
 $(KEXEC_MANPAGE): kexec/kexec.8
 	@$(MKDIR) -p     $(MANDIR)/man8
-	cp kexec/kexec.8 $(KEXEC_MANPAGE)
+	cp $^ $(KEXEC_MANPAGE)
 echo::
 	@echo "KEXEC_SRCS $(KEXEC_SRCS)"
 	@echo "KEXEC_DEPS $(KEXEC_DEPS)"
diff --git a/kexec/arch/ppc/Makefile b/kexec/arch/ppc/Makefile
index 3dba7cf..41242a5 100644
--- a/kexec/arch/ppc/Makefile
+++ b/kexec/arch/ppc/Makefile
@@ -1,7 +1,7 @@
 #
 # kexec ppc (linux booting linux)
 #
-include kexec/arch/ppc/libfdt/Makefile.libfdt
+include $(srcdir)/kexec/arch/ppc/libfdt/Makefile.libfdt
 
 ppc_KEXEC_SRCS =  kexec/arch/ppc/kexec-ppc.c
 ppc_KEXEC_SRCS += kexec/arch/ppc/kexec-elf-ppc.c
diff --git a/vmcore-dmesg/Makefile b/vmcore-dmesg/Makefile
index 5a6d84a..42c218a 100644
--- a/vmcore-dmesg/Makefile
+++ b/vmcore-dmesg/Makefile
@@ -21,7 +21,7 @@ $(VMCORE_DMESG): $(VMCORE_DMESG_OBJS)
 
 $(VMCORE_DMESG_MANPAGE): vmcore-dmesg/vmcore-dmesg.8
 	$(MKDIR) -p     $(MANDIR)/man8
-	cp vmcore-dmesg/vmcore-dmesg.8 $(VMCORE_DMESG_MANPAGE)
+	cp $^ $(VMCORE_DMESG_MANPAGE)
 echo::
 	@echo "VMCORE_DMESG_SRCS $(VMCORE_DMESG_SRCS)"
 	@echo "VMCORE_DMESG_DEPS $(VMCORE_DMESG_DEPS)"
-- 
1.7.9



From horms at verge.net.au  Tue Feb  7 19:47:25 2012
From: horms at verge.net.au (Simon Horman)
Date: Wed, 8 Feb 2012 09:47:25 +0900
Subject: [PATCH] Fix out-of-tree build
In-Reply-To: <1328658605-25688-1-git-send-email-tylerwhall@gmail.com>
References: <1328658605-25688-1-git-send-email-tylerwhall@gmail.com>
Message-ID: <20120208004725.GB14954@verge.net.au>

On Tue, Feb 07, 2012 at 06:50:05PM -0500, Tyler Hall wrote:
> Use automatic variables for prerequisites when copying man pages and
> include a makefile relative to $(srcdir).

Thanks, applied.


From dzickus at redhat.com  Wed Feb  8 15:11:45 2012
From: dzickus at redhat.com (Don Zickus)
Date: Wed, 8 Feb 2012 15:11:45 -0500
Subject: [PATCH] x86, kdump: No need to disable ioapic in crash path
In-Reply-To: <m1r4y6i5cw.fsf@fess.ebiederm.org>
References: <1328206323-25580-1-git-send-email-dzickus@redhat.com>
 <m1r4ycsts1.fsf@fess.ebiederm.org>
 <20120207215741.GD5650@redhat.com>
 <20120207221924.GH6346@redhat.com>
 <m1r4y6i5cw.fsf@fess.ebiederm.org>
Message-ID: <20120208201145.GX5650@redhat.com>

On Tue, Feb 07, 2012 at 03:35:59PM -0800, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal at redhat.com> writes:
> 
> > On Tue, Feb 07, 2012 at 04:57:41PM -0500, Don Zickus wrote:
> >> On Thu, Feb 02, 2012 at 03:24:46PM -0800, Eric W. Biederman wrote:
> >> > > Eric, brought up a point that because the boot code was restructured we may
> >> > > not need to disable the io apic any more in the crash path.  The original
> >> > > concern that led to the development of disable_IO_APIC, was that the TSC
> >> > > calibration on boot up relied on the PIT timer for reference.  Access
> >> > > to the PIT required 8259 interrupts to be working.  This wouldn't work
> >> > > if the ioapic needed to be configured.  So on panic path, the ioapic was
> >> > > reconfigured to use virtual wire mode to allow the 8259 to passthrough.
> >> > 
> >> > A small clarification originally it was the jiffies calibration that
> >> > would fail if we could cause the PIT to generate interrupts through the
> >> > 8259.  The boot would then hang at calibrating jiffies.
> >> 
> >> Ok.  Thanks!
> >
> > So now what has changed? Do we setup LAPIC and IOAPIC early enough to
> > receive PIT interrupts in regular mode (non-virtual wire mode) or
> > something else?
> 
> Yes.  Part of the Moorstown work required that this be done because
> moorsetown did not support legacy mode.  Last I looked the code hadn't
> been generalized beyond Moorsetown but empirically it works now.
> 
> Don as to what to test the only case I can think of that might be spooky
> is a screaming interrupt during the handover.  You might want to try
> playing with lkcdtm to try some of the more exotic crash scenarios.  But
> all I expect further testing might reveal are places where we are not
> as robust in initializing the hardware as we might be.  Things that
> might have been papered over by the ioapic shutdown.

I ran lkdtm by panic'ing in the interrupt handle thus leaving device
interrupt un-ack'd and the apic might have been un-ack'd too (jprobes
hooked in at do_IRQ).  3 out 3 times the second kernel came up on my core2
quad.

Cheers,
Don


From ebiederm at xmission.com  Wed Feb  8 17:55:14 2012
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Wed, 08 Feb 2012 14:55:14 -0800
Subject: [PATCH] x86, kdump: No need to disable ioapic in crash path
In-Reply-To: <20120208201145.GX5650@redhat.com> (Don Zickus's message of "Wed, 
 8 Feb 2012 15:11:45 -0500")
References: <1328206323-25580-1-git-send-email-dzickus@redhat.com>
 <m1r4ycsts1.fsf@fess.ebiederm.org> <20120207215741.GD5650@redhat.com>
 <20120207221924.GH6346@redhat.com> <m1r4y6i5cw.fsf@fess.ebiederm.org>
 <20120208201145.GX5650@redhat.com>
Message-ID: <m1sjilc4vh.fsf@fess.ebiederm.org>

Don Zickus <dzickus at redhat.com> writes:

> On Tue, Feb 07, 2012 at 03:35:59PM -0800, Eric W. Biederman wrote:
>> Vivek Goyal <vgoyal at redhat.com> writes:
>> 
>> > On Tue, Feb 07, 2012 at 04:57:41PM -0500, Don Zickus wrote:
>> >> On Thu, Feb 02, 2012 at 03:24:46PM -0800, Eric W. Biederman wrote:
>> >> > > Eric, brought up a point that because the boot code was restructured we may
>> >> > > not need to disable the io apic any more in the crash path.  The original
>> >> > > concern that led to the development of disable_IO_APIC, was that the TSC
>> >> > > calibration on boot up relied on the PIT timer for reference.  Access
>> >> > > to the PIT required 8259 interrupts to be working.  This wouldn't work
>> >> > > if the ioapic needed to be configured.  So on panic path, the ioapic was
>> >> > > reconfigured to use virtual wire mode to allow the 8259 to passthrough.
>> >> > 
>> >> > A small clarification originally it was the jiffies calibration that
>> >> > would fail if we could cause the PIT to generate interrupts through the
>> >> > 8259.  The boot would then hang at calibrating jiffies.
>> >> 
>> >> Ok.  Thanks!
>> >
>> > So now what has changed? Do we setup LAPIC and IOAPIC early enough to
>> > receive PIT interrupts in regular mode (non-virtual wire mode) or
>> > something else?
>> 
>> Yes.  Part of the Moorstown work required that this be done because
>> moorsetown did not support legacy mode.  Last I looked the code hadn't
>> been generalized beyond Moorsetown but empirically it works now.
>> 
>> Don as to what to test the only case I can think of that might be spooky
>> is a screaming interrupt during the handover.  You might want to try
>> playing with lkcdtm to try some of the more exotic crash scenarios.  But
>> all I expect further testing might reveal are places where we are not
>> as robust in initializing the hardware as we might be.  Things that
>> might have been papered over by the ioapic shutdown.
>
> I ran lkdtm by panic'ing in the interrupt handle thus leaving device
> interrupt un-ack'd and the apic might have been un-ack'd too (jprobes
> hooked in at do_IRQ).  3 out 3 times the second kernel came up on my core2
> quad.

That sounds like more than enough basic testing for me.  Document your
testing in a patch description and let's get the unnecessary local apic
and ioapic stomping removed from the kexec on panic path.

There were bugs.  We deleted the code that had them.  The bugs are gone
and there are no new problems goes over very well in my book.

Eric



From mujeeb.adil at gmail.com  Thu Feb  9 01:03:14 2012
From: mujeeb.adil at gmail.com (Adil Mujeeb)
Date: Thu, 9 Feb 2012 11:33:14 +0530
Subject: kdump / Kexec not working
Message-ID: <CANBXnM=7eJVwCOoA-AoNPPf0A8OWyeQ=tG-W6ZiONG3WOb+EoQ@mail.gmail.com>

Hi List,

I am new to crash / kdump tool and facing some problem as mentioned below.

I have SLES11 based system. I am building kernel source (SLES11 based
2.6.32 version) and added my
modules (for study purpose) in it. Building, installing and booting
with this kernel is successful. I have enabled the options for kdump
as mentioned below:

Enable Kexec system call:
CONFIG_KEXEC=y

Enable kernel crash dumps:
CONFIG_CRASH_DUMP=y

Optional: Disable Symmetric Multi-Processing (SMP) support
CONFIG_SMP=y

Enable sysfs file system support:
CONFIG_SYSFS=y

Enable /proc/vmcore support:
CONFIG_PROC_VMCORE=y

Configure the kernel with debug info:
CONFIG_DEBUG_INFO=y

Configure the start section for reserved RAM for the crash kernel:
CONFIG_PHYSICAL_START=0x200000             (2MB)

Configure kdump kernel so it can be identified:
CONFIG_LOCALVERSION="-crash"


Kdump configuration /etc/sysconfig/kdump:
KDUMP_KERNELVER=""

KDUMP_COMMANDLINE=""

KDUMP_COMMANDLINE_APPEND="maxcpus=1 "

KEXEC_OPTIONS=""

KDUMP_IMMEDIATE_REBOOT="yes"

KDUMP_TRANSFER=""

KDUMP_SAVEDIR="file:///var/crash"

KDUMP_KEEP_OLD_DUMPS="5"

KDUMP_FREE_DISK_SIZE="64"

KDUMP_VERBOSE="3"

KDUMP_DUMPLEVEL="0"

KDUMP_DUMPFORMAT="compressed"

There is no option KDUMP_DUMPDEV option
There is no option KDUMP_RUNLEVEL

I booted successfully with this kernel and tried to crash it by
kernel module. The system freezes and did not reboot as I expected the
kexec and kdump to do it. After rebooting manually there is no dump
file generated.

What could be the issue here?

Another observation is boot.kdump seems to on but manually start
giving me error:

linux:/home/adil # chkconfig boot.kdump
boot.kdump  on
linux:/home/adil #

hltncra110731:/home/adil # /etc/init.d/boot.kdump status
kdump kernel not loaded

                                                    dead
hltncra110731:/home/adil # /etc/init.d/boot.kdump start
Loading kdump
Can't find kernel text map area from kcore
Cannot load /boot/vmlinuz-2.6.32.12-crash

                                                    failed
hltncra110731:/home/adil #

Please help how to correctly setup and use crash on my machine.

Thank you,
Adil


From dzickus at redhat.com  Thu Feb  9 09:48:57 2012
From: dzickus at redhat.com (Don Zickus)
Date: Thu, 9 Feb 2012 09:48:57 -0500
Subject: [PATCH] x86, kdump: No need to disable ioapic in crash path
In-Reply-To: <m1sjilc4vh.fsf@fess.ebiederm.org>
References: <1328206323-25580-1-git-send-email-dzickus@redhat.com>
 <m1r4ycsts1.fsf@fess.ebiederm.org>
 <20120207215741.GD5650@redhat.com>
 <20120207221924.GH6346@redhat.com>
 <m1r4y6i5cw.fsf@fess.ebiederm.org>
 <20120208201145.GX5650@redhat.com>
 <m1sjilc4vh.fsf@fess.ebiederm.org>
Message-ID: <20120209144857.GC5650@redhat.com>

On Wed, Feb 08, 2012 at 02:55:14PM -0800, Eric W. Biederman wrote:
> > I ran lkdtm by panic'ing in the interrupt handle thus leaving device
> > interrupt un-ack'd and the apic might have been un-ack'd too (jprobes
> > hooked in at do_IRQ).  3 out 3 times the second kernel came up on my core2
> > quad.
> 
> That sounds like more than enough basic testing for me.  Document your
> testing in a patch description and let's get the unnecessary local apic
> and ioapic stomping removed from the kexec on panic path.
> 
> There were bugs.  We deleted the code that had them.  The bugs are gone
> and there are no new problems goes over very well in my book.

Great.  Thanks.  I'll put together the patch.

Cheers,
Don


From dzickus at redhat.com  Thu Feb  9 16:53:41 2012
From: dzickus at redhat.com (Don Zickus)
Date: Thu,  9 Feb 2012 16:53:41 -0500
Subject: [PATCH v2] x86, kdump: No need to disable ioapic/lapic in crash path
Message-ID: <1328824421-11068-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.

Eric, brought up a point that because the boot code was restructured we may
not need to disable the io apic any more in the crash path.  The original
concern that led to the development of disable_IO_APIC, was that the jiffies
calibration on boot up relied on the PIT timer for reference.  Access
to the PIT required 8259 interrupts to be working.  This wouldn't work
if the ioapic needed to be configured.  So on panic path, the ioapic was
reconfigured to use virtual wire mode to allow the 8259 to passthrough.

Those concerns don't hold true now, thanks to the jiffies calibration code
not needing the PIT.  As a result, we can remove this call and simplify the
locking needed in the panic path.

The same work allowed us to remove the need to disable the local apic on
shutdown too.  This should allow us to jump to the second a little faster.

I tested kdump on an Ivy Bridge platform, a Pentium4 and an old athlon that
did not have an ioapic.  All three were successful.

I also tested using lkdtm that would use jprobes to panic the system when
entering do_IRQ.  The idea was to see how the system reacted with an
interrupt pending in the second kernel.  My core2 quad successfully kdump'd
3 times in a row with no issues.

v2: removed the disable lapic code too

Cc: Eric W. Biederman <ebiederm at xmission.com>
Cc: Vivek Goyal <vgoyal at redhat.com>
Signed-off-by: Don Zickus <dzickus at redhat.com>
---
 arch/x86/kernel/crash.c |    8 --------
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 13ad899..571f253 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -54,16 +54,12 @@ static void kdump_nmi_callback(int cpu, struct pt_regs *regs)
 	 */
 	cpu_emergency_vmxoff();
 	cpu_emergency_svm_disable();
-
-	disable_local_APIC();
 }
 
 static void kdump_nmi_shootdown_cpus(void)
 {
 	in_crash_kexec = 1;
 	nmi_shootdown_cpus(kdump_nmi_callback);
-
-	disable_local_APIC();
 }
 
 #else
@@ -95,10 +91,6 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
 	cpu_emergency_vmxoff();
 	cpu_emergency_svm_disable();
 
-	lapic_shutdown();
-#if defined(CONFIG_X86_IO_APIC)
-	disable_IO_APIC();
-#endif
 #ifdef CONFIG_HPET_TIMER
 	hpet_disable();
 #endif
-- 
1.7.7.6



From ebiederm at xmission.com  Thu Feb  9 18:49:43 2012
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Thu, 09 Feb 2012 15:49:43 -0800
Subject: [PATCH v2] x86,
 kdump: No need to disable ioapic/lapic in crash path
In-Reply-To: <1328824421-11068-1-git-send-email-dzickus@redhat.com> (Don
 Zickus's message of "Thu, 9 Feb 2012 16:53:41 -0500")
References: <1328824421-11068-1-git-send-email-dzickus@redhat.com>
Message-ID: <m1k43v5zzc.fsf@fess.ebiederm.org>


The code and the testing look good, and it has long been desirable to
get rid of this code and reduce the complexity of the kexec on panic
path.

Ingo, Peter, Thomas if one of you could pick this up that would be
wonderful.


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.



[snip]
> I tested kdump on an Ivy Bridge platform, a Pentium4 and an old athlon that
> did not have an ioapic.  All three were successful.
>
> I also tested using lkdtm that would use jprobes to panic the system when
> entering do_IRQ.  The idea was to see how the system reacted with an
> interrupt pending in the second kernel.  My core2 quad successfully kdump'd
> 3 times in a row with no issues.
>
> v2: removed the disable lapic code too
>
> Cc: Eric W. Biederman <ebiederm at xmission.com>
> Cc: Vivek Goyal <vgoyal at redhat.com>
> Signed-off-by: Don Zickus <dzickus at redhat.com>
Reviewed-by: "Eric W. Biederman" <ebiederm at xmission.com>

> ---
>  arch/x86/kernel/crash.c |    8 --------
>  1 files changed, 0 insertions(+), 8 deletions(-)

[snip]

Eric


From kumagai-atsushi at mxc.nes.nec.co.jp  Fri Feb 10 04:45:43 2012
From: kumagai-atsushi at mxc.nes.nec.co.jp (Atsushi Kumagai)
Date: Fri, 10 Feb 2012 18:45:43 +0900
Subject: [PATCH v1 3/3] [makedumpfile] Add support for PPC32
In-Reply-To: <20120118100949.29422.17463.stgit@suzukikp.in.ibm.com>
References: <20120118100510.29422.93587.stgit@suzukikp.in.ibm.com>
 <20120118100949.29422.17463.stgit@suzukikp.in.ibm.com>
Message-ID: <20120210184543.fbb08606.kumagai-atsushi@mxc.nes.nec.co.jp>

Hi, Suzuki

On Wed, 18 Jan 2012 15:40:03 +0530
"Suzuki K. Poulose" <suzuki at in.ibm.com> wrote:

> 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

I will make small changes:

diff --git a/makedumpfile.c b/makedumpfile.c
index cefb7cf..901b85c 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -5693,7 +5693,7 @@ initial_xen(void)

 #if defined(__powerpc64__) || defined(__powerpc32__)
        MSG("\n");
-       MSG("xen is not supported on powerpc.\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 88b7bc2..e43ea84 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -686,7 +686,7 @@ unsigned long long vaddr_to_paddr_ppc(unsigned long vaddr);
 #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 */
+#endif          /* powerpc32 */

 #ifdef __s390x__ /* s390x */
 int get_machdep_info_s390x(void);


The other parts looks good.
I will merge this patch to makedumpfile-1.4.3.

By the way, could you tell me kernel versions that you've tested ?
I want to update "SUPPORTED KERNELS" in the README.


Thanks
Atsushi Kumagai

> 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
> 
> 
> _______________________________________________
> 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 Feb 10 04:44:29 2012
From: kumagai-atsushi at mxc.nes.nec.co.jp (Atsushi Kumagai)
Date: Fri, 10 Feb 2012 18:44:29 +0900
Subject: [PATCH v1 2/3][makedumpfile][ppc64] Rename the __powerpc__
 macro to __powerpc64__ for PPC64
In-Reply-To: <20120118100921.29422.90156.stgit@suzukikp.in.ibm.com>
References: <20120118100510.29422.93587.stgit@suzukikp.in.ibm.com>
 <20120118100921.29422.90156.stgit@suzukikp.in.ibm.com>
Message-ID: <20120210184429.534aa570.kumagai-atsushi@mxc.nes.nec.co.jp>

Hi, Suzuki

On Wed, 18 Jan 2012 15:39:44 +0530
"Suzuki K. Poulose" <suzuki at in.ibm.com> wrote:

> 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(-)

I will make small changes to your patch:

--- a/arch/ppc64.c
+++ b/arch/ppc64.c
@@ -18,7 +18,7 @@
  * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */

-#ifdef __powerpc__
+#ifdef __powerpc64__

 #include "../print_info.h"
 #include "../elf_info.h"
@@ -93,4 +93,4 @@ vaddr_to_paddr_ppc64(unsigned long vaddr)
        return NOT_PADDR;
 }

-#endif /* powerpc */
+#endif /* powerpc64 */


The other parts looks good.
I will merge this patch to makedumpfile-1.4.3.

Thanks
Atsushi Kumagai


> 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
> 
> 
> _______________________________________________
> 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 Feb 10 04:42:35 2012
From: kumagai-atsushi at mxc.nes.nec.co.jp (Atsushi Kumagai)
Date: Fri, 10 Feb 2012 18:42:35 +0900
Subject: [PATCH v1 1/3] [makedumpfile] Support for cross building
In-Reply-To: <20120118100755.29422.5803.stgit@suzukikp.in.ibm.com>
References: <20120118100510.29422.93587.stgit@suzukikp.in.ibm.com>
 <20120118100755.29422.5803.stgit@suzukikp.in.ibm.com>
Message-ID: <20120210184235.0f4a5dd2.kumagai-atsushi@mxc.nes.nec.co.jp>

Hi, Suzuki

On Wed, 18 Jan 2012 15:39:14 +0530
"Suzuki K. Poulose" <suzuki at in.ibm.com> wrote:

> 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(-)

This patch looks good.
I will merge it to makedumpfile-1.4.3.

Thanks
Atsushi Kumagai

> 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.
> 
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec


From suzuki at in.ibm.com  Fri Feb 10 06:36:35 2012
From: suzuki at in.ibm.com (Suzuki K. Poulose)
Date: Fri, 10 Feb 2012 17:06:35 +0530
Subject: [PATCH v1 3/3] [makedumpfile] Add support for PPC32
In-Reply-To: <20120210184543.fbb08606.kumagai-atsushi@mxc.nes.nec.co.jp>
References: <20120118100510.29422.93587.stgit@suzukikp.in.ibm.com>
 <20120118100949.29422.17463.stgit@suzukikp.in.ibm.com>
 <20120210184543.fbb08606.kumagai-atsushi@mxc.nes.nec.co.jp>
Message-ID: <4F350143.1090508@in.ibm.com>

On 02/10/2012 03:15 PM, Atsushi Kumagai wrote:
> Hi, Suzuki
>
> On Wed, 18 Jan 2012 15:40:03 +0530
> "Suzuki K. Poulose"<suzuki at in.ibm.com>  wrote:
>
>> 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
>
> I will make small changes:
>
> diff --git a/makedumpfile.c b/makedumpfile.c
> index cefb7cf..901b85c 100644
> --- a/makedumpfile.c
> +++ b/makedumpfile.c
> @@ -5693,7 +5693,7 @@ initial_xen(void)
>
>   #if defined(__powerpc64__) || defined(__powerpc32__)
>          MSG("\n");
> -       MSG("xen is not supported on powerpc.\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 88b7bc2..e43ea84 100644
> --- a/makedumpfile.h
> +++ b/makedumpfile.h
> @@ -686,7 +686,7 @@ unsigned long long vaddr_to_paddr_ppc(unsigned long vaddr);
>   #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 */
> +#endif          /* powerpc32 */
>
>   #ifdef __s390x__ /* s390x */
>   int get_machdep_info_s390x(void);
>
>
> The other parts looks good.
> I will merge this patch to makedumpfile-1.4.3.
>
> By the way, could you tell me kernel versions that you've tested ?
> I want to update "SUPPORTED KERNELS" in the README.

I have tested this on 3.2.0. Eventhough the makedumpfile says the kernel
is not supported, the dumps work fine.

Thanks
Suzuki



From dzickus at redhat.com  Sat Feb 11 18:09:47 2012
From: dzickus at redhat.com (tip-bot for Don Zickus)
Date: Sat, 11 Feb 2012 15:09:47 -0800
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/
 lapic in crash path
Message-ID: <tip-d9bc9be89629445758670220787683e37c93f6c1@git.kernel.org>

Commit-ID:  d9bc9be89629445758670220787683e37c93f6c1
Gitweb:     http://git.kernel.org/tip/d9bc9be89629445758670220787683e37c93f6c1
Author:     Don Zickus <dzickus at redhat.com>
AuthorDate: Thu, 9 Feb 2012 16:53:41 -0500
Committer:  Ingo Molnar <mingo at elte.hu>
CommitDate: Sat, 11 Feb 2012 15:38:53 +0100

x86/kdump: No need to disable ioapic/lapic in crash path

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

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

 CPU0:
 do_IRQ
 -> handle_irq
    -> handle_edge_irq
        -> ack_apic_edge
           -> move_native_irq
               -> mask_IO_APIC_irq
                  -> mask_IO_APIC_irq_desc
                     -> spin_lock_irqsave(&ioapic_lock, flags)
                     ---Receive NMI here after getting spinlock---
                        -> nmi
                           -> do_nmi
                              -> crash_nmi_callback
                              ---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.

Eric brought up a point that because the boot code was
restructured we may not need to disable the io apic any more in
the crash path.  The original concern that led to the
development of disable_IO_APIC, was that the jiffies calibration
on boot up relied on the PIT timer for reference.  Access to the
PIT required 8259 interrupts to be working.  This wouldn't work
if the ioapic needed to be configured.  So on panic path, the
ioapic was reconfigured to use virtual wire mode to allow the 8259 to passthrough.

Those concerns don't hold true now, thanks to the jiffies
calibration code not needing the PIT.  As a result, we can
remove this call and simplify the locking needed in the panic
path.

The same work allowed us to remove the need to disable the local
apic on shutdown too.  This should allow us to jump to the
second a little faster.

I tested kdump on an Ivy Bridge platform, a Pentium4 and an old
athlon that did not have an ioapic.  All three were successful.

I also tested using lkdtm that would use jprobes to panic the
system when entering do_IRQ.  The idea was to see how the system
reacted with an interrupt pending in the second kernel.  My
core2 quad successfully kdump'd 3 times in a row with no issues.

v2: removed the disable lapic code too

Signed-off-by: Don Zickus <dzickus at redhat.com>
Acked-by: Eric W. Biederman <ebiederm at xmission.com>
Cc: kexec-list <kexec at lists.infradead.org>
Cc: Vivek Goyal <vgoyal at redhat.com>
Cc: Linus Torvalds <torvalds at linux-foundation.org>
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: Yinghai Lu <yinghai at kernel.org>
Signed-off-by: Ingo Molnar <mingo at elte.hu>
---
 arch/x86/kernel/crash.c |    8 --------
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 13ad899..571f253 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -54,16 +54,12 @@ static void kdump_nmi_callback(int cpu, struct pt_regs *regs)
 	 */
 	cpu_emergency_vmxoff();
 	cpu_emergency_svm_disable();
-
-	disable_local_APIC();
 }
 
 static void kdump_nmi_shootdown_cpus(void)
 {
 	in_crash_kexec = 1;
 	nmi_shootdown_cpus(kdump_nmi_callback);
-
-	disable_local_APIC();
 }
 
 #else
@@ -95,10 +91,6 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
 	cpu_emergency_vmxoff();
 	cpu_emergency_svm_disable();
 
-	lapic_shutdown();
-#if defined(CONFIG_X86_IO_APIC)
-	disable_IO_APIC();
-#endif
 #ifdef CONFIG_HPET_TIMER
 	hpet_disable();
 #endif


From yinghai at kernel.org  Sat Feb 11 20:04:15 2012
From: yinghai at kernel.org (Yinghai Lu)
Date: Sat, 11 Feb 2012 17:04:15 -0800
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <tip-d9bc9be89629445758670220787683e37c93f6c1@git.kernel.org>
References: <tip-d9bc9be89629445758670220787683e37c93f6c1@git.kernel.org>
Message-ID: <CAE9FiQWRjvu_uNcx_bJXYHeg4D4k6YzHHmSudsq7EyubLi7+nw@mail.gmail.com>

On Sat, Feb 11, 2012 at 3:09 PM, tip-bot for Don Zickus
<dzickus at redhat.com> wrote:
> Commit-ID: ?d9bc9be89629445758670220787683e37c93f6c1
> Gitweb: ? ? http://git.kernel.org/tip/d9bc9be89629445758670220787683e37c93f6c1
> Author: ? ? Don Zickus <dzickus at redhat.com>
> AuthorDate: Thu, 9 Feb 2012 16:53:41 -0500
> Committer: ?Ingo Molnar <mingo at elte.hu>
> CommitDate: Sat, 11 Feb 2012 15:38:53 +0100
>
> x86/kdump: No need to disable ioapic/lapic in crash path
>
> A customer of ours noticed when their machine crashed, kdump did
> not work but hung instead. ?Using their firmware dumping
> solution they grabbed a vmcore and decoded the stacks on the
> cpus. ?What they noticed seemed to be a rare deadlock with the
> ioapic_lock.
>
> ?CPU4:
> ?machine_crash_shutdown
> ?-> machine_ops.crash_shutdown
> ? ?-> native_machine_crash_shutdown
> ? ? ? -> kdump_nmi_shootdown_cpus ------> Send NMI to other CPUs
> ? ? ? -> disable_IO_APIC
> ? ? ? ? ?-> clear_IO_APIC
> ? ? ? ? ? ? -> clear_IO_APIC_pin
> ? ? ? ? ? ? ? ?-> ioapic_read_entry
> ? ? ? ? ? ? ? ? ? -> spin_lock_irqsave(&ioapic_lock, flags)
> ? ? ? ? ? ? ? ? ? ---Infinite loop here---
>
> ?CPU0:
> ?do_IRQ
> ?-> handle_irq
> ? ?-> handle_edge_irq
> ? ? ? ?-> ack_apic_edge
> ? ? ? ? ? -> move_native_irq
> ? ? ? ? ? ? ? -> mask_IO_APIC_irq
> ? ? ? ? ? ? ? ? ?-> mask_IO_APIC_irq_desc
> ? ? ? ? ? ? ? ? ? ? -> spin_lock_irqsave(&ioapic_lock, flags)
> ? ? ? ? ? ? ? ? ? ? ---Receive NMI here after getting spinlock---
> ? ? ? ? ? ? ? ? ? ? ? ?-> nmi
> ? ? ? ? ? ? ? ? ? ? ? ? ? -> do_nmi
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-> crash_nmi_callback
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?---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.
>
> Eric brought up a point that because the boot code was
> restructured we may not need to disable the io apic any more in
> the crash path. ?The original concern that led to the
> development of disable_IO_APIC, was that the jiffies calibration
> on boot up relied on the PIT timer for reference. ?Access to the
> PIT required 8259 interrupts to be working. ?This wouldn't work
> if the ioapic needed to be configured. ?So on panic path, the
> ioapic was reconfigured to use virtual wire mode to allow the 8259 to passthrough.
>
> Those concerns don't hold true now, thanks to the jiffies
> calibration code not needing the PIT. ?As a result, we can
> remove this call and simplify the locking needed in the panic
> path.
>
> The same work allowed us to remove the need to disable the local
> apic on shutdown too. ?This should allow us to jump to the
> second a little faster.
>
> I tested kdump on an Ivy Bridge platform, a Pentium4 and an old
> athlon that did not have an ioapic. ?All three were successful.
>
> I also tested using lkdtm that would use jprobes to panic the
> system when entering do_IRQ. ?The idea was to see how the system
> reacted with an interrupt pending in the second kernel. ?My
> core2 quad successfully kdump'd 3 times in a row with no issues.
>
> v2: removed the disable lapic code too

with this commit, kdump is not working anymore on my setups with
Nehalem, Westmere, sandbridge.
these setup all have VT-d enabled.


After reverting this commit, kdump is working again.

So assume you need to drop this patch.

Thanks

Yinghai Lu


From ebiederm at xmission.com  Sat Feb 11 22:13:15 2012
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Sat, 11 Feb 2012 19:13:15 -0800
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <CAE9FiQWRjvu_uNcx_bJXYHeg4D4k6YzHHmSudsq7EyubLi7+nw@mail.gmail.com>
 (Yinghai Lu's message of "Sat, 11 Feb 2012 17:04:15 -0800")
References: <tip-d9bc9be89629445758670220787683e37c93f6c1@git.kernel.org>
 <CAE9FiQWRjvu_uNcx_bJXYHeg4D4k6YzHHmSudsq7EyubLi7+nw@mail.gmail.com>
Message-ID: <m1ipjc3fsk.fsf@fess.ebiederm.org>

Yinghai Lu <yinghai at kernel.org> writes:

> On Sat, Feb 11, 2012 at 3:09 PM, tip-bot for Don Zickus
> <dzickus at redhat.com> wrote:
>> Commit-ID: ?d9bc9be89629445758670220787683e37c93f6c1
>> Gitweb: ? ? http://git.kernel.org/tip/d9bc9be89629445758670220787683e37c93f6c1
>> Author: ? ? Don Zickus <dzickus at redhat.com>
>> AuthorDate: Thu, 9 Feb 2012 16:53:41 -0500
>> Committer: ?Ingo Molnar <mingo at elte.hu>
>> CommitDate: Sat, 11 Feb 2012 15:38:53 +0100
>>
>> x86/kdump: No need to disable ioapic/lapic in crash path
>>
>> A customer of ours noticed when their machine crashed, kdump did
>> not work but hung instead. ?Using their firmware dumping
>> solution they grabbed a vmcore and decoded the stacks on the
>> cpus. ?What they noticed seemed to be a rare deadlock with the
>> ioapic_lock.
>>
>> ?CPU4:
>> ?machine_crash_shutdown
>> ?-> machine_ops.crash_shutdown
>> ? ?-> native_machine_crash_shutdown
>> ? ? ? -> kdump_nmi_shootdown_cpus ------> Send NMI to other CPUs
>> ? ? ? -> disable_IO_APIC
>> ? ? ? ? ?-> clear_IO_APIC
>> ? ? ? ? ? ? -> clear_IO_APIC_pin
>> ? ? ? ? ? ? ? ?-> ioapic_read_entry
>> ? ? ? ? ? ? ? ? ? -> spin_lock_irqsave(&ioapic_lock, flags)
>> ? ? ? ? ? ? ? ? ? ---Infinite loop here---
>>
>> ?CPU0:
>> ?do_IRQ
>> ?-> handle_irq
>> ? ?-> handle_edge_irq
>> ? ? ? ?-> ack_apic_edge
>> ? ? ? ? ? -> move_native_irq
>> ? ? ? ? ? ? ? -> mask_IO_APIC_irq
>> ? ? ? ? ? ? ? ? ?-> mask_IO_APIC_irq_desc
>> ? ? ? ? ? ? ? ? ? ? -> spin_lock_irqsave(&ioapic_lock, flags)
>> ? ? ? ? ? ? ? ? ? ? ---Receive NMI here after getting spinlock---
>> ? ? ? ? ? ? ? ? ? ? ? ?-> nmi
>> ? ? ? ? ? ? ? ? ? ? ? ? ? -> do_nmi
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-> crash_nmi_callback
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?---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.
>>
>> Eric brought up a point that because the boot code was
>> restructured we may not need to disable the io apic any more in
>> the crash path. ?The original concern that led to the
>> development of disable_IO_APIC, was that the jiffies calibration
>> on boot up relied on the PIT timer for reference. ?Access to the
>> PIT required 8259 interrupts to be working. ?This wouldn't work
>> if the ioapic needed to be configured. ?So on panic path, the
>> ioapic was reconfigured to use virtual wire mode to allow the 8259 to passthrough.
>>
>> Those concerns don't hold true now, thanks to the jiffies
>> calibration code not needing the PIT. ?As a result, we can
>> remove this call and simplify the locking needed in the panic
>> path.
>>
>> The same work allowed us to remove the need to disable the local
>> apic on shutdown too. ?This should allow us to jump to the
>> second a little faster.
>>
>> I tested kdump on an Ivy Bridge platform, a Pentium4 and an old
>> athlon that did not have an ioapic. ?All three were successful.
>>
>> I also tested using lkdtm that would use jprobes to panic the
>> system when entering do_IRQ. ?The idea was to see how the system
>> reacted with an interrupt pending in the second kernel. ?My
>> core2 quad successfully kdump'd 3 times in a row with no issues.
>>
>> v2: removed the disable lapic code too
>
> with this commit, kdump is not working anymore on my setups with
> Nehalem, Westmere, sandbridge.
> these setup all have VT-d enabled.
>
>
> After reverting this commit, kdump is working again.
>
> So assume you need to drop this patch.

It sounds like there is a bug in ioapic initialization in the context of
VT-d.  Where do you fail?

It would be much better to debug this than to blindly revert this patch,
as this change has the potential to significantly increase the
reliability of the kdump path.

Eric


From yinghai at kernel.org  Sat Feb 11 23:17:43 2012
From: yinghai at kernel.org (Yinghai Lu)
Date: Sat, 11 Feb 2012 20:17:43 -0800
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <m1ipjc3fsk.fsf@fess.ebiederm.org>
References: <tip-d9bc9be89629445758670220787683e37c93f6c1@git.kernel.org>
 <CAE9FiQWRjvu_uNcx_bJXYHeg4D4k6YzHHmSudsq7EyubLi7+nw@mail.gmail.com>
 <m1ipjc3fsk.fsf@fess.ebiederm.org>
Message-ID: <CAE9FiQVLnyRB+pAqi22C5mCbHOOVKxsBhQKaB6P0p9f2LBL8bA@mail.gmail.com>

On Sat, Feb 11, 2012 at 7:13 PM, Eric W. Biederman
<ebiederm at xmission.com> wrote:
> Yinghai Lu <yinghai at kernel.org> writes:
>> After reverting this commit, kdump is working again.
>>
>> So assume you need to drop this patch.
>
> It sounds like there is a bug in ioapic initialization in the context of
> VT-d. ?Where do you fail?
>
before get debug print out from second kernel, the system get reset.

Yinghai


From mingo at elte.hu  Sun Feb 12 06:12:50 2012
From: mingo at elte.hu (Ingo Molnar)
Date: Sun, 12 Feb 2012 12:12:50 +0100
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <CAE9FiQWRjvu_uNcx_bJXYHeg4D4k6YzHHmSudsq7EyubLi7+nw@mail.gmail.com>
References: <tip-d9bc9be89629445758670220787683e37c93f6c1@git.kernel.org>
 <CAE9FiQWRjvu_uNcx_bJXYHeg4D4k6YzHHmSudsq7EyubLi7+nw@mail.gmail.com>
Message-ID: <20120212111250.GA21493@elte.hu>


* Yinghai Lu <yinghai at kernel.org> wrote:

> On Sat, Feb 11, 2012 at 3:09 PM, tip-bot for Don Zickus
> <dzickus at redhat.com> wrote:
> > Commit-ID: ?d9bc9be89629445758670220787683e37c93f6c1
> > Gitweb: ? ? http://git.kernel.org/tip/d9bc9be89629445758670220787683e37c93f6c1
> > Author: ? ? Don Zickus <dzickus at redhat.com>
> > AuthorDate: Thu, 9 Feb 2012 16:53:41 -0500
> > Committer: ?Ingo Molnar <mingo at elte.hu>
> > CommitDate: Sat, 11 Feb 2012 15:38:53 +0100
> >
> > x86/kdump: No need to disable ioapic/lapic in crash path
> >
> > A customer of ours noticed when their machine crashed, kdump did
> > not work but hung instead. ?Using their firmware dumping
> > solution they grabbed a vmcore and decoded the stacks on the
> > cpus. ?What they noticed seemed to be a rare deadlock with the
> > ioapic_lock.
> >
> > ?CPU4:
> > ?machine_crash_shutdown
> > ?-> machine_ops.crash_shutdown
> > ? ?-> native_machine_crash_shutdown
> > ? ? ? -> kdump_nmi_shootdown_cpus ------> Send NMI to other CPUs
> > ? ? ? -> disable_IO_APIC
> > ? ? ? ? ?-> clear_IO_APIC
> > ? ? ? ? ? ? -> clear_IO_APIC_pin
> > ? ? ? ? ? ? ? ?-> ioapic_read_entry
> > ? ? ? ? ? ? ? ? ? -> spin_lock_irqsave(&ioapic_lock, flags)
> > ? ? ? ? ? ? ? ? ? ---Infinite loop here---
> >
> > ?CPU0:
> > ?do_IRQ
> > ?-> handle_irq
> > ? ?-> handle_edge_irq
> > ? ? ? ?-> ack_apic_edge
> > ? ? ? ? ? -> move_native_irq
> > ? ? ? ? ? ? ? -> mask_IO_APIC_irq
> > ? ? ? ? ? ? ? ? ?-> mask_IO_APIC_irq_desc
> > ? ? ? ? ? ? ? ? ? ? -> spin_lock_irqsave(&ioapic_lock, flags)
> > ? ? ? ? ? ? ? ? ? ? ---Receive NMI here after getting spinlock---
> > ? ? ? ? ? ? ? ? ? ? ? ?-> nmi
> > ? ? ? ? ? ? ? ? ? ? ? ? ? -> do_nmi
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-> crash_nmi_callback
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?---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.
> >
> > Eric brought up a point that because the boot code was
> > restructured we may not need to disable the io apic any more in
> > the crash path. ?The original concern that led to the
> > development of disable_IO_APIC, was that the jiffies calibration
> > on boot up relied on the PIT timer for reference. ?Access to the
> > PIT required 8259 interrupts to be working. ?This wouldn't work
> > if the ioapic needed to be configured. ?So on panic path, the
> > ioapic was reconfigured to use virtual wire mode to allow the 8259 to passthrough.
> >
> > Those concerns don't hold true now, thanks to the jiffies
> > calibration code not needing the PIT. ?As a result, we can
> > remove this call and simplify the locking needed in the panic
> > path.
> >
> > The same work allowed us to remove the need to disable the local
> > apic on shutdown too. ?This should allow us to jump to the
> > second a little faster.
> >
> > I tested kdump on an Ivy Bridge platform, a Pentium4 and an old
> > athlon that did not have an ioapic. ?All three were successful.
> >
> > I also tested using lkdtm that would use jprobes to panic the
> > system when entering do_IRQ. ?The idea was to see how the system
> > reacted with an interrupt pending in the second kernel. ?My
> > core2 quad successfully kdump'd 3 times in a row with no issues.
> >
> > v2: removed the disable lapic code too
> 
> with this commit, kdump is not working anymore on my setups with
> Nehalem, Westmere, sandbridge.
> these setup all have VT-d enabled.
> 
> After reverting this commit, kdump is working again.
> 
> So assume you need to drop this patch.

Dropped the patch, thanks for reporting this.

Don, Eric?

	Ingo


From kumagai-atsushi at mxc.nes.nec.co.jp  Sun Feb 12 21:01:11 2012
From: kumagai-atsushi at mxc.nes.nec.co.jp (Atsushi Kumagai)
Date: Mon, 13 Feb 2012 11:01:11 +0900
Subject: [PATCH v1 3/3] [makedumpfile] Add support for PPC32
In-Reply-To: <4F350143.1090508@in.ibm.com>
References: <20120118100510.29422.93587.stgit@suzukikp.in.ibm.com>
 <20120118100949.29422.17463.stgit@suzukikp.in.ibm.com>
 <20120210184543.fbb08606.kumagai-atsushi@mxc.nes.nec.co.jp>
 <4F350143.1090508@in.ibm.com>
Message-ID: <20120213110111.53d580b3.kumagai-atsushi@mxc.nes.nec.co.jp>

Hi, Suzuki

On Fri, 10 Feb 2012 17:06:35 +0530
"Suzuki K. Poulose" <suzuki at in.ibm.com> wrote:

> > The other parts looks good.
> > I will merge this patch to makedumpfile-1.4.3.
> >
> > By the way, could you tell me kernel versions that you've tested ?
> > I want to update "SUPPORTED KERNELS" in the README.
> 
> I have tested this on 3.2.0. Eventhough the makedumpfile says the kernel
> is not supported, the dumps work fine.

Thank you for your reply. It's helpful information.

Thanks
Atsushi Kumagai


From ebiederm at xmission.com  Mon Feb 13 07:52:10 2012
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Mon, 13 Feb 2012 04:52:10 -0800
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <CAE9FiQVLnyRB+pAqi22C5mCbHOOVKxsBhQKaB6P0p9f2LBL8bA@mail.gmail.com>
 (Yinghai Lu's message of "Sat, 11 Feb 2012 20:17:43 -0800")
References: <tip-d9bc9be89629445758670220787683e37c93f6c1@git.kernel.org>
 <CAE9FiQWRjvu_uNcx_bJXYHeg4D4k6YzHHmSudsq7EyubLi7+nw@mail.gmail.com>
 <m1ipjc3fsk.fsf@fess.ebiederm.org>
 <CAE9FiQVLnyRB+pAqi22C5mCbHOOVKxsBhQKaB6P0p9f2LBL8bA@mail.gmail.com>
Message-ID: <m1zkcmyjyd.fsf@fess.ebiederm.org>

Yinghai Lu <yinghai at kernel.org> writes:

> On Sat, Feb 11, 2012 at 7:13 PM, Eric W. Biederman
> <ebiederm at xmission.com> wrote:
>> Yinghai Lu <yinghai at kernel.org> writes:
>>> After reverting this commit, kdump is working again.
>>>
>>> So assume you need to drop this patch.
>>
>> It sounds like there is a bug in ioapic initialization in the context of
>> VT-d. ?Where do you fail?
>>
> before get debug print out from second kernel, the system get reset.

Ouch.

Don can you work with with Yinghai to figure out what is different
between your test configuration and his?

YH did you have early printk enabled?

YH Did I understand you properly that things work if you don't enable
VT-d?   By VT-d are you referring to interrupt remapping?

For anyone watching.  The premise of this patch was that we can boot
the kernel without resorting to legacy tricks that require us to
put the interrupt controllers in PIT mode.

Apparently there is some weird corner case that YH can reproduce that
Don did not have in his test set that YH does that causes things to
fail.

I really don't see any likely candidates when looking at the code.  The
most I can see is some code that we don't run when interrupt remapping
is enabled in disable_IO_APIC.

So I suspect we have a bug in our apic initialization somewhere, but
apic initialization should happen after printk are enabled.  Or at least
after early printks so the reset YH is reporting doesn't make much sense.

Eric


From dzickus at redhat.com  Mon Feb 13 10:28:08 2012
From: dzickus at redhat.com (Don Zickus)
Date: Mon, 13 Feb 2012 10:28:08 -0500
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <CAE9FiQWRjvu_uNcx_bJXYHeg4D4k6YzHHmSudsq7EyubLi7+nw@mail.gmail.com>
References: <tip-d9bc9be89629445758670220787683e37c93f6c1@git.kernel.org>
 <CAE9FiQWRjvu_uNcx_bJXYHeg4D4k6YzHHmSudsq7EyubLi7+nw@mail.gmail.com>
Message-ID: <20120213152808.GD9751@redhat.com>

On Sat, Feb 11, 2012 at 05:04:15PM -0800, Yinghai Lu wrote:
> >
> > v2: removed the disable lapic code too
> 
> with this commit, kdump is not working anymore on my setups with
> Nehalem, Westmere, sandbridge.
> these setup all have VT-d enabled.

Hi Yinghai,

Thanks for the report.  Can you attach the .config you were using and what
vendor you were using for Nehalem, Westmere and Sandybridge.  I'll try to
reproduce it in my lab.

Cheers,
Don


From yinghai at kernel.org  Mon Feb 13 11:51:00 2012
From: yinghai at kernel.org (Yinghai Lu)
Date: Mon, 13 Feb 2012 08:51:00 -0800
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <m1zkcmyjyd.fsf@fess.ebiederm.org>
References: <tip-d9bc9be89629445758670220787683e37c93f6c1@git.kernel.org>
 <CAE9FiQWRjvu_uNcx_bJXYHeg4D4k6YzHHmSudsq7EyubLi7+nw@mail.gmail.com>
 <m1ipjc3fsk.fsf@fess.ebiederm.org>
 <CAE9FiQVLnyRB+pAqi22C5mCbHOOVKxsBhQKaB6P0p9f2LBL8bA@mail.gmail.com>
 <m1zkcmyjyd.fsf@fess.ebiederm.org>
Message-ID: <CAE9FiQVj12UCGbOe4wZfx-L8tdab-1si-RA=vBnNeZ7cUNqyyg@mail.gmail.com>

On Mon, Feb 13, 2012 at 4:52 AM, Eric W. Biederman
<ebiederm at xmission.com> wrote:
> Yinghai Lu <yinghai at kernel.org> writes:
>
>> On Sat, Feb 11, 2012 at 7:13 PM, Eric W. Biederman
>> <ebiederm at xmission.com> wrote:
>>> Yinghai Lu <yinghai at kernel.org> writes:
>>>> After reverting this commit, kdump is working again.
>>>>
>>>> So assume you need to drop this patch.
>>>
>>> It sounds like there is a bug in ioapic initialization in the context of
>>> VT-d. ?Where do you fail?
>>>
>> before get debug print out from second kernel, the system get reset.
>
> Ouch.
>
> Don can you work with with Yinghai to figure out what is different
> between your test configuration and his?
>
> YH did you have early printk enabled?

yes.

I always have "console=uart8250,io,0x3f8,115200n8" appended.

also i have local patches that print info from
arch/x86/boot/compressed/misc.c::decompress_kernel()
and
arch/x86/kernel/head64.c::x86_64_start_kernel()

>
> YH Did I understand you properly that things work if you don't enable
> VT-d?

that is default setting for BIOS and OS.

will check if disable that will help.

> By VT-d are you referring to interrupt remapping?

yes, include interrupt rempapping and dma remapping.

>
> For anyone watching. ?The premise of this patch was that we can boot
> the kernel without resorting to legacy tricks that require us to
> put the interrupt controllers in PIT mode.
>
> Apparently there is some weird corner case that YH can reproduce that
> Don did not have in his test set that YH does that causes things to
> fail.
>
> I really don't see any likely candidates when looking at the code. ?The
> most I can see is some code that we don't run when interrupt remapping
> is enabled in disable_IO_APIC.
>
> So I suspect we have a bug in our apic initialization somewhere, but
> apic initialization should happen after printk are enabled. ?Or at least
> after early printks so the reset YH is reporting doesn't make much sense.

will try Don's first version patch that only removing disable_IO_APIC.

Yinghai


From yinghai at kernel.org  Mon Feb 13 13:16:00 2012
From: yinghai at kernel.org (Yinghai Lu)
Date: Mon, 13 Feb 2012 10:16:00 -0800
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <CAE9FiQVj12UCGbOe4wZfx-L8tdab-1si-RA=vBnNeZ7cUNqyyg@mail.gmail.com>
References: <tip-d9bc9be89629445758670220787683e37c93f6c1@git.kernel.org>
 <CAE9FiQWRjvu_uNcx_bJXYHeg4D4k6YzHHmSudsq7EyubLi7+nw@mail.gmail.com>
 <m1ipjc3fsk.fsf@fess.ebiederm.org>
 <CAE9FiQVLnyRB+pAqi22C5mCbHOOVKxsBhQKaB6P0p9f2LBL8bA@mail.gmail.com>
 <m1zkcmyjyd.fsf@fess.ebiederm.org>
 <CAE9FiQVj12UCGbOe4wZfx-L8tdab-1si-RA=vBnNeZ7cUNqyyg@mail.gmail.com>
Message-ID: <CAE9FiQVPnO8-tuPoio0Wxv=8rjdm2tJbBk3+3ystueyYtZn9BA@mail.gmail.com>

On Mon, Feb 13, 2012 at 8:51 AM, Yinghai Lu <yinghai at kernel.org> wrote:
>> So I suspect we have a bug in our apic initialization somewhere, but
>> apic initialization should happen after printk are enabled. ?Or at least
>> after early printks so the reset YH is reporting doesn't make much sense.
>
> will try Don's first version patch that only removing disable_IO_APIC.

first version patch (only removing disable_IO_APIC) is working.

Thanks

Yinghai


From dzickus at redhat.com  Mon Feb 13 17:12:58 2012
From: dzickus at redhat.com (Don Zickus)
Date: Mon, 13 Feb 2012 17:12:58 -0500
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <CAE9FiQXX7BXKuVHZ9NRCEmeTnPj4zVJL5gf5eSp6b+4e3jN3EA@mail.gmail.com>
References: <tip-d9bc9be89629445758670220787683e37c93f6c1@git.kernel.org>
 <CAE9FiQWRjvu_uNcx_bJXYHeg4D4k6YzHHmSudsq7EyubLi7+nw@mail.gmail.com>
 <20120213152808.GD9751@redhat.com>
 <CAE9FiQXX7BXKuVHZ9NRCEmeTnPj4zVJL5gf5eSp6b+4e3jN3EA@mail.gmail.com>
Message-ID: <20120213221258.GP9751@redhat.com>

On Mon, Feb 13, 2012 at 08:52:19AM -0800, Yinghai Lu wrote:
> On Mon, Feb 13, 2012 at 7:28 AM, Don Zickus <dzickus at redhat.com> wrote:
> > On Sat, Feb 11, 2012 at 05:04:15PM -0800, Yinghai Lu wrote:
> >> >
> >> > v2: removed the disable lapic code too
> >>
> >> with this commit, kdump is not working anymore on my setups with
> >> Nehalem, Westmere, sandbridge.
> >> these setup all have VT-d enabled.
> >
> > Hi Yinghai,
> >
> > Thanks for the report. ?Can you attach the .config you were using and what
> > vendor you were using for Nehalem, Westmere and Sandybridge. ?I'll try to
> > reproduce it in my lab.
> 
> Sure, please check attached one

Looks like I can reproduce the hang with my original patch and things work
when we stick the disable_local_APIC() back in there.  I'll keep poking.

Cheers,
Don


From dzickus at redhat.com  Mon Feb 13 17:51:15 2012
From: dzickus at redhat.com (Don Zickus)
Date: Mon, 13 Feb 2012 17:51:15 -0500
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <20120213221258.GP9751@redhat.com>
References: <tip-d9bc9be89629445758670220787683e37c93f6c1@git.kernel.org>
 <CAE9FiQWRjvu_uNcx_bJXYHeg4D4k6YzHHmSudsq7EyubLi7+nw@mail.gmail.com>
 <20120213152808.GD9751@redhat.com>
 <CAE9FiQXX7BXKuVHZ9NRCEmeTnPj4zVJL5gf5eSp6b+4e3jN3EA@mail.gmail.com>
 <20120213221258.GP9751@redhat.com>
Message-ID: <20120213225115.GT9751@redhat.com>

On Mon, Feb 13, 2012 at 05:12:58PM -0500, Don Zickus wrote:
> On Mon, Feb 13, 2012 at 08:52:19AM -0800, Yinghai Lu wrote:
> > On Mon, Feb 13, 2012 at 7:28 AM, Don Zickus <dzickus at redhat.com> wrote:
> > > On Sat, Feb 11, 2012 at 05:04:15PM -0800, Yinghai Lu wrote:
> > >> >
> > >> > v2: removed the disable lapic code too
> > >>
> > >> with this commit, kdump is not working anymore on my setups with
> > >> Nehalem, Westmere, sandbridge.
> > >> these setup all have VT-d enabled.
> > >
> > > Hi Yinghai,
> > >
> > > Thanks for the report. ?Can you attach the .config you were using and what
> > > vendor you were using for Nehalem, Westmere and Sandybridge. ?I'll try to
> > > reproduce it in my lab.
> > 
> > Sure, please check attached one
> 
> Looks like I can reproduce the hang with my original patch and things work
> when we stick the disable_local_APIC() back in there.  I'll keep poking.

Hmm, my config worked fine in both cases, hence why I didn't catch it (its
based on a bloated Fedora config).  I'll look at the differences to see if
something pops out.

Cheers,
Don


From yinghai at kernel.org  Mon Feb 13 11:52:19 2012
From: yinghai at kernel.org (Yinghai Lu)
Date: Mon, 13 Feb 2012 08:52:19 -0800
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <20120213152808.GD9751@redhat.com>
References: <tip-d9bc9be89629445758670220787683e37c93f6c1@git.kernel.org>
 <CAE9FiQWRjvu_uNcx_bJXYHeg4D4k6YzHHmSudsq7EyubLi7+nw@mail.gmail.com>
 <20120213152808.GD9751@redhat.com>
Message-ID: <CAE9FiQXX7BXKuVHZ9NRCEmeTnPj4zVJL5gf5eSp6b+4e3jN3EA@mail.gmail.com>

On Mon, Feb 13, 2012 at 7:28 AM, Don Zickus <dzickus at redhat.com> wrote:
> On Sat, Feb 11, 2012 at 05:04:15PM -0800, Yinghai Lu wrote:
>> >
>> > v2: removed the disable lapic code too
>>
>> with this commit, kdump is not working anymore on my setups with
>> Nehalem, Westmere, sandbridge.
>> these setup all have VT-d enabled.
>
> Hi Yinghai,
>
> Thanks for the report. ?Can you attach the .config you were using and what
> vendor you were using for Nehalem, Westmere and Sandybridge. ?I'll try to
> reproduce it in my lab.

Sure, please check attached one

Yinghai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.2012_02_11
Type: application/octet-stream
Size: 91818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/kexec/attachments/20120213/274487be/attachment-0001.obj>

From webmaster at cc.psd-prahova.ro  Tue Feb 14 09:30:30 2012
From: webmaster at cc.psd-prahova.ro (webmaster at cc.psd-prahova.ro)
Date: Tue, 14 Feb 2012 16:30:30 +0200 (EET)
Subject: Anunt Important
Message-ID: <20120214143833.D6BA4AD688D@cc.psd-prahova.ro>


http://www.max-media.ro/administratie/prahova-printre-judetele-care-au-canalizare.-meritul-ii-apartine-lui-mircea-cosma.html


From paulus at samba.org  Tue Feb 14 23:16:09 2012
From: paulus at samba.org (Paul Mackerras)
Date: Wed, 15 Feb 2012 15:16:09 +1100
Subject: [RFC PATCH v6 00/10] fadump: Firmware-assisted dump support for
 Powerpc.
In-Reply-To: <20111210064301.10195.3344.stgit@mars.in.ibm.com>
References: <20111210064301.10195.3344.stgit@mars.in.ibm.com>
Message-ID: <20120215041608.GA15258@bloggs.ozlabs.ibm.com>

On Sat, Dec 10, 2011 at 12:19:59PM +0530, Mahesh J Salgaonkar wrote:

> The most of the code implementation has been adapted from phyp assisted dump
> implementation written by Linas Vepstas and Manish Ahuja.

When you repost the series, please be explicit about what the
relationship between the new fadump facility and the old phyp-dump
is, both in the documentation you're adding and in the patch
descriptions.

I gather that fadump uses the same firmware interfaces as phyp-dump,
and can be characterised as a rewrite of phyp-dump.  It would be good
if you would explicitly mention:

- What advantages fadump has over phyp-dump
- Whether there are any capabilities that phyp-dump does that fadump
  doesn't
- What is different between fadump and phyp-dump in the interface to
  usermode code
- Any user-visible differences between how fadump operates compared to
  phyp-dump.  For example, will users see a difference in how much
  memory is available to the kernel?

Paul.



From dzickus at redhat.com  Wed Feb 15 21:53:31 2012
From: dzickus at redhat.com (Don Zickus)
Date: Wed, 15 Feb 2012 21:53:31 -0500
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <CAE9FiQXX7BXKuVHZ9NRCEmeTnPj4zVJL5gf5eSp6b+4e3jN3EA@mail.gmail.com>
References: <tip-d9bc9be89629445758670220787683e37c93f6c1@git.kernel.org>
 <CAE9FiQWRjvu_uNcx_bJXYHeg4D4k6YzHHmSudsq7EyubLi7+nw@mail.gmail.com>
 <20120213152808.GD9751@redhat.com>
 <CAE9FiQXX7BXKuVHZ9NRCEmeTnPj4zVJL5gf5eSp6b+4e3jN3EA@mail.gmail.com>
Message-ID: <20120216025331.GT9751@redhat.com>

On Mon, Feb 13, 2012 at 08:52:19AM -0800, Yinghai Lu wrote:
> On Mon, Feb 13, 2012 at 7:28 AM, Don Zickus <dzickus at redhat.com> wrote:
> > On Sat, Feb 11, 2012 at 05:04:15PM -0800, Yinghai Lu wrote:
> >> >
> >> > v2: removed the disable lapic code too
> >>
> >> with this commit, kdump is not working anymore on my setups with
> >> Nehalem, Westmere, sandbridge.
> >> these setup all have VT-d enabled.
> >
> > Hi Yinghai,
> >
> > Thanks for the report. ?Can you attach the .config you were using and what
> > vendor you were using for Nehalem, Westmere and Sandybridge. ?I'll try to
> > reproduce it in my lab.
> 
> Sure, please check attached one

For some reason using gzip instead of xz makes things work for me with
your config.

CONFIG_KERNEL_GZIP=y
CONFIG_KERNEL_XZ=n

Do you see the same thing?

Cheers,
Don


From suzuki at in.ibm.com  Wed Feb 15 22:35:17 2012
From: suzuki at in.ibm.com (Suzuki K. Poulose)
Date: Thu, 16 Feb 2012 09:05:17 +0530
Subject: [PATCH v1 0/4][makedumpfile] vmalloc translation support for PPC32
Message-ID: <20120216033411.7972.77705.stgit@suzukikp>

The series introduces an infrastructure to define platform specific
bits for page translation for PPC and PPC44x support for vmalloc
translation.

This is similar to what we have implemented for Crash-utility.

The patches are based makedumpfile-1.4.2 + PPC32 support patches
which is queued in for 1.4.3.

---

Suzuki K. Poulose (4):
      [makedumpfile][ppc] PPC44x page translation definitions
      [makedumpfile][ppc] Define platform descriptors for page translation
      [makedumpfile][ppc] Generic vmalloc translation support
      [makedumpfile] Add read_string routine


 arch/ppc.c     |  108 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
 makedumpfile.c |   14 +++++++
 makedumpfile.h |   21 +++++++++++
 3 files changed, 139 insertions(+), 4 deletions(-)

-- 
Suzuki Poulose



From suzuki at in.ibm.com  Wed Feb 15 22:35:40 2012
From: suzuki at in.ibm.com (Suzuki K. Poulose)
Date: Thu, 16 Feb 2012 09:05:40 +0530
Subject: [PATCH v1 1/4] [makedumpfile] Add read_string routine
In-Reply-To: <20120216033411.7972.77705.stgit@suzukikp>
References: <20120216033411.7972.77705.stgit@suzukikp>
Message-ID: <20120216033535.7972.21257.stgit@suzukikp>

This patch adds a read_string() wrapper around readmem().

int read_string(int type_addr, unsigned long long addr, char *bufptr, size_t len);

The functionality is similar to that of readmem(), except that we stop reading
when we find an end-of-string marker than reading 'len' bytes.

This will be useful for reading the name of the 'powerpc' platform which is
needed for dynamic page address definition bits.


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

 makedumpfile.c |   12 ++++++++++++
 makedumpfile.h |    1 +
 2 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/makedumpfile.c b/makedumpfile.c
index 901b85c..e978e1c 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -373,6 +373,18 @@ error:
 	return FALSE;
 }
 
+int
+read_string(int type_addr, unsigned long long addr, char *buf, size_t len)
+{
+	int i;
+
+	memset(buf, 0, len);
+	for (i = 0; i < len; i ++)
+		if (!readmem(VADDR, addr + i, &buf[i], 1))
+			break;
+	return i;
+}
+
 int32_t
 get_kernel_version(char *release)
 {
diff --git a/makedumpfile.h b/makedumpfile.h
index e43ea84..9dc254e 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -1243,6 +1243,7 @@ extern struct srcfile_table	srcfile_table;
 
 
 int readmem(int type_addr, unsigned long long addr, void *bufptr, size_t size);
+int read_string(int type_addr, unsigned long long addr, char *bufptr, size_t len);
 int get_str_osrelease_from_vmlinux(void);
 int read_vmcoreinfo_xen(void);
 int exclude_xen_user_domain(void);



From suzuki at in.ibm.com  Wed Feb 15 22:36:18 2012
From: suzuki at in.ibm.com (Suzuki K. Poulose)
Date: Thu, 16 Feb 2012 09:06:18 +0530
Subject: [PATCH v1 2/4] [makedumpfile][ppc] Generic vmalloc translation support
In-Reply-To: <20120216033411.7972.77705.stgit@suzukikp>
References: <20120216033411.7972.77705.stgit@suzukikp>
Message-ID: <20120216033601.7972.27961.stgit@suzukikp>

This patch adds the generic vmalloc address translation support for PPC32.

There are different types of platforms under PPC32 and the vmalloc translation
requires the knowledge about the page translation bits for each of them. This patch
introduces a generic translation routine with some default values which may work
well for most of the platforms. Later patches in this series would add an
infrastructure to identify the platforms and dynamically change the translation
based on the platform definition.

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

 arch/ppc.c     |   40 ++++++++++++++++++++++++++++++++++++----
 makedumpfile.h |    6 ++++++
 2 files changed, 42 insertions(+), 4 deletions(-)

diff --git a/arch/ppc.c b/arch/ppc.c
index 2bc8d5f..2ca0dc5 100644
--- a/arch/ppc.c
+++ b/arch/ppc.c
@@ -77,7 +77,9 @@ vaddr_to_paddr_ppc(unsigned long vaddr)
 {
 	unsigned long *pgd, *pmd;
 	unsigned long long pte;
+	unsigned long pte_32;
 	unsigned long long paddr;
+	int res = 0;
 
 	paddr = vaddr_to_paddr_general(vaddr);
 	if (paddr != NOT_PADDR)
@@ -91,10 +93,40 @@ vaddr_to_paddr_ppc(unsigned long vaddr)
 	if (!is_vmalloc_addr_ppc(vaddr))
 		return (vaddr - info->kernel_start);
 
-	/*
-	 * TODO: Support vmalloc translation.
-	 */
-	ERRMSG("This makedumpfile does not support vmalloc translation.\n");
+	if ((SYMBOL(swapper_pg_dir) == NOT_FOUND_SYMBOL) &&
+		!readmem(VADDR, SYMBOL(swapper_pg_dir), &pgd, sizeof(pgd))) {
+		ERRMSG("Can't get the PGD for vmalloc translation. \n");
+		return NOT_PADDR;
+	}
+
+	pgd += vaddr >> PGDIR_SHIFT;
+	DEBUG_MSG("vaddr: 0x%lx , PGD = 0x%lx\n", vaddr, (unsigned long)pgd);
+	if (!readmem(VADDR, (unsigned long)pgd, &pmd, sizeof(pmd))) {
+		ERRMSG("Can't get the PMD for address 0x%lx\n.", vaddr);
+		return NOT_PADDR;
+	}
+
+	pmd += (PAGEBASE(vaddr) & (PTRS_PER_PTE - 1));
+	DEBUG_MSG("vaddr: 0x%lx , PMD = 0x%lx\n", vaddr, (unsigned long)pmd);
+
+	if (PTE_SIZE == sizeof(unsigned long long))
+		res = readmem(VADDR, (unsigned long)pmd, &pte, sizeof(pte));
+	else {
+		res = readmem(VADDR, (unsigned long)pmd, &pte_32, sizeof(pte_32));
+		pte = pte_32;
+	}
+
+	if (!res) {
+		ERRMSG("Can't get PTE for address 0x%lx\n", vaddr);
+		return NOT_PADDR;
+	}
+
+	DEBUG_MSG("vaddr: 0x%lx , PTE = 0x%llx\n", vaddr, (unsigned long long)pte);
+	if (pte & _PAGE_PRESENT) {
+		paddr = PAGEBASE(pte) | PAGEOFFSET(vaddr);
+		return paddr;
+	}
+
 	return NOT_PADDR;
 }
 
diff --git a/makedumpfile.h b/makedumpfile.h
index 9dc254e..f7603d7 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -539,6 +539,12 @@ do { \
 #define _SECTION_SIZE_BITS	(24)
 #define _MAX_PHYSMEM_BITS	(44)
 
+#define PGDIR_SHIFT		(22)
+#define PTRS_PER_PTE		(1024)
+#define PTE_SIZE		(sizeof(unsigned long))
+
+#define _PAGE_PRESENT		(0x1)
+
 #endif
 
 #ifdef __s390x__



From suzuki at in.ibm.com  Wed Feb 15 22:36:47 2012
From: suzuki at in.ibm.com (Suzuki K. Poulose)
Date: Thu, 16 Feb 2012 09:06:47 +0530
Subject: [PATCH v1 3/4] [makedumpfile][ppc] Define platform descriptors for
 page translation
In-Reply-To: <20120216033411.7972.77705.stgit@suzukikp>
References: <20120216033411.7972.77705.stgit@suzukikp>
Message-ID: <20120216033632.7972.13594.stgit@suzukikp>

This patch introduces the 'platform' descriptor and an infrastructure
to dynamically probe the platform where the core was generated.

struct platform {
        char *name;		/* name of the platform */
        int pgdir_shift;
        int ptrs_per_pte;
        int pte_size;		/* size of a pte (32/64) */
} base_platform;

The above structure would hold the definitions for page translation for the
platform where the core was generated.

We maintain a list of probe functions, defined for each platform, which can
check if the 'platform string' (obtained by reading the kernel variable
 'powerpc_base_platform') matches one of its variants and update the descriptor
with the specific values. There is a default probe function -at the end of the list - 
which would set the default values for the translation.

get_machdep_info_ppc() will call ppc_probe_base_platform() to scan through
the list of known platform probes to identify the running platform and update
the descriptor accordingly.

This infrastructure will be used for the vmalloc translation for PPC. Since there
are a variety of platforms out there with different translation schemes, this 
infrastructure would help us to support all of them with very little overhead.

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

 arch/ppc.c     |   53 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 makedumpfile.c |    2 ++
 makedumpfile.h |   16 +++++++++++++---
 3 files changed, 68 insertions(+), 3 deletions(-)

diff --git a/arch/ppc.c b/arch/ppc.c
index 2ca0dc5..0ad2cf4 100644
--- a/arch/ppc.c
+++ b/arch/ppc.c
@@ -25,6 +25,56 @@
 #include "../elf_info.h"
 #include "../makedumpfile.h"
 
+#define MAX_PLATFORM_LEN	64	/* length of platform string */
+
+struct platform {
+	char *name;
+	int pgdir_shift;
+	int ptrs_per_pte;
+	int pte_size;
+} base_platform;
+
+typedef int (*probe_func_t)(char *, struct platform *);
+
+static int probe_default_platform(char *, struct platform*);
+
+probe_func_t probe_platforms[] = {
+	probe_default_platform,		/* This should be at the end of the list */
+	NULL
+};
+
+static int probe_default_platform(char *s, struct platform *p)
+{
+	/* Accept as the default platform */
+	p->name = strdup(s);
+	p->pgdir_shift = DEFAULT_PGDIR_SHIFT;
+	p->ptrs_per_pte = DEFAULT_PTRS_PER_PTE;
+	p->pte_size = DEFAULT_PTE_SIZE;
+
+	return TRUE;
+}
+
+static void
+ppc_probe_base_platform(void)
+{
+	unsigned long ptr;
+	char ppc_platform[MAX_PLATFORM_LEN];
+	int i;
+
+
+	if (SYMBOL(powerpc_base_platform) == NOT_FOUND_SYMBOL ||
+	    !readmem(VADDR, SYMBOL(powerpc_base_platform), &ptr, sizeof(ptr)) ||
+	    !read_string(VADDR, ptr, ppc_platform, MAX_PLATFORM_LEN - 1))
+		/* lets fallback to default if we couldn't find the platform */
+		ppc_platform[0] = '\0';
+
+	for(i = 0; probe_platforms[i] != NULL; i++) {
+		probe_func_t probe = probe_platforms[i];
+		if(probe(ppc_platform, &base_platform))
+			break;
+	}
+}
+
 int
 get_machdep_info_ppc(void)
 {
@@ -63,6 +113,9 @@ get_machdep_info_ppc(void)
 	info->vmalloc_start = vmalloc_start;
 	DEBUG_MSG("vmalloc_start: %lx\n", vmalloc_start);
 
+	ppc_probe_base_platform();
+	DEBUG_MSG("Using '%s' platform VM definitions\n", base_platform.name);
+
 	return TRUE;
 }
 
diff --git a/makedumpfile.c b/makedumpfile.c
index e978e1c..2550edc 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -855,6 +855,8 @@ get_symbol_info(void)
 	if (SYMBOL(__per_cpu_offset) != NOT_FOUND_SYMBOL)
 		SYMBOL_ARRAY_LENGTH_INIT(__per_cpu_offset, "__per_cpu_offset");
 
+	SYMBOL_INIT(powerpc_base_platform, "powerpc_base_platform");
+
 	return TRUE;
 }
 
diff --git a/makedumpfile.h b/makedumpfile.h
index f7603d7..3a5152c 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -539,9 +539,13 @@ do { \
 #define _SECTION_SIZE_BITS	(24)
 #define _MAX_PHYSMEM_BITS	(44)
 
-#define PGDIR_SHIFT		(22)
-#define PTRS_PER_PTE		(1024)
-#define PTE_SIZE		(sizeof(unsigned long))
+#define DEFAULT_PGDIR_SHIFT	(22)
+#define DEFAULT_PTRS_PER_PTE	(1024)
+#define DEFAULT_PTE_SIZE	(sizeof(unsigned long))
+
+#define PGDIR_SHIFT		(base_platform.pgdir_shift)
+#define PTRS_PER_PTE		(base_platform.ptrs_per_pte)
+#define PTE_SIZE		(base_platform.pte_size)
 
 #define _PAGE_PRESENT		(0x1)
 
@@ -1018,6 +1022,12 @@ struct symbol_table {
 	unsigned long long	high_memory;
 
 	/*
+	 * PPC platform string pointer. Used for
+	 * vmalloc translation.
+	 */
+	unsigned long long	powerpc_base_platform;
+
+	/*
 	 * for sadump
 	 */
 	unsigned long long	linux_banner;



From suzuki at in.ibm.com  Wed Feb 15 22:37:07 2012
From: suzuki at in.ibm.com (Suzuki K. Poulose)
Date: Thu, 16 Feb 2012 09:07:07 +0530
Subject: [PATCH v1 4/4] [makedumpfile][ppc] PPC44x page translation definitions
In-Reply-To: <20120216033411.7972.77705.stgit@suzukikp>
References: <20120216033411.7972.77705.stgit@suzukikp>
Message-ID: <20120216033656.7972.19596.stgit@suzukikp>

This patch defines the translation bits for PPC44x.


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

 arch/ppc.c     |   15 +++++++++++++++
 makedumpfile.h |    4 ++++
 2 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/arch/ppc.c b/arch/ppc.c
index 0ad2cf4..b63a617 100644
--- a/arch/ppc.c
+++ b/arch/ppc.c
@@ -37,12 +37,27 @@ struct platform {
 typedef int (*probe_func_t)(char *, struct platform *);
 
 static int probe_default_platform(char *, struct platform*);
+static int probe_ppc44x_platform(char *, struct platform*);
 
 probe_func_t probe_platforms[] = {
+	probe_ppc44x_platform,
 	probe_default_platform,		/* This should be at the end of the list */
 	NULL
 };
 
+static int probe_ppc44x_platform(char *s, struct platform *p)
+{
+	if (!strncmp(s, "ppc440", 6) || strcmp(s, "ppc470")) {
+		p->name = strdup(s);
+		p->pgdir_shift = PPC44x_PGDIR_SHIFT;
+		p->ptrs_per_pte = PPC44x_PTRS_PER_PTE;
+		p->pte_size = PPC44x_PTE_SIZE;
+
+		return TRUE;
+	}
+	return FALSE;
+}
+	
 static int probe_default_platform(char *s, struct platform *p)
 {
 	/* Accept as the default platform */
diff --git a/makedumpfile.h b/makedumpfile.h
index 3a5152c..430202b 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -543,6 +543,10 @@ do { \
 #define DEFAULT_PTRS_PER_PTE	(1024)
 #define DEFAULT_PTE_SIZE	(sizeof(unsigned long))
 
+#define PPC44x_PGDIR_SHIFT	(21)
+#define PPC44x_PTRS_PER_PTE	(512)
+#define PPC44x_PTE_SIZE 	(sizeof(unsigned long long))
+
 #define PGDIR_SHIFT		(base_platform.pgdir_shift)
 #define PTRS_PER_PTE		(base_platform.ptrs_per_pte)
 #define PTE_SIZE		(base_platform.pte_size)



From mahesh at linux.vnet.ibm.com  Thu Feb 16 06:14:06 2012
From: mahesh at linux.vnet.ibm.com (Mahesh J Salgaonkar)
Date: Thu, 16 Feb 2012 16:44:06 +0530
Subject: [RFC PATCH v7 00/10] fadump: Firmware-assisted dump support for
 Powerpc.
Message-ID: <20120216111050.4733.38034.stgit@mars>

Hi All,

Please find the version 7 of the patchset that implements firmware-assisted
dump mechanism to capture kernel crash dump for Powerpc architecture.
Firmware-assisted dump is a robust mechanism to get reliable kernel crash
dump with the assistance of firmware. This approach does not use kexec,
instead firmware assists in booting the kdump kernel while preserving memory
contents.

- Firmware assisted dump (fadump) infrastructure is intended to replace
  the existing phyp assisted dump.
- Fadump uses the same firmware interfaces and memory reservation model
  as phyp assisted dump.
- Unlike phyp dump, fadump exports the memory dump through /proc/vmcore
  in the ELF format in the same way as kdump. This helps us reuse the
  kdump infrastructure for dump capture and filtering.
- Unlike phyp dump, userspace tool does not need to refer any sysfs
  interface while reading /proc/vmcore.
- Unlike phyp dump, fadump allows user to release all the memory reserved
  for dump, with a single operation of echo 1 > /sys/kernel/fadump_release_mem.
- Once enabled through kernel boot parameter, fadump can be
  started/stopped through /sys/kernel/fadump_registered interface and
  can be easily integrated with kdump service start/stop init scripts.
- Once the dump is copied out, the memory that held the dump is
  immediately available to the running kernel. And therefore, unlike
  kdump, fadump doesn't need a 2nd reboot to get back the system to
  the production configuration.

Fadump reuses much of the code written by Manish Ahuja and Linas Vepstas
for the phyp assisted dump.

I have tested the patches on following system configuration:
1. LPAR on Power6 with 4GB RAM and 8 CPUs
2. LPAR on Power7 with 2GB RAM and 20 CPUs
3. LPAR on Power7 with 1TB RAM and 896 CPUs

Please review the patchset and let me know your comments.


ChangeLog:

Change in v7:
-------------
- Updated the documentation explaining the enhancement in fadump over old
  phyp dump.
- Re-based patches to commit d65b4e98d7 (v3.3-rc3)

Change in v6:
-------------
- Use of_read_number and of_read_ulong while reading the dump sizes
  from rtas node ibm,configure-kernel-kdump-sizes and few minor changes.
- Kernel command line option 'fadump' now uses on/off values to
  enable/disable fadump.
- Added the last patch in this series 10/10 to remove phyp dump code.

Change in v5:
-------------
- Added 'fadump_' prefix to all static functions defined.

patch 02/10:
- Merged patch 10/10 which introduces a config option CONFIG_FA_DUMP
  for firmware assisted dump feature on Powerpc (ppc64) architecture.
- Increased MIN_BOOT_MEM by 64M to avoid OOM issue during network
  dump capture. When kdump infrastructure is configured to save vmcore
  over network, we run into OOM issue while loading modules related to
  network setup.

Changes in v4:
--------------
patch 04/10:
- Move the init_elfcore_header() function and 'memblock_num_regions' macro
 from generic code to power specific code as these are used only by
 firmware assisted dump implementation which is power specific feature.

patch 05/10:
- Fixes a issue where memblock_free() is invoked from build_cpu_notes()
  function during error_out path. Invoke cpu_notes_buf_free() in error_out
  path instead of memblock_free().

Changes in v3:
-------------
- Re-factored the implementation to work with kdump service start/stop.
  Introduce fadump_registered sysfs control file which will be used by
  kdump init scripts to start/stop firmware assisted dump. echo 1 to
  /sys/kernel/fadump_registered file for fadump registration and
  echo 0 to /sys/kernel/fadump_registered file for fadump un-registration.
- Introduced the locking mechanism to handle simultaneous writes to
  sysfs control files fadump_registered and fadump_release_mem

  Affected patches are: 01/10, 03/10, 08/10.

Changes in v2:
-------------
patch 01/10:
- Modified the documentation to reflect the change of fadump_region
  file under debugfs filesystem.

patch 02/10:
- Modified to use standard pr_debug() macro.
- Modified early_init_dt_scan_fw_dump() to get the size of
  "ibm,configure-kernel-dump-sizes" property and use it to iterate through
  an array of dump sections.
- Introduced boot option 'fadump_reserve_mem=' to let user specify the
  fadump boot memory to be reserved.

patch 03/10:
- Removed few debug print statements.
- Moved the setup_fadump() call from setup_system() and now calling it
  subsys_initcall.
- Moved fadump_region attribute under debugfs.
- Clear the TCE entries if firmware assisted dump is active.

patch 05/10:
- Moved the crash_fadump() invocation from generic code to panic notifier.
- Introduced cpu_notes_buf_alloc() function to allocate cpu notes buffer
  using get_free_pages().

patch 08/10:
- Introduced cpu_notes_buf_free() function to free memory allocated for
  cpu notes buffer.

Thanks,
-Mahesh.

---

Mahesh Salgaonkar (10):
      fadump: Add documentation for firmware-assisted dump.
      fadump: Reserve the memory for firmware assisted dump.
      fadump: Register for firmware assisted dump.
      fadump: Initialize elfcore header and add PT_LOAD program headers.
      fadump: Convert firmware-assisted cpu state dump data into elf notes.
      fadump: Add PT_NOTE program header for vmcoreinfo
      fadump: Introduce cleanup routine to invalidate /proc/vmcore.
      fadump: Invalidate registration and release reserved memory for general use.
      fadump: Invalidate the fadump registration during machine shutdown.
      fadump: Remove the phyp assisted dump code.


 Documentation/powerpc/firmware-assisted-dump.txt |  270 +++++
 Documentation/powerpc/phyp-assisted-dump.txt     |  127 --
 arch/powerpc/Kconfig                             |   17 
 arch/powerpc/include/asm/fadump.h                |  218 ++++
 arch/powerpc/include/asm/phyp_dump.h             |   47 -
 arch/powerpc/kernel/Makefile                     |    1 
 arch/powerpc/kernel/fadump.c                     | 1312 ++++++++++++++++++++++
 arch/powerpc/kernel/iommu.c                      |    8 
 arch/powerpc/kernel/prom.c                       |   98 --
 arch/powerpc/kernel/setup-common.c               |   14 
 arch/powerpc/kernel/traps.c                      |    3 
 arch/powerpc/mm/hash_utils_64.c                  |   11 
 arch/powerpc/platforms/pseries/Makefile          |    1 
 arch/powerpc/platforms/pseries/phyp_dump.c       |  513 ---------
 fs/proc/vmcore.c                                 |   23 
 15 files changed, 1881 insertions(+), 782 deletions(-)
 create mode 100644 Documentation/powerpc/firmware-assisted-dump.txt
 delete mode 100644 Documentation/powerpc/phyp-assisted-dump.txt
 create mode 100644 arch/powerpc/include/asm/fadump.h
 delete mode 100644 arch/powerpc/include/asm/phyp_dump.h
 create mode 100644 arch/powerpc/kernel/fadump.c
 delete mode 100644 arch/powerpc/platforms/pseries/phyp_dump.c

-- 
-Mahesh



From mahesh at linux.vnet.ibm.com  Thu Feb 16 06:14:14 2012
From: mahesh at linux.vnet.ibm.com (Mahesh J Salgaonkar)
Date: Thu, 16 Feb 2012 16:44:14 +0530
Subject: [RFC PATCH v7 01/10] fadump: Add documentation for firmware-assisted
 dump.
In-Reply-To: <20120216111050.4733.38034.stgit@mars>
References: <20120216111050.4733.38034.stgit@mars>
Message-ID: <20120216111414.4733.67540.stgit@mars>

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

Documentation for firmware-assisted dump. This document is based on the
original documentation written for phyp assisted dump by Linas Vepstas
and Manish Ahuja, with few changes to reflect the current implementation.

Signed-off-by: Mahesh Salgaonkar <mahesh at linux.vnet.ibm.com>
---
 Documentation/powerpc/firmware-assisted-dump.txt |  270 ++++++++++++++++++++++
 1 files changed, 270 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/powerpc/firmware-assisted-dump.txt

diff --git a/Documentation/powerpc/firmware-assisted-dump.txt b/Documentation/powerpc/firmware-assisted-dump.txt
new file mode 100644
index 0000000..3007bc9
--- /dev/null
+++ b/Documentation/powerpc/firmware-assisted-dump.txt
@@ -0,0 +1,270 @@
+
+                   Firmware-Assisted Dump
+                   ------------------------
+                       July 2011
+
+The goal of firmware-assisted dump is to enable the dump of
+a crashed system, and to do so from a fully-reset system, and
+to minimize the total elapsed time until the system is back
+in production use.
+
+- Firmware assisted dump (fadump) infrastructure is intended to replace
+  the existing phyp assisted dump.
+- Fadump uses the same firmware interfaces and memory reservation model
+  as phyp assisted dump.
+- Unlike phyp dump, fadump exports the memory dump through /proc/vmcore
+  in the ELF format in the same way as kdump. This helps us reuse the
+  kdump infrastructure for dump capture and filtering.
+- Unlike phyp dump, userspace tool does not need to refer any sysfs
+  interface while reading /proc/vmcore.
+- Unlike phyp dump, fadump allows user to release all the memory reserved
+  for dump, with a single operation of echo 1 > /sys/kernel/fadump_release_mem.
+- Once enabled through kernel boot parameter, fadump can be
+  started/stopped through /sys/kernel/fadump_registered interface (see
+  sysfs files section below) and can be easily integrated with kdump
+  service start/stop init scripts.
+
+Comparing with kdump or other strategies, firmware-assisted
+dump offers several strong, practical advantages:
+
+-- Unlike kdump, the system has been reset, and loaded
+   with a fresh copy of the kernel.  In particular,
+   PCI and I/O devices have been reinitialized and are
+   in a clean, consistent state.
+-- Once the dump is copied out, the memory that held the dump
+   is immediately available to the running kernel. And therefore,
+   unlike kdump, fadump doesn't need a 2nd reboot to get back
+   the system to the production configuration.
+
+The above can only be accomplished by coordination with,
+and assistance from the Power firmware. The procedure is
+as follows:
+
+-- The first kernel registers the sections of memory with the
+   Power firmware for dump preservation during OS initialization.
+   These registered sections of memory are reserved by the first
+   kernel during early boot.
+
+-- When a system crashes, the Power firmware will save
+   the low memory (boot memory of size larger of 5% of system RAM
+   or 256MB) of RAM to the previous registered region. It will
+   also save system registers, and hardware PTE's.
+
+   NOTE: The term 'boot memory' means size of the low memory chunk
+         that is required for a kernel to boot successfully when
+         booted with restricted memory. By default, the boot memory
+         size will be the larger of 5% of system RAM or 256MB.
+         Alternatively, user can also specify boot memory size
+         through boot parameter 'fadump_reserve_mem=' which will
+         override the default calculated size. Use this option
+         if default boot memory size is not sufficient for second
+         kernel to boot successfully.
+
+-- After the low memory (boot memory) area has been saved, the
+   firmware will reset PCI and other hardware state.  It will
+   *not* clear the RAM. It will then launch the bootloader, as
+   normal.
+
+-- The freshly booted kernel will notice that there is a new
+   node (ibm,dump-kernel) in the device tree, indicating that
+   there is crash data available from a previous boot. During
+   the early boot OS will reserve rest of the memory above
+   boot memory size effectively booting with restricted memory
+   size. This will make sure that the second kernel will not
+   touch any of the dump memory area.
+
+-- User-space tools will read /proc/vmcore to obtain the contents
+   of memory, which holds the previous crashed kernel dump in ELF
+   format. The userspace tools may copy this info to disk, or
+   network, nas, san, iscsi, etc. as desired.
+
+-- Once the userspace tool is done saving dump, it will echo
+   '1' to /sys/kernel/fadump_release_mem to release the reserved
+   memory back to general use, except the memory required for
+   next firmware-assisted dump registration.
+
+   e.g.
+     # echo 1 > /sys/kernel/fadump_release_mem
+
+Please note that the firmware-assisted dump feature
+is only available on Power6 and above systems with recent
+firmware versions.
+
+Implementation details:
+----------------------
+
+During boot, a check is made to see if firmware supports
+this feature on that particular machine. If it does, then
+we check to see if an active dump is waiting for us. If yes
+then everything but boot memory size of RAM is reserved during
+early boot (See Fig. 2). This area is released once we finish
+collecting the dump from user land scripts (e.g. kdump scripts)
+that are run. If there is dump data, then the
+/sys/kernel/fadump_release_mem file is created, and the reserved
+memory is held.
+
+If there is no waiting dump data, then only the memory required
+to hold CPU state, HPTE region, boot memory dump and elfcore
+header, is reserved at the top of memory (see Fig. 1). This area
+is *not* released: this region will be kept permanently reserved,
+so that it can act as a receptacle for a copy of the boot memory
+content in addition to CPU state and HPTE region, in the case a
+crash does occur.
+
+  o Memory Reservation during first kernel
+
+  Low memory                                        Top of memory
+  0      boot memory size                                       |
+  |           |                       |<--Reserved dump area -->|
+  V           V                       |   Permanent Reservation V
+  +-----------+----------/ /----------+---+----+-----------+----+
+  |           |                       |CPU|HPTE|  DUMP     |ELF |
+  +-----------+----------/ /----------+---+----+-----------+----+
+        |                                           ^
+        |                                           |
+        \                                           /
+         -------------------------------------------
+          Boot memory content gets transferred to
+          reserved area by firmware at the time of
+          crash
+                   Fig. 1
+
+  o Memory Reservation during second kernel after crash
+
+  Low memory                                        Top of memory
+  0      boot memory size                                       |
+  |           |<------------- Reserved dump area ----------- -->|
+  V           V                                                 V
+  +-----------+----------/ /----------+---+----+-----------+----+
+  |           |                       |CPU|HPTE|  DUMP     |ELF |
+  +-----------+----------/ /----------+---+----+-----------+----+
+        |                                                    |
+        V                                                    V
+   Used by second                                    /proc/vmcore
+   kernel to boot
+                   Fig. 2
+
+Currently the dump will be copied from /proc/vmcore to a
+a new file upon user intervention. The dump data available through
+/proc/vmcore will be in ELF format. Hence the existing kdump
+infrastructure (kdump scripts) to save the dump works fine with
+minor modifications.
+
+The tools to examine the dump will be same as the ones
+used for kdump.
+
+How to enable firmware-assisted dump (fadump):
+-------------------------------------
+
+1. Set config option CONFIG_FA_DUMP=y and build kernel.
+2. Boot into linux kernel with 'fadump=on' kernel cmdline option.
+3. Optionally, user can also set 'fadump_reserve_mem=' kernel cmdline
+   to specify size of the memory to reserve for boot memory dump
+   preservation.
+
+NOTE: If firmware-assisted dump fails to reserve memory then it will
+   fallback to existing kdump mechanism if 'crashkernel=' option
+   is set at kernel cmdline.
+
+Sysfs/debugfs files:
+------------
+
+Firmware-assisted dump feature uses sysfs file system to hold
+the control files and debugfs file to display memory reserved region.
+
+Here is the list of files under kernel sysfs:
+
+ /sys/kernel/fadump_enabled
+
+    This is used to display the fadump status.
+    0 = fadump is disabled
+    1 = fadump is enabled
+
+    This interface can be used by kdump init scripts to identify if
+    fadump is enabled in the kernel and act accordingly.
+
+ /sys/kernel/fadump_registered
+
+    This is used to display the fadump registration status as well
+    as to control (start/stop) the fadump registration.
+    0 = fadump is not registered.
+    1 = fadump is registered and ready to handle system crash.
+
+    To register fadump echo 1 > /sys/kernel/fadump_registered and
+    echo 0 > /sys/kernel/fadump_registered for un-register and stop the
+    fadump. Once the fadump is un-registered, the system crash will not
+    be handled and vmcore will not be captured. This interface can be
+    easily integrated with kdump service start/stop.
+
+ /sys/kernel/fadump_release_mem
+
+    This file is available only when fadump is active during
+    second kernel. This is used to release the reserved memory
+    region that are held for saving crash dump. To release the
+    reserved memory echo 1 to it:
+
+    echo 1  > /sys/kernel/fadump_release_mem
+
+    After echo 1, the content of the /sys/kernel/debug/powerpc/fadump_region
+    file will change to reflect the new memory reservations.
+
+    The existing userspace tools (kdump infrastructure) can be easily
+    enhanced to use this interface to release the memory reserved for
+    dump and continue without 2nd reboot.
+
+Here is the list of files under powerpc debugfs:
+(Assuming debugfs is mounted on /sys/kernel/debug directory.)
+
+ /sys/kernel/debug/powerpc/fadump_region
+
+    This file shows the reserved memory regions if fadump is
+    enabled otherwise this file is empty. The output format
+    is:
+    <region>: [<start>-<end>] <reserved-size> bytes, Dumped: <dump-size>
+
+    e.g.
+    Contents when fadump is registered during first kernel
+
+    # cat /sys/kernel/debug/powerpc/fadump_region
+    CPU : [0x0000006ffb0000-0x0000006fff001f] 0x40020 bytes, Dumped: 0x0
+    HPTE: [0x0000006fff0020-0x0000006fff101f] 0x1000 bytes, Dumped: 0x0
+    DUMP: [0x0000006fff1020-0x0000007fff101f] 0x10000000 bytes, Dumped: 0x0
+
+    Contents when fadump is active during second kernel
+
+    # cat /sys/kernel/debug/powerpc/fadump_region
+    CPU : [0x0000006ffb0000-0x0000006fff001f] 0x40020 bytes, Dumped: 0x40020
+    HPTE: [0x0000006fff0020-0x0000006fff101f] 0x1000 bytes, Dumped: 0x1000
+    DUMP: [0x0000006fff1020-0x0000007fff101f] 0x10000000 bytes, Dumped: 0x10000000
+        : [0x00000010000000-0x0000006ffaffff] 0x5ffb0000 bytes, Dumped: 0x5ffb0000
+
+NOTE: Please refer to Documentation/filesystems/debugfs.txt on
+      how to mount the debugfs filesystem.
+
+
+TODO:
+-----
+ o Need to come up with the better approach to find out more
+   accurate boot memory size that is required for a kernel to
+   boot successfully when booted with restricted memory.
+ o The fadump implementation introduces a fadump crash info structure
+   in the scratch area before the ELF core header. The idea of introducing
+   this structure is to pass some important crash info data to the second
+   kernel which will help second kernel to populate ELF core header with
+   correct data before it gets exported through /proc/vmcore. The current
+   design implementation does not address a possibility of introducing
+   additional fields (in future) to this structure without affecting
+   compatibility. Need to come up with the better approach to address this.
+   The possible approaches are:
+	1. Introduce version field for version tracking, bump up the version
+	whenever a new field is added to the structure in future. The version
+	field can be used to find out what fields are valid for the current
+	version of the structure.
+	2. Reserve the area of predefined size (say PAGE_SIZE) for this
+	structure and have unused area as reserved (initialized to zero)
+	for future field additions.
+   The advantage of approach 1 over 2 is we don't need to reserve extra space.
+---
+Author: Mahesh Salgaonkar <mahesh at linux.vnet.ibm.com>
+This document is based on the original documentation written for phyp
+assisted dump by Linas Vepstas and Manish Ahuja.



From mahesh at linux.vnet.ibm.com  Thu Feb 16 06:14:30 2012
From: mahesh at linux.vnet.ibm.com (Mahesh J Salgaonkar)
Date: Thu, 16 Feb 2012 16:44:30 +0530
Subject: [RFC PATCH v7 03/10] fadump: Register for firmware assisted dump.
In-Reply-To: <20120216111050.4733.38034.stgit@mars>
References: <20120216111050.4733.38034.stgit@mars>
Message-ID: <20120216111429.4733.24480.stgit@mars>

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

This patch registers for firmware-assisted dump using rtas token
ibm,configure-kernel-dump. During registration firmware is informed about
the reserved area where it saves the CPU state data, HPTE table and contents
of RMR region at the time of kernel crash. Apart from this, firmware also
preserves the contents of entire partition memory even if it is not specified
during registration.

This patch also populates sysfs files under /sys/kernel to display
fadump status and reserved memory regions.

This patch introduces fadump_registered sysfs control file which will be
used by kdump init scripts to start/stop firmware assisted dump. echo 1 to
/sys/kernel/fadump_registered file for fadump registration and
echo 0 to /sys/kernel/fadump_registered file for fadump un-registration.

Signed-off-by: Mahesh Salgaonkar <mahesh at linux.vnet.ibm.com>
---
 arch/powerpc/include/asm/fadump.h |   57 ++++++
 arch/powerpc/kernel/fadump.c      |  352 +++++++++++++++++++++++++++++++++++++
 arch/powerpc/kernel/iommu.c       |    8 +
 arch/powerpc/mm/hash_utils_64.c   |   11 +
 4 files changed, 424 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/fadump.h b/arch/powerpc/include/asm/fadump.h
index 7be25d3..bbaf278 100644
--- a/arch/powerpc/include/asm/fadump.h
+++ b/arch/powerpc/include/asm/fadump.h
@@ -48,6 +48,58 @@
 #define FADUMP_HPTE_REGION	0x0002
 #define FADUMP_REAL_MODE_REGION	0x0011
 
+/* Dump request flag */
+#define FADUMP_REQUEST_FLAG	0x00000001
+
+/* FAD commands */
+#define FADUMP_REGISTER		1
+#define FADUMP_UNREGISTER	2
+#define FADUMP_INVALIDATE	3
+
+/* Kernel Dump section info */
+struct fadump_section {
+	u32	request_flag;
+	u16	source_data_type;
+	u16	error_flags;
+	u64	source_address;
+	u64	source_len;
+	u64	bytes_dumped;
+	u64	destination_address;
+};
+
+/* ibm,configure-kernel-dump header. */
+struct fadump_section_header {
+	u32	dump_format_version;
+	u16	dump_num_sections;
+	u16	dump_status_flag;
+	u32	offset_first_dump_section;
+
+	/* Fields for disk dump option. */
+	u32	dd_block_size;
+	u64	dd_block_offset;
+	u64	dd_num_blocks;
+	u32	dd_offset_disk_path;
+
+	/* Maximum time allowed to prevent an automatic dump-reboot. */
+	u32	max_time_auto;
+};
+
+/*
+ * Firmware Assisted dump memory structure. This structure is required for
+ * registering future kernel dump with power firmware through rtas call.
+ *
+ * No disk dump option. Hence disk dump path string section is not included.
+ */
+struct fadump_mem_struct {
+	struct fadump_section_header	header;
+
+	/* Kernel dump sections */
+	struct fadump_section		cpu_state_data;
+	struct fadump_section		hpte_region;
+	struct fadump_section		rmr_region;
+};
+
+/* Firmware-assisted dump configuration details. */
 struct fw_dump {
 	unsigned long	cpu_state_data_size;
 	unsigned long	hpte_region_size;
@@ -62,10 +114,15 @@ struct fw_dump {
 	unsigned long	fadump_enabled:1;
 	unsigned long	fadump_supported:1;
 	unsigned long	dump_active:1;
+	unsigned long	dump_registered:1;
 };
 
 extern int early_init_dt_scan_fw_dump(unsigned long node,
 		const char *uname, int depth, void *data);
 extern int fadump_reserve_mem(void);
+extern int setup_fadump(void);
+extern int is_fadump_active(void);
+#else	/* CONFIG_FA_DUMP */
+static inline int is_fadump_active(void) { return 0; }
 #endif
 #endif
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index deb276a..13c22cd 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -29,6 +29,9 @@
 
 #include <linux/string.h>
 #include <linux/memblock.h>
+#include <linux/delay.h>
+#include <linux/debugfs.h>
+#include <linux/seq_file.h>
 
 #include <asm/page.h>
 #include <asm/prom.h>
@@ -36,6 +39,10 @@
 #include <asm/fadump.h>
 
 static struct fw_dump fw_dump;
+static struct fadump_mem_struct fdm;
+static const struct fadump_mem_struct *fdm_active;
+
+static DEFINE_MUTEX(fadump_mutex);
 
 /* Scan the Firmware Assisted dump configuration details. */
 int __init early_init_dt_scan_fw_dump(unsigned long node,
@@ -64,7 +71,8 @@ int __init early_init_dt_scan_fw_dump(unsigned long node,
 	 * The 'ibm,kernel-dump' rtas node is present only if there is
 	 * dump data waiting for us.
 	 */
-	if (of_get_flat_dt_prop(node, "ibm,kernel-dump", NULL))
+	fdm_active = of_get_flat_dt_prop(node, "ibm,kernel-dump", NULL);
+	if (fdm_active)
 		fw_dump.dump_active = 1;
 
 	/* Get the sizes required to store dump data for the firmware provided
@@ -98,6 +106,85 @@ int __init early_init_dt_scan_fw_dump(unsigned long node,
 	return 1;
 }
 
+int is_fadump_active(void)
+{
+	return fw_dump.dump_active;
+}
+
+/* Print firmware assisted dump configurations for debugging purpose. */
+static void fadump_show_config(void)
+{
+	pr_debug("Support for firmware-assisted dump (fadump): %s\n",
+			(fw_dump.fadump_supported ? "present" : "no support"));
+
+	if (!fw_dump.fadump_supported)
+		return;
+
+	pr_debug("Fadump enabled    : %s\n",
+				(fw_dump.fadump_enabled ? "yes" : "no"));
+	pr_debug("Dump Active       : %s\n",
+				(fw_dump.dump_active ? "yes" : "no"));
+	pr_debug("Dump section sizes:\n");
+	pr_debug("    CPU state data size: %lx\n", fw_dump.cpu_state_data_size);
+	pr_debug("    HPTE region size   : %lx\n", fw_dump.hpte_region_size);
+	pr_debug("Boot memory size  : %lx\n", fw_dump.boot_memory_size);
+}
+
+static unsigned long init_fadump_mem_struct(struct fadump_mem_struct *fdm,
+				unsigned long addr)
+{
+	if (!fdm)
+		return 0;
+
+	memset(fdm, 0, sizeof(struct fadump_mem_struct));
+	addr = addr & PAGE_MASK;
+
+	fdm->header.dump_format_version = 0x00000001;
+	fdm->header.dump_num_sections = 3;
+	fdm->header.dump_status_flag = 0;
+	fdm->header.offset_first_dump_section =
+		(u32)offsetof(struct fadump_mem_struct, cpu_state_data);
+
+	/*
+	 * Fields for disk dump option.
+	 * We are not using disk dump option, hence set these fields to 0.
+	 */
+	fdm->header.dd_block_size = 0;
+	fdm->header.dd_block_offset = 0;
+	fdm->header.dd_num_blocks = 0;
+	fdm->header.dd_offset_disk_path = 0;
+
+	/* set 0 to disable an automatic dump-reboot. */
+	fdm->header.max_time_auto = 0;
+
+	/* Kernel dump sections */
+	/* cpu state data section. */
+	fdm->cpu_state_data.request_flag = FADUMP_REQUEST_FLAG;
+	fdm->cpu_state_data.source_data_type = FADUMP_CPU_STATE_DATA;
+	fdm->cpu_state_data.source_address = 0;
+	fdm->cpu_state_data.source_len = fw_dump.cpu_state_data_size;
+	fdm->cpu_state_data.destination_address = addr;
+	addr += fw_dump.cpu_state_data_size;
+
+	/* hpte region section */
+	fdm->hpte_region.request_flag = FADUMP_REQUEST_FLAG;
+	fdm->hpte_region.source_data_type = FADUMP_HPTE_REGION;
+	fdm->hpte_region.source_address = 0;
+	fdm->hpte_region.source_len = fw_dump.hpte_region_size;
+	fdm->hpte_region.destination_address = addr;
+	addr += fw_dump.hpte_region_size;
+
+	/* RMA region section */
+	fdm->rmr_region.request_flag = FADUMP_REQUEST_FLAG;
+	fdm->rmr_region.source_data_type = FADUMP_REAL_MODE_REGION;
+	fdm->rmr_region.source_address = RMA_START;
+	fdm->rmr_region.source_len = fw_dump.boot_memory_size;
+	fdm->rmr_region.destination_address = addr;
+	addr += fw_dump.boot_memory_size;
+
+	return addr;
+}
+
 /**
  * fadump_calculate_reserve_size(): reserve variable boot area 5% of System RAM
  *
@@ -166,8 +253,15 @@ int __init fadump_reserve_mem(void)
 		fw_dump.fadump_enabled = 0;
 		return 0;
 	}
-	/* Initialize boot memory size */
-	fw_dump.boot_memory_size = fadump_calculate_reserve_size();
+	/*
+	 * Initialize boot memory size
+	 * If dump is active then we have already calculated the size during
+	 * first kernel.
+	 */
+	if (fdm_active)
+		fw_dump.boot_memory_size = fdm_active->rmr_region.source_len;
+	else
+		fw_dump.boot_memory_size = fadump_calculate_reserve_size();
 
 	/*
 	 * Calculate the memory boundary.
@@ -244,3 +338,255 @@ static int __init early_fadump_reserve_mem(char *p)
 	return 0;
 }
 early_param("fadump_reserve_mem", early_fadump_reserve_mem);
+
+static void register_fw_dump(struct fadump_mem_struct *fdm)
+{
+	int rc;
+	unsigned int wait_time;
+
+	pr_debug("Registering for firmware-assisted kernel dump...\n");
+
+	/* TODO: Add upper time limit for the delay */
+	do {
+		rc = rtas_call(fw_dump.ibm_configure_kernel_dump, 3, 1, NULL,
+			FADUMP_REGISTER, fdm,
+			sizeof(struct fadump_mem_struct));
+
+		wait_time = rtas_busy_delay_time(rc);
+		if (wait_time)
+			mdelay(wait_time);
+
+	} while (wait_time);
+
+	switch (rc) {
+	case -1:
+		printk(KERN_ERR "Failed to register firmware-assisted kernel"
+			" dump. Hardware Error(%d).\n", rc);
+		break;
+	case -3:
+		printk(KERN_ERR "Failed to register firmware-assisted kernel"
+			" dump. Parameter Error(%d).\n", rc);
+		break;
+	case -9:
+		printk(KERN_ERR "firmware-assisted kernel dump is already "
+			" registered.");
+		fw_dump.dump_registered = 1;
+		break;
+	case 0:
+		printk(KERN_INFO "firmware-assisted kernel dump registration"
+			" is successful\n");
+		fw_dump.dump_registered = 1;
+		break;
+	}
+}
+
+static void register_fadump(void)
+{
+	/*
+	 * If no memory is reserved then we can not register for firmware-
+	 * assisted dump.
+	 */
+	if (!fw_dump.reserve_dump_area_size)
+		return;
+
+	/* register the future kernel dump with firmware. */
+	register_fw_dump(&fdm);
+}
+
+static int fadump_unregister_dump(struct fadump_mem_struct *fdm)
+{
+	int rc = 0;
+	unsigned int wait_time;
+
+	pr_debug("Un-register firmware-assisted dump\n");
+
+	/* TODO: Add upper time limit for the delay */
+	do {
+		rc = rtas_call(fw_dump.ibm_configure_kernel_dump, 3, 1, NULL,
+			FADUMP_UNREGISTER, fdm,
+			sizeof(struct fadump_mem_struct));
+
+		wait_time = rtas_busy_delay_time(rc);
+		if (wait_time)
+			mdelay(wait_time);
+	} while (wait_time);
+
+	if (rc) {
+		printk(KERN_ERR "Failed to un-register firmware-assisted dump."
+			" unexpected error(%d).\n", rc);
+		return rc;
+	}
+	fw_dump.dump_registered = 0;
+	return 0;
+}
+
+static ssize_t fadump_enabled_show(struct kobject *kobj,
+					struct kobj_attribute *attr,
+					char *buf)
+{
+	return sprintf(buf, "%d\n", fw_dump.fadump_enabled);
+}
+
+static ssize_t fadump_register_show(struct kobject *kobj,
+					struct kobj_attribute *attr,
+					char *buf)
+{
+	return sprintf(buf, "%d\n", fw_dump.dump_registered);
+}
+
+static ssize_t fadump_register_store(struct kobject *kobj,
+					struct kobj_attribute *attr,
+					const char *buf, size_t count)
+{
+	int ret = 0;
+
+	if (!fw_dump.fadump_enabled || fdm_active)
+		return -EPERM;
+
+	mutex_lock(&fadump_mutex);
+
+	switch (buf[0]) {
+	case '0':
+		if (fw_dump.dump_registered == 0) {
+			ret = -EINVAL;
+			goto unlock_out;
+		}
+		/* Un-register Firmware-assisted dump */
+		fadump_unregister_dump(&fdm);
+		break;
+	case '1':
+		if (fw_dump.dump_registered == 1) {
+			ret = -EINVAL;
+			goto unlock_out;
+		}
+		/* Register Firmware-assisted dump */
+		register_fadump();
+		break;
+	default:
+		ret = -EINVAL;
+		break;
+	}
+
+unlock_out:
+	mutex_unlock(&fadump_mutex);
+	return ret < 0 ? ret : count;
+}
+
+static int fadump_region_show(struct seq_file *m, void *private)
+{
+	const struct fadump_mem_struct *fdm_ptr;
+
+	if (!fw_dump.fadump_enabled)
+		return 0;
+
+	if (fdm_active)
+		fdm_ptr = fdm_active;
+	else
+		fdm_ptr = &fdm;
+
+	seq_printf(m,
+			"CPU : [%#016llx-%#016llx] %#llx bytes, "
+			"Dumped: %#llx\n",
+			fdm_ptr->cpu_state_data.destination_address,
+			fdm_ptr->cpu_state_data.destination_address +
+			fdm_ptr->cpu_state_data.source_len - 1,
+			fdm_ptr->cpu_state_data.source_len,
+			fdm_ptr->cpu_state_data.bytes_dumped);
+	seq_printf(m,
+			"HPTE: [%#016llx-%#016llx] %#llx bytes, "
+			"Dumped: %#llx\n",
+			fdm_ptr->hpte_region.destination_address,
+			fdm_ptr->hpte_region.destination_address +
+			fdm_ptr->hpte_region.source_len - 1,
+			fdm_ptr->hpte_region.source_len,
+			fdm_ptr->hpte_region.bytes_dumped);
+	seq_printf(m,
+			"DUMP: [%#016llx-%#016llx] %#llx bytes, "
+			"Dumped: %#llx\n",
+			fdm_ptr->rmr_region.destination_address,
+			fdm_ptr->rmr_region.destination_address +
+			fdm_ptr->rmr_region.source_len - 1,
+			fdm_ptr->rmr_region.source_len,
+			fdm_ptr->rmr_region.bytes_dumped);
+
+	if (!fdm_active ||
+		(fw_dump.reserve_dump_area_start ==
+		fdm_ptr->cpu_state_data.destination_address))
+		return 0;
+
+	/* Dump is active. Show reserved memory region. */
+	seq_printf(m,
+			"    : [%#016llx-%#016llx] %#llx bytes, "
+			"Dumped: %#llx\n",
+			(unsigned long long)fw_dump.reserve_dump_area_start,
+			fdm_ptr->cpu_state_data.destination_address - 1,
+			fdm_ptr->cpu_state_data.destination_address -
+			fw_dump.reserve_dump_area_start,
+			fdm_ptr->cpu_state_data.destination_address -
+			fw_dump.reserve_dump_area_start);
+	return 0;
+}
+
+static struct kobj_attribute fadump_attr = __ATTR(fadump_enabled,
+						0444, fadump_enabled_show,
+						NULL);
+static struct kobj_attribute fadump_register_attr = __ATTR(fadump_registered,
+						0644, fadump_register_show,
+						fadump_register_store);
+
+static int fadump_region_open(struct inode *inode, struct file *file)
+{
+	return single_open(file, fadump_region_show, inode->i_private);
+}
+
+static const struct file_operations fadump_region_fops = {
+	.open    = fadump_region_open,
+	.read    = seq_read,
+	.llseek  = seq_lseek,
+	.release = single_release,
+};
+
+static void fadump_init_files(void)
+{
+	struct dentry *debugfs_file;
+	int rc = 0;
+
+	rc = sysfs_create_file(kernel_kobj, &fadump_attr.attr);
+	if (rc)
+		printk(KERN_ERR "fadump: unable to create sysfs file"
+			" fadump_enabled (%d)\n", rc);
+
+	rc = sysfs_create_file(kernel_kobj, &fadump_register_attr.attr);
+	if (rc)
+		printk(KERN_ERR "fadump: unable to create sysfs file"
+			" fadump_registered (%d)\n", rc);
+
+	debugfs_file = debugfs_create_file("fadump_region", 0444,
+					powerpc_debugfs_root, NULL,
+					&fadump_region_fops);
+	if (!debugfs_file)
+		printk(KERN_ERR "fadump: unable to create debugfs file"
+				" fadump_region\n");
+	return;
+}
+
+/*
+ * Prepare for firmware-assisted dump.
+ */
+int __init setup_fadump(void)
+{
+	if (!fw_dump.fadump_supported) {
+		printk(KERN_ERR "Firmware-assisted dump is not supported on"
+			" this hardware\n");
+		return 0;
+	}
+
+	fadump_show_config();
+	/* Initialize the kernel dump memory structure for FAD registration. */
+	if (fw_dump.reserve_dump_area_size)
+		init_fadump_mem_struct(&fdm, fw_dump.reserve_dump_area_start);
+	fadump_init_files();
+
+	return 1;
+}
+subsys_initcall(setup_fadump);
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 0cfcf98..359f078 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -39,6 +39,7 @@
 #include <asm/pci-bridge.h>
 #include <asm/machdep.h>
 #include <asm/kdump.h>
+#include <asm/fadump.h>
 
 #define DBG(...)
 
@@ -445,7 +446,12 @@ void iommu_unmap_sg(struct iommu_table *tbl, struct scatterlist *sglist,
 
 static void iommu_table_clear(struct iommu_table *tbl)
 {
-	if (!is_kdump_kernel()) {
+	/*
+	 * In case of firmware assisted dump system goes through clean
+	 * reboot process at the time of system crash. Hence it's safe to
+	 * clear the TCE entries if firmware assisted dump is active.
+	 */
+	if (!is_kdump_kernel() || is_fadump_active()) {
 		/* Clear the table in case firmware left allocations in it */
 		ppc_md.tce_free(tbl, tbl->it_offset, tbl->it_size);
 		return;
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 2d28218..b534bba 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -55,6 +55,7 @@
 #include <asm/spu.h>
 #include <asm/udbg.h>
 #include <asm/code-patching.h>
+#include <asm/fadump.h>
 
 #ifdef DEBUG
 #define DBG(fmt...) udbg_printf(fmt)
@@ -625,6 +626,16 @@ static void __init htab_initialize(void)
 		/* Using a hypervisor which owns the htab */
 		htab_address = NULL;
 		_SDR1 = 0; 
+#ifdef CONFIG_FA_DUMP
+		/*
+		 * If firmware assisted dump is active firmware preserves
+		 * the contents of htab along with entire partition memory.
+		 * Clear the htab if firmware assisted dump is active so
+		 * that we dont end up using old mappings.
+		 */
+		if (is_fadump_active() && ppc_md.hpte_clear_all)
+			ppc_md.hpte_clear_all();
+#endif
 	} else {
 		/* Find storage for the HPT.  Must be contiguous in
 		 * the absolute address space. On cell we want it to be



From mahesh at linux.vnet.ibm.com  Thu Feb 16 06:14:22 2012
From: mahesh at linux.vnet.ibm.com (Mahesh J Salgaonkar)
Date: Thu, 16 Feb 2012 16:44:22 +0530
Subject: [RFC PATCH v7 02/10] fadump: Reserve the memory for firmware assisted
 dump.
In-Reply-To: <20120216111050.4733.38034.stgit@mars>
References: <20120216111050.4733.38034.stgit@mars>
Message-ID: <20120216111421.4733.17834.stgit@mars>

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

Reserve the memory during early boot to preserve CPU state data, HPTE region
and RMA (real mode area) region data in case of kernel crash. At the time of
crash, powerpc firmware will store CPU state data, HPTE region data and move
RMA region data to the reserved memory area.

If the firmware-assisted dump fails to reserve the memory, then fallback
to existing kexec-based kdump.

Most of the code implementation to reserve memory has been
adapted from phyp assisted dump implementation written by Linas Vepstas
and Manish Ahuja

This patch also introduces a config option CONFIG_FA_DUMP for firmware
assisted dump feature on Powerpc (ppc64) architecture.

Signed-off-by: Mahesh Salgaonkar <mahesh at linux.vnet.ibm.com>
---
 arch/powerpc/Kconfig              |   13 ++
 arch/powerpc/include/asm/fadump.h |   71 +++++++++++
 arch/powerpc/kernel/Makefile      |    1 
 arch/powerpc/kernel/fadump.c      |  246 +++++++++++++++++++++++++++++++++++++
 arch/powerpc/kernel/prom.c        |   15 ++
 5 files changed, 345 insertions(+), 1 deletions(-)
 create mode 100644 arch/powerpc/include/asm/fadump.h
 create mode 100644 arch/powerpc/kernel/fadump.c

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 1919634..afa4dab 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -386,6 +386,19 @@ config PHYP_DUMP
 
 	  If unsure, say "N"
 
+config FA_DUMP
+	bool "Firmware-assisted dump"
+	depends on PPC64 && PPC_RTAS && CRASH_DUMP
+	help
+	  A robust mechanism to get reliable kernel crash dump with
+	  assistance from firmware. This approach does not use kexec,
+	  instead firmware assists in booting the kdump kernel
+	  while preserving memory contents. Firmware-assisted dump
+	  is meant to be a kdump replacement offering robustness and
+	  speed not possible without system firmware assistance.
+
+	  If unsure, say "N"
+
 config IRQ_ALL_CPUS
 	bool "Distribute interrupts on all CPUs by default"
 	depends on SMP && !MV64360
diff --git a/arch/powerpc/include/asm/fadump.h b/arch/powerpc/include/asm/fadump.h
new file mode 100644
index 0000000..7be25d3
--- /dev/null
+++ b/arch/powerpc/include/asm/fadump.h
@@ -0,0 +1,71 @@
+/*
+ * Firmware Assisted dump header file.
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright 2011 IBM Corporation
+ * Author: Mahesh Salgaonkar <mahesh at linux.vnet.ibm.com>
+ */
+
+#ifndef __PPC64_FA_DUMP_H__
+#define __PPC64_FA_DUMP_H__
+
+#ifdef CONFIG_FA_DUMP
+
+/*
+ * The RMA region will be saved for later dumping when kernel crashes.
+ * RMA is Real Mode Area, the first block of logical memory address owned
+ * by logical partition, containing the storage that may be accessed with
+ * translate off.
+ */
+#define RMA_START	0x0
+#define RMA_END		(ppc64_rma_size)
+
+/*
+ * On some Power systems where RMO is 128MB, it still requires minimum of
+ * 256MB for kernel to boot successfully. When kdump infrastructure is
+ * configured to save vmcore over network, we run into OOM issue while
+ * loading modules related to network setup. Hence we need aditional 64M
+ * of memory to avoid OOM issue.
+ */
+#define MIN_BOOT_MEM	(((RMA_END < (0x1UL << 28)) ? (0x1UL << 28) : RMA_END) \
+			+ (0x1UL << 26))
+
+/* Firmware provided dump sections */
+#define FADUMP_CPU_STATE_DATA	0x0001
+#define FADUMP_HPTE_REGION	0x0002
+#define FADUMP_REAL_MODE_REGION	0x0011
+
+struct fw_dump {
+	unsigned long	cpu_state_data_size;
+	unsigned long	hpte_region_size;
+	unsigned long	boot_memory_size;
+	unsigned long	reserve_dump_area_start;
+	unsigned long	reserve_dump_area_size;
+	/* cmd line option during boot */
+	unsigned long	reserve_bootvar;
+
+	int		ibm_configure_kernel_dump;
+
+	unsigned long	fadump_enabled:1;
+	unsigned long	fadump_supported:1;
+	unsigned long	dump_active:1;
+};
+
+extern int early_init_dt_scan_fw_dump(unsigned long node,
+		const char *uname, int depth, void *data);
+extern int fadump_reserve_mem(void);
+#endif
+#endif
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index ee728e4..391bf7e 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -60,6 +60,7 @@ obj-$(CONFIG_IBMVIO)		+= vio.o
 obj-$(CONFIG_IBMEBUS)           += ibmebus.o
 obj-$(CONFIG_GENERIC_TBSYNC)	+= smp-tbsync.o
 obj-$(CONFIG_CRASH_DUMP)	+= crash_dump.o
+obj-$(CONFIG_FA_DUMP)		+= fadump.o
 ifeq ($(CONFIG_PPC32),y)
 obj-$(CONFIG_E500)		+= idle_e500.o
 endif
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
new file mode 100644
index 0000000..deb276a
--- /dev/null
+++ b/arch/powerpc/kernel/fadump.c
@@ -0,0 +1,246 @@
+/*
+ * Firmware Assisted dump: A robust mechanism to get reliable kernel crash
+ * dump with assistance from firmware. This approach does not use kexec,
+ * instead firmware assists in booting the kdump kernel while preserving
+ * memory contents. The most of the code implementation has been adapted
+ * from phyp assisted dump implementation written by Linas Vepstas and
+ * Manish Ahuja
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright 2011 IBM Corporation
+ * Author: Mahesh Salgaonkar <mahesh at linux.vnet.ibm.com>
+ */
+
+#undef DEBUG
+#define pr_fmt(fmt) "fadump: " fmt
+
+#include <linux/string.h>
+#include <linux/memblock.h>
+
+#include <asm/page.h>
+#include <asm/prom.h>
+#include <asm/rtas.h>
+#include <asm/fadump.h>
+
+static struct fw_dump fw_dump;
+
+/* Scan the Firmware Assisted dump configuration details. */
+int __init early_init_dt_scan_fw_dump(unsigned long node,
+			const char *uname, int depth, void *data)
+{
+	__be32 *sections;
+	int i, num_sections;
+	unsigned long size;
+	const int *token;
+
+	if (depth != 1 || strcmp(uname, "rtas") != 0)
+		return 0;
+
+	/*
+	 * Check if Firmware Assisted dump is supported. if yes, check
+	 * if dump has been initiated on last reboot.
+	 */
+	token = of_get_flat_dt_prop(node, "ibm,configure-kernel-dump", NULL);
+	if (!token)
+		return 0;
+
+	fw_dump.fadump_supported = 1;
+	fw_dump.ibm_configure_kernel_dump = *token;
+
+	/*
+	 * The 'ibm,kernel-dump' rtas node is present only if there is
+	 * dump data waiting for us.
+	 */
+	if (of_get_flat_dt_prop(node, "ibm,kernel-dump", NULL))
+		fw_dump.dump_active = 1;
+
+	/* Get the sizes required to store dump data for the firmware provided
+	 * dump sections.
+	 * For each dump section type supported, a 32bit cell which defines
+	 * the ID of a supported section followed by two 32 bit cells which
+	 * gives teh size of the section in bytes.
+	 */
+	sections = of_get_flat_dt_prop(node, "ibm,configure-kernel-dump-sizes",
+					&size);
+
+	if (!sections)
+		return 0;
+
+	num_sections = size / (3 * sizeof(u32));
+
+	for (i = 0; i < num_sections; i++, sections += 3) {
+		u32 type = (u32)of_read_number(sections, 1);
+
+		switch (type) {
+		case FADUMP_CPU_STATE_DATA:
+			fw_dump.cpu_state_data_size =
+					of_read_ulong(&sections[1], 2);
+			break;
+		case FADUMP_HPTE_REGION:
+			fw_dump.hpte_region_size =
+					of_read_ulong(&sections[1], 2);
+			break;
+		}
+	}
+	return 1;
+}
+
+/**
+ * fadump_calculate_reserve_size(): reserve variable boot area 5% of System RAM
+ *
+ * Function to find the largest memory size we need to reserve during early
+ * boot process. This will be the size of the memory that is required for a
+ * kernel to boot successfully.
+ *
+ * This function has been taken from phyp-assisted dump feature implementation.
+ *
+ * returns larger of 256MB or 5% rounded down to multiples of 256MB.
+ *
+ * TODO: Come up with better approach to find out more accurate memory size
+ * that is required for a kernel to boot successfully.
+ *
+ */
+static inline unsigned long fadump_calculate_reserve_size(void)
+{
+	unsigned long size;
+
+	/*
+	 * Check if the size is specified through fadump_reserve_mem= cmdline
+	 * option. If yes, then use that.
+	 */
+	if (fw_dump.reserve_bootvar)
+		return fw_dump.reserve_bootvar;
+
+	/* divide by 20 to get 5% of value */
+	size = memblock_end_of_DRAM() / 20;
+
+	/* round it down in multiples of 256 */
+	size = size & ~0x0FFFFFFFUL;
+
+	/* Truncate to memory_limit. We don't want to over reserve the memory.*/
+	if (memory_limit && size > memory_limit)
+		size = memory_limit;
+
+	return (size > MIN_BOOT_MEM ? size : MIN_BOOT_MEM);
+}
+
+/*
+ * Calculate the total memory size required to be reserved for
+ * firmware-assisted dump registration.
+ */
+static unsigned long get_fadump_area_size(void)
+{
+	unsigned long size = 0;
+
+	size += fw_dump.cpu_state_data_size;
+	size += fw_dump.hpte_region_size;
+	size += fw_dump.boot_memory_size;
+
+	size = PAGE_ALIGN(size);
+	return size;
+}
+
+int __init fadump_reserve_mem(void)
+{
+	unsigned long base, size, memory_boundary;
+
+	if (!fw_dump.fadump_enabled)
+		return 0;
+
+	if (!fw_dump.fadump_supported) {
+		printk(KERN_INFO "Firmware-assisted dump is not supported on"
+				" this hardware\n");
+		fw_dump.fadump_enabled = 0;
+		return 0;
+	}
+	/* Initialize boot memory size */
+	fw_dump.boot_memory_size = fadump_calculate_reserve_size();
+
+	/*
+	 * Calculate the memory boundary.
+	 * If memory_limit is less than actual memory boundary then reserve
+	 * the memory for fadump beyond the memory_limit and adjust the
+	 * memory_limit accordingly, so that the running kernel can run with
+	 * specified memory_limit.
+	 */
+	if (memory_limit && memory_limit < memblock_end_of_DRAM()) {
+		size = get_fadump_area_size();
+		if ((memory_limit + size) < memblock_end_of_DRAM())
+			memory_limit += size;
+		else
+			memory_limit = memblock_end_of_DRAM();
+		printk(KERN_INFO "Adjusted memory_limit for firmware-assisted"
+				" dump, now %#016llx\n",
+				(unsigned long long)memory_limit);
+	}
+	if (memory_limit)
+		memory_boundary = memory_limit;
+	else
+		memory_boundary = memblock_end_of_DRAM();
+
+	if (fw_dump.dump_active) {
+		printk(KERN_INFO "Firmware-assisted dump is active.\n");
+		/*
+		 * If last boot has crashed then reserve all the memory
+		 * above boot_memory_size so that we don't touch it until
+		 * dump is written to disk by userspace tool. This memory
+		 * will be released for general use once the dump is saved.
+		 */
+		base = fw_dump.boot_memory_size;
+		size = memory_boundary - base;
+		memblock_reserve(base, size);
+		printk(KERN_INFO "Reserved %ldMB of memory at %ldMB "
+				"for saving crash dump\n",
+				(unsigned long)(size >> 20),
+				(unsigned long)(base >> 20));
+	} else {
+		/* Reserve the memory at the top of memory. */
+		size = get_fadump_area_size();
+		base = memory_boundary - size;
+		memblock_reserve(base, size);
+		printk(KERN_INFO "Reserved %ldMB of memory at %ldMB "
+				"for firmware-assisted dump\n",
+				(unsigned long)(size >> 20),
+				(unsigned long)(base >> 20));
+	}
+	fw_dump.reserve_dump_area_start = base;
+	fw_dump.reserve_dump_area_size = size;
+	return 1;
+}
+
+/* Look for fadump= cmdline option. */
+static int __init early_fadump_param(char *p)
+{
+	if (!p)
+		return 1;
+
+	if (strncmp(p, "on", 2) == 0)
+		fw_dump.fadump_enabled = 1;
+	else if (strncmp(p, "off", 3) == 0)
+		fw_dump.fadump_enabled = 0;
+
+	return 0;
+}
+early_param("fadump", early_fadump_param);
+
+/* Look for fadump_reserve_mem= cmdline option */
+static int __init early_fadump_reserve_mem(char *p)
+{
+	if (p)
+		fw_dump.reserve_bootvar = memparse(p, &p);
+	return 0;
+}
+early_param("fadump_reserve_mem", early_fadump_reserve_mem);
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index abe405d..70222b3 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -55,6 +55,7 @@
 #include <asm/phyp_dump.h>
 #include <asm/kexec.h>
 #include <asm/opal.h>
+#include <asm/fadump.h>
 
 #include <mm/mmu_decl.h>
 
@@ -719,6 +720,11 @@ void __init early_init_devtree(void *params)
 	of_scan_flat_dt(early_init_dt_scan_phyp_dump, NULL);
 #endif
 
+#ifdef CONFIG_FA_DUMP
+	/* scan tree to see if dump is active during last boot */
+	of_scan_flat_dt(early_init_dt_scan_fw_dump, NULL);
+#endif
+
 	/* Pre-initialize the cmd_line with the content of boot_commmand_line,
 	 * which will be empty except when the content of the variable has
 	 * been overriden by a bootloading mechanism. This happens typically
@@ -750,7 +756,14 @@ void __init early_init_devtree(void *params)
 	if (PHYSICAL_START > MEMORY_START)
 		memblock_reserve(MEMORY_START, 0x8000);
 	reserve_kdump_trampoline();
-	reserve_crashkernel();
+#ifdef CONFIG_FA_DUMP
+	/*
+	 * If we fail to reserve memory for firmware-assisted dump then
+	 * fallback to kexec based kdump.
+	 */
+	if (fadump_reserve_mem() == 0)
+#endif
+		reserve_crashkernel();
 	early_reserve_mem();
 	phyp_dump_reserve_mem();
 



From mahesh at linux.vnet.ibm.com  Thu Feb 16 06:14:37 2012
From: mahesh at linux.vnet.ibm.com (Mahesh J Salgaonkar)
Date: Thu, 16 Feb 2012 16:44:37 +0530
Subject: [RFC PATCH v7 04/10] fadump: Initialize elfcore header and add
 PT_LOAD program headers.
In-Reply-To: <20120216111050.4733.38034.stgit@mars>
References: <20120216111050.4733.38034.stgit@mars>
Message-ID: <20120216111437.4733.37250.stgit@mars>

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

Build the crash memory range list by traversing through system memory during
the first kernel before we register for firmware-assisted dump. After the
successful dump registration, initialize the elfcore header and populate
PT_LOAD program headers with crash memory ranges. The elfcore header is
saved in the scratch area within the reserved memory. The scratch area starts
at the end of the memory reserved for saving RMR region contents. The
scratch area contains fadump crash info structure that contains magic number
for fadump validation and physical address where the eflcore header can be
found. This structure will also be used to pass some important crash info
data to the second kernel which will help second kernel to populate ELF core
header with correct data before it gets exported through /proc/vmcore. Since
the firmware preserves the entire partition memory at the time of crash the
contents of the scratch area will be preserved till second kernel boot.

Since the memory dump exported through /proc/vmcore is in ELF format similar
to kdump, it will help us to reuse the kdump infrastructure for dump capture
and filtering. Unlike phyp dump, userspace tool does not need to refer any
sysfs interface while reading /proc/vmcore.

NOTE: The current design implementation does not address a possibility of
introducing additional fields (in future) to this structure without affecting
compatibility. It's on TODO list to come up with better approach to
address this.

Reserved dump area start => +-------------------------------------+
                            |  CPU state dump data                |
                            +-------------------------------------+
                            |  HPTE region data                   |
                            +-------------------------------------+
                            |  RMR region data                    |
Scratch area start       => +-------------------------------------+
                            |  fadump crash info structure {      |
                            |     magic nummber                   |
                     +------|---- elfcorehdr_addr                 |
                     |      |  }                                  |
                     +----> +-------------------------------------+
                            |  ELF core header                    |
Reserved dump area end   => +-------------------------------------+

Signed-off-by: Mahesh Salgaonkar <mahesh at linux.vnet.ibm.com>
---
 arch/powerpc/include/asm/fadump.h |   43 +++++++
 arch/powerpc/kernel/fadump.c      |  233 +++++++++++++++++++++++++++++++++++++
 2 files changed, 275 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/include/asm/fadump.h b/arch/powerpc/include/asm/fadump.h
index bbaf278..9e172a5 100644
--- a/arch/powerpc/include/asm/fadump.h
+++ b/arch/powerpc/include/asm/fadump.h
@@ -43,6 +43,12 @@
 #define MIN_BOOT_MEM	(((RMA_END < (0x1UL << 28)) ? (0x1UL << 28) : RMA_END) \
 			+ (0x1UL << 26))
 
+#define memblock_num_regions(memblock_type)	(memblock.memblock_type.cnt)
+
+#ifndef ELF_CORE_EFLAGS
+#define ELF_CORE_EFLAGS 0
+#endif
+
 /* Firmware provided dump sections */
 #define FADUMP_CPU_STATE_DATA	0x0001
 #define FADUMP_HPTE_REGION	0x0002
@@ -56,6 +62,9 @@
 #define FADUMP_UNREGISTER	2
 #define FADUMP_INVALIDATE	3
 
+/* Dump status flag */
+#define FADUMP_ERROR_FLAG	0x2000
+
 /* Kernel Dump section info */
 struct fadump_section {
 	u32	request_flag;
@@ -109,6 +118,7 @@ struct fw_dump {
 	/* cmd line option during boot */
 	unsigned long	reserve_bootvar;
 
+	unsigned long	fadumphdr_addr;
 	int		ibm_configure_kernel_dump;
 
 	unsigned long	fadump_enabled:1;
@@ -117,6 +127,39 @@ struct fw_dump {
 	unsigned long	dump_registered:1;
 };
 
+/*
+ * Copy the ascii values for first 8 characters from a string into u64
+ * variable at their respective indexes.
+ * e.g.
+ *  The string "FADMPINF" will be converted into 0x4641444d50494e46
+ */
+static inline u64 str_to_u64(const char *str)
+{
+	u64 val = 0;
+	int i;
+
+	for (i = 0; i < sizeof(val); i++)
+		val = (*str) ? (val << 8) | *str++ : val << 8;
+	return val;
+}
+#define STR_TO_HEX(x)	str_to_u64(x)
+
+#define FADUMP_CRASH_INFO_MAGIC		STR_TO_HEX("FADMPINF")
+
+/* fadump crash info structure */
+struct fadump_crash_info_header {
+	u64		magic_number;
+	u64		elfcorehdr_addr;
+};
+
+/* Crash memory ranges */
+#define INIT_CRASHMEM_RANGES	(INIT_MEMBLOCK_REGIONS + 2)
+
+struct fad_crash_memory_ranges {
+	unsigned long long	base;
+	unsigned long long	size;
+};
+
 extern int early_init_dt_scan_fw_dump(unsigned long node,
 		const char *uname, int depth, void *data);
 extern int fadump_reserve_mem(void);
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 13c22cd..f85a63f 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -32,6 +32,7 @@
 #include <linux/delay.h>
 #include <linux/debugfs.h>
 #include <linux/seq_file.h>
+#include <linux/crash_dump.h>
 
 #include <asm/page.h>
 #include <asm/prom.h>
@@ -43,6 +44,8 @@ static struct fadump_mem_struct fdm;
 static const struct fadump_mem_struct *fdm_active;
 
 static DEFINE_MUTEX(fadump_mutex);
+struct fad_crash_memory_ranges crash_memory_ranges[INIT_CRASHMEM_RANGES];
+int crash_mem_ranges;
 
 /* Scan the Firmware Assisted dump configuration details. */
 int __init early_init_dt_scan_fw_dump(unsigned long node,
@@ -235,6 +238,10 @@ static unsigned long get_fadump_area_size(void)
 	size += fw_dump.cpu_state_data_size;
 	size += fw_dump.hpte_region_size;
 	size += fw_dump.boot_memory_size;
+	size += sizeof(struct fadump_crash_info_header);
+	size += sizeof(struct elfhdr); /* ELF core header.*/
+	/* Program headers for crash memory regions. */
+	size += sizeof(struct elf_phdr) * (memblock_num_regions(memory) + 2);
 
 	size = PAGE_ALIGN(size);
 	return size;
@@ -300,6 +307,12 @@ int __init fadump_reserve_mem(void)
 				"for saving crash dump\n",
 				(unsigned long)(size >> 20),
 				(unsigned long)(base >> 20));
+
+		fw_dump.fadumphdr_addr =
+				fdm_active->rmr_region.destination_address +
+				fdm_active->rmr_region.source_len;
+		pr_debug("fadumphdr_addr = %p\n",
+				(void *) fw_dump.fadumphdr_addr);
 	} else {
 		/* Reserve the memory at the top of memory. */
 		size = get_fadump_area_size();
@@ -380,8 +393,210 @@ static void register_fw_dump(struct fadump_mem_struct *fdm)
 	}
 }
 
+/*
+ * Validate and process the dump data stored by firmware before exporting
+ * it through '/proc/vmcore'.
+ */
+static int __init process_fadump(const struct fadump_mem_struct *fdm_active)
+{
+	struct fadump_crash_info_header *fdh;
+
+	if (!fdm_active || !fw_dump.fadumphdr_addr)
+		return -EINVAL;
+
+	/* Check if the dump data is valid. */
+	if ((fdm_active->header.dump_status_flag == FADUMP_ERROR_FLAG) ||
+			(fdm_active->rmr_region.error_flags != 0)) {
+		printk(KERN_ERR "Dump taken by platform is not valid\n");
+		return -EINVAL;
+	}
+	if (fdm_active->rmr_region.bytes_dumped !=
+			fdm_active->rmr_region.source_len) {
+		printk(KERN_ERR "Dump taken by platform is incomplete\n");
+		return -EINVAL;
+	}
+
+	/* Validate the fadump crash info header */
+	fdh = __va(fw_dump.fadumphdr_addr);
+	if (fdh->magic_number != FADUMP_CRASH_INFO_MAGIC) {
+		printk(KERN_ERR "Crash info header is not valid.\n");
+		return -EINVAL;
+	}
+
+	/*
+	 * We are done validating dump info and elfcore header is now ready
+	 * to be exported. set elfcorehdr_addr so that vmcore module will
+	 * export the elfcore header through '/proc/vmcore'.
+	 */
+	elfcorehdr_addr = fdh->elfcorehdr_addr;
+
+	return 0;
+}
+
+static inline void fadump_add_crash_memory(unsigned long long base,
+					unsigned long long end)
+{
+	if (base == end)
+		return;
+
+	pr_debug("crash_memory_range[%d] [%#016llx-%#016llx], %#llx bytes\n",
+		crash_mem_ranges, base, end - 1, (end - base));
+	crash_memory_ranges[crash_mem_ranges].base = base;
+	crash_memory_ranges[crash_mem_ranges].size = end - base;
+	crash_mem_ranges++;
+}
+
+static void fadump_exclude_reserved_area(unsigned long long start,
+					unsigned long long end)
+{
+	unsigned long long ra_start, ra_end;
+
+	ra_start = fw_dump.reserve_dump_area_start;
+	ra_end = ra_start + fw_dump.reserve_dump_area_size;
+
+	if ((ra_start < end) && (ra_end > start)) {
+		if ((start < ra_start) && (end > ra_end)) {
+			fadump_add_crash_memory(start, ra_start);
+			fadump_add_crash_memory(ra_end, end);
+		} else if (start < ra_start) {
+			fadump_add_crash_memory(start, ra_start);
+		} else if (ra_end < end) {
+			fadump_add_crash_memory(ra_end, end);
+		}
+	} else
+		fadump_add_crash_memory(start, end);
+}
+
+static int fadump_init_elfcore_header(char *bufp)
+{
+	struct elfhdr *elf;
+
+	elf = (struct elfhdr *) bufp;
+	bufp += sizeof(struct elfhdr);
+	memcpy(elf->e_ident, ELFMAG, SELFMAG);
+	elf->e_ident[EI_CLASS] = ELF_CLASS;
+	elf->e_ident[EI_DATA] = ELF_DATA;
+	elf->e_ident[EI_VERSION] = EV_CURRENT;
+	elf->e_ident[EI_OSABI] = ELF_OSABI;
+	memset(elf->e_ident+EI_PAD, 0, EI_NIDENT-EI_PAD);
+	elf->e_type = ET_CORE;
+	elf->e_machine = ELF_ARCH;
+	elf->e_version = EV_CURRENT;
+	elf->e_entry = 0;
+	elf->e_phoff = sizeof(struct elfhdr);
+	elf->e_shoff = 0;
+	elf->e_flags = ELF_CORE_EFLAGS;
+	elf->e_ehsize = sizeof(struct elfhdr);
+	elf->e_phentsize = sizeof(struct elf_phdr);
+	elf->e_phnum = 0;
+	elf->e_shentsize = 0;
+	elf->e_shnum = 0;
+	elf->e_shstrndx = 0;
+
+	return 0;
+}
+
+/*
+ * Traverse through memblock structure and setup crash memory ranges. These
+ * ranges will be used create PT_LOAD program headers in elfcore header.
+ */
+static void fadump_setup_crash_memory_ranges(void)
+{
+	struct memblock_region *reg;
+	unsigned long long start, end;
+
+	pr_debug("Setup crash memory ranges.\n");
+	crash_mem_ranges = 0;
+	/*
+	 * add the first memory chunk (RMA_START through boot_memory_size) as
+	 * a separate memory chunk. The reason is, at the time crash firmware
+	 * will move the content of this memory chunk to different location
+	 * specified during fadump registration. We need to create a separate
+	 * program header for this chunk with the correct offset.
+	 */
+	fadump_add_crash_memory(RMA_START, fw_dump.boot_memory_size);
+
+	for_each_memblock(memory, reg) {
+		start = (unsigned long long)reg->base;
+		end = start + (unsigned long long)reg->size;
+		if (start == RMA_START && end >= fw_dump.boot_memory_size)
+			start = fw_dump.boot_memory_size;
+
+		/* add this range excluding the reserved dump area. */
+		fadump_exclude_reserved_area(start, end);
+	}
+}
+
+static int fadump_create_elfcore_headers(char *bufp)
+{
+	struct elfhdr *elf;
+	struct elf_phdr *phdr;
+	int i;
+
+	fadump_init_elfcore_header(bufp);
+	elf = (struct elfhdr *)bufp;
+	bufp += sizeof(struct elfhdr);
+
+	/* setup PT_LOAD sections. */
+
+	for (i = 0; i < crash_mem_ranges; i++) {
+		unsigned long long mbase, msize;
+		mbase = crash_memory_ranges[i].base;
+		msize = crash_memory_ranges[i].size;
+
+		if (!msize)
+			continue;
+
+		phdr = (struct elf_phdr *)bufp;
+		bufp += sizeof(struct elf_phdr);
+		phdr->p_type	= PT_LOAD;
+		phdr->p_flags	= PF_R|PF_W|PF_X;
+		phdr->p_offset	= mbase;
+
+		if (mbase == RMA_START) {
+			/*
+			 * The entire RMA region will be moved by firmware
+			 * to the specified destination_address. Hence set
+			 * the correct offset.
+			 */
+			phdr->p_offset = fdm.rmr_region.destination_address;
+		}
+
+		phdr->p_paddr = mbase;
+		phdr->p_vaddr = (unsigned long)__va(mbase);
+		phdr->p_filesz = msize;
+		phdr->p_memsz = msize;
+		phdr->p_align = 0;
+
+		/* Increment number of program headers. */
+		(elf->e_phnum)++;
+	}
+	return 0;
+}
+
+static unsigned long init_fadump_header(unsigned long addr)
+{
+	struct fadump_crash_info_header *fdh;
+
+	if (!addr)
+		return 0;
+
+	fw_dump.fadumphdr_addr = addr;
+	fdh = __va(addr);
+	addr += sizeof(struct fadump_crash_info_header);
+
+	memset(fdh, 0, sizeof(struct fadump_crash_info_header));
+	fdh->magic_number = FADUMP_CRASH_INFO_MAGIC;
+	fdh->elfcorehdr_addr = addr;
+
+	return addr;
+}
+
 static void register_fadump(void)
 {
+	unsigned long addr;
+	void *vaddr;
+
 	/*
 	 * If no memory is reserved then we can not register for firmware-
 	 * assisted dump.
@@ -389,6 +604,16 @@ static void register_fadump(void)
 	if (!fw_dump.reserve_dump_area_size)
 		return;
 
+	fadump_setup_crash_memory_ranges();
+
+	addr = fdm.rmr_region.destination_address + fdm.rmr_region.source_len;
+	/* Initialize fadump crash info header. */
+	addr = init_fadump_header(addr);
+	vaddr = __va(addr);
+
+	pr_debug("Creating ELF core headers at %#016lx\n", addr);
+	fadump_create_elfcore_headers(vaddr);
+
 	/* register the future kernel dump with firmware. */
 	register_fw_dump(&fdm);
 }
@@ -582,8 +807,14 @@ int __init setup_fadump(void)
 	}
 
 	fadump_show_config();
+	/*
+	 * If dump data is available then see if it is valid and prepare for
+	 * saving it to the disk.
+	 */
+	if (fw_dump.dump_active)
+		process_fadump(fdm_active);
 	/* Initialize the kernel dump memory structure for FAD registration. */
-	if (fw_dump.reserve_dump_area_size)
+	else if (fw_dump.reserve_dump_area_size)
 		init_fadump_mem_struct(&fdm, fw_dump.reserve_dump_area_start);
 	fadump_init_files();
 



From mahesh at linux.vnet.ibm.com  Thu Feb 16 06:14:53 2012
From: mahesh at linux.vnet.ibm.com (Mahesh J Salgaonkar)
Date: Thu, 16 Feb 2012 16:44:53 +0530
Subject: [RFC PATCH v7 06/10] fadump: Add PT_NOTE program header for vmcoreinfo
In-Reply-To: <20120216111050.4733.38034.stgit@mars>
References: <20120216111050.4733.38034.stgit@mars>
Message-ID: <20120216111452.4733.91579.stgit@mars>

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

Introduce a PT_NOTE program header that points to physical address of
vmcoreinfo_note buffer declared in kernel/kexec.c. The vmcoreinfo
note buffer is populated during crash_fadump() at the time of system
crash.

Signed-off-by: Mahesh Salgaonkar <mahesh at linux.vnet.ibm.com>
---
 arch/powerpc/kernel/fadump.c |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index cab56e7..5689954 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -814,6 +814,19 @@ static void fadump_setup_crash_memory_ranges(void)
 	}
 }
 
+/*
+ * If the given physical address falls within the boot memory region then
+ * return the relocated address that points to the dump region reserved
+ * for saving initial boot memory contents.
+ */
+static inline unsigned long fadump_relocate(unsigned long paddr)
+{
+	if (paddr > RMA_START && paddr < fw_dump.boot_memory_size)
+		return fdm.rmr_region.destination_address + paddr;
+	else
+		return paddr;
+}
+
 static int fadump_create_elfcore_headers(char *bufp)
 {
 	struct elfhdr *elf;
@@ -845,6 +858,22 @@ static int fadump_create_elfcore_headers(char *bufp)
 
 	(elf->e_phnum)++;
 
+	/* setup ELF PT_NOTE for vmcoreinfo */
+	phdr = (struct elf_phdr *)bufp;
+	bufp += sizeof(struct elf_phdr);
+	phdr->p_type	= PT_NOTE;
+	phdr->p_flags	= 0;
+	phdr->p_vaddr	= 0;
+	phdr->p_align	= 0;
+
+	phdr->p_paddr	= fadump_relocate(paddr_vmcoreinfo_note());
+	phdr->p_offset	= phdr->p_paddr;
+	phdr->p_memsz	= vmcoreinfo_max_size;
+	phdr->p_filesz	= vmcoreinfo_max_size;
+
+	/* Increment number of program headers. */
+	(elf->e_phnum)++;
+
 	/* setup PT_LOAD sections. */
 
 	for (i = 0; i < crash_mem_ranges; i++) {



From mahesh at linux.vnet.ibm.com  Thu Feb 16 06:15:00 2012
From: mahesh at linux.vnet.ibm.com (Mahesh J Salgaonkar)
Date: Thu, 16 Feb 2012 16:45:00 +0530
Subject: [RFC PATCH v7 07/10] fadump: Introduce cleanup routine to invalidate
 /proc/vmcore.
In-Reply-To: <20120216111050.4733.38034.stgit@mars>
References: <20120216111050.4733.38034.stgit@mars>
Message-ID: <20120216111459.4733.83147.stgit@mars>

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

With the firmware-assisted dump support we don't require a reboot when we
are in second kernel after crash. The second kernel after crash is a normal
kernel boot and has knowledge about entire system RAM with the page tables
initialized for entire system RAM. Hence once the dump is saved to disk, we
can just release the reserved memory area for general use and continue
with second kernel as production kernel.

Hence when we release the reserved memory that contains dump data, the
'/proc/vmcore' will not be valid anymore. Hence this patch introduces
a cleanup routine that invalidates and removes the /proc/vmcore file. This
routine will be invoked before we release the reserved dump memory area.

Signed-off-by: Mahesh Salgaonkar <mahesh at linux.vnet.ibm.com>
---
 fs/proc/vmcore.c |   23 +++++++++++++++++++++++
 1 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index b0f450a..0d5071d 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc/vmcore.c
@@ -700,3 +700,26 @@ static int __init vmcore_init(void)
 	return 0;
 }
 module_init(vmcore_init)
+
+/* Cleanup function for vmcore module. */
+void vmcore_cleanup(void)
+{
+	struct list_head *pos, *next;
+
+	if (proc_vmcore) {
+		remove_proc_entry(proc_vmcore->name, proc_vmcore->parent);
+		proc_vmcore = NULL;
+	}
+
+	/* clear the vmcore list. */
+	list_for_each_safe(pos, next, &vmcore_list) {
+		struct vmcore *m;
+
+		m = list_entry(pos, struct vmcore, list);
+		list_del(&m->list);
+		kfree(m);
+	}
+	kfree(elfcorebuf);
+	elfcorebuf = NULL;
+}
+EXPORT_SYMBOL_GPL(vmcore_cleanup);



From mahesh at linux.vnet.ibm.com  Thu Feb 16 06:15:08 2012
From: mahesh at linux.vnet.ibm.com (Mahesh J Salgaonkar)
Date: Thu, 16 Feb 2012 16:45:08 +0530
Subject: [RFC PATCH v7 08/10] fadump: Invalidate registration and release
 reserved memory for general use.
In-Reply-To: <20120216111050.4733.38034.stgit@mars>
References: <20120216111050.4733.38034.stgit@mars>
Message-ID: <20120216111507.4733.83863.stgit@mars>

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

This patch introduces an sysfs interface '/sys/kernel/fadump_release_mem' to
invalidate the last fadump registration, invalidate '/proc/vmcore', release
the reserved memory for general use and re-register for future kernel dump.
Once the dump is copied to the disk, unlike phyp dump, the userspace tool
can release all the memory reserved for dump with one single operation of
echo 1 to '/sys/kernel/fadump_release_mem'.

Release the reserved memory region excluding the size of the memory required
for future kernel dump registration. And therefore, unlike kdump, Fadump
doesn't need a 2nd reboot to get back the system to the production
configuration.

Signed-off-by: Mahesh Salgaonkar <mahesh at linux.vnet.ibm.com>
---
 arch/powerpc/include/asm/fadump.h |    3 +
 arch/powerpc/kernel/fadump.c      |  158 ++++++++++++++++++++++++++++++++++++-
 2 files changed, 157 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/fadump.h b/arch/powerpc/include/asm/fadump.h
index 6768195..88dbf96 100644
--- a/arch/powerpc/include/asm/fadump.h
+++ b/arch/powerpc/include/asm/fadump.h
@@ -208,6 +208,9 @@ extern int fadump_reserve_mem(void);
 extern int setup_fadump(void);
 extern int is_fadump_active(void);
 extern void crash_fadump(struct pt_regs *, const char *);
+extern void fadump_cleanup(void);
+
+extern void vmcore_cleanup(void);
 #else	/* CONFIG_FA_DUMP */
 static inline int is_fadump_active(void) { return 0; }
 static inline void crash_fadump(struct pt_regs *regs, const char *str) { }
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 5689954..8874d6b 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -33,6 +33,8 @@
 #include <linux/debugfs.h>
 #include <linux/seq_file.h>
 #include <linux/crash_dump.h>
+#include <linux/kobject.h>
+#include <linux/sysfs.h>
 
 #include <asm/page.h>
 #include <asm/prom.h>
@@ -984,6 +986,132 @@ static int fadump_unregister_dump(struct fadump_mem_struct *fdm)
 	return 0;
 }
 
+static int fadump_invalidate_dump(struct fadump_mem_struct *fdm)
+{
+	int rc = 0;
+	unsigned int wait_time;
+
+	pr_debug("Invalidating firmware-assisted dump registration\n");
+
+	/* TODO: Add upper time limit for the delay */
+	do {
+		rc = rtas_call(fw_dump.ibm_configure_kernel_dump, 3, 1, NULL,
+			FADUMP_INVALIDATE, fdm,
+			sizeof(struct fadump_mem_struct));
+
+		wait_time = rtas_busy_delay_time(rc);
+		if (wait_time)
+			mdelay(wait_time);
+	} while (wait_time);
+
+	if (rc) {
+		printk(KERN_ERR "Failed to invalidate firmware-assisted dump "
+			"rgistration. unexpected error(%d).\n", rc);
+		return rc;
+	}
+	fw_dump.dump_active = 0;
+	fdm_active = NULL;
+	return 0;
+}
+
+void fadump_cleanup(void)
+{
+	/* Invalidate the registration only if dump is active. */
+	if (fw_dump.dump_active) {
+		init_fadump_mem_struct(&fdm,
+			fdm_active->cpu_state_data.destination_address);
+		fadump_invalidate_dump(&fdm);
+	}
+}
+
+/*
+ * Release the memory that was reserved in early boot to preserve the memory
+ * contents. The released memory will be available for general use.
+ */
+static void fadump_release_memory(unsigned long begin, unsigned long end)
+{
+	unsigned long addr;
+	unsigned long ra_start, ra_end;
+
+	ra_start = fw_dump.reserve_dump_area_start;
+	ra_end = ra_start + fw_dump.reserve_dump_area_size;
+
+	for (addr = begin; addr < end; addr += PAGE_SIZE) {
+		/*
+		 * exclude the dump reserve area. Will reuse it for next
+		 * fadump registration.
+		 */
+		if (addr <= ra_end && ((addr + PAGE_SIZE) > ra_start))
+			continue;
+
+		ClearPageReserved(pfn_to_page(addr >> PAGE_SHIFT));
+		init_page_count(pfn_to_page(addr >> PAGE_SHIFT));
+		free_page((unsigned long)__va(addr));
+		totalram_pages++;
+	}
+}
+
+static void fadump_invalidate_release_mem(void)
+{
+	unsigned long reserved_area_start, reserved_area_end;
+	unsigned long destination_address;
+
+	mutex_lock(&fadump_mutex);
+	if (!fw_dump.dump_active) {
+		mutex_unlock(&fadump_mutex);
+		return;
+	}
+
+	destination_address = fdm_active->cpu_state_data.destination_address;
+	fadump_cleanup();
+	mutex_unlock(&fadump_mutex);
+
+	/*
+	 * Save the current reserved memory bounds we will require them
+	 * later for releasing the memory for general use.
+	 */
+	reserved_area_start = fw_dump.reserve_dump_area_start;
+	reserved_area_end = reserved_area_start +
+			fw_dump.reserve_dump_area_size;
+	/*
+	 * Setup reserve_dump_area_start and its size so that we can
+	 * reuse this reserved memory for Re-registration.
+	 */
+	fw_dump.reserve_dump_area_start = destination_address;
+	fw_dump.reserve_dump_area_size = get_fadump_area_size();
+
+	fadump_release_memory(reserved_area_start, reserved_area_end);
+	if (fw_dump.cpu_notes_buf) {
+		fadump_cpu_notes_buf_free(
+				(unsigned long)__va(fw_dump.cpu_notes_buf),
+				fw_dump.cpu_notes_buf_size);
+		fw_dump.cpu_notes_buf = 0;
+		fw_dump.cpu_notes_buf_size = 0;
+	}
+	/* Initialize the kernel dump memory structure for FAD registration. */
+	init_fadump_mem_struct(&fdm, fw_dump.reserve_dump_area_start);
+}
+
+static ssize_t fadump_release_memory_store(struct kobject *kobj,
+					struct kobj_attribute *attr,
+					const char *buf, size_t count)
+{
+	if (!fw_dump.dump_active)
+		return -EPERM;
+
+	if (buf[0] == '1') {
+		/*
+		 * Take away the '/proc/vmcore'. We are releasing the dump
+		 * memory, hence it will not be valid anymore.
+		 */
+		vmcore_cleanup();
+		fadump_invalidate_release_mem();
+
+	} else
+		return -EINVAL;
+	return count;
+}
+
 static ssize_t fadump_enabled_show(struct kobject *kobj,
 					struct kobj_attribute *attr,
 					char *buf)
@@ -1043,10 +1171,13 @@ static int fadump_region_show(struct seq_file *m, void *private)
 	if (!fw_dump.fadump_enabled)
 		return 0;
 
+	mutex_lock(&fadump_mutex);
 	if (fdm_active)
 		fdm_ptr = fdm_active;
-	else
+	else {
+		mutex_unlock(&fadump_mutex);
 		fdm_ptr = &fdm;
+	}
 
 	seq_printf(m,
 			"CPU : [%#016llx-%#016llx] %#llx bytes, "
@@ -1076,7 +1207,7 @@ static int fadump_region_show(struct seq_file *m, void *private)
 	if (!fdm_active ||
 		(fw_dump.reserve_dump_area_start ==
 		fdm_ptr->cpu_state_data.destination_address))
-		return 0;
+		goto out;
 
 	/* Dump is active. Show reserved memory region. */
 	seq_printf(m,
@@ -1088,9 +1219,15 @@ static int fadump_region_show(struct seq_file *m, void *private)
 			fw_dump.reserve_dump_area_start,
 			fdm_ptr->cpu_state_data.destination_address -
 			fw_dump.reserve_dump_area_start);
+out:
+	if (fdm_active)
+		mutex_unlock(&fadump_mutex);
 	return 0;
 }
 
+static struct kobj_attribute fadump_release_attr = __ATTR(fadump_release_mem,
+						0200, NULL,
+						fadump_release_memory_store);
 static struct kobj_attribute fadump_attr = __ATTR(fadump_enabled,
 						0444, fadump_enabled_show,
 						NULL);
@@ -1131,6 +1268,13 @@ static void fadump_init_files(void)
 	if (!debugfs_file)
 		printk(KERN_ERR "fadump: unable to create debugfs file"
 				" fadump_region\n");
+
+	if (fw_dump.dump_active) {
+		rc = sysfs_create_file(kernel_kobj, &fadump_release_attr.attr);
+		if (rc)
+			printk(KERN_ERR "fadump: unable to create sysfs file"
+				" fadump_release_mem (%d)\n", rc);
+	}
 	return;
 }
 
@@ -1150,8 +1294,14 @@ int __init setup_fadump(void)
 	 * If dump data is available then see if it is valid and prepare for
 	 * saving it to the disk.
 	 */
-	if (fw_dump.dump_active)
-		process_fadump(fdm_active);
+	if (fw_dump.dump_active) {
+		/*
+		 * if dump process fails then invalidate the registration
+		 * and release memory before proceeding for re-registration.
+		 */
+		if (process_fadump(fdm_active) < 0)
+			fadump_invalidate_release_mem();
+	}
 	/* Initialize the kernel dump memory structure for FAD registration. */
 	else if (fw_dump.reserve_dump_area_size)
 		init_fadump_mem_struct(&fdm, fw_dump.reserve_dump_area_start);



From mahesh at linux.vnet.ibm.com  Thu Feb 16 06:14:45 2012
From: mahesh at linux.vnet.ibm.com (Mahesh J Salgaonkar)
Date: Thu, 16 Feb 2012 16:44:45 +0530
Subject: [RFC PATCH v7 05/10] fadump: Convert firmware-assisted cpu state dump
 data into elf notes.
In-Reply-To: <20120216111050.4733.38034.stgit@mars>
References: <20120216111050.4733.38034.stgit@mars>
Message-ID: <20120216111444.4733.10759.stgit@mars>

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

When registered for firmware assisted dump on powerpc, firmware preserves
the registers for the active CPUs during a system crash. This patch reads
the cpu register data stored in Firmware-assisted dump format (except for
crashing cpu) and converts it into elf notes and updates the PT_NOTE program
header accordingly. The exact register state for crashing cpu is saved to
fadump crash info structure in scratch area during crash_fadump() and read
during second kernel boot.

Signed-off-by: Mahesh Salgaonkar <mahesh at linux.vnet.ibm.com>
---
 arch/powerpc/include/asm/fadump.h  |   44 +++++
 arch/powerpc/kernel/fadump.c       |  314 ++++++++++++++++++++++++++++++++++++
 arch/powerpc/kernel/setup-common.c |    6 +
 arch/powerpc/kernel/traps.c        |    3 
 4 files changed, 365 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/fadump.h b/arch/powerpc/include/asm/fadump.h
index 9e172a5..6768195 100644
--- a/arch/powerpc/include/asm/fadump.h
+++ b/arch/powerpc/include/asm/fadump.h
@@ -65,6 +65,18 @@
 /* Dump status flag */
 #define FADUMP_ERROR_FLAG	0x2000
 
+#define FADUMP_CPU_ID_MASK	((1UL << 32) - 1)
+
+#define CPU_UNKNOWN		(~((u32)0))
+
+/* Utility macros */
+#define SKIP_TO_NEXT_CPU(reg_entry)			\
+({							\
+	while (reg_entry->reg_id != REG_ID("CPUEND"))	\
+		reg_entry++;				\
+	reg_entry++;					\
+})
+
 /* Kernel Dump section info */
 struct fadump_section {
 	u32	request_flag;
@@ -119,6 +131,9 @@ struct fw_dump {
 	unsigned long	reserve_bootvar;
 
 	unsigned long	fadumphdr_addr;
+	unsigned long	cpu_notes_buf;
+	unsigned long	cpu_notes_buf_size;
+
 	int		ibm_configure_kernel_dump;
 
 	unsigned long	fadump_enabled:1;
@@ -143,13 +158,40 @@ static inline u64 str_to_u64(const char *str)
 	return val;
 }
 #define STR_TO_HEX(x)	str_to_u64(x)
+#define REG_ID(x)	str_to_u64(x)
 
 #define FADUMP_CRASH_INFO_MAGIC		STR_TO_HEX("FADMPINF")
+#define REGSAVE_AREA_MAGIC		STR_TO_HEX("REGSAVE")
+
+/* The firmware-assisted dump format.
+ *
+ * The register save area is an area in the partition's memory used to preserve
+ * the register contents (CPU state data) for the active CPUs during a firmware
+ * assisted dump. The dump format contains register save area header followed
+ * by register entries. Each list of registers for a CPU starts with
+ * "CPUSTRT" and ends with "CPUEND".
+ */
+
+/* Register save area header. */
+struct fadump_reg_save_area_header {
+	u64		magic_number;
+	u32		version;
+	u32		num_cpu_offset;
+};
+
+/* Register entry. */
+struct fadump_reg_entry {
+	u64		reg_id;
+	u64		reg_value;
+};
 
 /* fadump crash info structure */
 struct fadump_crash_info_header {
 	u64		magic_number;
 	u64		elfcorehdr_addr;
+	u32		crashing_cpu;
+	struct pt_regs	regs;
+	struct cpumask	cpu_online_mask;
 };
 
 /* Crash memory ranges */
@@ -165,7 +207,9 @@ extern int early_init_dt_scan_fw_dump(unsigned long node,
 extern int fadump_reserve_mem(void);
 extern int setup_fadump(void);
 extern int is_fadump_active(void);
+extern void crash_fadump(struct pt_regs *, const char *);
 #else	/* CONFIG_FA_DUMP */
 static inline int is_fadump_active(void) { return 0; }
+static inline void crash_fadump(struct pt_regs *regs, const char *str) { }
 #endif
 #endif
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index f85a63f..cab56e7 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -240,6 +240,7 @@ static unsigned long get_fadump_area_size(void)
 	size += fw_dump.boot_memory_size;
 	size += sizeof(struct fadump_crash_info_header);
 	size += sizeof(struct elfhdr); /* ELF core header.*/
+	size += sizeof(struct elf_phdr); /* place holder for cpu notes */
 	/* Program headers for crash memory regions. */
 	size += sizeof(struct elf_phdr) * (memblock_num_regions(memory) + 2);
 
@@ -393,6 +394,285 @@ static void register_fw_dump(struct fadump_mem_struct *fdm)
 	}
 }
 
+void crash_fadump(struct pt_regs *regs, const char *str)
+{
+	struct fadump_crash_info_header *fdh = NULL;
+
+	if (!fw_dump.dump_registered || !fw_dump.fadumphdr_addr)
+		return;
+
+	fdh = __va(fw_dump.fadumphdr_addr);
+	crashing_cpu = smp_processor_id();
+	fdh->crashing_cpu = crashing_cpu;
+	crash_save_vmcoreinfo();
+
+	if (regs)
+		fdh->regs = *regs;
+	else
+		ppc_save_regs(&fdh->regs);
+
+	fdh->cpu_online_mask = *cpu_online_mask;
+
+	/* Call ibm,os-term rtas call to trigger firmware assisted dump */
+	rtas_os_term((char *)str);
+}
+
+#define GPR_MASK	0xffffff0000000000
+static inline int fadump_gpr_index(u64 id)
+{
+	int i = -1;
+	char str[3];
+
+	if ((id & GPR_MASK) == REG_ID("GPR")) {
+		/* get the digits at the end */
+		id &= ~GPR_MASK;
+		id >>= 24;
+		str[2] = '\0';
+		str[1] = id & 0xff;
+		str[0] = (id >> 8) & 0xff;
+		sscanf(str, "%d", &i);
+		if (i > 31)
+			i = -1;
+	}
+	return i;
+}
+
+static inline void fadump_set_regval(struct pt_regs *regs, u64 reg_id,
+								u64 reg_val)
+{
+	int i;
+
+	i = fadump_gpr_index(reg_id);
+	if (i >= 0)
+		regs->gpr[i] = (unsigned long)reg_val;
+	else if (reg_id == REG_ID("NIA"))
+		regs->nip = (unsigned long)reg_val;
+	else if (reg_id == REG_ID("MSR"))
+		regs->msr = (unsigned long)reg_val;
+	else if (reg_id == REG_ID("CTR"))
+		regs->ctr = (unsigned long)reg_val;
+	else if (reg_id == REG_ID("LR"))
+		regs->link = (unsigned long)reg_val;
+	else if (reg_id == REG_ID("XER"))
+		regs->xer = (unsigned long)reg_val;
+	else if (reg_id == REG_ID("CR"))
+		regs->ccr = (unsigned long)reg_val;
+	else if (reg_id == REG_ID("DAR"))
+		regs->dar = (unsigned long)reg_val;
+	else if (reg_id == REG_ID("DSISR"))
+		regs->dsisr = (unsigned long)reg_val;
+}
+
+static struct fadump_reg_entry*
+fadump_read_registers(struct fadump_reg_entry *reg_entry, struct pt_regs *regs)
+{
+	memset(regs, 0, sizeof(struct pt_regs));
+
+	while (reg_entry->reg_id != REG_ID("CPUEND")) {
+		fadump_set_regval(regs, reg_entry->reg_id,
+					reg_entry->reg_value);
+		reg_entry++;
+	}
+	reg_entry++;
+	return reg_entry;
+}
+
+static u32 *fadump_append_elf_note(u32 *buf, char *name, unsigned type,
+						void *data, size_t data_len)
+{
+	struct elf_note note;
+
+	note.n_namesz = strlen(name) + 1;
+	note.n_descsz = data_len;
+	note.n_type   = type;
+	memcpy(buf, &note, sizeof(note));
+	buf += (sizeof(note) + 3)/4;
+	memcpy(buf, name, note.n_namesz);
+	buf += (note.n_namesz + 3)/4;
+	memcpy(buf, data, note.n_descsz);
+	buf += (note.n_descsz + 3)/4;
+
+	return buf;
+}
+
+static void fadump_final_note(u32 *buf)
+{
+	struct elf_note note;
+
+	note.n_namesz = 0;
+	note.n_descsz = 0;
+	note.n_type   = 0;
+	memcpy(buf, &note, sizeof(note));
+}
+
+static u32 *fadump_regs_to_elf_notes(u32 *buf, struct pt_regs *regs)
+{
+	struct elf_prstatus prstatus;
+
+	memset(&prstatus, 0, sizeof(prstatus));
+	/*
+	 * FIXME: How do i get PID? Do I really need it?
+	 * prstatus.pr_pid = ????
+	 */
+	elf_core_copy_kernel_regs(&prstatus.pr_reg, regs);
+	buf = fadump_append_elf_note(buf, KEXEC_CORE_NOTE_NAME, NT_PRSTATUS,
+				&prstatus, sizeof(prstatus));
+	return buf;
+}
+
+static void fadump_update_elfcore_header(char *bufp)
+{
+	struct elfhdr *elf;
+	struct elf_phdr *phdr;
+
+	elf = (struct elfhdr *)bufp;
+	bufp += sizeof(struct elfhdr);
+
+	/* First note is a place holder for cpu notes info. */
+	phdr = (struct elf_phdr *)bufp;
+
+	if (phdr->p_type == PT_NOTE) {
+		phdr->p_paddr = fw_dump.cpu_notes_buf;
+		phdr->p_offset	= phdr->p_paddr;
+		phdr->p_filesz	= fw_dump.cpu_notes_buf_size;
+		phdr->p_memsz = fw_dump.cpu_notes_buf_size;
+	}
+	return;
+}
+
+static void *fadump_cpu_notes_buf_alloc(unsigned long size)
+{
+	void *vaddr;
+	struct page *page;
+	unsigned long order, count, i;
+
+	order = get_order(size);
+	vaddr = (void *)__get_free_pages(GFP_KERNEL|__GFP_ZERO, order);
+	if (!vaddr)
+		return NULL;
+
+	count = 1 << order;
+	page = virt_to_page(vaddr);
+	for (i = 0; i < count; i++)
+		SetPageReserved(page + i);
+	return vaddr;
+}
+
+static void fadump_cpu_notes_buf_free(unsigned long vaddr, unsigned long size)
+{
+	struct page *page;
+	unsigned long order, count, i;
+
+	order = get_order(size);
+	count = 1 << order;
+	page = virt_to_page(vaddr);
+	for (i = 0; i < count; i++)
+		ClearPageReserved(page + i);
+	__free_pages(page, order);
+}
+
+/*
+ * Read CPU state dump data and convert it into ELF notes.
+ * The CPU dump starts with magic number "REGSAVE". NumCpusOffset should be
+ * used to access the data to allow for additional fields to be added without
+ * affecting compatibility. Each list of registers for a CPU starts with
+ * "CPUSTRT" and ends with "CPUEND". Each register entry is of 16 bytes,
+ * 8 Byte ASCII identifier and 8 Byte register value. The register entry
+ * with identifier "CPUSTRT" and "CPUEND" contains 4 byte cpu id as part
+ * of register value. For more details refer to PAPR document.
+ *
+ * Only for the crashing cpu we ignore the CPU dump data and get exact
+ * state from fadump crash info structure populated by first kernel at the
+ * time of crash.
+ */
+static int __init fadump_build_cpu_notes(const struct fadump_mem_struct *fdm)
+{
+	struct fadump_reg_save_area_header *reg_header;
+	struct fadump_reg_entry *reg_entry;
+	struct fadump_crash_info_header *fdh = NULL;
+	void *vaddr;
+	unsigned long addr;
+	u32 num_cpus, *note_buf;
+	struct pt_regs regs;
+	int i, rc = 0, cpu = 0;
+
+	if (!fdm->cpu_state_data.bytes_dumped)
+		return -EINVAL;
+
+	addr = fdm->cpu_state_data.destination_address;
+	vaddr = __va(addr);
+
+	reg_header = vaddr;
+	if (reg_header->magic_number != REGSAVE_AREA_MAGIC) {
+		printk(KERN_ERR "Unable to read register save area.\n");
+		return -ENOENT;
+	}
+	pr_debug("--------CPU State Data------------\n");
+	pr_debug("Magic Number: %llx\n", reg_header->magic_number);
+	pr_debug("NumCpuOffset: %x\n", reg_header->num_cpu_offset);
+
+	vaddr += reg_header->num_cpu_offset;
+	num_cpus = *((u32 *)(vaddr));
+	pr_debug("NumCpus     : %u\n", num_cpus);
+	vaddr += sizeof(u32);
+	reg_entry = (struct fadump_reg_entry *)vaddr;
+
+	/* Allocate buffer to hold cpu crash notes. */
+	fw_dump.cpu_notes_buf_size = num_cpus * sizeof(note_buf_t);
+	fw_dump.cpu_notes_buf_size = PAGE_ALIGN(fw_dump.cpu_notes_buf_size);
+	note_buf = fadump_cpu_notes_buf_alloc(fw_dump.cpu_notes_buf_size);
+	if (!note_buf) {
+		printk(KERN_ERR "Failed to allocate 0x%lx bytes for "
+			"cpu notes buffer\n", fw_dump.cpu_notes_buf_size);
+		return -ENOMEM;
+	}
+	fw_dump.cpu_notes_buf = __pa(note_buf);
+
+	pr_debug("Allocated buffer for cpu notes of size %ld at %p\n",
+			(num_cpus * sizeof(note_buf_t)), note_buf);
+
+	if (fw_dump.fadumphdr_addr)
+		fdh = __va(fw_dump.fadumphdr_addr);
+
+	for (i = 0; i < num_cpus; i++) {
+		if (reg_entry->reg_id != REG_ID("CPUSTRT")) {
+			printk(KERN_ERR "Unable to read CPU state data\n");
+			rc = -ENOENT;
+			goto error_out;
+		}
+		/* Lower 4 bytes of reg_value contains logical cpu id */
+		cpu = reg_entry->reg_value & FADUMP_CPU_ID_MASK;
+		if (!cpumask_test_cpu(cpu, &fdh->cpu_online_mask)) {
+			SKIP_TO_NEXT_CPU(reg_entry);
+			continue;
+		}
+		pr_debug("Reading register data for cpu %d...\n", cpu);
+		if (fdh && fdh->crashing_cpu == cpu) {
+			regs = fdh->regs;
+			note_buf = fadump_regs_to_elf_notes(note_buf, &regs);
+			SKIP_TO_NEXT_CPU(reg_entry);
+		} else {
+			reg_entry++;
+			reg_entry = fadump_read_registers(reg_entry, &regs);
+			note_buf = fadump_regs_to_elf_notes(note_buf, &regs);
+		}
+	}
+	fadump_final_note(note_buf);
+
+	pr_debug("Updating elfcore header (%llx) with cpu notes\n",
+							fdh->elfcorehdr_addr);
+	fadump_update_elfcore_header((char *)__va(fdh->elfcorehdr_addr));
+	return 0;
+
+error_out:
+	fadump_cpu_notes_buf_free((unsigned long)__va(fw_dump.cpu_notes_buf),
+					fw_dump.cpu_notes_buf_size);
+	fw_dump.cpu_notes_buf = 0;
+	fw_dump.cpu_notes_buf_size = 0;
+	return rc;
+
+}
+
 /*
  * Validate and process the dump data stored by firmware before exporting
  * it through '/proc/vmcore'.
@@ -400,18 +680,21 @@ static void register_fw_dump(struct fadump_mem_struct *fdm)
 static int __init process_fadump(const struct fadump_mem_struct *fdm_active)
 {
 	struct fadump_crash_info_header *fdh;
+	int rc = 0;
 
 	if (!fdm_active || !fw_dump.fadumphdr_addr)
 		return -EINVAL;
 
 	/* Check if the dump data is valid. */
 	if ((fdm_active->header.dump_status_flag == FADUMP_ERROR_FLAG) ||
+			(fdm_active->cpu_state_data.error_flags != 0) ||
 			(fdm_active->rmr_region.error_flags != 0)) {
 		printk(KERN_ERR "Dump taken by platform is not valid\n");
 		return -EINVAL;
 	}
-	if (fdm_active->rmr_region.bytes_dumped !=
-			fdm_active->rmr_region.source_len) {
+	if ((fdm_active->rmr_region.bytes_dumped !=
+			fdm_active->rmr_region.source_len) ||
+			!fdm_active->cpu_state_data.bytes_dumped) {
 		printk(KERN_ERR "Dump taken by platform is incomplete\n");
 		return -EINVAL;
 	}
@@ -423,6 +706,10 @@ static int __init process_fadump(const struct fadump_mem_struct *fdm_active)
 		return -EINVAL;
 	}
 
+	rc = fadump_build_cpu_notes(fdm_active);
+	if (rc)
+		return rc;
+
 	/*
 	 * We are done validating dump info and elfcore header is now ready
 	 * to be exported. set elfcorehdr_addr so that vmcore module will
@@ -537,6 +824,27 @@ static int fadump_create_elfcore_headers(char *bufp)
 	elf = (struct elfhdr *)bufp;
 	bufp += sizeof(struct elfhdr);
 
+	/*
+	 * setup ELF PT_NOTE, place holder for cpu notes info. The notes info
+	 * will be populated during second kernel boot after crash. Hence
+	 * this PT_NOTE will always be the first elf note.
+	 *
+	 * NOTE: Any new ELF note addition should be placed after this note.
+	 */
+	phdr = (struct elf_phdr *)bufp;
+	bufp += sizeof(struct elf_phdr);
+	phdr->p_type = PT_NOTE;
+	phdr->p_flags = 0;
+	phdr->p_vaddr = 0;
+	phdr->p_align = 0;
+
+	phdr->p_offset = 0;
+	phdr->p_paddr = 0;
+	phdr->p_filesz = 0;
+	phdr->p_memsz = 0;
+
+	(elf->e_phnum)++;
+
 	/* setup PT_LOAD sections. */
 
 	for (i = 0; i < crash_mem_ranges; i++) {
@@ -588,6 +896,8 @@ static unsigned long init_fadump_header(unsigned long addr)
 	memset(fdh, 0, sizeof(struct fadump_crash_info_header));
 	fdh->magic_number = FADUMP_CRASH_INFO_MAGIC;
 	fdh->elfcorehdr_addr = addr;
+	/* We will set the crashing cpu id in crash_fadump() during crash. */
+	fdh->crashing_cpu = CPU_UNKNOWN;
 
 	return addr;
 }
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 77bb77d..4e62a56 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -61,6 +61,7 @@
 #include <asm/xmon.h>
 #include <asm/cputhreads.h>
 #include <mm/mmu_decl.h>
+#include <asm/fadump.h>
 
 #include "setup.h"
 
@@ -639,6 +640,11 @@ EXPORT_SYMBOL(check_legacy_ioport);
 static int ppc_panic_event(struct notifier_block *this,
                              unsigned long event, void *ptr)
 {
+	/*
+	 * If firmware-assisted dump has been registered then trigger
+	 * firmware-assisted dump and let firmware handle everything else.
+	 */
+	crash_fadump(NULL, ptr);
 	ppc_md.panic(ptr);  /* May not return */
 	return NOTIFY_DONE;
 }
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index c091527..5d40e59 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -57,6 +57,7 @@
 #include <asm/kexec.h>
 #include <asm/ppc-opcode.h>
 #include <asm/rio.h>
+#include <asm/fadump.h>
 
 #if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC)
 int (*__debugger)(struct pt_regs *regs) __read_mostly;
@@ -145,6 +146,8 @@ static void __kprobes oops_end(unsigned long flags, struct pt_regs *regs,
 		arch_spin_unlock(&die_lock);
 	raw_local_irq_restore(flags);
 
+	crash_fadump(regs, "die oops");
+
 	/*
 	 * A system reset (0x100) is a request to dump, so we always send
 	 * it through the crashdump code.



From mahesh at linux.vnet.ibm.com  Thu Feb 16 06:15:15 2012
From: mahesh at linux.vnet.ibm.com (Mahesh J Salgaonkar)
Date: Thu, 16 Feb 2012 16:45:15 +0530
Subject: [RFC PATCH v7 09/10] fadump: Invalidate the fadump registration
 during machine shutdown.
In-Reply-To: <20120216111050.4733.38034.stgit@mars>
References: <20120216111050.4733.38034.stgit@mars>
Message-ID: <20120216111515.4733.42652.stgit@mars>

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

If dump is active during system reboot, shutdown or halt then invalidate
the fadump registration as it does not get invalidated automatically.

Signed-off-by: Mahesh Salgaonkar <mahesh at linux.vnet.ibm.com>
---
 arch/powerpc/kernel/setup-common.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 4e62a56..b0ebdea 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -110,6 +110,14 @@ EXPORT_SYMBOL(ppc_do_canonicalize_irqs);
 /* also used by kexec */
 void machine_shutdown(void)
 {
+#ifdef CONFIG_FA_DUMP
+	/*
+	 * if fadump is active, cleanup the fadump registration before we
+	 * shutdown.
+	 */
+	fadump_cleanup();
+#endif
+
 	if (ppc_md.machine_shutdown)
 		ppc_md.machine_shutdown();
 }



From mahesh at linux.vnet.ibm.com  Thu Feb 16 06:15:23 2012
From: mahesh at linux.vnet.ibm.com (Mahesh J Salgaonkar)
Date: Thu, 16 Feb 2012 16:45:23 +0530
Subject: [RFC PATCH v7 10/10] fadump: Remove the phyp assisted dump code.
In-Reply-To: <20120216111050.4733.38034.stgit@mars>
References: <20120216111050.4733.38034.stgit@mars>
Message-ID: <20120216111522.4733.86427.stgit@mars>

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

Remove the phyp assisted dump implementation which is not is use.

Signed-off-by: Mahesh Salgaonkar <mahesh at linux.vnet.ibm.com>
---
 Documentation/powerpc/phyp-assisted-dump.txt |  127 ------
 arch/powerpc/Kconfig                         |   10 -
 arch/powerpc/include/asm/phyp_dump.h         |   47 --
 arch/powerpc/kernel/prom.c                   |   87 ----
 arch/powerpc/platforms/pseries/Makefile      |    1 
 arch/powerpc/platforms/pseries/phyp_dump.c   |  513 --------------------------
 6 files changed, 0 insertions(+), 785 deletions(-)
 delete mode 100644 Documentation/powerpc/phyp-assisted-dump.txt
 delete mode 100644 arch/powerpc/include/asm/phyp_dump.h
 delete mode 100644 arch/powerpc/platforms/pseries/phyp_dump.c

diff --git a/Documentation/powerpc/phyp-assisted-dump.txt b/Documentation/powerpc/phyp-assisted-dump.txt
deleted file mode 100644
index ad34020..0000000
--- a/Documentation/powerpc/phyp-assisted-dump.txt
+++ /dev/null
@@ -1,127 +0,0 @@
-
-                   Hypervisor-Assisted Dump
-                   ------------------------
-                       November 2007
-
-The goal of hypervisor-assisted dump is to enable the dump of
-a crashed system, and to do so from a fully-reset system, and
-to minimize the total elapsed time until the system is back
-in production use.
-
-As compared to kdump or other strategies, hypervisor-assisted
-dump offers several strong, practical advantages:
-
--- Unlike kdump, the system has been reset, and loaded
-   with a fresh copy of the kernel.  In particular,
-   PCI and I/O devices have been reinitialized and are
-   in a clean, consistent state.
--- As the dump is performed, the dumped memory becomes
-   immediately available to the system for normal use.
--- After the dump is completed, no further reboots are
-   required; the system will be fully usable, and running
-   in its normal, production mode on its normal kernel.
-
-The above can only be accomplished by coordination with,
-and assistance from the hypervisor. The procedure is
-as follows:
-
--- When a system crashes, the hypervisor will save
-   the low 256MB of RAM to a previously registered
-   save region. It will also save system state, system
-   registers, and hardware PTE's.
-
--- After the low 256MB area has been saved, the
-   hypervisor will reset PCI and other hardware state.
-   It will *not* clear RAM. It will then launch the
-   bootloader, as normal.
-
--- The freshly booted kernel will notice that there
-   is a new node (ibm,dump-kernel) in the device tree,
-   indicating that there is crash data available from
-   a previous boot. It will boot into only 256MB of RAM,
-   reserving the rest of system memory.
-
--- Userspace tools will parse /sys/kernel/release_region
-   and read /proc/vmcore to obtain the contents of memory,
-   which holds the previous crashed kernel. The userspace
-   tools may copy this info to disk, or network, nas, san,
-   iscsi, etc. as desired.
-
-   For Example: the values in /sys/kernel/release-region
-   would look something like this (address-range pairs).
-   CPU:0x177fee000-0x10000: HPTE:0x177ffe020-0x1000: /
-   DUMP:0x177fff020-0x10000000, 0x10000000-0x16F1D370A
-
--- As the userspace tools complete saving a portion of
-   dump, they echo an offset and size to
-   /sys/kernel/release_region to release the reserved
-   memory back to general use.
-
-   An example of this is:
-     "echo 0x40000000 0x10000000 > /sys/kernel/release_region"
-   which will release 256MB at the 1GB boundary.
-
-Please note that the hypervisor-assisted dump feature
-is only available on Power6-based systems with recent
-firmware versions.
-
-Implementation details:
-----------------------
-
-During boot, a check is made to see if firmware supports
-this feature on this particular machine. If it does, then
-we check to see if a active dump is waiting for us. If yes
-then everything but 256 MB of RAM is reserved during early
-boot. This area is released once we collect a dump from user
-land scripts that are run. If there is dump data, then
-the /sys/kernel/release_region file is created, and
-the reserved memory is held.
-
-If there is no waiting dump data, then only the highest
-256MB of the ram is reserved as a scratch area. This area
-is *not* released: this region will be kept permanently
-reserved, so that it can act as a receptacle for a copy
-of the low 256MB in the case a crash does occur. See,
-however, "open issues" below, as to whether
-such a reserved region is really needed.
-
-Currently the dump will be copied from /proc/vmcore to a
-a new file upon user intervention. The starting address
-to be read and the range for each data point in provided
-in /sys/kernel/release_region.
-
-The tools to examine the dump will be same as the ones
-used for kdump.
-
-General notes:
---------------
-Security: please note that there are potential security issues
-with any sort of dump mechanism. In particular, plaintext
-(unencrypted) data, and possibly passwords, may be present in
-the dump data. Userspace tools must take adequate precautions to
-preserve security.
-
-Open issues/ToDo:
-------------
- o The various code paths that tell the hypervisor that a crash
-   occurred, vs. it simply being a normal reboot, should be
-   reviewed, and possibly clarified/fixed.
-
- o Instead of using /sys/kernel, should there be a /sys/dump
-   instead? There is a dump_subsys being created by the s390 code,
-   perhaps the pseries code should use a similar layout as well.
-
- o Is reserving a 256MB region really required? The goal of
-   reserving a 256MB scratch area is to make sure that no
-   important crash data is clobbered when the hypervisor
-   save low mem to the scratch area. But, if one could assure
-   that nothing important is located in some 256MB area, then
-   it would not need to be reserved. Something that can be
-   improved in subsequent versions.
-
- o Still working the kdump team to integrate this with kdump,
-   some work remains but this would not affect the current
-   patches.
-
- o Still need to write a shell script, to copy the dump away.
-   Currently I am parsing it manually.
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index afa4dab..c713111 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -376,16 +376,6 @@ config CRASH_DUMP
 	  The same kernel binary can be used as production kernel and dump
 	  capture kernel.
 
-config PHYP_DUMP
-	bool "Hypervisor-assisted dump (EXPERIMENTAL)"
-	depends on PPC_PSERIES && EXPERIMENTAL
-	help
-	  Hypervisor-assisted dump is meant to be a kdump replacement
-	  offering robustness and speed not possible without system
-	  hypervisor assistance.
-
-	  If unsure, say "N"
-
 config FA_DUMP
 	bool "Firmware-assisted dump"
 	depends on PPC64 && PPC_RTAS && CRASH_DUMP
diff --git a/arch/powerpc/include/asm/phyp_dump.h b/arch/powerpc/include/asm/phyp_dump.h
deleted file mode 100644
index fa74c6c..0000000
--- a/arch/powerpc/include/asm/phyp_dump.h
+++ /dev/null
@@ -1,47 +0,0 @@
-/*
- * Hypervisor-assisted dump
- *
- * Linas Vepstas, Manish Ahuja 2008
- * Copyright 2008 IBM Corp.
- *
- *      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; either version
- *      2 of the License, or (at your option) any later version.
- */
-
-#ifndef _PPC64_PHYP_DUMP_H
-#define _PPC64_PHYP_DUMP_H
-
-#ifdef CONFIG_PHYP_DUMP
-
-/* The RMR region will be saved for later dumping
- * whenever the kernel crashes. Set this to 256MB. */
-#define PHYP_DUMP_RMR_START 0x0
-#define PHYP_DUMP_RMR_END   (1UL<<28)
-
-struct phyp_dump {
-	/* Memory that is reserved during very early boot. */
-	unsigned long init_reserve_start;
-	unsigned long init_reserve_size;
-	/* cmd line options during boot */
-	unsigned long reserve_bootvar;
-	unsigned long phyp_dump_at_boot;
-	/* Check status during boot if dump supported, active & present*/
-	unsigned long phyp_dump_configured;
-	unsigned long phyp_dump_is_active;
-	/* store cpu & hpte size */
-	unsigned long cpu_state_size;
-	unsigned long hpte_region_size;
-	/* previous scratch area values */
-	unsigned long reserved_scratch_addr;
-	unsigned long reserved_scratch_size;
-};
-
-extern struct phyp_dump *phyp_dump_info;
-
-int early_init_dt_scan_phyp_dump(unsigned long node,
-		const char *uname, int depth, void *data);
-
-#endif /* CONFIG_PHYP_DUMP */
-#endif /* _PPC64_PHYP_DUMP_H */
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 70222b3..89e850a 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -52,7 +52,6 @@
 #include <asm/machdep.h>
 #include <asm/pSeries_reconfig.h>
 #include <asm/pci-bridge.h>
-#include <asm/phyp_dump.h>
 #include <asm/kexec.h>
 #include <asm/opal.h>
 #include <asm/fadump.h>
@@ -616,86 +615,6 @@ static void __init early_reserve_mem(void)
 	}
 }
 
-#ifdef CONFIG_PHYP_DUMP
-/**
- * phyp_dump_calculate_reserve_size() - reserve variable boot area 5% or arg
- *
- * Function to find the largest size we need to reserve
- * during early boot process.
- *
- * It either looks for boot param and returns that OR
- * returns larger of 256 or 5% rounded down to multiples of 256MB.
- *
- */
-static inline unsigned long phyp_dump_calculate_reserve_size(void)
-{
-	unsigned long tmp;
-
-	if (phyp_dump_info->reserve_bootvar)
-		return phyp_dump_info->reserve_bootvar;
-
-	/* divide by 20 to get 5% of value */
-	tmp = memblock_end_of_DRAM();
-	do_div(tmp, 20);
-
-	/* round it down in multiples of 256 */
-	tmp = tmp & ~0x0FFFFFFFUL;
-
-	return (tmp > PHYP_DUMP_RMR_END ? tmp : PHYP_DUMP_RMR_END);
-}
-
-/**
- * phyp_dump_reserve_mem() - reserve all not-yet-dumped mmemory
- *
- * This routine may reserve memory regions in the kernel only
- * if the system is supported and a dump was taken in last
- * boot instance or if the hardware is supported and the
- * scratch area needs to be setup. In other instances it returns
- * without reserving anything. The memory in case of dump being
- * active is freed when the dump is collected (by userland tools).
- */
-static void __init phyp_dump_reserve_mem(void)
-{
-	unsigned long base, size;
-	unsigned long variable_reserve_size;
-
-	if (!phyp_dump_info->phyp_dump_configured) {
-		printk(KERN_ERR "Phyp-dump not supported on this hardware\n");
-		return;
-	}
-
-	if (!phyp_dump_info->phyp_dump_at_boot) {
-		printk(KERN_INFO "Phyp-dump disabled at boot time\n");
-		return;
-	}
-
-	variable_reserve_size = phyp_dump_calculate_reserve_size();
-
-	if (phyp_dump_info->phyp_dump_is_active) {
-		/* Reserve *everything* above RMR.Area freed by userland tools*/
-		base = variable_reserve_size;
-		size = memblock_end_of_DRAM() - base;
-
-		/* XXX crashed_ram_end is wrong, since it may be beyond
-		 * the memory_limit, it will need to be adjusted. */
-		memblock_reserve(base, size);
-
-		phyp_dump_info->init_reserve_start = base;
-		phyp_dump_info->init_reserve_size = size;
-	} else {
-		size = phyp_dump_info->cpu_state_size +
-			phyp_dump_info->hpte_region_size +
-			variable_reserve_size;
-		base = memblock_end_of_DRAM() - size;
-		memblock_reserve(base, size);
-		phyp_dump_info->init_reserve_start = base;
-		phyp_dump_info->init_reserve_size = size;
-	}
-}
-#else
-static inline void __init phyp_dump_reserve_mem(void) {}
-#endif /* CONFIG_PHYP_DUMP  && CONFIG_PPC_RTAS */
-
 void __init early_init_devtree(void *params)
 {
 	phys_addr_t limit;
@@ -715,11 +634,6 @@ void __init early_init_devtree(void *params)
 	of_scan_flat_dt(early_init_dt_scan_opal, NULL);
 #endif
 
-#ifdef CONFIG_PHYP_DUMP
-	/* scan tree to see if dump occurred during last boot */
-	of_scan_flat_dt(early_init_dt_scan_phyp_dump, NULL);
-#endif
-
 #ifdef CONFIG_FA_DUMP
 	/* scan tree to see if dump is active during last boot */
 	of_scan_flat_dt(early_init_dt_scan_fw_dump, NULL);
@@ -765,7 +679,6 @@ void __init early_init_devtree(void *params)
 #endif
 		reserve_crashkernel();
 	early_reserve_mem();
-	phyp_dump_reserve_mem();
 
 	/*
 	 * Ensure that total memory size is page-aligned, because otherwise
diff --git a/arch/powerpc/platforms/pseries/Makefile b/arch/powerpc/platforms/pseries/Makefile
index 236db46..67b3e6e 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -18,7 +18,6 @@ obj-$(CONFIG_MEMORY_HOTPLUG)	+= hotplug-memory.o
 obj-$(CONFIG_HVC_CONSOLE)	+= hvconsole.o
 obj-$(CONFIG_HVCS)		+= hvcserver.o
 obj-$(CONFIG_HCALL_STATS)	+= hvCall_inst.o
-obj-$(CONFIG_PHYP_DUMP)		+= phyp_dump.o
 obj-$(CONFIG_CMM)		+= cmm.o
 obj-$(CONFIG_DTL)		+= dtl.o
 obj-$(CONFIG_IO_EVENT_IRQ)	+= io_event_irq.o
diff --git a/arch/powerpc/platforms/pseries/phyp_dump.c b/arch/powerpc/platforms/pseries/phyp_dump.c
deleted file mode 100644
index 6e7742d..0000000
--- a/arch/powerpc/platforms/pseries/phyp_dump.c
+++ /dev/null
@@ -1,513 +0,0 @@
-/*
- * Hypervisor-assisted dump
- *
- * Linas Vepstas, Manish Ahuja 2008
- * Copyright 2008 IBM Corp.
- *
- *      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; either version
- *      2 of the License, or (at your option) any later version.
- *
- */
-
-#include <linux/gfp.h>
-#include <linux/init.h>
-#include <linux/kobject.h>
-#include <linux/mm.h>
-#include <linux/of.h>
-#include <linux/pfn.h>
-#include <linux/swap.h>
-#include <linux/sysfs.h>
-
-#include <asm/page.h>
-#include <asm/phyp_dump.h>
-#include <asm/machdep.h>
-#include <asm/prom.h>
-#include <asm/rtas.h>
-
-/* Variables, used to communicate data between early boot and late boot */
-static struct phyp_dump phyp_dump_vars;
-struct phyp_dump *phyp_dump_info = &phyp_dump_vars;
-
-static int ibm_configure_kernel_dump;
-/* ------------------------------------------------- */
-/* RTAS interfaces to declare the dump regions */
-
-struct dump_section {
-	u32 dump_flags;
-	u16 source_type;
-	u16 error_flags;
-	u64 source_address;
-	u64 source_length;
-	u64 length_copied;
-	u64 destination_address;
-};
-
-struct phyp_dump_header {
-	u32 version;
-	u16 num_of_sections;
-	u16 status;
-
-	u32 first_offset_section;
-	u32 dump_disk_section;
-	u64 block_num_dd;
-	u64 num_of_blocks_dd;
-	u32 offset_dd;
-	u32 maxtime_to_auto;
-	/* No dump disk path string used */
-
-	struct dump_section cpu_data;
-	struct dump_section hpte_data;
-	struct dump_section kernel_data;
-};
-
-/* The dump header *must be* in low memory, so .bss it */
-static struct phyp_dump_header phdr;
-
-#define NUM_DUMP_SECTIONS	3
-#define DUMP_HEADER_VERSION	0x1
-#define DUMP_REQUEST_FLAG	0x1
-#define DUMP_SOURCE_CPU		0x0001
-#define DUMP_SOURCE_HPTE	0x0002
-#define DUMP_SOURCE_RMO		0x0011
-#define DUMP_ERROR_FLAG		0x2000
-#define DUMP_TRIGGERED		0x4000
-#define DUMP_PERFORMED		0x8000
-
-
-/**
- * init_dump_header() - initialize the header declaring a dump
- * Returns: length of dump save area.
- *
- * When the hypervisor saves crashed state, it needs to put
- * it somewhere. The dump header tells the hypervisor where
- * the data can be saved.
- */
-static unsigned long init_dump_header(struct phyp_dump_header *ph)
-{
-	unsigned long addr_offset = 0;
-
-	/* Set up the dump header */
-	ph->version = DUMP_HEADER_VERSION;
-	ph->num_of_sections = NUM_DUMP_SECTIONS;
-	ph->status = 0;
-
-	ph->first_offset_section =
-		(u32)offsetof(struct phyp_dump_header, cpu_data);
-	ph->dump_disk_section = 0;
-	ph->block_num_dd = 0;
-	ph->num_of_blocks_dd = 0;
-	ph->offset_dd = 0;
-
-	ph->maxtime_to_auto = 0; /* disabled */
-
-	/* The first two sections are mandatory */
-	ph->cpu_data.dump_flags = DUMP_REQUEST_FLAG;
-	ph->cpu_data.source_type = DUMP_SOURCE_CPU;
-	ph->cpu_data.source_address = 0;
-	ph->cpu_data.source_length = phyp_dump_info->cpu_state_size;
-	ph->cpu_data.destination_address = addr_offset;
-	addr_offset += phyp_dump_info->cpu_state_size;
-
-	ph->hpte_data.dump_flags = DUMP_REQUEST_FLAG;
-	ph->hpte_data.source_type = DUMP_SOURCE_HPTE;
-	ph->hpte_data.source_address = 0;
-	ph->hpte_data.source_length = phyp_dump_info->hpte_region_size;
-	ph->hpte_data.destination_address = addr_offset;
-	addr_offset += phyp_dump_info->hpte_region_size;
-
-	/* This section describes the low kernel region */
-	ph->kernel_data.dump_flags = DUMP_REQUEST_FLAG;
-	ph->kernel_data.source_type = DUMP_SOURCE_RMO;
-	ph->kernel_data.source_address = PHYP_DUMP_RMR_START;
-	ph->kernel_data.source_length = PHYP_DUMP_RMR_END;
-	ph->kernel_data.destination_address = addr_offset;
-	addr_offset += ph->kernel_data.source_length;
-
-	return addr_offset;
-}
-
-static void print_dump_header(const struct phyp_dump_header *ph)
-{
-#ifdef DEBUG
-	if (ph == NULL)
-		return;
-
-	printk(KERN_INFO "dump header:\n");
-	/* setup some ph->sections required */
-	printk(KERN_INFO "version = %d\n", ph->version);
-	printk(KERN_INFO "Sections = %d\n", ph->num_of_sections);
-	printk(KERN_INFO "Status = 0x%x\n", ph->status);
-
-	/* No ph->disk, so all should be set to 0 */
-	printk(KERN_INFO "Offset to first section 0x%x\n",
-		ph->first_offset_section);
-	printk(KERN_INFO "dump disk sections should be zero\n");
-	printk(KERN_INFO "dump disk section = %d\n", ph->dump_disk_section);
-	printk(KERN_INFO "block num = %lld\n", ph->block_num_dd);
-	printk(KERN_INFO "number of blocks = %lld\n", ph->num_of_blocks_dd);
-	printk(KERN_INFO "dump disk offset = %d\n", ph->offset_dd);
-	printk(KERN_INFO "Max auto time= %d\n", ph->maxtime_to_auto);
-
-	/*set cpu state and hpte states as well scratch pad area */
-	printk(KERN_INFO " CPU AREA\n");
-	printk(KERN_INFO "cpu dump_flags =%d\n", ph->cpu_data.dump_flags);
-	printk(KERN_INFO "cpu source_type =%d\n", ph->cpu_data.source_type);
-	printk(KERN_INFO "cpu error_flags =%d\n", ph->cpu_data.error_flags);
-	printk(KERN_INFO "cpu source_address =%llx\n",
-		ph->cpu_data.source_address);
-	printk(KERN_INFO "cpu source_length =%llx\n",
-		ph->cpu_data.source_length);
-	printk(KERN_INFO "cpu length_copied =%llx\n",
-		ph->cpu_data.length_copied);
-
-	printk(KERN_INFO " HPTE AREA\n");
-	printk(KERN_INFO "HPTE dump_flags =%d\n", ph->hpte_data.dump_flags);
-	printk(KERN_INFO "HPTE source_type =%d\n", ph->hpte_data.source_type);
-	printk(KERN_INFO "HPTE error_flags =%d\n", ph->hpte_data.error_flags);
-	printk(KERN_INFO "HPTE source_address =%llx\n",
-		ph->hpte_data.source_address);
-	printk(KERN_INFO "HPTE source_length =%llx\n",
-		ph->hpte_data.source_length);
-	printk(KERN_INFO "HPTE length_copied =%llx\n",
-		ph->hpte_data.length_copied);
-
-	printk(KERN_INFO " SRSD AREA\n");
-	printk(KERN_INFO "SRSD dump_flags =%d\n", ph->kernel_data.dump_flags);
-	printk(KERN_INFO "SRSD source_type =%d\n", ph->kernel_data.source_type);
-	printk(KERN_INFO "SRSD error_flags =%d\n", ph->kernel_data.error_flags);
-	printk(KERN_INFO "SRSD source_address =%llx\n",
-		ph->kernel_data.source_address);
-	printk(KERN_INFO "SRSD source_length =%llx\n",
-		ph->kernel_data.source_length);
-	printk(KERN_INFO "SRSD length_copied =%llx\n",
-		ph->kernel_data.length_copied);
-#endif
-}
-
-static ssize_t show_phyp_dump_active(struct kobject *kobj,
-			struct kobj_attribute *attr, char *buf)
-{
-
-	/* create filesystem entry so kdump is phyp-dump aware */
-	return sprintf(buf, "%lx\n", phyp_dump_info->phyp_dump_at_boot);
-}
-
-static struct kobj_attribute pdl = __ATTR(phyp_dump_active, 0600,
-					show_phyp_dump_active,
-					NULL);
-
-static void register_dump_area(struct phyp_dump_header *ph, unsigned long addr)
-{
-	int rc;
-
-	/* Add addr value if not initialized before */
-	if (ph->cpu_data.destination_address == 0) {
-		ph->cpu_data.destination_address += addr;
-		ph->hpte_data.destination_address += addr;
-		ph->kernel_data.destination_address += addr;
-	}
-
-	/* ToDo Invalidate kdump and free memory range. */
-
-	do {
-		rc = rtas_call(ibm_configure_kernel_dump, 3, 1, NULL,
-				1, ph, sizeof(struct phyp_dump_header));
-	} while (rtas_busy_delay(rc));
-
-	if (rc) {
-		printk(KERN_ERR "phyp-dump: unexpected error (%d) on "
-						"register\n", rc);
-		print_dump_header(ph);
-		return;
-	}
-
-	rc = sysfs_create_file(kernel_kobj, &pdl.attr);
-	if (rc)
-		printk(KERN_ERR "phyp-dump: unable to create sysfs"
-				" file (%d)\n", rc);
-}
-
-static
-void invalidate_last_dump(struct phyp_dump_header *ph, unsigned long addr)
-{
-	int rc;
-
-	/* Add addr value if not initialized before */
-	if (ph->cpu_data.destination_address == 0) {
-		ph->cpu_data.destination_address += addr;
-		ph->hpte_data.destination_address += addr;
-		ph->kernel_data.destination_address += addr;
-	}
-
-	do {
-		rc = rtas_call(ibm_configure_kernel_dump, 3, 1, NULL,
-				2, ph, sizeof(struct phyp_dump_header));
-	} while (rtas_busy_delay(rc));
-
-	if (rc) {
-		printk(KERN_ERR "phyp-dump: unexpected error (%d) "
-						"on invalidate\n", rc);
-		print_dump_header(ph);
-	}
-}
-
-/* ------------------------------------------------- */
-/**
- * release_memory_range -- release memory previously memblock_reserved
- * @start_pfn: starting physical frame number
- * @nr_pages: number of pages to free.
- *
- * This routine will release memory that had been previously
- * memblock_reserved in early boot. The released memory becomes
- * available for genreal use.
- */
-static void release_memory_range(unsigned long start_pfn,
-			unsigned long nr_pages)
-{
-	struct page *rpage;
-	unsigned long end_pfn;
-	long i;
-
-	end_pfn = start_pfn + nr_pages;
-
-	for (i = start_pfn; i <= end_pfn; i++) {
-		rpage = pfn_to_page(i);
-		if (PageReserved(rpage)) {
-			ClearPageReserved(rpage);
-			init_page_count(rpage);
-			__free_page(rpage);
-			totalram_pages++;
-		}
-	}
-}
-
-/**
- * track_freed_range -- Counts the range being freed.
- * Once the counter goes to zero, it re-registers dump for
- * future use.
- */
-static void
-track_freed_range(unsigned long addr, unsigned long length)
-{
-	static unsigned long scratch_area_size, reserved_area_size;
-
-	if (addr < phyp_dump_info->init_reserve_start)
-		return;
-
-	if ((addr >= phyp_dump_info->init_reserve_start) &&
-	    (addr <= phyp_dump_info->init_reserve_start +
-	     phyp_dump_info->init_reserve_size))
-		reserved_area_size += length;
-
-	if ((addr >= phyp_dump_info->reserved_scratch_addr) &&
-	    (addr <= phyp_dump_info->reserved_scratch_addr +
-	     phyp_dump_info->reserved_scratch_size))
-		scratch_area_size += length;
-
-	if ((reserved_area_size == phyp_dump_info->init_reserve_size) &&
-	    (scratch_area_size == phyp_dump_info->reserved_scratch_size)) {
-
-		invalidate_last_dump(&phdr,
-				phyp_dump_info->reserved_scratch_addr);
-		register_dump_area(&phdr,
-				phyp_dump_info->reserved_scratch_addr);
-	}
-}
-
-/* ------------------------------------------------- */
-/**
- * sysfs_release_region -- sysfs interface to release memory range.
- *
- * Usage:
- *   "echo <start addr> <length> > /sys/kernel/release_region"
- *
- * Example:
- *   "echo 0x40000000 0x10000000 > /sys/kernel/release_region"
- *
- * will release 256MB starting at 1GB.
- */
-static ssize_t store_release_region(struct kobject *kobj,
-				struct kobj_attribute *attr,
-				const char *buf, size_t count)
-{
-	unsigned long start_addr, length, end_addr;
-	unsigned long start_pfn, nr_pages;
-	ssize_t ret;
-
-	ret = sscanf(buf, "%lx %lx", &start_addr, &length);
-	if (ret != 2)
-		return -EINVAL;
-
-	track_freed_range(start_addr, length);
-
-	/* Range-check - don't free any reserved memory that
-	 * wasn't reserved for phyp-dump */
-	if (start_addr < phyp_dump_info->init_reserve_start)
-		start_addr = phyp_dump_info->init_reserve_start;
-
-	end_addr = phyp_dump_info->init_reserve_start +
-			phyp_dump_info->init_reserve_size;
-	if (start_addr+length > end_addr)
-		length = end_addr - start_addr;
-
-	/* Release the region of memory assed in by user */
-	start_pfn = PFN_DOWN(start_addr);
-	nr_pages = PFN_DOWN(length);
-	release_memory_range(start_pfn, nr_pages);
-
-	return count;
-}
-
-static ssize_t show_release_region(struct kobject *kobj,
-			struct kobj_attribute *attr, char *buf)
-{
-	u64 second_addr_range;
-
-	/* total reserved size - start of scratch area */
-	second_addr_range = phyp_dump_info->init_reserve_size -
-				phyp_dump_info->reserved_scratch_size;
-	return sprintf(buf, "CPU:0x%llx-0x%llx: HPTE:0x%llx-0x%llx:"
-			    " DUMP:0x%llx-0x%llx, 0x%lx-0x%llx:\n",
-		phdr.cpu_data.destination_address,
-		phdr.cpu_data.length_copied,
-		phdr.hpte_data.destination_address,
-		phdr.hpte_data.length_copied,
-		phdr.kernel_data.destination_address,
-		phdr.kernel_data.length_copied,
-		phyp_dump_info->init_reserve_start,
-		second_addr_range);
-}
-
-static struct kobj_attribute rr = __ATTR(release_region, 0600,
-					show_release_region,
-					store_release_region);
-
-static int __init phyp_dump_setup(void)
-{
-	struct device_node *rtas;
-	const struct phyp_dump_header *dump_header = NULL;
-	unsigned long dump_area_start;
-	unsigned long dump_area_length;
-	int header_len = 0;
-	int rc;
-
-	/* If no memory was reserved in early boot, there is nothing to do */
-	if (phyp_dump_info->init_reserve_size == 0)
-		return 0;
-
-	/* Return if phyp dump not supported */
-	if (!phyp_dump_info->phyp_dump_configured)
-		return -ENOSYS;
-
-	/* Is there dump data waiting for us? If there isn't,
-	 * then register a new dump area, and release all of
-	 * the rest of the reserved ram.
-	 *
-	 * The /rtas/ibm,kernel-dump rtas node is present only
-	 * if there is dump data waiting for us.
-	 */
-	rtas = of_find_node_by_path("/rtas");
-	if (rtas) {
-		dump_header = of_get_property(rtas, "ibm,kernel-dump",
-						&header_len);
-		of_node_put(rtas);
-	}
-
-	ibm_configure_kernel_dump = rtas_token("ibm,configure-kernel-dump");
-
-	print_dump_header(dump_header);
-	dump_area_length = init_dump_header(&phdr);
-	/* align down */
-	dump_area_start = phyp_dump_info->init_reserve_start & PAGE_MASK;
-
-	if (dump_header == NULL) {
-		register_dump_area(&phdr, dump_area_start);
-		return 0;
-	}
-
-	/* re-register the dump area, if old dump was invalid */
-	if ((dump_header) && (dump_header->status & DUMP_ERROR_FLAG)) {
-		invalidate_last_dump(&phdr, dump_area_start);
-		register_dump_area(&phdr, dump_area_start);
-		return 0;
-	}
-
-	if (dump_header) {
-		phyp_dump_info->reserved_scratch_addr =
-				dump_header->cpu_data.destination_address;
-		phyp_dump_info->reserved_scratch_size =
-				dump_header->cpu_data.source_length +
-				dump_header->hpte_data.source_length +
-				dump_header->kernel_data.source_length;
-	}
-
-	/* Should we create a dump_subsys, analogous to s390/ipl.c ? */
-	rc = sysfs_create_file(kernel_kobj, &rr.attr);
-	if (rc)
-		printk(KERN_ERR "phyp-dump: unable to create sysfs file (%d)\n",
-									rc);
-
-	/* ToDo: re-register the dump area, for next time. */
-	return 0;
-}
-machine_subsys_initcall(pseries, phyp_dump_setup);
-
-int __init early_init_dt_scan_phyp_dump(unsigned long node,
-		const char *uname, int depth, void *data)
-{
-	const unsigned int *sizes;
-
-	phyp_dump_info->phyp_dump_configured = 0;
-	phyp_dump_info->phyp_dump_is_active = 0;
-
-	if (depth != 1 || strcmp(uname, "rtas") != 0)
-		return 0;
-
-	if (of_get_flat_dt_prop(node, "ibm,configure-kernel-dump", NULL))
-		phyp_dump_info->phyp_dump_configured++;
-
-	if (of_get_flat_dt_prop(node, "ibm,dump-kernel", NULL))
-		phyp_dump_info->phyp_dump_is_active++;
-
-	sizes = of_get_flat_dt_prop(node, "ibm,configure-kernel-dump-sizes",
-				    NULL);
-	if (!sizes)
-		return 0;
-
-	if (sizes[0] == 1)
-		phyp_dump_info->cpu_state_size = *((unsigned long *)&sizes[1]);
-
-	if (sizes[3] == 2)
-		phyp_dump_info->hpte_region_size =
-						*((unsigned long *)&sizes[4]);
-	return 1;
-}
-
-/* Look for phyp_dump= cmdline option */
-static int __init early_phyp_dump_enabled(char *p)
-{
-	phyp_dump_info->phyp_dump_at_boot = 1;
-
-        if (!p)
-                return 0;
-
-        if (strncmp(p, "1", 1) == 0)
-		phyp_dump_info->phyp_dump_at_boot = 1;
-        else if (strncmp(p, "0", 1) == 0)
-		phyp_dump_info->phyp_dump_at_boot = 0;
-
-        return 0;
-}
-early_param("phyp_dump", early_phyp_dump_enabled);
-
-/* Look for phyp_dump_reserve_size= cmdline option */
-static int __init early_phyp_dump_reserve_size(char *p)
-{
-        if (p)
-		phyp_dump_info->reserve_bootvar = memparse(p, &p);
-
-        return 0;
-}
-early_param("phyp_dump_reserve_size", early_phyp_dump_reserve_size);



From yinghai at kernel.org  Thu Feb 16 13:43:06 2012
From: yinghai at kernel.org (Yinghai Lu)
Date: Thu, 16 Feb 2012 10:43:06 -0800
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <20120216025331.GT9751@redhat.com>
References: <tip-d9bc9be89629445758670220787683e37c93f6c1@git.kernel.org>
 <CAE9FiQWRjvu_uNcx_bJXYHeg4D4k6YzHHmSudsq7EyubLi7+nw@mail.gmail.com>
 <20120213152808.GD9751@redhat.com>
 <CAE9FiQXX7BXKuVHZ9NRCEmeTnPj4zVJL5gf5eSp6b+4e3jN3EA@mail.gmail.com>
 <20120216025331.GT9751@redhat.com>
Message-ID: <CAE9FiQW4utm0roHR7zHS_tHbOAhqi4SECjH8cwJ3H=zEKhQLXA@mail.gmail.com>

On Wed, Feb 15, 2012 at 6:53 PM, Don Zickus <dzickus at redhat.com> wrote:
>
> For some reason using gzip instead of xz makes things work for me with
> your config.
>
> CONFIG_KERNEL_GZIP=y
> CONFIG_KERNEL_XZ=n
>
> Do you see the same thing?

no.

with GZIP still get instant reset.

Yinghai


From dzickus at redhat.com  Thu Feb 16 12:27:35 2012
From: dzickus at redhat.com (Don Zickus)
Date: Thu, 16 Feb 2012 12:27:35 -0500
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <CAE9FiQVPnO8-tuPoio0Wxv=8rjdm2tJbBk3+3ystueyYtZn9BA@mail.gmail.com>
References: <tip-d9bc9be89629445758670220787683e37c93f6c1@git.kernel.org>
 <CAE9FiQWRjvu_uNcx_bJXYHeg4D4k6YzHHmSudsq7EyubLi7+nw@mail.gmail.com>
 <m1ipjc3fsk.fsf@fess.ebiederm.org>
 <CAE9FiQVLnyRB+pAqi22C5mCbHOOVKxsBhQKaB6P0p9f2LBL8bA@mail.gmail.com>
 <m1zkcmyjyd.fsf@fess.ebiederm.org>
 <CAE9FiQVj12UCGbOe4wZfx-L8tdab-1si-RA=vBnNeZ7cUNqyyg@mail.gmail.com>
 <CAE9FiQVPnO8-tuPoio0Wxv=8rjdm2tJbBk3+3ystueyYtZn9BA@mail.gmail.com>
Message-ID: <20120216172735.GX9751@redhat.com>

On Mon, Feb 13, 2012 at 10:16:00AM -0800, Yinghai Lu wrote:
> On Mon, Feb 13, 2012 at 8:51 AM, Yinghai Lu <yinghai at kernel.org> wrote:
> >> So I suspect we have a bug in our apic initialization somewhere, but
> >> apic initialization should happen after printk are enabled. ?Or at least
> >> after early printks so the reset YH is reporting doesn't make much sense.
> >
> > will try Don's first version patch that only removing disable_IO_APIC.
> 
> first version patch (only removing disable_IO_APIC) is working.

So I think I figured it out.  I went through and commented out code in
disable_local_APIC until I narrowed it down to the piece of code that
needs to be disabled for it to work.

Surprise, surprise... its LVTPC or perf! :-)  Actually it is the
nmi_watchdog which uses perf.  My theory is NMIs are not disabled and one
is generated by the local apic during decompression (just bad timing) and
*splat*.

Yinghai, you can probably prove this by

echo 0 > /proc/sys/kernel/nmi_watchdog

then do your kdump crash test.

At least that test worked for me.

So either we explicitly shutdown perf or just mask off LVTPC in a modified
disable_local_APIC?

Eric, thoughts, preferences?

Cheers,
Don


From dzickus at redhat.com  Thu Feb 16 16:41:41 2012
From: dzickus at redhat.com (Don Zickus)
Date: Thu, 16 Feb 2012 16:41:41 -0500
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <CAE9FiQW4utm0roHR7zHS_tHbOAhqi4SECjH8cwJ3H=zEKhQLXA@mail.gmail.com>
References: <tip-d9bc9be89629445758670220787683e37c93f6c1@git.kernel.org>
 <CAE9FiQWRjvu_uNcx_bJXYHeg4D4k6YzHHmSudsq7EyubLi7+nw@mail.gmail.com>
 <20120213152808.GD9751@redhat.com>
 <CAE9FiQXX7BXKuVHZ9NRCEmeTnPj4zVJL5gf5eSp6b+4e3jN3EA@mail.gmail.com>
 <20120216025331.GT9751@redhat.com>
 <CAE9FiQW4utm0roHR7zHS_tHbOAhqi4SECjH8cwJ3H=zEKhQLXA@mail.gmail.com>
Message-ID: <20120216214141.GG9751@redhat.com>

On Thu, Feb 16, 2012 at 10:43:06AM -0800, Yinghai Lu wrote:
> On Wed, Feb 15, 2012 at 6:53 PM, Don Zickus <dzickus at redhat.com> wrote:
> >
> > For some reason using gzip instead of xz makes things work for me with
> > your config.
> >
> > CONFIG_KERNEL_GZIP=y
> > CONFIG_KERNEL_XZ=n
> >
> > Do you see the same thing?
> 
> no.
> 
> with GZIP still get instant reset.

What about my other idea, 'echo 0 > /proc/sys/kernel/nmi_watchdog'?

Cheers,
Don


From yinghai at kernel.org  Thu Feb 16 16:53:29 2012
From: yinghai at kernel.org (Yinghai Lu)
Date: Thu, 16 Feb 2012 13:53:29 -0800
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <20120216172735.GX9751@redhat.com>
References: <tip-d9bc9be89629445758670220787683e37c93f6c1@git.kernel.org>
 <CAE9FiQWRjvu_uNcx_bJXYHeg4D4k6YzHHmSudsq7EyubLi7+nw@mail.gmail.com>
 <m1ipjc3fsk.fsf@fess.ebiederm.org>
 <CAE9FiQVLnyRB+pAqi22C5mCbHOOVKxsBhQKaB6P0p9f2LBL8bA@mail.gmail.com>
 <m1zkcmyjyd.fsf@fess.ebiederm.org>
 <CAE9FiQVj12UCGbOe4wZfx-L8tdab-1si-RA=vBnNeZ7cUNqyyg@mail.gmail.com>
 <CAE9FiQVPnO8-tuPoio0Wxv=8rjdm2tJbBk3+3ystueyYtZn9BA@mail.gmail.com>
 <20120216172735.GX9751@redhat.com>
Message-ID: <CAE9FiQVhbAM9vjx-uFcuc0ndsUp0aez9_TsQHStje5G5iwYbag@mail.gmail.com>

On Thu, Feb 16, 2012 at 9:27 AM, Don Zickus <dzickus at redhat.com> wrote:

> So I think I figured it out. ?I went through and commented out code in
> disable_local_APIC until I narrowed it down to the piece of code that
> needs to be disabled for it to work.
>
> Surprise, surprise... its LVTPC or perf! :-) ?Actually it is the
> nmi_watchdog which uses perf. ?My theory is NMIs are not disabled and one
> is generated by the local apic during decompression (just bad timing) and
> *splat*.
>
> Yinghai, you can probably prove this by
>
> echo 0 > /proc/sys/kernel/nmi_watchdog
>
> then do your kdump crash test.

yes.  that will make kdump crash working.

Yinghai


From dzickus at redhat.com  Thu Feb 16 16:56:03 2012
From: dzickus at redhat.com (Don Zickus)
Date: Thu, 16 Feb 2012 16:56:03 -0500
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <CAE9FiQVhbAM9vjx-uFcuc0ndsUp0aez9_TsQHStje5G5iwYbag@mail.gmail.com>
References: <tip-d9bc9be89629445758670220787683e37c93f6c1@git.kernel.org>
 <CAE9FiQWRjvu_uNcx_bJXYHeg4D4k6YzHHmSudsq7EyubLi7+nw@mail.gmail.com>
 <m1ipjc3fsk.fsf@fess.ebiederm.org>
 <CAE9FiQVLnyRB+pAqi22C5mCbHOOVKxsBhQKaB6P0p9f2LBL8bA@mail.gmail.com>
 <m1zkcmyjyd.fsf@fess.ebiederm.org>
 <CAE9FiQVj12UCGbOe4wZfx-L8tdab-1si-RA=vBnNeZ7cUNqyyg@mail.gmail.com>
 <CAE9FiQVPnO8-tuPoio0Wxv=8rjdm2tJbBk3+3ystueyYtZn9BA@mail.gmail.com>
 <20120216172735.GX9751@redhat.com>
 <CAE9FiQVhbAM9vjx-uFcuc0ndsUp0aez9_TsQHStje5G5iwYbag@mail.gmail.com>
Message-ID: <20120216215603.GH9751@redhat.com>

On Thu, Feb 16, 2012 at 01:53:29PM -0800, Yinghai Lu wrote:
> On Thu, Feb 16, 2012 at 9:27 AM, Don Zickus <dzickus at redhat.com> wrote:
> 
> > So I think I figured it out. ?I went through and commented out code in
> > disable_local_APIC until I narrowed it down to the piece of code that
> > needs to be disabled for it to work.
> >
> > Surprise, surprise... its LVTPC or perf! :-) ?Actually it is the
> > nmi_watchdog which uses perf. ?My theory is NMIs are not disabled and one
> > is generated by the local apic during decompression (just bad timing) and
> > *splat*.
> >
> > Yinghai, you can probably prove this by
> >
> > echo 0 > /proc/sys/kernel/nmi_watchdog
> >
> > then do your kdump crash test.
> 
> yes.  that will make kdump crash working.

Cool.  Thanks.

Eric,

Just let me know how you want to handle disabling NMIs in the kexec in
panic shutdown case.

Cheers,
Don


From kumagai-atsushi at mxc.nes.nec.co.jp  Thu Feb 16 19:32:20 2012
From: kumagai-atsushi at mxc.nes.nec.co.jp (Atsushi Kumagai)
Date: Fri, 17 Feb 2012 09:32:20 +0900
Subject: [PATCH v1 0/4][makedumpfile] vmalloc translation support for PPC32
In-Reply-To: <20120216033411.7972.77705.stgit@suzukikp>
References: <20120216033411.7972.77705.stgit@suzukikp>
Message-ID: <20120217093220.0c2993a1.kumagai-atsushi@mxc.nes.nec.co.jp>

Hi, Suzuki

On Thu, 16 Feb 2012 09:05:17 +0530
"Suzuki K. Poulose" <suzuki at in.ibm.com> wrote:

> The series introduces an infrastructure to define platform specific
> bits for page translation for PPC and PPC44x support for vmalloc
> translation.
> 
> This is similar to what we have implemented for Crash-utility.
> 
> The patches are based makedumpfile-1.4.2 + PPC32 support patches
> which is queued in for 1.4.3.
> 
> ---
> 
> Suzuki K. Poulose (4):
>       [makedumpfile][ppc] PPC44x page translation definitions
>       [makedumpfile][ppc] Define platform descriptors for page translation
>       [makedumpfile][ppc] Generic vmalloc translation support
>       [makedumpfile] Add read_string routine
> 
> 
>  arch/ppc.c     |  108 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
>  makedumpfile.c |   14 +++++++
>  makedumpfile.h |   21 +++++++++++
>  3 files changed, 139 insertions(+), 4 deletions(-)
> 
> -- 
> Suzuki Poulose

Could you tell me what kind of data is stored in vmalloc region in PPC ?
I want to estimate importance of your patches for makedumpfile.

Thanks
Atsushi Kumagai


From ebiederm at xmission.com  Thu Feb 16 22:38:21 2012
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Thu, 16 Feb 2012 19:38:21 -0800
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <20120216215603.GH9751@redhat.com> (Don Zickus's message of "Thu, 
 16 Feb 2012 16:56:03 -0500")
References: <tip-d9bc9be89629445758670220787683e37c93f6c1@git.kernel.org>
 <CAE9FiQWRjvu_uNcx_bJXYHeg4D4k6YzHHmSudsq7EyubLi7+nw@mail.gmail.com>
 <m1ipjc3fsk.fsf@fess.ebiederm.org>
 <CAE9FiQVLnyRB+pAqi22C5mCbHOOVKxsBhQKaB6P0p9f2LBL8bA@mail.gmail.com>
 <m1zkcmyjyd.fsf@fess.ebiederm.org>
 <CAE9FiQVj12UCGbOe4wZfx-L8tdab-1si-RA=vBnNeZ7cUNqyyg@mail.gmail.com>
 <CAE9FiQVPnO8-tuPoio0Wxv=8rjdm2tJbBk3+3ystueyYtZn9BA@mail.gmail.com>
 <20120216172735.GX9751@redhat.com>
 <CAE9FiQVhbAM9vjx-uFcuc0ndsUp0aez9_TsQHStje5G5iwYbag@mail.gmail.com>
 <20120216215603.GH9751@redhat.com>
Message-ID: <m1y5s2ku36.fsf@fess.ebiederm.org>

Don Zickus <dzickus at redhat.com> writes:

> On Thu, Feb 16, 2012 at 01:53:29PM -0800, Yinghai Lu wrote:
>> On Thu, Feb 16, 2012 at 9:27 AM, Don Zickus <dzickus at redhat.com> wrote:
>> 
>> > So I think I figured it out. ?I went through and commented out code in
>> > disable_local_APIC until I narrowed it down to the piece of code that
>> > needs to be disabled for it to work.
>> >
>> > Surprise, surprise... its LVTPC or perf! :-) ?Actually it is the
>> > nmi_watchdog which uses perf. ?My theory is NMIs are not disabled and one
>> > is generated by the local apic during decompression (just bad timing) and
>> > *splat*.
>> >
>> > Yinghai, you can probably prove this by
>> >
>> > echo 0 > /proc/sys/kernel/nmi_watchdog
>> >
>> > then do your kdump crash test.
>> 
>> yes.  that will make kdump crash working.
>
> Cool.  Thanks.
>
> Eric,
>
> Just let me know how you want to handle disabling NMIs in the kexec in
> panic shutdown case.

Interesting.  Apparently we have been avoiding this problem by accident.

Thanks for hunting this down.

The options I can see are:
- Ensure we can handle and ignore exceptions like this.
- Always shutoff the lapic and ioapic entries that can generate this.

The good news is that both solutions should be lock free.

The current kernel boot code relies on the assumption that all
interrupts can be disabled.  In this case with nmi's that is clearly not
the case.

The most robust solution and what we want to do long term is to
install an idt that will simply ignore all interrupts until the
idt is replaced.  Since really all we need to deal with is the NMI
vector, which is vector #2, we can have a very small interrupt
descriptor table.

Unfortunately we go through some cpu mode switches in /sbin/kexec,
allowing us to enter the kernels 32bit entry point before we
run the decompresser, so at first glance both /sbin/kexec and the
kernel need to be fixed in a coordinated fashion.

There are two was I can see of removing the need for an exactly
coordinated release.
- Document that an old /sbin/kexec userspace requires you not to
  use the nmi watchdog with modern kernels.
- For a short while simply retain code that stomps the nmi watchdog.
  (But still leaves us open to other kinds of nmi's).

Grr.  Looking a little more closely, all throughout the linux kernel's
boot there is the assumption that any interrupt during boot is a failure
of some kind, and except for an errant nmi watchdog that is a true
assumption.

Don I guess I really have to recommend disabling the nmi watchdog in the
kexec on panic path if we can do so at all reasonably. 

I like the idea of ignoring nmis during boot but that seems to be a
slightly larger project and with little practical improvement in kexec
on panic quality.  Other than getting what should be one or two
i/o writes out of the kexec on panic path.

Eric



From suzuki at in.ibm.com  Fri Feb 17 00:55:27 2012
From: suzuki at in.ibm.com (Suzuki K. Poulose)
Date: Fri, 17 Feb 2012 11:25:27 +0530
Subject: [PATCH v1 0/4][makedumpfile] vmalloc translation support for PPC32
In-Reply-To: <20120217093220.0c2993a1.kumagai-atsushi@mxc.nes.nec.co.jp>
References: <20120216033411.7972.77705.stgit@suzukikp>
 <20120217093220.0c2993a1.kumagai-atsushi@mxc.nes.nec.co.jp>
Message-ID: <4F3DEBCF.8000201@in.ibm.com>

On 02/17/2012 06:02 AM, Atsushi Kumagai wrote:
> Hi, Suzuki
>
> On Thu, 16 Feb 2012 09:05:17 +0530
> "Suzuki K. Poulose"<suzuki at in.ibm.com>  wrote:
>
>> The series introduces an infrastructure to define platform specific
>> bits for page translation for PPC and PPC44x support for vmalloc
>> translation.
>>
>> This is similar to what we have implemented for Crash-utility.
>>
>> The patches are based makedumpfile-1.4.2 + PPC32 support patches
>> which is queued in for 1.4.3.
>>
>> ---
>>
>> Suzuki K. Poulose (4):
>>        [makedumpfile][ppc] PPC44x page translation definitions
>>        [makedumpfile][ppc] Define platform descriptors for page translation
>>        [makedumpfile][ppc] Generic vmalloc translation support
>>        [makedumpfile] Add read_string routine
>>
>>
>>   arch/ppc.c     |  108 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
>>   makedumpfile.c |   14 +++++++
>>   makedumpfile.h |   21 +++++++++++
>>   3 files changed, 139 insertions(+), 4 deletions(-)
>>
>> --
>> Suzuki Poulose
>
> Could you tell me what kind of data is stored in vmalloc region in PPC ?
> I want to estimate importance of your patches for makedumpfile.
I know at least the modules are loaded in the vmalloc'd region. I have
Cc'ed linux-ppc dev. We should be able to get enough info from the experts here.

Josh / Kumar / Others,

Could you please let us know your thoughts ?

Thanks

Suzuki



From benh at kernel.crashing.org  Fri Feb 17 03:39:29 2012
From: benh at kernel.crashing.org (Benjamin Herrenschmidt)
Date: Fri, 17 Feb 2012 19:39:29 +1100
Subject: [PATCH v1 0/4][makedumpfile] vmalloc translation support for PPC32
In-Reply-To: <4F3DEBCF.8000201@in.ibm.com>
References: <20120216033411.7972.77705.stgit@suzukikp>
 <20120217093220.0c2993a1.kumagai-atsushi@mxc.nes.nec.co.jp>
 <4F3DEBCF.8000201@in.ibm.com>
Message-ID: <1329467969.2892.58.camel@pasglop>

On Fri, 2012-02-17 at 11:25 +0530, Suzuki K. Poulose wrote:
> > Could you tell me what kind of data is stored in vmalloc region in
> PPC ?
> > I want to estimate importance of your patches for makedumpfile.
> I know at least the modules are loaded in the vmalloc'd region. I have
> Cc'ed linux-ppc dev. We should be able to get enough info from the
> experts here.
> 
> Josh / Kumar / Others,
> 
> Could you please let us know your thoughts ?

Modules, driver IO mappings, etc... I can see that being useful for
crashdumps.

Cheers,
Ben.




From ebiederm at xmission.com  Fri Feb 17 07:41:01 2012
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Fri, 17 Feb 2012 04:41:01 -0800
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <m1y5s2ku36.fsf@fess.ebiederm.org> (Eric W. Biederman's message
 of "Thu, 16 Feb 2012 19:38:21 -0800")
References: <tip-d9bc9be89629445758670220787683e37c93f6c1@git.kernel.org>
 <CAE9FiQWRjvu_uNcx_bJXYHeg4D4k6YzHHmSudsq7EyubLi7+nw@mail.gmail.com>
 <m1ipjc3fsk.fsf@fess.ebiederm.org>
 <CAE9FiQVLnyRB+pAqi22C5mCbHOOVKxsBhQKaB6P0p9f2LBL8bA@mail.gmail.com>
 <m1zkcmyjyd.fsf@fess.ebiederm.org>
 <CAE9FiQVj12UCGbOe4wZfx-L8tdab-1si-RA=vBnNeZ7cUNqyyg@mail.gmail.com>
 <CAE9FiQVPnO8-tuPoio0Wxv=8rjdm2tJbBk3+3ystueyYtZn9BA@mail.gmail.com>
 <20120216172735.GX9751@redhat.com>
 <CAE9FiQVhbAM9vjx-uFcuc0ndsUp0aez9_TsQHStje5G5iwYbag@mail.gmail.com>
 <20120216215603.GH9751@redhat.com> <m1y5s2ku36.fsf@fess.ebiederm.org>
Message-ID: <m1fwe9bpk2.fsf@fess.ebiederm.org>

ebiederm at xmission.com (Eric W. Biederman) writes:

> Don Zickus <dzickus at redhat.com> writes:
>
>> On Thu, Feb 16, 2012 at 01:53:29PM -0800, Yinghai Lu wrote:
>>> On Thu, Feb 16, 2012 at 9:27 AM, Don Zickus <dzickus at redhat.com> wrote:
>>> 
>>> > So I think I figured it out. ?I went through and commented out code in
>>> > disable_local_APIC until I narrowed it down to the piece of code that
>>> > needs to be disabled for it to work.
>>> >
>>> > Surprise, surprise... its LVTPC or perf! :-) ?Actually it is the
>>> > nmi_watchdog which uses perf. ?My theory is NMIs are not disabled and one
>>> > is generated by the local apic during decompression (just bad timing) and
>>> > *splat*.
>>> >
>>> > Yinghai, you can probably prove this by
>>> >
>>> > echo 0 > /proc/sys/kernel/nmi_watchdog
>>> >
>>> > then do your kdump crash test.
>>> 
>>> yes.  that will make kdump crash working.
>>
>> Cool.  Thanks.
>>
>> Eric,
>>
>> Just let me know how you want to handle disabling NMIs in the kexec in
>> panic shutdown case.
>
> Interesting.  Apparently we have been avoiding this problem by accident.
>
> Thanks for hunting this down.
>
> The options I can see are:
> - Ensure we can handle and ignore exceptions like this.
> - Always shutoff the lapic and ioapic entries that can generate this.
>
> The good news is that both solutions should be lock free.
>
> The current kernel boot code relies on the assumption that all
> interrupts can be disabled.  In this case with nmi's that is clearly not
> the case.
>
> The most robust solution and what we want to do long term is to
> install an idt that will simply ignore all interrupts until the
> idt is replaced.  Since really all we need to deal with is the NMI
> vector, which is vector #2, we can have a very small interrupt
> descriptor table.
>
> Unfortunately we go through some cpu mode switches in /sbin/kexec,
> allowing us to enter the kernels 32bit entry point before we
> run the decompresser, so at first glance both /sbin/kexec and the
> kernel need to be fixed in a coordinated fashion.
>
> There are two was I can see of removing the need for an exactly
> coordinated release.
> - Document that an old /sbin/kexec userspace requires you not to
>   use the nmi watchdog with modern kernels.
> - For a short while simply retain code that stomps the nmi watchdog.
>   (But still leaves us open to other kinds of nmi's).
>
> Grr.  Looking a little more closely, all throughout the linux kernel's
> boot there is the assumption that any interrupt during boot is a failure
> of some kind, and except for an errant nmi watchdog that is a true
> assumption.
>
> Don I guess I really have to recommend disabling the nmi watchdog in the
> kexec on panic path if we can do so at all reasonably. 
>
> I like the idea of ignoring nmis during boot but that seems to be a
> slightly larger project and with little practical improvement in kexec
> on panic quality.  Other than getting what should be one or two
> i/o writes out of the kexec on panic path.

Hmm.

Thinking about it a little more.  The kernel's boot path is inconsistent
with the rest of the kernel's nmi handling.  For anything exception
except an nmi stopping and giving up is fine.  For an nmi it is very
rare for an NMI to signal a truly nasty failure (usually it just means
someone saw a bitflip somewhere), and we can almost always continue
without problem.

I think in practice we really should make our boot path consistent with
the rest of the kernel and ignore/log/report nmis but not fail on them.
Triple faulting (trigger a cpu reset) as we do today just seems like a
recipe for deep and confusing mystery, and not being helpful to the
user.

My preferred fix would be to fix the boot path and /sbin/kexec to ignore
and report nmis as we boot, as that is really what we want long term and
it gives us the most robust solution.

The fix with a guarantee of no more scope creep is to just disable the
nmi watchdog on the kexec on panic path.

Don if you have time please figure out is needed to ignore nmi's and
possible record and/or report them while we boot, otherwise please cook
up a patch that just disables the nmi watchdog wherever we are sending
it from (the local apic or the ioapic).

Eric


From d.hatayama at gmail.com  Fri Feb 17 10:49:16 2012
From: d.hatayama at gmail.com (HATAYAMA Daisuke)
Date: Sat, 18 Feb 2012 00:49:16 +0900
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <m1fwe9bpk2.fsf@fess.ebiederm.org>
References: <tip-d9bc9be89629445758670220787683e37c93f6c1@git.kernel.org>
 <CAE9FiQWRjvu_uNcx_bJXYHeg4D4k6YzHHmSudsq7EyubLi7+nw@mail.gmail.com>
 <m1ipjc3fsk.fsf@fess.ebiederm.org>
 <CAE9FiQVLnyRB+pAqi22C5mCbHOOVKxsBhQKaB6P0p9f2LBL8bA@mail.gmail.com>
 <m1zkcmyjyd.fsf@fess.ebiederm.org>
 <CAE9FiQVj12UCGbOe4wZfx-L8tdab-1si-RA=vBnNeZ7cUNqyyg@mail.gmail.com>
 <CAE9FiQVPnO8-tuPoio0Wxv=8rjdm2tJbBk3+3ystueyYtZn9BA@mail.gmail.com>
 <20120216172735.GX9751@redhat.com>
 <CAE9FiQVhbAM9vjx-uFcuc0ndsUp0aez9_TsQHStje5G5iwYbag@mail.gmail.com>
 <20120216215603.GH9751@redhat.com>
 <m1y5s2ku36.fsf@fess.ebiederm.org>
 <m1fwe9bpk2.fsf@fess.ebiederm.org>
Message-ID: <CABOkKT21zhyMwMmbR9WTipk5e=y_qMZ8ByG=njatjKbFLZW+xQ@mail.gmail.com>

2012/2/17 Eric W. Biederman <ebiederm at xmission.com>:
> ebiederm at xmission.com (Eric W. Biederman) writes:
>
>> Don Zickus <dzickus at redhat.com> writes:
>>
>>> On Thu, Feb 16, 2012 at 01:53:29PM -0800, Yinghai Lu wrote:
>>>> On Thu, Feb 16, 2012 at 9:27 AM, Don Zickus <dzickus at redhat.com> wrote:
>>>>
>>>> > So I think I figured it out. ?I went through and commented out code in
>>>> > disable_local_APIC until I narrowed it down to the piece of code that
>>>> > needs to be disabled for it to work.
>>>> >
>>>> > Surprise, surprise... its LVTPC or perf! :-) ?Actually it is the
>>>> > nmi_watchdog which uses perf. ?My theory is NMIs are not disabled and one
>>>> > is generated by the local apic during decompression (just bad timing) and
>>>> > *splat*.
>>>> >
>>>> > Yinghai, you can probably prove this by
>>>> >
>>>> > echo 0 > /proc/sys/kernel/nmi_watchdog
>>>> >
>>>> > then do your kdump crash test.
>>>>
>>>> yes. ?that will make kdump crash working.
>>>
>>> Cool. ?Thanks.
>>>
>>> Eric,
>>>
>>> Just let me know how you want to handle disabling NMIs in the kexec in
>>> panic shutdown case.
>>
>> Interesting. ?Apparently we have been avoiding this problem by accident.
>>
>> Thanks for hunting this down.
>>
>> The options I can see are:
>> - Ensure we can handle and ignore exceptions like this.
>> - Always shutoff the lapic and ioapic entries that can generate this.
>>
>> The good news is that both solutions should be lock free.
>>
>> The current kernel boot code relies on the assumption that all
>> interrupts can be disabled. ?In this case with nmi's that is clearly not
>> the case.
>>
>> The most robust solution and what we want to do long term is to
>> install an idt that will simply ignore all interrupts until the
>> idt is replaced. ?Since really all we need to deal with is the NMI
>> vector, which is vector #2, we can have a very small interrupt
>> descriptor table.
>>
>> Unfortunately we go through some cpu mode switches in /sbin/kexec,
>> allowing us to enter the kernels 32bit entry point before we
>> run the decompresser, so at first glance both /sbin/kexec and the
>> kernel need to be fixed in a coordinated fashion.
>>
>> There are two was I can see of removing the need for an exactly
>> coordinated release.
>> - Document that an old /sbin/kexec userspace requires you not to
>> ? use the nmi watchdog with modern kernels.
>> - For a short while simply retain code that stomps the nmi watchdog.
>> ? (But still leaves us open to other kinds of nmi's).
>>
>> Grr. ?Looking a little more closely, all throughout the linux kernel's
>> boot there is the assumption that any interrupt during boot is a failure
>> of some kind, and except for an errant nmi watchdog that is a true
>> assumption.
>>
>> Don I guess I really have to recommend disabling the nmi watchdog in the
>> kexec on panic path if we can do so at all reasonably.
>>
>> I like the idea of ignoring nmis during boot but that seems to be a
>> slightly larger project and with little practical improvement in kexec
>> on panic quality. ?Other than getting what should be one or two
>> i/o writes out of the kexec on panic path.
>
> Hmm.
>
> Thinking about it a little more. ?The kernel's boot path is inconsistent
> with the rest of the kernel's nmi handling. ?For anything exception
> except an nmi stopping and giving up is fine. ?For an nmi it is very
> rare for an NMI to signal a truly nasty failure (usually it just means
> someone saw a bitflip somewhere), and we can almost always continue
> without problem.
>
> I think in practice we really should make our boot path consistent with
> the rest of the kernel and ignore/log/report nmis but not fail on them.
> Triple faulting (trigger a cpu reset) as we do today just seems like a
> recipe for deep and confusing mystery, and not being helpful to the
> user.
>
> My preferred fix would be to fix the boot path and /sbin/kexec to ignore
> and report nmis as we boot, as that is really what we want long term and
> it gives us the most robust solution.
>
> The fix with a guarantee of no more scope creep is to just disable the
> nmi watchdog on the kexec on panic path.
>
> Don if you have time please figure out is needed to ignore nmi's and
> possible record and/or report them while we boot, otherwise please cook
> up a patch that just disables the nmi watchdog wherever we are sending
> it from (the local apic or the ioapic).
>
> Eric

A few days ago I investigted the case where system is reseted due to
triple fault caused by the NMI after idt is disabled in
machine_kexec. I didn't see the reset when trigering the kdump with
NMI since the NMI is masked until next iret instruction executed as
described in 6.7.2. Handling Multiple NMIs of Intel Manual Vol.3A.
The NMI mask remains untill the first iret execution on the 2nd
kernel: just the return path of the first kernel_thread invocation for
init process. The exact path is:

  switch_to
  -> ret_from_fork
     -> int_ret_from_sys_call
        -> retint_restore_args
           -> irq_return

At that phase idt is already set up and kdump works.

>From the discussion I interpret kdump doesn't assume this behaviour,
right?

BTW, does anyone know the detail of the NMI mask? I couldn't figure
out about it from the Intel spec more than ``certain hardware
conditions''... I expect those who look at here are x86 NMI experts.

Thanks.
HATAYAMA, Daisuke


From dzickus at redhat.com  Fri Feb 17 14:54:30 2012
From: dzickus at redhat.com (Don Zickus)
Date: Fri, 17 Feb 2012 14:54:30 -0500
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <m1fwe9bpk2.fsf@fess.ebiederm.org>
References: <m1ipjc3fsk.fsf@fess.ebiederm.org>
 <CAE9FiQVLnyRB+pAqi22C5mCbHOOVKxsBhQKaB6P0p9f2LBL8bA@mail.gmail.com>
 <m1zkcmyjyd.fsf@fess.ebiederm.org>
 <CAE9FiQVj12UCGbOe4wZfx-L8tdab-1si-RA=vBnNeZ7cUNqyyg@mail.gmail.com>
 <CAE9FiQVPnO8-tuPoio0Wxv=8rjdm2tJbBk3+3ystueyYtZn9BA@mail.gmail.com>
 <20120216172735.GX9751@redhat.com>
 <CAE9FiQVhbAM9vjx-uFcuc0ndsUp0aez9_TsQHStje5G5iwYbag@mail.gmail.com>
 <20120216215603.GH9751@redhat.com>
 <m1y5s2ku36.fsf@fess.ebiederm.org>
 <m1fwe9bpk2.fsf@fess.ebiederm.org>
Message-ID: <20120217195430.GO9751@redhat.com>

On Fri, Feb 17, 2012 at 04:41:01AM -0800, Eric W. Biederman wrote:
> 
> The fix with a guarantee of no more scope creep is to just disable the
> nmi watchdog on the kexec on panic path.
> 
> Don if you have time please figure out is needed to ignore nmi's and
> possible record and/or report them while we boot, otherwise please cook
> up a patch that just disables the nmi watchdog wherever we are sending
> it from (the local apic or the ioapic).

Can I keep things even simpler?  The original problem was the deadlock
with the ioapic lock.  We fixed that by removing the call to
disable_IO_APIC().  Can we just leave the disable_local_APIC calls in
there for now?  Is there any real harm?

All this rewrite is going to take time which will delay fixing a current
problem with kexec on panic, the ioapic deadlock.

Thoughts?

Cheers,
Don


From dzickus at redhat.com  Fri Feb 17 15:18:42 2012
From: dzickus at redhat.com (Don Zickus)
Date: Fri, 17 Feb 2012 15:18:42 -0500
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <CABOkKT21zhyMwMmbR9WTipk5e=y_qMZ8ByG=njatjKbFLZW+xQ@mail.gmail.com>
References: <CAE9FiQVLnyRB+pAqi22C5mCbHOOVKxsBhQKaB6P0p9f2LBL8bA@mail.gmail.com>
 <m1zkcmyjyd.fsf@fess.ebiederm.org>
 <CAE9FiQVj12UCGbOe4wZfx-L8tdab-1si-RA=vBnNeZ7cUNqyyg@mail.gmail.com>
 <CAE9FiQVPnO8-tuPoio0Wxv=8rjdm2tJbBk3+3ystueyYtZn9BA@mail.gmail.com>
 <20120216172735.GX9751@redhat.com>
 <CAE9FiQVhbAM9vjx-uFcuc0ndsUp0aez9_TsQHStje5G5iwYbag@mail.gmail.com>
 <20120216215603.GH9751@redhat.com>
 <m1y5s2ku36.fsf@fess.ebiederm.org>
 <m1fwe9bpk2.fsf@fess.ebiederm.org>
 <CABOkKT21zhyMwMmbR9WTipk5e=y_qMZ8ByG=njatjKbFLZW+xQ@mail.gmail.com>
Message-ID: <20120217201842.GP9751@redhat.com>

On Sat, Feb 18, 2012 at 12:49:16AM +0900, HATAYAMA Daisuke wrote:
> A few days ago I investigted the case where system is reseted due to
> triple fault caused by the NMI after idt is disabled in
> machine_kexec. I didn't see the reset when trigering the kdump with
> NMI since the NMI is masked until next iret instruction executed as
> described in 6.7.2. Handling Multiple NMIs of Intel Manual Vol.3A.
> The NMI mask remains untill the first iret execution on the 2nd
> kernel: just the return path of the first kernel_thread invocation for
> init process. The exact path is:

hmm.  So even though the local apic was disabled you still got an NMI?
That could have been from an external NMI.  I forget how that is wired up,
if it goes through the IOAPIC to the Local APIC or directly to the NMI pin
on the cpu.

> 
>   switch_to
>   -> ret_from_fork
>      -> int_ret_from_sys_call
>         -> retint_restore_args
>            -> irq_return
> 
> At that phase idt is already set up and kdump works.
> 
> From the discussion I interpret kdump doesn't assume this behaviour,
> right?

probably not.

> 
> BTW, does anyone know the detail of the NMI mask? I couldn't figure
> out about it from the Intel spec more than ``certain hardware
> conditions''... I expect those who look at here are x86 NMI experts.

I don't understand the question.

Cheers,
Don


From ebiederm at xmission.com  Fri Feb 17 22:21:52 2012
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Fri, 17 Feb 2012 19:21:52 -0800
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <20120217195430.GO9751@redhat.com> (Don Zickus's message of "Fri, 
 17 Feb 2012 14:54:30 -0500")
References: <m1ipjc3fsk.fsf@fess.ebiederm.org>
 <CAE9FiQVLnyRB+pAqi22C5mCbHOOVKxsBhQKaB6P0p9f2LBL8bA@mail.gmail.com>
 <m1zkcmyjyd.fsf@fess.ebiederm.org>
 <CAE9FiQVj12UCGbOe4wZfx-L8tdab-1si-RA=vBnNeZ7cUNqyyg@mail.gmail.com>
 <CAE9FiQVPnO8-tuPoio0Wxv=8rjdm2tJbBk3+3ystueyYtZn9BA@mail.gmail.com>
 <20120216172735.GX9751@redhat.com>
 <CAE9FiQVhbAM9vjx-uFcuc0ndsUp0aez9_TsQHStje5G5iwYbag@mail.gmail.com>
 <20120216215603.GH9751@redhat.com> <m1y5s2ku36.fsf@fess.ebiederm.org>
 <m1fwe9bpk2.fsf@fess.ebiederm.org> <20120217195430.GO9751@redhat.com>
Message-ID: <m1y5s07rn3.fsf@fess.ebiederm.org>

Don Zickus <dzickus at redhat.com> writes:

> On Fri, Feb 17, 2012 at 04:41:01AM -0800, Eric W. Biederman wrote:
>> 
>> The fix with a guarantee of no more scope creep is to just disable the
>> nmi watchdog on the kexec on panic path.
>> 
>> Don if you have time please figure out is needed to ignore nmi's and
>> possible record and/or report them while we boot, otherwise please cook
>> up a patch that just disables the nmi watchdog wherever we are sending
>> it from (the local apic or the ioapic).
>
> Can I keep things even simpler?  The original problem was the deadlock
> with the ioapic lock.  We fixed that by removing the call to
> disable_IO_APIC().  Can we just leave the disable_local_APIC calls in
> there for now?  Is there any real harm?

> All this rewrite is going to take time which will delay fixing a current
> problem with kexec on panic, the ioapic deadlock.

Hmm.

My apologies I just realized that we can not disable the nmi watchdog
safely in all cases.  To avoid the deadlock we fundamentally can not
write to the io_apic, because the locks are the io_apic write path.
The nmi watchdog can be sourced from either the local apics or the
io_apics.  To disable the nmi_watchdog we need at least potentially
to write io_apic.

So it appears to me that the only reasonable and robust thing we can
do is to ignore nmis in the kexec on panic path.

So it looks to me that the only path forward at this point is to fix
the other bug where an unexpected nmi will kill the kexec on panic boot.

I just took a look at the code in /sbin/kexec and that code does not in
fact change the idt except when we switch to 16bit mode, which we
definitely do not do in the kexec on panic case.  So it appears that we
don't need to coordinate an /sbin/kexec release with a kernel release to
ignore nmis.

In fact it looks like we only need to fix the interrupt descriptors
loaded in machine_kexec_64.c and head64.c to ignore nmis.

At which point we will have fixed two bugs and have a much more reliable
kexec on panic implementation.

Eric


From paulus at samba.org  Sun Feb 19 18:47:51 2012
From: paulus at samba.org (Paul Mackerras)
Date: Mon, 20 Feb 2012 10:47:51 +1100
Subject: [RFC PATCH v7 00/10] fadump: Firmware-assisted dump support for
 Powerpc.
In-Reply-To: <20120216111050.4733.38034.stgit@mars>
References: <20120216111050.4733.38034.stgit@mars>
Message-ID: <20120219234751.GA10186@bloggs.ozlabs.ibm.com>

On Thu, Feb 16, 2012 at 04:44:06PM +0530, Mahesh J Salgaonkar wrote:

> Please find the version 7 of the patchset that implements firmware-assisted
> dump mechanism to capture kernel crash dump for Powerpc architecture.
> Firmware-assisted dump is a robust mechanism to get reliable kernel crash
> dump with the assistance of firmware. This approach does not use kexec,
> instead firmware assists in booting the kdump kernel while preserving memory
> contents.

For the series:

Reviewed-by: Paul Mackerras <paulus at samba.org>

I think it's pretty much good enough to go in now.  I have one relatively
minor comment about a printk which could be addressed if you decide to
do another version of the series.

Paul.


From paulus at samba.org  Sun Feb 19 19:02:51 2012
From: paulus at samba.org (Paul Mackerras)
Date: Mon, 20 Feb 2012 11:02:51 +1100
Subject: [RFC PATCH v7 03/10] fadump: Register for firmware assisted dump.
In-Reply-To: <20120216111429.4733.24480.stgit@mars>
References: <20120216111050.4733.38034.stgit@mars>
 <20120216111429.4733.24480.stgit@mars>
Message-ID: <20120220000250.GB10186@bloggs.ozlabs.ibm.com>

On Thu, Feb 16, 2012 at 04:44:30PM +0530, Mahesh J Salgaonkar wrote:

> +/*
> + * Prepare for firmware-assisted dump.
> + */
> +int __init setup_fadump(void)
> +{
> +	if (!fw_dump.fadump_supported) {
> +		printk(KERN_ERR "Firmware-assisted dump is not supported on"
> +			" this hardware\n");
> +		return 0;
> +	}
> +
> +	fadump_show_config();
> +	/* Initialize the kernel dump memory structure for FAD registration. */
> +	if (fw_dump.reserve_dump_area_size)
> +		init_fadump_mem_struct(&fdm, fw_dump.reserve_dump_area_start);
> +	fadump_init_files();
> +
> +	return 1;
> +}
> +subsys_initcall(setup_fadump);

If I have read the code correctly, we are going to get this printk on
non-pSeries machines or on older pSeries machines, even if the user
has not put the fadump=on option on the kernel command line.  The
printk will be annoying since there is no actual error condition.  It
seems to me that the condition for the printk should include
fw_dump.fadump_enabled.  In other words you should probably add

	if (!fw_dump.fadump_enabled)
		return 0;

at the beginning of the function.

Paul.


From d.hatayama at jp.fujitsu.com  Sun Feb 19 19:52:22 2012
From: d.hatayama at jp.fujitsu.com (HATAYAMA Daisuke)
Date: Mon, 20 Feb 2012 09:52:22 +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: <20120220.095222.59660243.d.hatayama@jp.fujitsu.com>

From: "Suzuki K. Poulose" <suzuki at in.ibm.com>
Subject: [PATCH][makedumpfile] Fix compilation error in sadump_info.h
Date: Fri, 13 Jan 2012 12:27:50 +0530

> 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>

Oh, I didn't notice this commit... Thanks for fixing.

Thanks.
HATAYAMA, Daisuke

> ---
> 
>  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;
>  }
> 
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

From d.hatayama at jp.fujitsu.com  Sun Feb 19 21:19:15 2012
From: d.hatayama at jp.fujitsu.com (HATAYAMA Daisuke)
Date: Mon, 20 Feb 2012 11:19:15 +0900 (   )
Subject: [PATCH][makedumpfile] sadump: check if given cpu is online in
 per-cpu related helper functions
Message-ID: <20120220.111915.28783507.d.hatayama@jp.fujitsu.com>

Per-cpu helper functions sanity check given cpu ids if they are
not-minus and less than the maximal but it should have checked if they
are online. By this mistake, one cannot see generated vmcore correctly
if sadump collects vmcore when some cpus are offline e.g. using cpu
hotplug or panic and so all the cpus except for a unique CPU halting.

Signed-off-by: HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com>
---
 sadump_info.c |   18 ++++++++++++++----
 1 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/sadump_info.c b/sadump_info.c
index dce0841..69763be 100644
--- a/sadump_info.c
+++ b/sadump_info.c
@@ -46,7 +46,7 @@
 			  KEXEC_CORE_NOTE_DESC_BYTES )
 
 #define for_each_online_cpu(cpu)					\
-	for (cpu = 0; cpu < BITPERBYTE * si->cpumask_size; ++cpu)	\
+	for (cpu = 0; cpu < max_mask_cpu(); ++cpu)	\
 		if (is_online_cpu(cpu))
 
 enum {
@@ -95,6 +95,7 @@ static int read_sadump_header_diskset(int diskid, struct sadump_diskset_info *sd
 static unsigned long long pfn_to_block(unsigned long long pfn);
 static int lookup_diskset(unsigned long long whole_offset, int *diskid,
 			  unsigned long long *disk_offset);
+static int max_mask_cpu(void);
 static int cpu_online_mask_init(void);
 static int per_cpu_init(void);
 static int get_data_from_elf_note_desc(const char *note_buf, uint32_t n_descsz,
@@ -799,6 +800,12 @@ sadump_initialize_bitmap_memory(void)
 }
 
 static int
+max_mask_cpu(void)
+{
+	return BITPERBYTE * si->cpumask_size;
+}
+
+static int
 cpu_online_mask_init(void)
 {
 	ulong cpu_online_mask_addr;
@@ -1289,6 +1296,9 @@ is_online_cpu(int cpu)
 {
 	unsigned long mask;
 
+	if (cpu < 0 || cpu >= max_mask_cpu())
+		return FALSE;
+
 	mask = ULONG(si->cpu_online_mask_buf +
 		     (cpu / BITPERWORD) * sizeof(unsigned long));
 
@@ -1300,7 +1310,7 @@ legacy_per_cpu_ptr(unsigned long ptr, int cpu)
 {
 	unsigned long addr;
 
-	if (cpu < 0 || cpu >= get_nr_cpus())
+	if (!is_online_cpu(cpu))
 		return 0UL;
 
 	if (!readmem(VADDR, ~ptr + cpu*sizeof(unsigned long), &addr,
@@ -1313,7 +1323,7 @@ legacy_per_cpu_ptr(unsigned long ptr, int cpu)
 static unsigned long
 per_cpu_ptr(unsigned long ptr, int cpu)
 {
-	if (cpu < 0 || cpu >= get_nr_cpus())
+	if (!is_online_cpu(cpu))
 		return 0UL;
 
 	if (si->__per_cpu_offset[cpu] == si->__per_cpu_load)
@@ -1329,7 +1339,7 @@ get_prstatus_from_crash_notes(int cpu, char *prstatus_buf)
 	char note_buf[KEXEC_NOTE_BYTES], zero_buf[KEXEC_NOTE_BYTES];
 	char *prstatus_ptr;
 
-	if (cpu < 0 || get_nr_cpus() <= cpu)
+	if (!is_online_cpu(cpu))
 		return FALSE;
 
 	if (SYMBOL(crash_notes) == NOT_FOUND_SYMBOL)
-- 
1.7.4.4




From d.hatayama at jp.fujitsu.com  Mon Feb 20 00:17:33 2012
From: d.hatayama at jp.fujitsu.com (HATAYAMA Daisuke)
Date: Mon, 20 Feb 2012 14:17:33 +0900 (   )
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <20120217201842.GP9751@redhat.com>
References: <m1fwe9bpk2.fsf@fess.ebiederm.org>
 <CABOkKT21zhyMwMmbR9WTipk5e=y_qMZ8ByG=njatjKbFLZW+xQ@mail.gmail.com>
 <20120217201842.GP9751@redhat.com>
Message-ID: <20120220.141733.294710222.d.hatayama@jp.fujitsu.com>

From: Don Zickus <dzickus at redhat.com>
Subject: Re: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in crash path
Date: Fri, 17 Feb 2012 15:18:42 -0500

> On Sat, Feb 18, 2012 at 12:49:16AM +0900, HATAYAMA Daisuke wrote:
>> A few days ago I investigted the case where system is reseted due to
>> triple fault caused by the NMI after idt is disabled in
>> machine_kexec. I didn't see the reset when trigering the kdump with
>> NMI since the NMI is masked until next iret instruction executed as
>> described in 6.7.2. Handling Multiple NMIs of Intel Manual Vol.3A.
>> The NMI mask remains untill the first iret execution on the 2nd
>> kernel: just the return path of the first kernel_thread invocation for
>> init process. The exact path is:
> 
> hmm.  So even though the local apic was disabled you still got an NMI?
> That could have been from an external NMI.  I forget how that is wired up,
> if it goes through the IOAPIC to the Local APIC or directly to the NMI pin
> on the cpu.
> 

Please don't confused. I used RHEL kernels based on 2.6.18 and
2.6.32. I didn't use the patch disabling local apic.

>> 
>>   switch_to
>>   -> ret_from_fork
>>      -> int_ret_from_sys_call
>>         -> retint_restore_args
>>            -> irq_return
>> 
>> At that phase idt is already set up and kdump works.
>> 
>> From the discussion I interpret kdump doesn't assume this behaviour,
>> right?
> 
> probably not.
> 

Thanks.

>> 
>> BTW, does anyone know the detail of the NMI mask? I couldn't figure
>> out about it from the Intel spec more than ``certain hardware
>> conditions''... I expect those who look at here are x86 NMI experts.
> 
> I don't understand the question.
> 
> Cheers,
> Don
> 

Fig 10-4 explaining Local APIC Structure says INIT/NMI/SMI are
directly sent to CPU Core, but the later part of this route is not
explained formally anyware. Only the explanation is the sentence in
6.7 Nonmaskable Interrupt (NMI):

  The processor also invokes certain hardware conditions to insure
  that no other interrupts, including NMI interrupts, are received
  until the NMI handler has completed executing.

I'm just wondering if this is explained more formally anyware.

Thanks.
HATAYAMA, Daisuke



From kumagai-atsushi at mxc.nes.nec.co.jp  Mon Feb 20 03:02:53 2012
From: kumagai-atsushi at mxc.nes.nec.co.jp (Atsushi Kumagai)
Date: Mon, 20 Feb 2012 17:02:53 +0900
Subject: [PATCH][makedumpfile] sadump: check if given cpu is online in
 per-cpu related helper functions
In-Reply-To: <20120220.111915.28783507.d.hatayama@jp.fujitsu.com>
References: <20120220.111915.28783507.d.hatayama@jp.fujitsu.com>
Message-ID: <20120220170253.e79219aa.kumagai-atsushi@mxc.nes.nec.co.jp>

Hi Hatayama-san,

On Mon, 20 Feb 2012 11:19:15 +0900 (   )
HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> wrote:

> Per-cpu helper functions sanity check given cpu ids if they are
> not-minus and less than the maximal but it should have checked if they
> are online. By this mistake, one cannot see generated vmcore correctly
> if sadump collects vmcore when some cpus are offline e.g. using cpu
> hotplug or panic and so all the cpus except for a unique CPU halting.
> 
> Signed-off-by: HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com>
> ---
>  sadump_info.c |   18 ++++++++++++++----
>  1 files changed, 14 insertions(+), 4 deletions(-)

Thank you for your patch. 
I will review it and it will be merged into v1.4.4
because I'm preparing the release of v1.4.3 now.

Thanks
Atsushi Kumagai


From d.hatayama at jp.fujitsu.com  Mon Feb 20 04:10:00 2012
From: d.hatayama at jp.fujitsu.com (HATAYAMA Daisuke)
Date: Mon, 20 Feb 2012 18:10:00 +0900
Subject: [PATCH makedumpfile 0/2] LZO Compression Support
Message-ID: <20120220090528.30966.59163.stgit@localhost6.localdomain6>

The following series implements LZO compression support to
makedumpfile. LZO is as good as in size but by far better in speed
than ZLIB, readucing down time during generation of crash dump and
refiltering.

The RFC discussion:

  http://lists.infradead.org/pipermail/kexec/2011-November/005783.html
  http://lists.infradead.org/pipermail/kexec/2011-December/005868.html

How to build:

  1. Get lzo libraries: lzo, lzo-devel and lzo-minilzo from either of
  the following:

    1) Original author's website:
       http://www.oberhumer.com/opensource/lzo/

    2) yum framework on fedora. Older releases don't have the packages.

  2. Apply the patch set to makedumpfile v1.4.2.

  3. Do make.

How to use:

  Introduce new -l option. If a user specify this, makedumpfile
  generates dumpfile compressed by pages with lzo compression.

  Example)
  $ makedumpfile -l vmcore dumpfile

Performance evaluation:

  - Kumagai-san's evaluation simulating actually working servers:
    http://lists.infradead.org/pipermail/kexec/2011-December/005868.html

  - My evaluation focusing on the worst cases:
    http://lists.infradead.org/pipermail/kexec/2011-November/005783.html

LZO Support for crash:

  I'll post LZO support patch for crash after makedumpfile merges
  these patches.

---

HATAYAMA Daisuke (2):
      Add help and manual messages about LZO compression support
      Add LZO Support


 Makefile       |    2 +-
 diskdump_mod.h |    3 ++-
 makedumpfile.8 |    6 +++---
 makedumpfile.c |   57 +++++++++++++++++++++++++++++++++++++++++++++++---------
 makedumpfile.h |    2 ++
 print_info.c   |   16 ++++++++--------
 6 files changed, 64 insertions(+), 22 deletions(-)

-- 
HATAYAMA Daisuke


From d.hatayama at jp.fujitsu.com  Mon Feb 20 04:10:05 2012
From: d.hatayama at jp.fujitsu.com (HATAYAMA Daisuke)
Date: Mon, 20 Feb 2012 18:10:05 +0900
Subject: [PATCH makedumpfile 1/2] Add LZO Support
In-Reply-To: <20120220090528.30966.59163.stgit@localhost6.localdomain6>
References: <20120220090528.30966.59163.stgit@localhost6.localdomain6>
Message-ID: <20120220091005.30966.41255.stgit@localhost6.localdomain6>

Add -l option as one of the command-line options users can specify. If
-l option is specified, then makedumpfile generates dumpfile in
kdump-compressed format with lzo compression by each page.

Signed-off-by: HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com>
---

 Makefile       |    2 +-
 diskdump_mod.h |    3 ++-
 makedumpfile.c |   57 +++++++++++++++++++++++++++++++++++++++++++++++---------
 makedumpfile.h |    2 ++
 4 files changed, 53 insertions(+), 11 deletions(-)

diff --git a/Makefile b/Makefile
index e6b7b89..21b3058 100644
--- a/Makefile
+++ b/Makefile
@@ -29,7 +29,7 @@ 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 = -ldw -lbz2 -lebl -ldl -lelf -lz
+LIBS = -ldw -lbz2 -lebl -ldl -lelf -lz -llzo2
 ifneq ($(LINKTYPE), dynamic)
 LIBS := -static $(LIBS)
 endif
diff --git a/diskdump_mod.h b/diskdump_mod.h
index c1de972..e672485 100644
--- a/diskdump_mod.h
+++ b/diskdump_mod.h
@@ -78,7 +78,8 @@ struct kdump_sub_header {
 };
 
 /* page flags */
-#define DUMP_DH_COMPRESSED	0x1	/* page is compressed               */
+#define DUMP_DH_COMPRESSED_ZLIB	0x1	/* page is compressed with zlib */
+#define DUMP_DH_COMPRESSED_LZO	0x2	/* paged is compressed with lzo */
 
 /* descriptor of each page for vmcore */
 typedef struct page_desc {
diff --git a/makedumpfile.c b/makedumpfile.c
index c51fda3..e0079b8 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -257,7 +257,7 @@ readpmem_kdump_compressed(unsigned long long paddr, void *bufptr, size_t size)
 		goto error;
 	}
 
-	if (pd.flags & DUMP_DH_COMPRESSED) {
+	if (pd.flags & DUMP_DH_COMPRESSED_ZLIB) {
 		retlen = info->page_size;
 		ret = uncompress((unsigned char *)buf2, &retlen,
 					(unsigned char *)buf, pd.size);
@@ -266,6 +266,17 @@ readpmem_kdump_compressed(unsigned long long paddr, void *bufptr, size_t size)
 			goto error;
 		}
 		memcpy(bufptr, buf2 + page_offset, size);
+	} else if (info->flag_lzo_support
+		   && (pd.flags & DUMP_DH_COMPRESSED_LZO)) {
+		retlen = info->page_size;
+		ret = lzo1x_decompress_safe((unsigned char *)buf, pd.size,
+					    (unsigned char *)buf2, &retlen,
+					    LZO1X_MEM_DECOMPRESS);
+		if ((ret != LZO_E_OK) || (retlen != info->page_size)) {
+			ERRMSG("Uncompress failed: %d\n", ret);
+			goto error;
+		}
+		memcpy(bufptr, buf2 + page_offset, size);
 	} else
 		memcpy(bufptr, buf + page_offset, size);
 
@@ -2498,6 +2509,9 @@ initial(void)
 	unsigned long size;
 	int debug_info = FALSE;
 
+	if (lzo_init() == LZO_E_OK)
+		info->flag_lzo_support = TRUE;
+
 	if (!is_xen_memory() && info->flag_exclude_xen_dom) {
 		MSG("'-X' option is disable,");
 		MSG("because %s is not Xen's memory core image.\n", info->name_memory);
@@ -4665,10 +4679,11 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data *cd_page)
 	off_t offset_data = 0;
 	struct disk_dump_header *dh = info->dump_header;
 	unsigned char buf[info->page_size], *buf_out = NULL;
-	unsigned long len_buf_out;
+	unsigned long len_buf_out, len_buf_out_zlib, len_buf_out_lzo;
 	struct dump_bitmap bitmap2;
 	struct timeval tv_start;
 	const off_t failed = (off_t)-1;
+	lzo_bytep wrkmem = NULL;
 
 	int ret = FALSE;
 
@@ -4677,7 +4692,16 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data *cd_page)
 
 	initialize_2nd_bitmap(&bitmap2);
 
-	len_buf_out = compressBound(info->page_size);
+	if ((wrkmem = malloc(LZO1X_1_MEM_COMPRESS)) == NULL) {
+		ERRMSG("Can't allocate memory for the working memory. %s\n",
+		       strerror(errno));
+		goto out;
+	}
+
+	len_buf_out_zlib = compressBound(info->page_size);
+	len_buf_out_lzo = info->page_size + info->page_size / 16 + 64 + 3;
+	len_buf_out = MAX(len_buf_out_zlib, len_buf_out_lzo);
+
 	if ((buf_out = malloc(len_buf_out)) == NULL) {
 		ERRMSG("Can't allocate memory for the compression buffer. %s\n",
 		    strerror(errno));
@@ -4759,11 +4783,21 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data *cd_page)
 		 * Compress the page data.
 		 */
 		size_out = len_buf_out;
-		if (info->flag_compress
-		    && (compress2(buf_out, &size_out, buf,
-		    info->page_size, Z_BEST_SPEED) == Z_OK)
+		if ((info->flag_compress & DUMP_DH_COMPRESSED_ZLIB)
+		    && ((size_out = len_buf_out),
+			compress2(buf_out, &size_out, buf, info->page_size,
+				  Z_BEST_SPEED) == Z_OK)
 		    && (size_out < info->page_size)) {
-			pd.flags = 1;
+			pd.flags = DUMP_DH_COMPRESSED_ZLIB;
+			pd.size  = size_out;
+			memcpy(buf, buf_out, pd.size);
+		} else if (info->flag_lzo_support
+			   && (info->flag_compress & DUMP_DH_COMPRESSED_LZO)
+			   && ((size_out = info->page_size),
+			       lzo1x_1_compress(buf, info->page_size, buf_out,
+						&size_out, wrkmem) == LZO_E_OK)
+			   && (size_out < info->page_size)) {
+			pd.flags = DUMP_DH_COMPRESSED_LZO;
 			pd.size  = size_out;
 			memcpy(buf, buf_out, pd.size);
 		} else {
@@ -4806,6 +4840,8 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data *cd_page)
 out:
 	if (buf_out != NULL)
 		free(buf_out);
+	if (wrkmem != NULL)
+		free(wrkmem);
 
 	return ret;
 }
@@ -6896,7 +6932,7 @@ main(int argc, char *argv[])
 
 	info->block_order = DEFAULT_ORDER;
 	message_level = DEFAULT_MSG_LEVEL;
-	while ((opt = getopt_long(argc, argv, "b:cDd:EFfg:hi:MRrsvXx:", longopts,
+	while ((opt = getopt_long(argc, argv, "b:cDd:EFfg:hi:lMRrsvXx:", longopts,
 	    NULL)) != -1) {
 		switch (opt) {
 		case 'b':
@@ -6906,7 +6942,7 @@ main(int argc, char *argv[])
 			info->name_filterconfig = optarg;
 			break;
 		case 'c':
-			info->flag_compress = 1;
+			info->flag_compress = DUMP_DH_COMPRESSED_ZLIB;
 			break;
 		case 'D':
 			flag_debug = TRUE;
@@ -6945,6 +6981,9 @@ main(int argc, char *argv[])
 				goto out;
 			info->flag_sadump_diskset = 1;
 			break;
+		case 'l':
+			info->flag_compress = DUMP_DH_COMPRESSED_LZO;
+			break;
 		case 'm':
 			message_level = atoi(optarg);
 			break;
diff --git a/makedumpfile.h b/makedumpfile.h
index ebb8929..9594ca7 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -31,6 +31,7 @@
 #include <libelf.h>
 #include <byteswap.h>
 #include <getopt.h>
+#include <lzo/lzo1x.h>
 #include "common.h"
 #include "dwarf_info.h"
 #include "diskdump_mod.h"
@@ -767,6 +768,7 @@ struct DumpInfo {
 	int		num_dump_level;      /* number of dump level */
 	int		array_dump_level[NUM_ARRAY_DUMP_LEVEL];
 	int		flag_compress;       /* flag of compression */
+	int		flag_lzo_support;    /* flag of LZO compression support */
 	int		flag_elf_dumpfile;   /* flag of creating ELF dumpfile */
 	int		flag_generate_vmcoreinfo;/* flag of generating vmcoreinfo file */
 	int		flag_read_vmcoreinfo;    /* flag of reading vmcoreinfo file */



From d.hatayama at jp.fujitsu.com  Mon Feb 20 04:10:10 2012
From: d.hatayama at jp.fujitsu.com (HATAYAMA Daisuke)
Date: Mon, 20 Feb 2012 18:10:10 +0900
Subject: [PATCH makedumpfile 2/2] Add help and manual messages about LZO
 compression support
In-Reply-To: <20120220090528.30966.59163.stgit@localhost6.localdomain6>
References: <20120220090528.30966.59163.stgit@localhost6.localdomain6>
Message-ID: <20120220091010.30966.39926.stgit@localhost6.localdomain6>

Signed-off-by: HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com>
---

 makedumpfile.8 |    6 +++---
 print_info.c   |   16 ++++++++--------
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/makedumpfile.8 b/makedumpfile.8
index 4733420..f607bf5 100644
--- a/makedumpfile.8
+++ b/makedumpfile.8
@@ -121,8 +121,8 @@ configuration, you need to use --diskset option.
 .SH OPTIONS
 
 .TP
-\fB\-c\fR
-Compress dump data by each page.
+\fB\-c,\-l\fR
+Compress dump data by each page using zlib for -c option or lzo for -l option.
 .br
 A user cannot specify this option with \-E option, because the ELF format does
 not support compressed data.
@@ -196,7 +196,7 @@ by dump_level 11, makedumpfile retries it by dump_level 31.
 \fB\-E\fR
 Create \fIDUMPFILE\fR in the ELF format.
 .br
-This option cannot be specified with \-c option, because the ELF format does not
+This option cannot be specified with either of \-c option or \-l option, because the ELF format does not
 support compressed data.
 .br
 .B Example:
diff --git a/print_info.c b/print_info.c
index 31460b7..237892e 100644
--- a/print_info.c
+++ b/print_info.c
@@ -35,15 +35,15 @@ print_usage(void)
 	MSG("\n");
 	MSG("Usage:\n");
 	MSG("  Creating DUMPFILE:\n");
-	MSG("  # makedumpfile    [-c|-E] [-d DL] [-x VMLINUX|-i VMCOREINFO] VMCORE DUMPFILE\n");
+	MSG("  # makedumpfile    [-c|-l|-E] [-d DL] [-x VMLINUX|-i VMCOREINFO] VMCORE DUMPFILE\n");
 	MSG("\n");
 	MSG("  Creating DUMPFILE with filtered kernel data specified through filter config\n");
 	MSG("  file:\n");
-	MSG("  # makedumpfile    [-c|-E] [-d DL] -x VMLINUX --config FILTERCONFIGFILE VMCORE\n");
+	MSG("  # makedumpfile    [-c|-l|-E] [-d DL] -x VMLINUX --config FILTERCONFIGFILE VMCORE\n");
 	MSG("    DUMPFILE\n");
 	MSG("\n");
 	MSG("  Outputting the dump data in the flattened format to the standard output:\n");
-	MSG("  # makedumpfile -F [-c|-E] [-d DL] [-x VMLINUX|-i VMCOREINFO] VMCORE\n");
+	MSG("  # makedumpfile -F [-c|-l|-E] [-d DL] [-x VMLINUX|-i VMCOREINFO] VMCORE\n");
 	MSG("\n");
 	MSG("  Rearranging the dump data in the flattened format to a readable DUMPFILE:\n");
 	MSG("  # makedumpfile -R DUMPFILE\n");
@@ -70,14 +70,14 @@ print_usage(void)
 	MSG("\n");
 	MSG("\n");
 	MSG("  Creating DUMPFILE from multiple VMCOREs generated on sadump diskset configuration:\n");
-	MSG("  # makedumpfile [-c] [-d DL] -x VMLINUX --diskset=VMCORE1 --diskset=VMCORE2\n");
+	MSG("  # makedumpfile [-c|-l] [-d DL] -x VMLINUX --diskset=VMCORE1 --diskset=VMCORE2\n");
 	MSG("    [--diskset=VMCORE3 ..] DUMPFILE\n");
 	MSG("\n");
 	MSG("\n");
 	MSG("Available options:\n");
-	MSG("  [-c]:\n");
-	MSG("      Compress dump data by each page.\n");
-	MSG("      A user cannot specify this option with -E option, because the ELF format\n");
+	MSG("  [-c|-l]:\n");
+	MSG("      Compress dump data by each page using zlib for -c option and lzo for -l option.\n");
+	MSG("      A user cannot specify either of these options with -E option, because the ELF format\n");
 	MSG("      does not support compressed data.\n");
 	MSG("      THIS IS ONLY FOR THE CRASH UTILITY.\n");
 	MSG("\n");
@@ -103,7 +103,7 @@ print_usage(void)
 	MSG("\n");
 	MSG("  [-E]:\n");
 	MSG("      Create DUMPFILE in the ELF format.\n");
-	MSG("      This option cannot be specified with -c option, because the ELF\n");
+	MSG("      This option cannot be specified with either of -c option or -l option, because the ELF\n");
 	MSG("      format does not support compressed data.\n");
 	MSG("\n");
 	MSG("  [-x VMLINUX]:\n");



From d.hatayama at jp.fujitsu.com  Mon Feb 20 04:17:40 2012
From: d.hatayama at jp.fujitsu.com (HATAYAMA Daisuke)
Date: Mon, 20 Feb 2012 18:17:40 +0900 (   )
Subject: [PATCH][makedumpfile] sadump: check if given cpu is online in
 per-cpu related helper functions
In-Reply-To: <20120220170253.e79219aa.kumagai-atsushi@mxc.nes.nec.co.jp>
References: <20120220.111915.28783507.d.hatayama@jp.fujitsu.com>
 <20120220170253.e79219aa.kumagai-atsushi@mxc.nes.nec.co.jp>
Message-ID: <20120220.181740.278734450.d.hatayama@jp.fujitsu.com>

Hello Kumagai-san,

From: Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp>
Subject: Re: [PATCH][makedumpfile] sadump: check if given cpu is online in per-cpu related helper functions
Date: Mon, 20 Feb 2012 17:02:53 +0900

> Hi Hatayama-san,
> 
> On Mon, 20 Feb 2012 11:19:15 +0900 (   )
> HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> wrote:
> 
>> Per-cpu helper functions sanity check given cpu ids if they are
>> not-minus and less than the maximal but it should have checked if they
>> are online. By this mistake, one cannot see generated vmcore correctly
>> if sadump collects vmcore when some cpus are offline e.g. using cpu
>> hotplug or panic and so all the cpus except for a unique CPU halting.
>> 
>> Signed-off-by: HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com>
>> ---
>>  sadump_info.c |   18 ++++++++++++++----
>>  1 files changed, 14 insertions(+), 4 deletions(-)
> 
> Thank you for your patch. 
> I will review it and it will be merged into v1.4.4
> because I'm preparing the release of v1.4.3 now.
> 
> Thanks
> Atsushi Kumagai
> 

I see. Thanks.

Thanks.
HATAYAMA, Daisuke



From kumagai-atsushi at mxc.nes.nec.co.jp  Mon Feb 20 04:56:01 2012
From: kumagai-atsushi at mxc.nes.nec.co.jp (Atsushi Kumagai)
Date: Mon, 20 Feb 2012 18:56:01 +0900
Subject: [PATCH v1 0/4][makedumpfile] vmalloc translation support for PPC32
In-Reply-To: <1329467969.2892.58.camel@pasglop>
References: <20120216033411.7972.77705.stgit@suzukikp>
 <20120217093220.0c2993a1.kumagai-atsushi@mxc.nes.nec.co.jp>
 <4F3DEBCF.8000201@in.ibm.com> <1329467969.2892.58.camel@pasglop>
Message-ID: <20120220185601.d08b8864.kumagai-atsushi@mxc.nes.nec.co.jp>

Hi, Benjamin
Hi, Suzuki

On Fri, 17 Feb 2012 19:39:29 +1100
Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote:

> On Fri, 2012-02-17 at 11:25 +0530, Suzuki K. Poulose wrote:
> > > Could you tell me what kind of data is stored in vmalloc region in
> > PPC ?
> > > I want to estimate importance of your patches for makedumpfile.
> > I know at least the modules are loaded in the vmalloc'd region. I have
> > Cc'ed linux-ppc dev. We should be able to get enough info from the
> > experts here.
> > 
> > Josh / Kumar / Others,
> > 
> > Could you please let us know your thoughts ?
> 
> Modules, driver IO mappings, etc... I can see that being useful for
> crashdumps.

Thank you for your information.

The above data may be required for one function of makedumpfile (filter
out kernel data) but not so crucial for makedumpfile as page descriptors
and related data(e.g. pglist_data).

Moreover, I'm preparing the release of v1.4.3 now, so I'll merge vmalloc
support for PPC32 into v1.4.4. Is it all right for you, Suzuki ?


Thanks
Atsushi Kumagai


From suzuki at in.ibm.com  Mon Feb 20 05:31:03 2012
From: suzuki at in.ibm.com (Suzuki K. Poulose)
Date: Mon, 20 Feb 2012 16:01:03 +0530
Subject: [PATCH v1 0/4][makedumpfile] vmalloc translation support for PPC32
In-Reply-To: <20120220185601.d08b8864.kumagai-atsushi@mxc.nes.nec.co.jp>
References: <20120216033411.7972.77705.stgit@suzukikp>
 <20120217093220.0c2993a1.kumagai-atsushi@mxc.nes.nec.co.jp>
 <4F3DEBCF.8000201@in.ibm.com> <1329467969.2892.58.camel@pasglop>
 <20120220185601.d08b8864.kumagai-atsushi@mxc.nes.nec.co.jp>
Message-ID: <4F4220E7.2060505@in.ibm.com>

On 02/20/2012 03:26 PM, Atsushi Kumagai wrote:
> Hi, Benjamin
> Hi, Suzuki
>
> On Fri, 17 Feb 2012 19:39:29 +1100
> Benjamin Herrenschmidt<benh at kernel.crashing.org>  wrote:
>
>> On Fri, 2012-02-17 at 11:25 +0530, Suzuki K. Poulose wrote:
>>>> Could you tell me what kind of data is stored in vmalloc region in
>>> PPC ?
>>>> I want to estimate importance of your patches for makedumpfile.
>>> I know at least the modules are loaded in the vmalloc'd region. I have
>>> Cc'ed linux-ppc dev. We should be able to get enough info from the
>>> experts here.
>>>
>>> Josh / Kumar / Others,
>>>
>>> Could you please let us know your thoughts ?
>>
>> Modules, driver IO mappings, etc... I can see that being useful for
>> crashdumps.
>
> Thank you for your information.
>
> The above data may be required for one function of makedumpfile (filter
> out kernel data) but not so crucial for makedumpfile as page descriptors
> and related data(e.g. pglist_data).
>
> Moreover, I'm preparing the release of v1.4.3 now, so I'll merge vmalloc
> support for PPC32 into v1.4.4. Is it all right for you, Suzuki ?

Yep,  fine with me.

Thanks
Suzuki



From mahesh at linux.vnet.ibm.com  Mon Feb 20 07:15:03 2012
From: mahesh at linux.vnet.ibm.com (Mahesh J Salgaonkar)
Date: Mon, 20 Feb 2012 17:45:03 +0530
Subject: [UPDATED] [RFC PATCH v7 03/10] fadump: Register for firmware
 assisted dump.
In-Reply-To: <20120220000250.GB10186@bloggs.ozlabs.ibm.com>
References: <20120216111050.4733.38034.stgit@mars>
 <20120216111429.4733.24480.stgit@mars>
 <20120220000250.GB10186@bloggs.ozlabs.ibm.com>
Message-ID: <20120220121503.GA10207@in.ibm.com>

On 2012-02-20 11:02:51 Mon, Paul Mackerras wrote:
> On Thu, Feb 16, 2012 at 04:44:30PM +0530, Mahesh J Salgaonkar wrote:
> 
> If I have read the code correctly, we are going to get this printk on
> non-pSeries machines or on older pSeries machines, even if the user
> has not put the fadump=on option on the kernel command line.  The
> printk will be annoying since there is no actual error condition.  It
> seems to me that the condition for the printk should include
> fw_dump.fadump_enabled.  In other words you should probably add
> 
> 	if (!fw_dump.fadump_enabled)
> 		return 0;
> 
> at the beginning of the function.

Hi Paul,

Thanks for pointing it out. Please find the updated patch below.

The existing patches above this (4/10 through 10/10) cleanly applies
on this update.

Thanks,
-Mahesh.

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

This patch registers for firmware-assisted dump using rtas token
ibm,configure-kernel-dump. During registration firmware is informed about
the reserved area where it saves the CPU state data, HPTE table and contents
of RMR region at the time of kernel crash. Apart from this, firmware also
preserves the contents of entire partition memory even if it is not specified
during registration.

This patch also populates sysfs files under /sys/kernel to display
fadump status and reserved memory regions.

This patch introduces fadump_registered sysfs control file which will be
used by kdump init scripts to start/stop firmware assisted dump. echo 1 to
/sys/kernel/fadump_registered file for fadump registration and
echo 0 to /sys/kernel/fadump_registered file for fadump un-registration.

Signed-off-by: Mahesh Salgaonkar <mahesh at linux.vnet.ibm.com>
---
 arch/powerpc/include/asm/fadump.h |   57 ++++++
 arch/powerpc/kernel/fadump.c      |  355 +++++++++++++++++++++++++++++++++++++
 arch/powerpc/kernel/iommu.c       |    8 +
 arch/powerpc/mm/hash_utils_64.c   |   11 +
 4 files changed, 427 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/fadump.h b/arch/powerpc/include/asm/fadump.h
index 7be25d3..bbaf278 100644
--- a/arch/powerpc/include/asm/fadump.h
+++ b/arch/powerpc/include/asm/fadump.h
@@ -48,6 +48,58 @@
 #define FADUMP_HPTE_REGION	0x0002
 #define FADUMP_REAL_MODE_REGION	0x0011
 
+/* Dump request flag */
+#define FADUMP_REQUEST_FLAG	0x00000001
+
+/* FAD commands */
+#define FADUMP_REGISTER		1
+#define FADUMP_UNREGISTER	2
+#define FADUMP_INVALIDATE	3
+
+/* Kernel Dump section info */
+struct fadump_section {
+	u32	request_flag;
+	u16	source_data_type;
+	u16	error_flags;
+	u64	source_address;
+	u64	source_len;
+	u64	bytes_dumped;
+	u64	destination_address;
+};
+
+/* ibm,configure-kernel-dump header. */
+struct fadump_section_header {
+	u32	dump_format_version;
+	u16	dump_num_sections;
+	u16	dump_status_flag;
+	u32	offset_first_dump_section;
+
+	/* Fields for disk dump option. */
+	u32	dd_block_size;
+	u64	dd_block_offset;
+	u64	dd_num_blocks;
+	u32	dd_offset_disk_path;
+
+	/* Maximum time allowed to prevent an automatic dump-reboot. */
+	u32	max_time_auto;
+};
+
+/*
+ * Firmware Assisted dump memory structure. This structure is required for
+ * registering future kernel dump with power firmware through rtas call.
+ *
+ * No disk dump option. Hence disk dump path string section is not included.
+ */
+struct fadump_mem_struct {
+	struct fadump_section_header	header;
+
+	/* Kernel dump sections */
+	struct fadump_section		cpu_state_data;
+	struct fadump_section		hpte_region;
+	struct fadump_section		rmr_region;
+};
+
+/* Firmware-assisted dump configuration details. */
 struct fw_dump {
 	unsigned long	cpu_state_data_size;
 	unsigned long	hpte_region_size;
@@ -62,10 +114,15 @@ struct fw_dump {
 	unsigned long	fadump_enabled:1;
 	unsigned long	fadump_supported:1;
 	unsigned long	dump_active:1;
+	unsigned long	dump_registered:1;
 };
 
 extern int early_init_dt_scan_fw_dump(unsigned long node,
 		const char *uname, int depth, void *data);
 extern int fadump_reserve_mem(void);
+extern int setup_fadump(void);
+extern int is_fadump_active(void);
+#else	/* CONFIG_FA_DUMP */
+static inline int is_fadump_active(void) { return 0; }
 #endif
 #endif
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index deb276a..eb8f782 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -29,6 +29,9 @@
 
 #include <linux/string.h>
 #include <linux/memblock.h>
+#include <linux/delay.h>
+#include <linux/debugfs.h>
+#include <linux/seq_file.h>
 
 #include <asm/page.h>
 #include <asm/prom.h>
@@ -36,6 +39,10 @@
 #include <asm/fadump.h>
 
 static struct fw_dump fw_dump;
+static struct fadump_mem_struct fdm;
+static const struct fadump_mem_struct *fdm_active;
+
+static DEFINE_MUTEX(fadump_mutex);
 
 /* Scan the Firmware Assisted dump configuration details. */
 int __init early_init_dt_scan_fw_dump(unsigned long node,
@@ -64,7 +71,8 @@ int __init early_init_dt_scan_fw_dump(unsigned long node,
 	 * The 'ibm,kernel-dump' rtas node is present only if there is
 	 * dump data waiting for us.
 	 */
-	if (of_get_flat_dt_prop(node, "ibm,kernel-dump", NULL))
+	fdm_active = of_get_flat_dt_prop(node, "ibm,kernel-dump", NULL);
+	if (fdm_active)
 		fw_dump.dump_active = 1;
 
 	/* Get the sizes required to store dump data for the firmware provided
@@ -98,6 +106,85 @@ int __init early_init_dt_scan_fw_dump(unsigned long node,
 	return 1;
 }
 
+int is_fadump_active(void)
+{
+	return fw_dump.dump_active;
+}
+
+/* Print firmware assisted dump configurations for debugging purpose. */
+static void fadump_show_config(void)
+{
+	pr_debug("Support for firmware-assisted dump (fadump): %s\n",
+			(fw_dump.fadump_supported ? "present" : "no support"));
+
+	if (!fw_dump.fadump_supported)
+		return;
+
+	pr_debug("Fadump enabled    : %s\n",
+				(fw_dump.fadump_enabled ? "yes" : "no"));
+	pr_debug("Dump Active       : %s\n",
+				(fw_dump.dump_active ? "yes" : "no"));
+	pr_debug("Dump section sizes:\n");
+	pr_debug("    CPU state data size: %lx\n", fw_dump.cpu_state_data_size);
+	pr_debug("    HPTE region size   : %lx\n", fw_dump.hpte_region_size);
+	pr_debug("Boot memory size  : %lx\n", fw_dump.boot_memory_size);
+}
+
+static unsigned long init_fadump_mem_struct(struct fadump_mem_struct *fdm,
+				unsigned long addr)
+{
+	if (!fdm)
+		return 0;
+
+	memset(fdm, 0, sizeof(struct fadump_mem_struct));
+	addr = addr & PAGE_MASK;
+
+	fdm->header.dump_format_version = 0x00000001;
+	fdm->header.dump_num_sections = 3;
+	fdm->header.dump_status_flag = 0;
+	fdm->header.offset_first_dump_section =
+		(u32)offsetof(struct fadump_mem_struct, cpu_state_data);
+
+	/*
+	 * Fields for disk dump option.
+	 * We are not using disk dump option, hence set these fields to 0.
+	 */
+	fdm->header.dd_block_size = 0;
+	fdm->header.dd_block_offset = 0;
+	fdm->header.dd_num_blocks = 0;
+	fdm->header.dd_offset_disk_path = 0;
+
+	/* set 0 to disable an automatic dump-reboot. */
+	fdm->header.max_time_auto = 0;
+
+	/* Kernel dump sections */
+	/* cpu state data section. */
+	fdm->cpu_state_data.request_flag = FADUMP_REQUEST_FLAG;
+	fdm->cpu_state_data.source_data_type = FADUMP_CPU_STATE_DATA;
+	fdm->cpu_state_data.source_address = 0;
+	fdm->cpu_state_data.source_len = fw_dump.cpu_state_data_size;
+	fdm->cpu_state_data.destination_address = addr;
+	addr += fw_dump.cpu_state_data_size;
+
+	/* hpte region section */
+	fdm->hpte_region.request_flag = FADUMP_REQUEST_FLAG;
+	fdm->hpte_region.source_data_type = FADUMP_HPTE_REGION;
+	fdm->hpte_region.source_address = 0;
+	fdm->hpte_region.source_len = fw_dump.hpte_region_size;
+	fdm->hpte_region.destination_address = addr;
+	addr += fw_dump.hpte_region_size;
+
+	/* RMA region section */
+	fdm->rmr_region.request_flag = FADUMP_REQUEST_FLAG;
+	fdm->rmr_region.source_data_type = FADUMP_REAL_MODE_REGION;
+	fdm->rmr_region.source_address = RMA_START;
+	fdm->rmr_region.source_len = fw_dump.boot_memory_size;
+	fdm->rmr_region.destination_address = addr;
+	addr += fw_dump.boot_memory_size;
+
+	return addr;
+}
+
 /**
  * fadump_calculate_reserve_size(): reserve variable boot area 5% of System RAM
  *
@@ -166,8 +253,15 @@ int __init fadump_reserve_mem(void)
 		fw_dump.fadump_enabled = 0;
 		return 0;
 	}
-	/* Initialize boot memory size */
-	fw_dump.boot_memory_size = fadump_calculate_reserve_size();
+	/*
+	 * Initialize boot memory size
+	 * If dump is active then we have already calculated the size during
+	 * first kernel.
+	 */
+	if (fdm_active)
+		fw_dump.boot_memory_size = fdm_active->rmr_region.source_len;
+	else
+		fw_dump.boot_memory_size = fadump_calculate_reserve_size();
 
 	/*
 	 * Calculate the memory boundary.
@@ -244,3 +338,258 @@ static int __init early_fadump_reserve_mem(char *p)
 	return 0;
 }
 early_param("fadump_reserve_mem", early_fadump_reserve_mem);
+
+static void register_fw_dump(struct fadump_mem_struct *fdm)
+{
+	int rc;
+	unsigned int wait_time;
+
+	pr_debug("Registering for firmware-assisted kernel dump...\n");
+
+	/* TODO: Add upper time limit for the delay */
+	do {
+		rc = rtas_call(fw_dump.ibm_configure_kernel_dump, 3, 1, NULL,
+			FADUMP_REGISTER, fdm,
+			sizeof(struct fadump_mem_struct));
+
+		wait_time = rtas_busy_delay_time(rc);
+		if (wait_time)
+			mdelay(wait_time);
+
+	} while (wait_time);
+
+	switch (rc) {
+	case -1:
+		printk(KERN_ERR "Failed to register firmware-assisted kernel"
+			" dump. Hardware Error(%d).\n", rc);
+		break;
+	case -3:
+		printk(KERN_ERR "Failed to register firmware-assisted kernel"
+			" dump. Parameter Error(%d).\n", rc);
+		break;
+	case -9:
+		printk(KERN_ERR "firmware-assisted kernel dump is already "
+			" registered.");
+		fw_dump.dump_registered = 1;
+		break;
+	case 0:
+		printk(KERN_INFO "firmware-assisted kernel dump registration"
+			" is successful\n");
+		fw_dump.dump_registered = 1;
+		break;
+	}
+}
+
+static void register_fadump(void)
+{
+	/*
+	 * If no memory is reserved then we can not register for firmware-
+	 * assisted dump.
+	 */
+	if (!fw_dump.reserve_dump_area_size)
+		return;
+
+	/* register the future kernel dump with firmware. */
+	register_fw_dump(&fdm);
+}
+
+static int fadump_unregister_dump(struct fadump_mem_struct *fdm)
+{
+	int rc = 0;
+	unsigned int wait_time;
+
+	pr_debug("Un-register firmware-assisted dump\n");
+
+	/* TODO: Add upper time limit for the delay */
+	do {
+		rc = rtas_call(fw_dump.ibm_configure_kernel_dump, 3, 1, NULL,
+			FADUMP_UNREGISTER, fdm,
+			sizeof(struct fadump_mem_struct));
+
+		wait_time = rtas_busy_delay_time(rc);
+		if (wait_time)
+			mdelay(wait_time);
+	} while (wait_time);
+
+	if (rc) {
+		printk(KERN_ERR "Failed to un-register firmware-assisted dump."
+			" unexpected error(%d).\n", rc);
+		return rc;
+	}
+	fw_dump.dump_registered = 0;
+	return 0;
+}
+
+static ssize_t fadump_enabled_show(struct kobject *kobj,
+					struct kobj_attribute *attr,
+					char *buf)
+{
+	return sprintf(buf, "%d\n", fw_dump.fadump_enabled);
+}
+
+static ssize_t fadump_register_show(struct kobject *kobj,
+					struct kobj_attribute *attr,
+					char *buf)
+{
+	return sprintf(buf, "%d\n", fw_dump.dump_registered);
+}
+
+static ssize_t fadump_register_store(struct kobject *kobj,
+					struct kobj_attribute *attr,
+					const char *buf, size_t count)
+{
+	int ret = 0;
+
+	if (!fw_dump.fadump_enabled || fdm_active)
+		return -EPERM;
+
+	mutex_lock(&fadump_mutex);
+
+	switch (buf[0]) {
+	case '0':
+		if (fw_dump.dump_registered == 0) {
+			ret = -EINVAL;
+			goto unlock_out;
+		}
+		/* Un-register Firmware-assisted dump */
+		fadump_unregister_dump(&fdm);
+		break;
+	case '1':
+		if (fw_dump.dump_registered == 1) {
+			ret = -EINVAL;
+			goto unlock_out;
+		}
+		/* Register Firmware-assisted dump */
+		register_fadump();
+		break;
+	default:
+		ret = -EINVAL;
+		break;
+	}
+
+unlock_out:
+	mutex_unlock(&fadump_mutex);
+	return ret < 0 ? ret : count;
+}
+
+static int fadump_region_show(struct seq_file *m, void *private)
+{
+	const struct fadump_mem_struct *fdm_ptr;
+
+	if (!fw_dump.fadump_enabled)
+		return 0;
+
+	if (fdm_active)
+		fdm_ptr = fdm_active;
+	else
+		fdm_ptr = &fdm;
+
+	seq_printf(m,
+			"CPU : [%#016llx-%#016llx] %#llx bytes, "
+			"Dumped: %#llx\n",
+			fdm_ptr->cpu_state_data.destination_address,
+			fdm_ptr->cpu_state_data.destination_address +
+			fdm_ptr->cpu_state_data.source_len - 1,
+			fdm_ptr->cpu_state_data.source_len,
+			fdm_ptr->cpu_state_data.bytes_dumped);
+	seq_printf(m,
+			"HPTE: [%#016llx-%#016llx] %#llx bytes, "
+			"Dumped: %#llx\n",
+			fdm_ptr->hpte_region.destination_address,
+			fdm_ptr->hpte_region.destination_address +
+			fdm_ptr->hpte_region.source_len - 1,
+			fdm_ptr->hpte_region.source_len,
+			fdm_ptr->hpte_region.bytes_dumped);
+	seq_printf(m,
+			"DUMP: [%#016llx-%#016llx] %#llx bytes, "
+			"Dumped: %#llx\n",
+			fdm_ptr->rmr_region.destination_address,
+			fdm_ptr->rmr_region.destination_address +
+			fdm_ptr->rmr_region.source_len - 1,
+			fdm_ptr->rmr_region.source_len,
+			fdm_ptr->rmr_region.bytes_dumped);
+
+	if (!fdm_active ||
+		(fw_dump.reserve_dump_area_start ==
+		fdm_ptr->cpu_state_data.destination_address))
+		return 0;
+
+	/* Dump is active. Show reserved memory region. */
+	seq_printf(m,
+			"    : [%#016llx-%#016llx] %#llx bytes, "
+			"Dumped: %#llx\n",
+			(unsigned long long)fw_dump.reserve_dump_area_start,
+			fdm_ptr->cpu_state_data.destination_address - 1,
+			fdm_ptr->cpu_state_data.destination_address -
+			fw_dump.reserve_dump_area_start,
+			fdm_ptr->cpu_state_data.destination_address -
+			fw_dump.reserve_dump_area_start);
+	return 0;
+}
+
+static struct kobj_attribute fadump_attr = __ATTR(fadump_enabled,
+						0444, fadump_enabled_show,
+						NULL);
+static struct kobj_attribute fadump_register_attr = __ATTR(fadump_registered,
+						0644, fadump_register_show,
+						fadump_register_store);
+
+static int fadump_region_open(struct inode *inode, struct file *file)
+{
+	return single_open(file, fadump_region_show, inode->i_private);
+}
+
+static const struct file_operations fadump_region_fops = {
+	.open    = fadump_region_open,
+	.read    = seq_read,
+	.llseek  = seq_lseek,
+	.release = single_release,
+};
+
+static void fadump_init_files(void)
+{
+	struct dentry *debugfs_file;
+	int rc = 0;
+
+	rc = sysfs_create_file(kernel_kobj, &fadump_attr.attr);
+	if (rc)
+		printk(KERN_ERR "fadump: unable to create sysfs file"
+			" fadump_enabled (%d)\n", rc);
+
+	rc = sysfs_create_file(kernel_kobj, &fadump_register_attr.attr);
+	if (rc)
+		printk(KERN_ERR "fadump: unable to create sysfs file"
+			" fadump_registered (%d)\n", rc);
+
+	debugfs_file = debugfs_create_file("fadump_region", 0444,
+					powerpc_debugfs_root, NULL,
+					&fadump_region_fops);
+	if (!debugfs_file)
+		printk(KERN_ERR "fadump: unable to create debugfs file"
+				" fadump_region\n");
+	return;
+}
+
+/*
+ * Prepare for firmware-assisted dump.
+ */
+int __init setup_fadump(void)
+{
+	if (!fw_dump.fadump_enabled)
+		return 0;
+
+	if (!fw_dump.fadump_supported) {
+		printk(KERN_ERR "Firmware-assisted dump is not supported on"
+			" this hardware\n");
+		return 0;
+	}
+
+	fadump_show_config();
+	/* Initialize the kernel dump memory structure for FAD registration. */
+	if (fw_dump.reserve_dump_area_size)
+		init_fadump_mem_struct(&fdm, fw_dump.reserve_dump_area_start);
+	fadump_init_files();
+
+	return 1;
+}
+subsys_initcall(setup_fadump);
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 0cfcf98..359f078 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -39,6 +39,7 @@
 #include <asm/pci-bridge.h>
 #include <asm/machdep.h>
 #include <asm/kdump.h>
+#include <asm/fadump.h>
 
 #define DBG(...)
 
@@ -445,7 +446,12 @@ void iommu_unmap_sg(struct iommu_table *tbl, struct scatterlist *sglist,
 
 static void iommu_table_clear(struct iommu_table *tbl)
 {
-	if (!is_kdump_kernel()) {
+	/*
+	 * In case of firmware assisted dump system goes through clean
+	 * reboot process at the time of system crash. Hence it's safe to
+	 * clear the TCE entries if firmware assisted dump is active.
+	 */
+	if (!is_kdump_kernel() || is_fadump_active()) {
 		/* Clear the table in case firmware left allocations in it */
 		ppc_md.tce_free(tbl, tbl->it_offset, tbl->it_size);
 		return;
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 2d28218..b534bba 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -55,6 +55,7 @@
 #include <asm/spu.h>
 #include <asm/udbg.h>
 #include <asm/code-patching.h>
+#include <asm/fadump.h>
 
 #ifdef DEBUG
 #define DBG(fmt...) udbg_printf(fmt)
@@ -625,6 +626,16 @@ static void __init htab_initialize(void)
 		/* Using a hypervisor which owns the htab */
 		htab_address = NULL;
 		_SDR1 = 0; 
+#ifdef CONFIG_FA_DUMP
+		/*
+		 * If firmware assisted dump is active firmware preserves
+		 * the contents of htab along with entire partition memory.
+		 * Clear the htab if firmware assisted dump is active so
+		 * that we dont end up using old mappings.
+		 */
+		if (is_fadump_active() && ppc_md.hpte_clear_all)
+			ppc_md.hpte_clear_all();
+#endif
 	} else {
 		/* Find storage for the HPT.  Must be contiguous in
 		 * the absolute address space. On cell we want it to be



-- 
Mahesh J Salgaonkar



From dzickus at redhat.com  Mon Feb 20 10:14:19 2012
From: dzickus at redhat.com (Don Zickus)
Date: Mon, 20 Feb 2012 10:14:19 -0500
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <m1y5s07rn3.fsf@fess.ebiederm.org>
References: <m1zkcmyjyd.fsf@fess.ebiederm.org>
 <CAE9FiQVj12UCGbOe4wZfx-L8tdab-1si-RA=vBnNeZ7cUNqyyg@mail.gmail.com>
 <CAE9FiQVPnO8-tuPoio0Wxv=8rjdm2tJbBk3+3ystueyYtZn9BA@mail.gmail.com>
 <20120216172735.GX9751@redhat.com>
 <CAE9FiQVhbAM9vjx-uFcuc0ndsUp0aez9_TsQHStje5G5iwYbag@mail.gmail.com>
 <20120216215603.GH9751@redhat.com>
 <m1y5s2ku36.fsf@fess.ebiederm.org>
 <m1fwe9bpk2.fsf@fess.ebiederm.org>
 <20120217195430.GO9751@redhat.com>
 <m1y5s07rn3.fsf@fess.ebiederm.org>
Message-ID: <20120220151419.GU9751@redhat.com>

On Fri, Feb 17, 2012 at 07:21:52PM -0800, Eric W. Biederman wrote:
> Don Zickus <dzickus at redhat.com> writes:
> 
> > On Fri, Feb 17, 2012 at 04:41:01AM -0800, Eric W. Biederman wrote:
> >> 
> >> The fix with a guarantee of no more scope creep is to just disable the
> >> nmi watchdog on the kexec on panic path.
> >> 
> >> Don if you have time please figure out is needed to ignore nmi's and
> >> possible record and/or report them while we boot, otherwise please cook
> >> up a patch that just disables the nmi watchdog wherever we are sending
> >> it from (the local apic or the ioapic).
> >
> > Can I keep things even simpler?  The original problem was the deadlock
> > with the ioapic lock.  We fixed that by removing the call to
> > disable_IO_APIC().  Can we just leave the disable_local_APIC calls in
> > there for now?  Is there any real harm?
> 
> > All this rewrite is going to take time which will delay fixing a current
> > problem with kexec on panic, the ioapic deadlock.
> 
> Hmm.
> 
> My apologies I just realized that we can not disable the nmi watchdog
> safely in all cases.  To avoid the deadlock we fundamentally can not
> write to the io_apic, because the locks are the io_apic write path.
> The nmi watchdog can be sourced from either the local apics or the
> io_apics.  To disable the nmi_watchdog we need at least potentially
> to write io_apic.

I am curious where you see the nmi watchdog being sourced from the ioapic?
I thought I removed that code 3 or 4 releases ago.

> 
> So it appears to me that the only reasonable and robust thing we can
> do is to ignore nmis in the kexec on panic path.
> 
> So it looks to me that the only path forward at this point is to fix
> the other bug where an unexpected nmi will kill the kexec on panic boot.
> 
> I just took a look at the code in /sbin/kexec and that code does not in
> fact change the idt except when we switch to 16bit mode, which we
> definitely do not do in the kexec on panic case.  So it appears that we
> don't need to coordinate an /sbin/kexec release with a kernel release to
> ignore nmis.
> 
> In fact it looks like we only need to fix the interrupt descriptors
> loaded in machine_kexec_64.c and head64.c to ignore nmis.
> 
> At which point we will have fixed two bugs and have a much more reliable
> kexec on panic implementation.

Ok.  I'll talk with Vivek about how the can be implemented.

Cheers.
Don


From seiji.aguchi at hds.com  Mon Feb 20 10:20:34 2012
From: seiji.aguchi at hds.com (Seiji Aguchi)
Date: Mon, 20 Feb 2012 10:20:34 -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: <5C4C569E8A4B9B42A84A977CF070A35B2DAC909D43@USINDEVS01.corp.hds.com>

> -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);
>+
>+	/*

Hmm...

This patch solves the kdump race, but it may make us confuse when we analyze vmcore,
Because it clears value of ioapic_lock without notice.

It kernel panic is related to IO_APIC, they will check value of ioapic_lock.

So, it is better if we can restore the value of ioapic_lock after calling disable_IO_APIC(),  
IOW, my idea is following.
 - Backup value of ioapic_lock
 - Bust ioapic_lock
 -  Call disable_IO_APIC()
 - Restore value of ioapic_lock

But, as you are discussing with Eric, we don't need to worry about this if we can completely remove disable_IO_APIC().

Seiji




From dzickus at redhat.com  Mon Feb 20 10:24:17 2012
From: dzickus at redhat.com (Don Zickus)
Date: Mon, 20 Feb 2012 10:24:17 -0500
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <20120220.141733.294710222.d.hatayama@jp.fujitsu.com>
References: <m1fwe9bpk2.fsf@fess.ebiederm.org>
 <CABOkKT21zhyMwMmbR9WTipk5e=y_qMZ8ByG=njatjKbFLZW+xQ@mail.gmail.com>
 <20120217201842.GP9751@redhat.com>
 <20120220.141733.294710222.d.hatayama@jp.fujitsu.com>
Message-ID: <20120220152417.GV9751@redhat.com>

On Mon, Feb 20, 2012 at 02:17:33PM +0900, HATAYAMA Daisuke wrote:
> From: Don Zickus <dzickus at redhat.com>
> Subject: Re: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in crash path
> Date: Fri, 17 Feb 2012 15:18:42 -0500
> 
> > On Sat, Feb 18, 2012 at 12:49:16AM +0900, HATAYAMA Daisuke wrote:
> >> A few days ago I investigted the case where system is reseted due to
> >> triple fault caused by the NMI after idt is disabled in
> >> machine_kexec. I didn't see the reset when trigering the kdump with
> >> NMI since the NMI is masked until next iret instruction executed as
> >> described in 6.7.2. Handling Multiple NMIs of Intel Manual Vol.3A.
> >> The NMI mask remains untill the first iret execution on the 2nd
> >> kernel: just the return path of the first kernel_thread invocation for
> >> init process. The exact path is:
> > 
> > hmm.  So even though the local apic was disabled you still got an NMI?
> > That could have been from an external NMI.  I forget how that is wired up,
> > if it goes through the IOAPIC to the Local APIC or directly to the NMI pin
> > on the cpu.
> > 
> 
> Please don't confused. I used RHEL kernels based on 2.6.18 and
> 2.6.32. I didn't use the patch disabling local apic.

Sure.  Those kernels should be using the 'disable_local_APIC' code.  My
patch just removed that call, IOW it stops disabling local apic or a
simpler way is to say it keeps the local apic enabled.

My question stills stands then, you might have experienced an external
NMI, but I am not entirely sure.


> 
> >> 
> >>   switch_to
> >>   -> ret_from_fork
> >>      -> int_ret_from_sys_call
> >>         -> retint_restore_args
> >>            -> irq_return
> >> 
> >> At that phase idt is already set up and kdump works.
> >> 
> >> From the discussion I interpret kdump doesn't assume this behaviour,
> >> right?
> > 
> > probably not.
> > 
> 
> Thanks.
> 
> >> 
> >> BTW, does anyone know the detail of the NMI mask? I couldn't figure
> >> out about it from the Intel spec more than ``certain hardware
> >> conditions''... I expect those who look at here are x86 NMI experts.
> > 
> > I don't understand the question.
> > 
> > Cheers,
> > Don
> > 
> 
> Fig 10-4 explaining Local APIC Structure says INIT/NMI/SMI are
> directly sent to CPU Core, but the later part of this route is not
> explained formally anyware. Only the explanation is the sentence in
> 6.7 Nonmaskable Interrupt (NMI):
> 
>   The processor also invokes certain hardware conditions to insure
>   that no other interrupts, including NMI interrupts, are received
>   until the NMI handler has completed executing.
> 
> I'm just wondering if this is explained more formally anyware.

It might be I just don't know where.  I just view the NMI as an exception.
Each cpu exception has a priority.  NMI has a higher priority than
interrupts but a lower priority that say INIT.  Therefore when the cpu
gets an exception it classifies it based on priority.  Higher priorities
will interrupt the current exception, such as NMI, while lower priorities
will wait until the current exception is finished.

To me those would be the hardware conditions, but that is my
interpretation.

Cheers,
Don

> 
> Thanks.
> HATAYAMA, Daisuke
> 


From kumagai-atsushi at mxc.nes.nec.co.jp  Tue Feb 21 02:50:41 2012
From: kumagai-atsushi at mxc.nes.nec.co.jp (Atsushi Kumagai)
Date: Tue, 21 Feb 2012 16:50:41 +0900
Subject: [PATCH makedumpfile 0/2] LZO Compression Support
In-Reply-To: <20120220090528.30966.59163.stgit@localhost6.localdomain6>
References: <20120220090528.30966.59163.stgit@localhost6.localdomain6>
Message-ID: <20120221165041.5ebd8a15.kumagai-atsushi@mxc.nes.nec.co.jp>

Hello Hatayama-san,

On Mon, 20 Feb 2012 18:10:00 +0900
HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> wrote:

> The following series implements LZO compression support to
> makedumpfile. LZO is as good as in size but by far better in speed
> than ZLIB, readucing down time during generation of crash dump and
> refiltering.
> 
> The RFC discussion:
> 
>   http://lists.infradead.org/pipermail/kexec/2011-November/005783.html
>   http://lists.infradead.org/pipermail/kexec/2011-December/005868.html
> 
> How to build:
> 
>   1. Get lzo libraries: lzo, lzo-devel and lzo-minilzo from either of
>   the following:
> 
>     1) Original author's website:
>        http://www.oberhumer.com/opensource/lzo/
> 
>     2) yum framework on fedora. Older releases don't have the packages.
> 
>   2. Apply the patch set to makedumpfile v1.4.2.
> 
>   3. Do make.
> 
> How to use:
> 
>   Introduce new -l option. If a user specify this, makedumpfile
>   generates dumpfile compressed by pages with lzo compression.
> 
>   Example)
>   $ makedumpfile -l vmcore dumpfile
> 
> Performance evaluation:
> 
>   - Kumagai-san's evaluation simulating actually working servers:
>     http://lists.infradead.org/pipermail/kexec/2011-December/005868.html
> 
>   - My evaluation focusing on the worst cases:
>     http://lists.infradead.org/pipermail/kexec/2011-November/005783.html
> 
> LZO Support for crash:
> 
>   I'll post LZO support patch for crash after makedumpfile merges
>   these patches.

Thank you for your patches.

I'll review and merge them into v1.4.4 with making LZO support optional.
I'll post the patch to make it optional after v1.4.3 is released.

Please wait for a while.

Thanks
Atsushi Kumagai


From ebiederm at xmission.com  Tue Feb 21 03:01:07 2012
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Tue, 21 Feb 2012 00:01:07 -0800
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <20120220151419.GU9751@redhat.com> (Don Zickus's message of "Mon, 
 20 Feb 2012 10:14:19 -0500")
References: <m1zkcmyjyd.fsf@fess.ebiederm.org>
 <CAE9FiQVj12UCGbOe4wZfx-L8tdab-1si-RA=vBnNeZ7cUNqyyg@mail.gmail.com>
 <CAE9FiQVPnO8-tuPoio0Wxv=8rjdm2tJbBk3+3ystueyYtZn9BA@mail.gmail.com>
 <20120216172735.GX9751@redhat.com>
 <CAE9FiQVhbAM9vjx-uFcuc0ndsUp0aez9_TsQHStje5G5iwYbag@mail.gmail.com>
 <20120216215603.GH9751@redhat.com> <m1y5s2ku36.fsf@fess.ebiederm.org>
 <m1fwe9bpk2.fsf@fess.ebiederm.org> <20120217195430.GO9751@redhat.com>
 <m1y5s07rn3.fsf@fess.ebiederm.org> <20120220151419.GU9751@redhat.com>
Message-ID: <m1obss39a4.fsf@fess.ebiederm.org>

Don Zickus <dzickus at redhat.com> writes:

2> On Fri, Feb 17, 2012 at 07:21:52PM -0800, Eric W. Biederman wrote:
>> Don Zickus <dzickus at redhat.com> writes:
>> 
>> > On Fri, Feb 17, 2012 at 04:41:01AM -0800, Eric W. Biederman wrote:
>> >> 
>> >> The fix with a guarantee of no more scope creep is to just disable the
>> >> nmi watchdog on the kexec on panic path.
>> >> 
>> >> Don if you have time please figure out is needed to ignore nmi's and
>> >> possible record and/or report them while we boot, otherwise please cook
>> >> up a patch that just disables the nmi watchdog wherever we are sending
>> >> it from (the local apic or the ioapic).
>> >
>> > Can I keep things even simpler?  The original problem was the deadlock
>> > with the ioapic lock.  We fixed that by removing the call to
>> > disable_IO_APIC().  Can we just leave the disable_local_APIC calls in
>> > there for now?  Is there any real harm?
>> 
>> > All this rewrite is going to take time which will delay fixing a current
>> > problem with kexec on panic, the ioapic deadlock.
>> 
>> Hmm.
>> 
>> My apologies I just realized that we can not disable the nmi watchdog
>> safely in all cases.  To avoid the deadlock we fundamentally can not
>> write to the io_apic, because the locks are the io_apic write path.
>> The nmi watchdog can be sourced from either the local apics or the
>> io_apics.  To disable the nmi_watchdog we need at least potentially
>> to write io_apic.
>
> I am curious where you see the nmi watchdog being sourced from the ioapic?
> I thought I removed that code 3 or 4 releases ago.

In my memory, and in references to the code in comments in various apic
related code.  I couldn't figure out what the current code was doing and
assumed the implementation was equivalent.  It does look like you
removed the code that used the io_apic.  I still haven't figured
out just how the new implementation works yet.

So maybe in the short term we can safely just stomp the timer that
triggers the nmi watchdog in the local apic.  Over the long term that
feels like it is just asking for trouble.

I wonder if the reason that we have an hpet stomp in that code is
for a similar reason.  Did we ever source nmi's from the hpet timer?

>> So it appears to me that the only reasonable and robust thing we can
>> do is to ignore nmis in the kexec on panic path.
>> 
>> So it looks to me that the only path forward at this point is to fix
>> the other bug where an unexpected nmi will kill the kexec on panic boot.
>> 
>> I just took a look at the code in /sbin/kexec and that code does not in
>> fact change the idt except when we switch to 16bit mode, which we
>> definitely do not do in the kexec on panic case.  So it appears that we
>> don't need to coordinate an /sbin/kexec release with a kernel release to
>> ignore nmis.
>> 
>> In fact it looks like we only need to fix the interrupt descriptors
>> loaded in machine_kexec_64.c and head64.c to ignore nmis.
>> 
>> At which point we will have fixed two bugs and have a much more reliable
>> kexec on panic implementation.
>
> Ok.  I'll talk with Vivek about how the can be implemented.

Thanks.  It really doesn't look very hard.  Just a tiny idt with
an nmi entry that says iret.

Eric


From d.hatayama at jp.fujitsu.com  Tue Feb 21 03:01:25 2012
From: d.hatayama at jp.fujitsu.com (HATAYAMA Daisuke)
Date: Tue, 21 Feb 2012 17:01:25 +0900 (   )
Subject: [PATCH makedumpfile 0/2] LZO Compression Support
In-Reply-To: <20120221165041.5ebd8a15.kumagai-atsushi@mxc.nes.nec.co.jp>
References: <20120220090528.30966.59163.stgit@localhost6.localdomain6>
 <20120221165041.5ebd8a15.kumagai-atsushi@mxc.nes.nec.co.jp>
Message-ID: <20120221.170125.347143815.d.hatayama@jp.fujitsu.com>

Hello Kumagai-san,

From: Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp>
Subject: Re: [PATCH makedumpfile 0/2] LZO Compression Support
Date: Tue, 21 Feb 2012 16:50:41 +0900

> Hello Hatayama-san,
> 
> On Mon, 20 Feb 2012 18:10:00 +0900
> HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> wrote:
> 
>> The following series implements LZO compression support to
>> makedumpfile. LZO is as good as in size but by far better in speed
>> than ZLIB, readucing down time during generation of crash dump and
>> refiltering.
>> 
>> The RFC discussion:
>> 
>>   http://lists.infradead.org/pipermail/kexec/2011-November/005783.html
>>   http://lists.infradead.org/pipermail/kexec/2011-December/005868.html
>> 
>> How to build:
>> 
>>   1. Get lzo libraries: lzo, lzo-devel and lzo-minilzo from either of
>>   the following:
>> 
>>     1) Original author's website:
>>        http://www.oberhumer.com/opensource/lzo/
>> 
>>     2) yum framework on fedora. Older releases don't have the packages.
>> 
>>   2. Apply the patch set to makedumpfile v1.4.2.
>> 
>>   3. Do make.
>> 
>> How to use:
>> 
>>   Introduce new -l option. If a user specify this, makedumpfile
>>   generates dumpfile compressed by pages with lzo compression.
>> 
>>   Example)
>>   $ makedumpfile -l vmcore dumpfile
>> 
>> Performance evaluation:
>> 
>>   - Kumagai-san's evaluation simulating actually working servers:
>>     http://lists.infradead.org/pipermail/kexec/2011-December/005868.html
>> 
>>   - My evaluation focusing on the worst cases:
>>     http://lists.infradead.org/pipermail/kexec/2011-November/005783.html
>> 
>> LZO Support for crash:
>> 
>>   I'll post LZO support patch for crash after makedumpfile merges
>>   these patches.
> 
> Thank you for your patches.
> 
> I'll review and merge them into v1.4.4 with making LZO support optional.
> I'll post the patch to make it optional after v1.4.3 is released.
> 
> Please wait for a while.
> 
> Thanks
> Atsushi Kumagai
> 

Thanks. But I'm OK if I'll repost the patch after you have decided how
you change Makefile to support optional building. Or is it more
effective for you to do them by yourself at the same time?

Thanks.
HATAYAMA, Daisuke



From dzickus at redhat.com  Tue Feb 21 08:59:34 2012
From: dzickus at redhat.com (Don Zickus)
Date: Tue, 21 Feb 2012 08:59:34 -0500
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <m1obss39a4.fsf@fess.ebiederm.org>
References: <CAE9FiQVPnO8-tuPoio0Wxv=8rjdm2tJbBk3+3ystueyYtZn9BA@mail.gmail.com>
 <20120216172735.GX9751@redhat.com>
 <CAE9FiQVhbAM9vjx-uFcuc0ndsUp0aez9_TsQHStje5G5iwYbag@mail.gmail.com>
 <20120216215603.GH9751@redhat.com>
 <m1y5s2ku36.fsf@fess.ebiederm.org>
 <m1fwe9bpk2.fsf@fess.ebiederm.org>
 <20120217195430.GO9751@redhat.com>
 <m1y5s07rn3.fsf@fess.ebiederm.org>
 <20120220151419.GU9751@redhat.com>
 <m1obss39a4.fsf@fess.ebiederm.org>
Message-ID: <20120221135934.GF26998@redhat.com>

On Tue, Feb 21, 2012 at 12:01:07AM -0800, Eric W. Biederman wrote:
> Don Zickus <dzickus at redhat.com> writes:
> 
> 2> On Fri, Feb 17, 2012 at 07:21:52PM -0800, Eric W. Biederman wrote:
> >> Don Zickus <dzickus at redhat.com> writes:
> >> 
> >> > On Fri, Feb 17, 2012 at 04:41:01AM -0800, Eric W. Biederman wrote:
> >> >> 
> >> >> The fix with a guarantee of no more scope creep is to just disable the
> >> >> nmi watchdog on the kexec on panic path.
> >> >> 
> >> >> Don if you have time please figure out is needed to ignore nmi's and
> >> >> possible record and/or report them while we boot, otherwise please cook
> >> >> up a patch that just disables the nmi watchdog wherever we are sending
> >> >> it from (the local apic or the ioapic).
> >> >
> >> > Can I keep things even simpler?  The original problem was the deadlock
> >> > with the ioapic lock.  We fixed that by removing the call to
> >> > disable_IO_APIC().  Can we just leave the disable_local_APIC calls in
> >> > there for now?  Is there any real harm?
> >> 
> >> > All this rewrite is going to take time which will delay fixing a current
> >> > problem with kexec on panic, the ioapic deadlock.
> >> 
> >> Hmm.
> >> 
> >> My apologies I just realized that we can not disable the nmi watchdog
> >> safely in all cases.  To avoid the deadlock we fundamentally can not
> >> write to the io_apic, because the locks are the io_apic write path.
> >> The nmi watchdog can be sourced from either the local apics or the
> >> io_apics.  To disable the nmi_watchdog we need at least potentially
> >> to write io_apic.
> >
> > I am curious where you see the nmi watchdog being sourced from the ioapic?
> > I thought I removed that code 3 or 4 releases ago.
> 
> In my memory, and in references to the code in comments in various apic
> related code.  I couldn't figure out what the current code was doing and
> assumed the implementation was equivalent.  It does look like you
> removed the code that used the io_apic.  I still haven't figured
> out just how the new implementation works yet.

It is just a client of perf now.  Perf controls the local apic accesses.
A lot simpler now.

> 
> So maybe in the short term we can safely just stomp the timer that
> triggers the nmi watchdog in the local apic.  Over the long term that
> feels like it is just asking for trouble.

I can understand that.

> 
> I wonder if the reason that we have an hpet stomp in that code is
> for a similar reason.  Did we ever source nmi's from the hpet timer?
> 
> >> So it appears to me that the only reasonable and robust thing we can
> >> do is to ignore nmis in the kexec on panic path.
> >> 
> >> So it looks to me that the only path forward at this point is to fix
> >> the other bug where an unexpected nmi will kill the kexec on panic boot.
> >> 
> >> I just took a look at the code in /sbin/kexec and that code does not in
> >> fact change the idt except when we switch to 16bit mode, which we
> >> definitely do not do in the kexec on panic case.  So it appears that we
> >> don't need to coordinate an /sbin/kexec release with a kernel release to
> >> ignore nmis.
> >> 
> >> In fact it looks like we only need to fix the interrupt descriptors
> >> loaded in machine_kexec_64.c and head64.c to ignore nmis.
> >> 
> >> At which point we will have fixed two bugs and have a much more reliable
> >> kexec on panic implementation.
> >
> > Ok.  I'll talk with Vivek about how the can be implemented.
> 
> Thanks.  It really doesn't look very hard.  Just a tiny idt with
> an nmi entry that says iret.

It probably is, except I never hacked on idt code before and my assembly
isn't that good.  I have been trying to find examples to copy from to give
it a try.  So far I was using early_idt_handlers with early_printk to see
if I could capture some printk messages while jumping from the first
kernel to the second kernel (when the other early_idt_handlers would kick
in for the second kernel).

Tips?  Better examples?

Cheers,
Don


From kumagai-atsushi at mxc.nes.nec.co.jp  Tue Feb 21 21:42:09 2012
From: kumagai-atsushi at mxc.nes.nec.co.jp (Atsushi Kumagai)
Date: Wed, 22 Feb 2012 11:42:09 +0900
Subject: [PATCH makedumpfile 0/2] LZO Compression Support
In-Reply-To: <20120221.170125.347143815.d.hatayama@jp.fujitsu.com>
References: <20120220090528.30966.59163.stgit@localhost6.localdomain6>
 <20120221165041.5ebd8a15.kumagai-atsushi@mxc.nes.nec.co.jp>
 <20120221.170125.347143815.d.hatayama@jp.fujitsu.com>
Message-ID: <20120222114209.d22e2e34.kumagai-atsushi@mxc.nes.nec.co.jp>

Hello Hatayama-san,

On Tue, 21 Feb 2012 17:01:25 +0900 (   )
HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> wrote:
 
> > Thank you for your patches.
> > 
> > I'll review and merge them into v1.4.4 with making LZO support optional.
> > I'll post the patch to make it optional after v1.4.3 is released.
> > 
> > Please wait for a while.
> > 
> > Thanks
> > Atsushi Kumagai
> > 
> 
> Thanks. But I'm OK if I'll repost the patch after you have decided how
> you change Makefile to support optional building. Or is it more
> effective for you to do them by yourself at the same time?

I wonder if you could repost the patch with implementing my idea.
My idea is that using build option (like "LINKTYPE" at v1.4.2).

 Example)
   1. enable lzo support
     $ make USELZO=on

   2. disable lzo support (default)
     $ make

In future, I would like to use automake but don't worry
about it now.

Thanks
Atsushi Kumagai


From d.hatayama at jp.fujitsu.com  Tue Feb 21 23:38:05 2012
From: d.hatayama at jp.fujitsu.com (HATAYAMA Daisuke)
Date: Wed, 22 Feb 2012 13:38:05 +0900 (   )
Subject: [PATCH makedumpfile 0/2] LZO Compression Support
In-Reply-To: <20120222114209.d22e2e34.kumagai-atsushi@mxc.nes.nec.co.jp>
References: <20120221165041.5ebd8a15.kumagai-atsushi@mxc.nes.nec.co.jp>
 <20120221.170125.347143815.d.hatayama@jp.fujitsu.com>
 <20120222114209.d22e2e34.kumagai-atsushi@mxc.nes.nec.co.jp>
Message-ID: <20120222.133805.28788070.d.hatayama@jp.fujitsu.com>

From: Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp>
Subject: Re: [PATCH makedumpfile 0/2] LZO Compression Support
Date: Wed, 22 Feb 2012 11:42:09 +0900

> Hello Hatayama-san,
> 
> On Tue, 21 Feb 2012 17:01:25 +0900 (   )
> HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> wrote:
>  
>> > Thank you for your patches.
>> > 
>> > I'll review and merge them into v1.4.4 with making LZO support optional.
>> > I'll post the patch to make it optional after v1.4.3 is released.
>> > 
>> > Please wait for a while.
>> > 
>> > Thanks
>> > Atsushi Kumagai
>> > 
>> 
>> Thanks. But I'm OK if I'll repost the patch after you have decided how
>> you change Makefile to support optional building. Or is it more
>> effective for you to do them by yourself at the same time?
> 
> I wonder if you could repost the patch with implementing my idea.
> My idea is that using build option (like "LINKTYPE" at v1.4.2).
> 
>  Example)
>    1. enable lzo support
>      $ make USELZO=on
> 
>    2. disable lzo support (default)
>      $ make
> 
> In future, I would like to use automake but don't worry
> about it now.

I see. I'll repost the patch soon.

Thanks.
HATAYAMA, Daisuke



From d.hatayama at jp.fujitsu.com  Wed Feb 22 20:33:54 2012
From: d.hatayama at jp.fujitsu.com (HATAYAMA Daisuke)
Date: Thu, 23 Feb 2012 10:33:54 +0900
Subject: [PATCH makedumpfile v2 0/4] LZO Compression Support
Message-ID: <20120223012940.5041.61104.stgit@localhost6.localdomain6>

The following series implements LZO compression support to
makedumpfile. LZO is as good as in size but by far better in speed
than ZLIB, readucing down time during generation of crash dump and
refiltering.

The RFC discussion was made here:

  http://lists.infradead.org/pipermail/kexec/2011-November/005783.html
  http://lists.infradead.org/pipermail/kexec/2011-December/005868.html

How to build:

  1. Get lzo libraries: lzo, lzo-devel and lzo-minilzo from either of
  the following:

    1) Original author's website:
       http://www.oberhumer.com/opensource/lzo/

    2) yum framework on fedora. Older releases don't have the packages.

  2. Apply the patch set to makedumpfile v1.4.2.

  3. Do make as follows:

    $ make USELZO=on

    Note: In default, no LZO compression support is included.

How to use:

  Introduce new -l option. If a user specify this, makedumpfile
  generates dumpfile compressed by pages with lzo compression.

  Example)
  $ makedumpfile -l vmcore dumpfile

Performance evaluation:

  - Kumagai-san's evaluation simulating working servers:
    http://lists.infradead.org/pipermail/kexec/2011-December/005868.html

  - My evaluation focusing on the worst cases:
    http://lists.infradead.org/pipermail/kexec/2011-November/005783.html

LZO Support for crash:

  I'll post LZO support patch for crash after makedumpfile merges
  these patches.

Changelog:

  v1 => v2:

    - Add build condition for LZO support. Enable LZO support if
      specifying USELZO=on to make command.

    - Avoid LONG_MAX/ULONG_MAX redefinitions.

---

HATAYAMA Daisuke (4):
      Add build condition for LZO support
      Add help and manual messages about LZO compression support
      Avoid LONG_MAX/ULONG_MAX redefinitions
      Add LZO Support


 Makefile       |    5 ++++
 common.h       |    4 +++
 diskdump_mod.h |    3 ++-
 makedumpfile.8 |    6 +++--
 makedumpfile.c |   67 ++++++++++++++++++++++++++++++++++++++++++++++++++------
 makedumpfile.h |    4 +++
 print_info.c   |   16 +++++++------
 7 files changed, 86 insertions(+), 19 deletions(-)

-- 
HATAYAMA Daisuke


From d.hatayama at jp.fujitsu.com  Wed Feb 22 20:33:59 2012
From: d.hatayama at jp.fujitsu.com (HATAYAMA Daisuke)
Date: Thu, 23 Feb 2012 10:33:59 +0900
Subject: [PATCH makedumpfile v2 1/4] Add LZO Support
In-Reply-To: <20120223012940.5041.61104.stgit@localhost6.localdomain6>
References: <20120223012940.5041.61104.stgit@localhost6.localdomain6>
Message-ID: <20120223013359.5041.11030.stgit@localhost6.localdomain6>

Add -l option as one of the command-line options users can specify. If
-l option is specified, then makedumpfile generates dumpfile in
kdump-compressed format with lzo compression by each page.

Signed-off-by: HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com>
---

 diskdump_mod.h |    3 ++-
 makedumpfile.c |   57 +++++++++++++++++++++++++++++++++++++++++++++++---------
 makedumpfile.h |    2 ++
 3 files changed, 52 insertions(+), 10 deletions(-)

diff --git a/diskdump_mod.h b/diskdump_mod.h
index c1de972..e672485 100644
--- a/diskdump_mod.h
+++ b/diskdump_mod.h
@@ -78,7 +78,8 @@ struct kdump_sub_header {
 };
 
 /* page flags */
-#define DUMP_DH_COMPRESSED	0x1	/* page is compressed               */
+#define DUMP_DH_COMPRESSED_ZLIB	0x1	/* page is compressed with zlib */
+#define DUMP_DH_COMPRESSED_LZO	0x2	/* paged is compressed with lzo */
 
 /* descriptor of each page for vmcore */
 typedef struct page_desc {
diff --git a/makedumpfile.c b/makedumpfile.c
index c51fda3..e0079b8 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -257,7 +257,7 @@ readpmem_kdump_compressed(unsigned long long paddr, void *bufptr, size_t size)
 		goto error;
 	}
 
-	if (pd.flags & DUMP_DH_COMPRESSED) {
+	if (pd.flags & DUMP_DH_COMPRESSED_ZLIB) {
 		retlen = info->page_size;
 		ret = uncompress((unsigned char *)buf2, &retlen,
 					(unsigned char *)buf, pd.size);
@@ -266,6 +266,17 @@ readpmem_kdump_compressed(unsigned long long paddr, void *bufptr, size_t size)
 			goto error;
 		}
 		memcpy(bufptr, buf2 + page_offset, size);
+	} else if (info->flag_lzo_support
+		   && (pd.flags & DUMP_DH_COMPRESSED_LZO)) {
+		retlen = info->page_size;
+		ret = lzo1x_decompress_safe((unsigned char *)buf, pd.size,
+					    (unsigned char *)buf2, &retlen,
+					    LZO1X_MEM_DECOMPRESS);
+		if ((ret != LZO_E_OK) || (retlen != info->page_size)) {
+			ERRMSG("Uncompress failed: %d\n", ret);
+			goto error;
+		}
+		memcpy(bufptr, buf2 + page_offset, size);
 	} else
 		memcpy(bufptr, buf + page_offset, size);
 
@@ -2498,6 +2509,9 @@ initial(void)
 	unsigned long size;
 	int debug_info = FALSE;
 
+	if (lzo_init() == LZO_E_OK)
+		info->flag_lzo_support = TRUE;
+
 	if (!is_xen_memory() && info->flag_exclude_xen_dom) {
 		MSG("'-X' option is disable,");
 		MSG("because %s is not Xen's memory core image.\n", info->name_memory);
@@ -4665,10 +4679,11 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data *cd_page)
 	off_t offset_data = 0;
 	struct disk_dump_header *dh = info->dump_header;
 	unsigned char buf[info->page_size], *buf_out = NULL;
-	unsigned long len_buf_out;
+	unsigned long len_buf_out, len_buf_out_zlib, len_buf_out_lzo;
 	struct dump_bitmap bitmap2;
 	struct timeval tv_start;
 	const off_t failed = (off_t)-1;
+	lzo_bytep wrkmem = NULL;
 
 	int ret = FALSE;
 
@@ -4677,7 +4692,16 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data *cd_page)
 
 	initialize_2nd_bitmap(&bitmap2);
 
-	len_buf_out = compressBound(info->page_size);
+	if ((wrkmem = malloc(LZO1X_1_MEM_COMPRESS)) == NULL) {
+		ERRMSG("Can't allocate memory for the working memory. %s\n",
+		       strerror(errno));
+		goto out;
+	}
+
+	len_buf_out_zlib = compressBound(info->page_size);
+	len_buf_out_lzo = info->page_size + info->page_size / 16 + 64 + 3;
+	len_buf_out = MAX(len_buf_out_zlib, len_buf_out_lzo);
+
 	if ((buf_out = malloc(len_buf_out)) == NULL) {
 		ERRMSG("Can't allocate memory for the compression buffer. %s\n",
 		    strerror(errno));
@@ -4759,11 +4783,21 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data *cd_page)
 		 * Compress the page data.
 		 */
 		size_out = len_buf_out;
-		if (info->flag_compress
-		    && (compress2(buf_out, &size_out, buf,
-		    info->page_size, Z_BEST_SPEED) == Z_OK)
+		if ((info->flag_compress & DUMP_DH_COMPRESSED_ZLIB)
+		    && ((size_out = len_buf_out),
+			compress2(buf_out, &size_out, buf, info->page_size,
+				  Z_BEST_SPEED) == Z_OK)
 		    && (size_out < info->page_size)) {
-			pd.flags = 1;
+			pd.flags = DUMP_DH_COMPRESSED_ZLIB;
+			pd.size  = size_out;
+			memcpy(buf, buf_out, pd.size);
+		} else if (info->flag_lzo_support
+			   && (info->flag_compress & DUMP_DH_COMPRESSED_LZO)
+			   && ((size_out = info->page_size),
+			       lzo1x_1_compress(buf, info->page_size, buf_out,
+						&size_out, wrkmem) == LZO_E_OK)
+			   && (size_out < info->page_size)) {
+			pd.flags = DUMP_DH_COMPRESSED_LZO;
 			pd.size  = size_out;
 			memcpy(buf, buf_out, pd.size);
 		} else {
@@ -4806,6 +4840,8 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data *cd_page)
 out:
 	if (buf_out != NULL)
 		free(buf_out);
+	if (wrkmem != NULL)
+		free(wrkmem);
 
 	return ret;
 }
@@ -6896,7 +6932,7 @@ main(int argc, char *argv[])
 
 	info->block_order = DEFAULT_ORDER;
 	message_level = DEFAULT_MSG_LEVEL;
-	while ((opt = getopt_long(argc, argv, "b:cDd:EFfg:hi:MRrsvXx:", longopts,
+	while ((opt = getopt_long(argc, argv, "b:cDd:EFfg:hi:lMRrsvXx:", longopts,
 	    NULL)) != -1) {
 		switch (opt) {
 		case 'b':
@@ -6906,7 +6942,7 @@ main(int argc, char *argv[])
 			info->name_filterconfig = optarg;
 			break;
 		case 'c':
-			info->flag_compress = 1;
+			info->flag_compress = DUMP_DH_COMPRESSED_ZLIB;
 			break;
 		case 'D':
 			flag_debug = TRUE;
@@ -6945,6 +6981,9 @@ main(int argc, char *argv[])
 				goto out;
 			info->flag_sadump_diskset = 1;
 			break;
+		case 'l':
+			info->flag_compress = DUMP_DH_COMPRESSED_LZO;
+			break;
 		case 'm':
 			message_level = atoi(optarg);
 			break;
diff --git a/makedumpfile.h b/makedumpfile.h
index ebb8929..9594ca7 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -31,6 +31,7 @@
 #include <libelf.h>
 #include <byteswap.h>
 #include <getopt.h>
+#include <lzo/lzo1x.h>
 #include "common.h"
 #include "dwarf_info.h"
 #include "diskdump_mod.h"
@@ -767,6 +768,7 @@ struct DumpInfo {
 	int		num_dump_level;      /* number of dump level */
 	int		array_dump_level[NUM_ARRAY_DUMP_LEVEL];
 	int		flag_compress;       /* flag of compression */
+	int		flag_lzo_support;    /* flag of LZO compression support */
 	int		flag_elf_dumpfile;   /* flag of creating ELF dumpfile */
 	int		flag_generate_vmcoreinfo;/* flag of generating vmcoreinfo file */
 	int		flag_read_vmcoreinfo;    /* flag of reading vmcoreinfo file */



From d.hatayama at jp.fujitsu.com  Wed Feb 22 20:34:05 2012
From: d.hatayama at jp.fujitsu.com (HATAYAMA Daisuke)
Date: Thu, 23 Feb 2012 10:34:05 +0900
Subject: [PATCH makedumpfile v2 2/4] Avoid LONG_MAX/ULONG_MAX redefinitions
In-Reply-To: <20120223012940.5041.61104.stgit@localhost6.localdomain6>
References: <20120223012940.5041.61104.stgit@localhost6.localdomain6>
Message-ID: <20120223013405.5041.35977.stgit@localhost6.localdomain6>

common.h locally defines LONG_MAX and ULONG_MAX. But when importing
lzo library's headers, ulimit.h that is imported implicitly is also
imported so the two definitions collide, and the warning message below
is displayed.

gcc -g -O2 -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DVERSION='"1.4.2"' -DRELEASE_DATE='"25 January 2012"' -D__x86_64__ -DUSELZO  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 -llzo2 -ldw -lbz2 -lebl -ldl -lelf -lz
In file included from makedumpfile.h:37:0,
                 from makedumpfile.c:16:
common.h:23:0: warning: "LONG_MAX" redefined
/usr/lib/gcc/x86_64-redhat-linux/4.5.1/include/limits.h:132:0: note: this is the location of the previous definition
common.h:24:0: warning: "ULONG_MAX" redefined
/usr/lib/gcc/x86_64-redhat-linux/4.5.1/include/limits.h:136:0: note: this is the location of the previous definition

To avoid this problem, check if each has already defiend before
defining it.

Signed-off-by: HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com>
---

 common.h |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/common.h b/common.h
index a4cc2f7..6ad3ca7 100644
--- a/common.h
+++ b/common.h
@@ -20,8 +20,12 @@
 #define FALSE		(0)
 #define ERROR		(-1)
 
+#ifndef LONG_MAX
 #define LONG_MAX	((long)(~0UL>>1))
+#endif
+#ifndef ULONG_MAX
 #define ULONG_MAX	(~0UL)
+#endif
 #define ULONGLONG_MAX	(~0ULL)
 
 #define MAX(a,b)	((a) > (b) ? (a) : (b))



From d.hatayama at jp.fujitsu.com  Wed Feb 22 20:34:10 2012
From: d.hatayama at jp.fujitsu.com (HATAYAMA Daisuke)
Date: Thu, 23 Feb 2012 10:34:10 +0900
Subject: [PATCH makedumpfile v2 3/4] Add help and manual messages about LZO
 compression support
In-Reply-To: <20120223012940.5041.61104.stgit@localhost6.localdomain6>
References: <20120223012940.5041.61104.stgit@localhost6.localdomain6>
Message-ID: <20120223013410.5041.83681.stgit@localhost6.localdomain6>

Signed-off-by: HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com>
---

 makedumpfile.8 |    6 +++---
 print_info.c   |   16 ++++++++--------
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/makedumpfile.8 b/makedumpfile.8
index 4733420..f607bf5 100644
--- a/makedumpfile.8
+++ b/makedumpfile.8
@@ -121,8 +121,8 @@ configuration, you need to use --diskset option.
 .SH OPTIONS
 
 .TP
-\fB\-c\fR
-Compress dump data by each page.
+\fB\-c,\-l\fR
+Compress dump data by each page using zlib for -c option or lzo for -l option.
 .br
 A user cannot specify this option with \-E option, because the ELF format does
 not support compressed data.
@@ -196,7 +196,7 @@ by dump_level 11, makedumpfile retries it by dump_level 31.
 \fB\-E\fR
 Create \fIDUMPFILE\fR in the ELF format.
 .br
-This option cannot be specified with \-c option, because the ELF format does not
+This option cannot be specified with either of \-c option or \-l option, because the ELF format does not
 support compressed data.
 .br
 .B Example:
diff --git a/print_info.c b/print_info.c
index 31460b7..237892e 100644
--- a/print_info.c
+++ b/print_info.c
@@ -35,15 +35,15 @@ print_usage(void)
 	MSG("\n");
 	MSG("Usage:\n");
 	MSG("  Creating DUMPFILE:\n");
-	MSG("  # makedumpfile    [-c|-E] [-d DL] [-x VMLINUX|-i VMCOREINFO] VMCORE DUMPFILE\n");
+	MSG("  # makedumpfile    [-c|-l|-E] [-d DL] [-x VMLINUX|-i VMCOREINFO] VMCORE DUMPFILE\n");
 	MSG("\n");
 	MSG("  Creating DUMPFILE with filtered kernel data specified through filter config\n");
 	MSG("  file:\n");
-	MSG("  # makedumpfile    [-c|-E] [-d DL] -x VMLINUX --config FILTERCONFIGFILE VMCORE\n");
+	MSG("  # makedumpfile    [-c|-l|-E] [-d DL] -x VMLINUX --config FILTERCONFIGFILE VMCORE\n");
 	MSG("    DUMPFILE\n");
 	MSG("\n");
 	MSG("  Outputting the dump data in the flattened format to the standard output:\n");
-	MSG("  # makedumpfile -F [-c|-E] [-d DL] [-x VMLINUX|-i VMCOREINFO] VMCORE\n");
+	MSG("  # makedumpfile -F [-c|-l|-E] [-d DL] [-x VMLINUX|-i VMCOREINFO] VMCORE\n");
 	MSG("\n");
 	MSG("  Rearranging the dump data in the flattened format to a readable DUMPFILE:\n");
 	MSG("  # makedumpfile -R DUMPFILE\n");
@@ -70,14 +70,14 @@ print_usage(void)
 	MSG("\n");
 	MSG("\n");
 	MSG("  Creating DUMPFILE from multiple VMCOREs generated on sadump diskset configuration:\n");
-	MSG("  # makedumpfile [-c] [-d DL] -x VMLINUX --diskset=VMCORE1 --diskset=VMCORE2\n");
+	MSG("  # makedumpfile [-c|-l] [-d DL] -x VMLINUX --diskset=VMCORE1 --diskset=VMCORE2\n");
 	MSG("    [--diskset=VMCORE3 ..] DUMPFILE\n");
 	MSG("\n");
 	MSG("\n");
 	MSG("Available options:\n");
-	MSG("  [-c]:\n");
-	MSG("      Compress dump data by each page.\n");
-	MSG("      A user cannot specify this option with -E option, because the ELF format\n");
+	MSG("  [-c|-l]:\n");
+	MSG("      Compress dump data by each page using zlib for -c option and lzo for -l option.\n");
+	MSG("      A user cannot specify either of these options with -E option, because the ELF format\n");
 	MSG("      does not support compressed data.\n");
 	MSG("      THIS IS ONLY FOR THE CRASH UTILITY.\n");
 	MSG("\n");
@@ -103,7 +103,7 @@ print_usage(void)
 	MSG("\n");
 	MSG("  [-E]:\n");
 	MSG("      Create DUMPFILE in the ELF format.\n");
-	MSG("      This option cannot be specified with -c option, because the ELF\n");
+	MSG("      This option cannot be specified with either of -c option or -l option, because the ELF\n");
 	MSG("      format does not support compressed data.\n");
 	MSG("\n");
 	MSG("  [-x VMLINUX]:\n");



From d.hatayama at jp.fujitsu.com  Wed Feb 22 20:34:15 2012
From: d.hatayama at jp.fujitsu.com (HATAYAMA Daisuke)
Date: Thu, 23 Feb 2012 10:34:15 +0900
Subject: [PATCH makedumpfile v2 4/4] Add build condition for LZO support
In-Reply-To: <20120223012940.5041.61104.stgit@localhost6.localdomain6>
References: <20120223012940.5041.61104.stgit@localhost6.localdomain6>
Message-ID: <20120223013415.5041.53419.stgit@localhost6.localdomain6>

To enable lzo compression support, build makedumpfile as:

  $ make USELZO

To disable, as:

  $ make

In default, lzo compression support is disabled.

Signed-off-by: HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com>
---

 Makefile       |    5 +++++
 makedumpfile.c |   18 ++++++++++++++++--
 makedumpfile.h |    2 ++
 3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index e6b7b89..55082f7 100644
--- a/Makefile
+++ b/Makefile
@@ -34,6 +34,11 @@ ifneq ($(LINKTYPE), dynamic)
 LIBS := -static $(LIBS)
 endif
 
+ifeq ($(USELZO), on)
+LIBS := -llzo2 $(LIBS)
+CFLAGS += -DUSELZO
+endif
+
 all: makedumpfile
 
 $(OBJ_PART): $(SRC_PART)
diff --git a/makedumpfile.c b/makedumpfile.c
index e0079b8..717519a 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -266,6 +266,7 @@ readpmem_kdump_compressed(unsigned long long paddr, void *bufptr, size_t size)
 			goto error;
 		}
 		memcpy(bufptr, buf2 + page_offset, size);
+#ifdef USELZO
 	} else if (info->flag_lzo_support
 		   && (pd.flags & DUMP_DH_COMPRESSED_LZO)) {
 		retlen = info->page_size;
@@ -277,6 +278,7 @@ readpmem_kdump_compressed(unsigned long long paddr, void *bufptr, size_t size)
 			goto error;
 		}
 		memcpy(bufptr, buf2 + page_offset, size);
+#endif
 	} else
 		memcpy(bufptr, buf + page_offset, size);
 
@@ -2509,8 +2511,10 @@ initial(void)
 	unsigned long size;
 	int debug_info = FALSE;
 
+#ifdef USELZO
 	if (lzo_init() == LZO_E_OK)
 		info->flag_lzo_support = TRUE;
+#endif
 
 	if (!is_xen_memory() && info->flag_exclude_xen_dom) {
 		MSG("'-X' option is disable,");
@@ -4679,11 +4683,10 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data *cd_page)
 	off_t offset_data = 0;
 	struct disk_dump_header *dh = info->dump_header;
 	unsigned char buf[info->page_size], *buf_out = NULL;
-	unsigned long len_buf_out, len_buf_out_zlib, len_buf_out_lzo;
+	unsigned long len_buf_out;
 	struct dump_bitmap bitmap2;
 	struct timeval tv_start;
 	const off_t failed = (off_t)-1;
-	lzo_bytep wrkmem = NULL;
 
 	int ret = FALSE;
 
@@ -4692,6 +4695,10 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data *cd_page)
 
 	initialize_2nd_bitmap(&bitmap2);
 
+#ifdef USELZO
+	unsigned long len_buf_out_zlib, len_buf_out_lzo;
+	lzo_bytep wrkmem;
+
 	if ((wrkmem = malloc(LZO1X_1_MEM_COMPRESS)) == NULL) {
 		ERRMSG("Can't allocate memory for the working memory. %s\n",
 		       strerror(errno));
@@ -4701,6 +4708,9 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data *cd_page)
 	len_buf_out_zlib = compressBound(info->page_size);
 	len_buf_out_lzo = info->page_size + info->page_size / 16 + 64 + 3;
 	len_buf_out = MAX(len_buf_out_zlib, len_buf_out_lzo);
+#else
+	len_buf_out = compressBound(info->page_size);
+#endif
 
 	if ((buf_out = malloc(len_buf_out)) == NULL) {
 		ERRMSG("Can't allocate memory for the compression buffer. %s\n",
@@ -4791,6 +4801,7 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data *cd_page)
 			pd.flags = DUMP_DH_COMPRESSED_ZLIB;
 			pd.size  = size_out;
 			memcpy(buf, buf_out, pd.size);
+#ifdef USELZO
 		} else if (info->flag_lzo_support
 			   && (info->flag_compress & DUMP_DH_COMPRESSED_LZO)
 			   && ((size_out = info->page_size),
@@ -4800,6 +4811,7 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data *cd_page)
 			pd.flags = DUMP_DH_COMPRESSED_LZO;
 			pd.size  = size_out;
 			memcpy(buf, buf_out, pd.size);
+#endif
 		} else {
 			pd.flags = 0;
 			pd.size  = info->page_size;
@@ -4840,8 +4852,10 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data *cd_page)
 out:
 	if (buf_out != NULL)
 		free(buf_out);
+#ifdef USELZO
 	if (wrkmem != NULL)
 		free(wrkmem);
+#endif
 
 	return ret;
 }
diff --git a/makedumpfile.h b/makedumpfile.h
index 9594ca7..170ac82 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -31,7 +31,9 @@
 #include <libelf.h>
 #include <byteswap.h>
 #include <getopt.h>
+#ifdef USELZO
 #include <lzo/lzo1x.h>
+#endif
 #include "common.h"
 #include "dwarf_info.h"
 #include "diskdump_mod.h"



From kumagai-atsushi at mxc.nes.nec.co.jp  Thu Feb 23 03:16:46 2012
From: kumagai-atsushi at mxc.nes.nec.co.jp (Atsushi Kumagai)
Date: Thu, 23 Feb 2012 17:16:46 +0900
Subject: [PATCH makedumpfile v2 0/4] LZO Compression Support
In-Reply-To: <20120223012940.5041.61104.stgit@localhost6.localdomain6>
References: <20120223012940.5041.61104.stgit@localhost6.localdomain6>
Message-ID: <20120223171646.18e3dd30.kumagai-atsushi@mxc.nes.nec.co.jp>

Hello Hatayama-san,

On Thu, 23 Feb 2012 10:33:54 +0900
HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> wrote:

> The following series implements LZO compression support to
> makedumpfile. LZO is as good as in size but by far better in speed
> than ZLIB, readucing down time during generation of crash dump and
> refiltering.
> 
> The RFC discussion was made here:
> 
>   http://lists.infradead.org/pipermail/kexec/2011-November/005783.html
>   http://lists.infradead.org/pipermail/kexec/2011-December/005868.html
> 
> How to build:
> 
>   1. Get lzo libraries: lzo, lzo-devel and lzo-minilzo from either of
>   the following:
> 
>     1) Original author's website:
>        http://www.oberhumer.com/opensource/lzo/
> 
>     2) yum framework on fedora. Older releases don't have the packages.
> 
>   2. Apply the patch set to makedumpfile v1.4.2.
> 
>   3. Do make as follows:
> 
>     $ make USELZO=on
> 
>     Note: In default, no LZO compression support is included.
> 
> How to use:
> 
>   Introduce new -l option. If a user specify this, makedumpfile
>   generates dumpfile compressed by pages with lzo compression.
> 
>   Example)
>   $ makedumpfile -l vmcore dumpfile
> 
> Performance evaluation:
> 
>   - Kumagai-san's evaluation simulating working servers:
>     http://lists.infradead.org/pipermail/kexec/2011-December/005868.html
> 
>   - My evaluation focusing on the worst cases:
>     http://lists.infradead.org/pipermail/kexec/2011-November/005783.html
> 
> LZO Support for crash:
> 
>   I'll post LZO support patch for crash after makedumpfile merges
>   these patches.
> 
> Changelog:
> 
>   v1 => v2:
> 
>     - Add build condition for LZO support. Enable LZO support if
>       specifying USELZO=on to make command.
> 
>     - Avoid LONG_MAX/ULONG_MAX redefinitions.

Thank you for your work.
I will review your patches for v1.4.4.

Thanks
Atsushi Kumagai


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

Hi Aruna,

On Wed, 1 Feb 2012 13:15:18 +0900
Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp> wrote:

> 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(-)

I'm reviewing your patch and it looks good.

However, I can't guess that the segmentation fault caused
by --split option because --split option doesn't require an argument.

Would you tell me the case that you thought.

Thanks
Atsushi Kumagai


From arunabal at linux.vnet.ibm.com  Thu Feb 23 05:42:48 2012
From: arunabal at linux.vnet.ibm.com (Aruna Balakrishnaiah)
Date: Thu, 23 Feb 2012 16:12:48 +0530
Subject: [PATCH] Fix segmentation fault for makedumpfile -x/--split
In-Reply-To: <20120223183505.2ab30cfd.kumagai-atsushi@mxc.nes.nec.co.jp>
References: <20120131102456.17966.37854.stgit@aruna-ThinkPad-T420>
 <20120201131518.7764c710.kumagai-atsushi@mxc.nes.nec.co.jp>
 <20120223183505.2ab30cfd.kumagai-atsushi@mxc.nes.nec.co.jp>
Message-ID: <4F461828.8020601@linux.vnet.ibm.com>

On Thursday 23 February 2012 03:05 PM, Atsushi Kumagai wrote:
Hi Atsushi,

> Hi Aruna,
>
> On Wed, 1 Feb 2012 13:15:18 +0900
> Atsushi Kumagai<kumagai-atsushi at mxc.nes.nec.co.jp>  wrote:
>
>> 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(-)
> I'm reviewing your patch and it looks good.
>
> However, I can't guess that the segmentation fault caused
> by --split option because --split option doesn't require an argument.
>
> Would you tell me the case that you thought.
This is the case,

makedumpfile --split -x /boot/vmlinuz vmcore vm1 vm2

when used compressed vmlinux with -x.

Thanks,
Aruna


> Thanks
> Atsushi Kumagai
>


-- 
Regards,
Aruna Balakrishnaiah<aruna at linux.vnet.ibm.com>
Linux Technology Center,
IBM India Systems and Technology Lab



From kumagai-atsushi at mxc.nes.nec.co.jp  Thu Feb 23 22:05:05 2012
From: kumagai-atsushi at mxc.nes.nec.co.jp (Atsushi Kumagai)
Date: Fri, 24 Feb 2012 12:05:05 +0900
Subject: [PATCH] Fix segmentation fault for makedumpfile -x/--split
In-Reply-To: <4F461828.8020601@linux.vnet.ibm.com>
References: <20120131102456.17966.37854.stgit@aruna-ThinkPad-T420>
 <20120201131518.7764c710.kumagai-atsushi@mxc.nes.nec.co.jp>
 <20120223183505.2ab30cfd.kumagai-atsushi@mxc.nes.nec.co.jp>
 <4F461828.8020601@linux.vnet.ibm.com>
Message-ID: <20120224120505.a747b51d.kumagai-atsushi@mxc.nes.nec.co.jp>

Hello Aruna,

On Thu, 23 Feb 2012 16:12:48 +0530
Aruna Balakrishnaiah <arunabal at linux.vnet.ibm.com> wrote:

> > I'm reviewing your patch and it looks good.
> >
> > However, I can't guess that the segmentation fault caused
> > by --split option because --split option doesn't require an argument.
> >
> > Would you tell me the case that you thought.
> This is the case,
> 
> makedumpfile --split -x /boot/vmlinuz vmcore vm1 vm2
> 
> when used compressed vmlinux with -x.

Thank you for your reply, I understand.
I merged your patch into makedumpfile-1.4.3.

Thanks
Atsushi Kumagai


From will.deacon at arm.com  Fri Feb 24 09:40:47 2012
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 24 Feb 2012 14:40:47 +0000
Subject: [PATCH] kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU
 configurations
Message-ID: <1330094447-11900-1-git-send-email-will.deacon@arm.com>

nommu platforms don't have very interesting swapper_pg_dir pointers and
usually just #define them to NULL, meaning that we can't include them in
the vmcoreinfo on the kexec crash path.

This patch only saves the swapper_pg_dir if we have an MMU.

Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 kernel/kexec.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/kernel/kexec.c b/kernel/kexec.c
index 7b08867..cb5d13c 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -1462,7 +1462,9 @@ static int __init crash_save_vmcoreinfo_init(void)
 
 	VMCOREINFO_SYMBOL(init_uts_ns);
 	VMCOREINFO_SYMBOL(node_online_map);
+#ifdef CONFIG_MMU
 	VMCOREINFO_SYMBOL(swapper_pg_dir);
+#endif
 	VMCOREINFO_SYMBOL(_stext);
 	VMCOREINFO_SYMBOL(vmlist);
 
-- 
1.7.4.1



From horms at verge.net.au  Fri Feb 24 21:37:49 2012
From: horms at verge.net.au (Simon Horman)
Date: Sat, 25 Feb 2012 11:37:49 +0900
Subject: [PATCH] kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU
 configurations
In-Reply-To: <1330094447-11900-1-git-send-email-will.deacon@arm.com>
References: <1330094447-11900-1-git-send-email-will.deacon@arm.com>
Message-ID: <20120225023748.GE21429@verge.net.au>

On Fri, Feb 24, 2012 at 02:40:47PM +0000, Will Deacon wrote:
> nommu platforms don't have very interesting swapper_pg_dir pointers and
> usually just #define them to NULL, meaning that we can't include them in
> the vmcoreinfo on the kexec crash path.
> 
> This patch only saves the swapper_pg_dir if we have an MMU.

Hi Will,

might this cover cases where swapper_pg_dir is interesting?

> Signed-off-by: Will Deacon <will.deacon at arm.com>
> ---
>  kernel/kexec.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 7b08867..cb5d13c 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -1462,7 +1462,9 @@ static int __init crash_save_vmcoreinfo_init(void)
>  
>  	VMCOREINFO_SYMBOL(init_uts_ns);
>  	VMCOREINFO_SYMBOL(node_online_map);
> +#ifdef CONFIG_MMU
>  	VMCOREINFO_SYMBOL(swapper_pg_dir);
> +#endif
>  	VMCOREINFO_SYMBOL(_stext);
>  	VMCOREINFO_SYMBOL(vmlist);
>  
> -- 
> 1.7.4.1
> 
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 


From will.deacon at arm.com  Sun Feb 26 17:58:42 2012
From: will.deacon at arm.com (Will Deacon)
Date: Sun, 26 Feb 2012 22:58:42 +0000
Subject: [PATCH] kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU
 configurations
In-Reply-To: <20120225023748.GE21429@verge.net.au>
References: <1330094447-11900-1-git-send-email-will.deacon@arm.com>
 <20120225023748.GE21429@verge.net.au>
Message-ID: <20120226225842.GA23028@mudshark.cambridge.arm.com>

On Sat, Feb 25, 2012 at 02:37:49AM +0000, Simon Horman wrote:
> On Fri, Feb 24, 2012 at 02:40:47PM +0000, Will Deacon wrote:
> > nommu platforms don't have very interesting swapper_pg_dir pointers and
> > usually just #define them to NULL, meaning that we can't include them in
> > the vmcoreinfo on the kexec crash path.
> > 
> > This patch only saves the swapper_pg_dir if we have an MMU.
> 
> Hi Will,

Hi Simon,

> might this cover cases where swapper_pg_dir is interesting?

The only case where it's interesting is when you have CONFIG_MMU enabled -
otherwise it's always NULL. If it's #defined as NULL, the current code will
fail at build time so simply omitting it from the dump seems like the best
bet to me (the alternative being to add a NULL entry explicitly, but I don't
see what the gains us).

Cheers,

Will


From horms at verge.net.au  Sun Feb 26 19:37:30 2012
From: horms at verge.net.au (Simon Horman)
Date: Mon, 27 Feb 2012 09:37:30 +0900
Subject: [PATCH] kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU
 configurations
In-Reply-To: <20120226225842.GA23028@mudshark.cambridge.arm.com>
References: <1330094447-11900-1-git-send-email-will.deacon@arm.com>
 <20120225023748.GE21429@verge.net.au>
 <20120226225842.GA23028@mudshark.cambridge.arm.com>
Message-ID: <20120227003727.GA30831@verge.net.au>

On Sun, Feb 26, 2012 at 10:58:42PM +0000, Will Deacon wrote:
> On Sat, Feb 25, 2012 at 02:37:49AM +0000, Simon Horman wrote:
> > On Fri, Feb 24, 2012 at 02:40:47PM +0000, Will Deacon wrote:
> > > nommu platforms don't have very interesting swapper_pg_dir pointers and
> > > usually just #define them to NULL, meaning that we can't include them in
> > > the vmcoreinfo on the kexec crash path.
> > > 
> > > This patch only saves the swapper_pg_dir if we have an MMU.
> > 
> > Hi Will,
> 
> Hi Simon,
> 
> > might this cover cases where swapper_pg_dir is interesting?
> 
> The only case where it's interesting is when you have CONFIG_MMU enabled -
> otherwise it's always NULL. If it's #defined as NULL, the current code will
> fail at build time so simply omitting it from the dump seems like the best
> bet to me (the alternative being to add a NULL entry explicitly, but I don't
> see what the gains us).

Hi Will,

thanks for the clarification. FWIW I am happy with your patch.

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


From will.deacon at arm.com  Mon Feb 27 14:30:54 2012
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 27 Feb 2012 19:30:54 +0000
Subject: [PATCH] kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU
 configurations
In-Reply-To: <20120227003727.GA30831@verge.net.au>
References: <1330094447-11900-1-git-send-email-will.deacon@arm.com>
 <20120225023748.GE21429@verge.net.au>
 <20120226225842.GA23028@mudshark.cambridge.arm.com>
 <20120227003727.GA30831@verge.net.au>
Message-ID: <20120227193054.GB24605@mudshark.cambridge.arm.com>

On Mon, Feb 27, 2012 at 12:37:30AM +0000, Simon Horman wrote:
> On Sun, Feb 26, 2012 at 10:58:42PM +0000, Will Deacon wrote:
> > On Sat, Feb 25, 2012 at 02:37:49AM +0000, Simon Horman wrote:
> > 
> > > might this cover cases where swapper_pg_dir is interesting?
> > 
> > The only case where it's interesting is when you have CONFIG_MMU enabled -
> > otherwise it's always NULL. If it's #defined as NULL, the current code will
> > fail at build time so simply omitting it from the dump seems like the best
> > bet to me (the alternative being to add a NULL entry explicitly, but I don't
> > see what the gains us).
> 
> Hi Will,
> 
> thanks for the clarification. FWIW I am happy with your patch.
> 
> Reviewed-by: Simon Horman <horms at verge.net.au>

Cheers, Simon. What's the usual path for generic kexec code getting into
mainline? Do I need to get this queued somewhere?

Will


From horms at verge.net.au  Mon Feb 27 18:52:35 2012
From: horms at verge.net.au (Simon Horman)
Date: Tue, 28 Feb 2012 08:52:35 +0900
Subject: [PATCH] kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU
 configurations
In-Reply-To: <20120227193054.GB24605@mudshark.cambridge.arm.com>
References: <1330094447-11900-1-git-send-email-will.deacon@arm.com>
 <20120225023748.GE21429@verge.net.au>
 <20120226225842.GA23028@mudshark.cambridge.arm.com>
 <20120227003727.GA30831@verge.net.au>
 <20120227193054.GB24605@mudshark.cambridge.arm.com>
Message-ID: <20120227235235.GE24159@verge.net.au>

On Mon, Feb 27, 2012 at 07:30:54PM +0000, Will Deacon wrote:
> On Mon, Feb 27, 2012 at 12:37:30AM +0000, Simon Horman wrote:
> > On Sun, Feb 26, 2012 at 10:58:42PM +0000, Will Deacon wrote:
> > > On Sat, Feb 25, 2012 at 02:37:49AM +0000, Simon Horman wrote:
> > > 
> > > > might this cover cases where swapper_pg_dir is interesting?
> > > 
> > > The only case where it's interesting is when you have CONFIG_MMU enabled -
> > > otherwise it's always NULL. If it's #defined as NULL, the current code will
> > > fail at build time so simply omitting it from the dump seems like the best
> > > bet to me (the alternative being to add a NULL entry explicitly, but I don't
> > > see what the gains us).
> > 
> > Hi Will,
> > 
> > thanks for the clarification. FWIW I am happy with your patch.
> > 
> > Reviewed-by: Simon Horman <horms at verge.net.au>
> 
> Cheers, Simon. What's the usual path for generic kexec code getting into
> mainline? Do I need to get this queued somewhere?

I think that Andrew Morton often picks up these kind of patches.

Andrew, can you pick this up if its reposted with you CCed?
For reference the patch is as follows:


From: Will Deacon <will.deacon at arm.com>

kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU configurations

nommu platforms don't have very interesting swapper_pg_dir pointers and
usually just #define them to NULL, meaning that we can't include them in
the vmcoreinfo on the kexec crash path.

This patch only saves the swapper_pg_dir if we have an MMU.

Signed-off-by: Will Deacon <will.deacon at arm.com>
Reviewed-by: Simon Horman <horms at verge.net.au>

---
 kernel/kexec.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/kernel/kexec.c b/kernel/kexec.c
index 7b08867..cb5d13c 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -1462,7 +1462,9 @@ static int __init crash_save_vmcoreinfo_init(void)
 
 	VMCOREINFO_SYMBOL(init_uts_ns);
 	VMCOREINFO_SYMBOL(node_online_map);
+#ifdef CONFIG_MMU
 	VMCOREINFO_SYMBOL(swapper_pg_dir);
+#endif
 	VMCOREINFO_SYMBOL(_stext);
 	VMCOREINFO_SYMBOL(vmlist);
 
-- 
1.7.4.1



From akpm at linux-foundation.org  Mon Feb 27 18:56:43 2012
From: akpm at linux-foundation.org (Andrew Morton)
Date: Mon, 27 Feb 2012 15:56:43 -0800
Subject: [PATCH] kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU
 configurations
In-Reply-To: <20120227235235.GE24159@verge.net.au>
References: <1330094447-11900-1-git-send-email-will.deacon@arm.com>
 <20120225023748.GE21429@verge.net.au>
 <20120226225842.GA23028@mudshark.cambridge.arm.com>
 <20120227003727.GA30831@verge.net.au>
 <20120227193054.GB24605@mudshark.cambridge.arm.com>
 <20120227235235.GE24159@verge.net.au>
Message-ID: <20120227155643.cafb1c6d.akpm@linux-foundation.org>

On Tue, 28 Feb 2012 08:52:35 +0900
Simon Horman <horms at verge.net.au> wrote:

> On Mon, Feb 27, 2012 at 07:30:54PM +0000, Will Deacon wrote:
> > On Mon, Feb 27, 2012 at 12:37:30AM +0000, Simon Horman wrote:
> > > On Sun, Feb 26, 2012 at 10:58:42PM +0000, Will Deacon wrote:
> > > > On Sat, Feb 25, 2012 at 02:37:49AM +0000, Simon Horman wrote:
> > > > 
> > > > > might this cover cases where swapper_pg_dir is interesting?
> > > > 
> > > > The only case where it's interesting is when you have CONFIG_MMU enabled -
> > > > otherwise it's always NULL. If it's #defined as NULL, the current code will
> > > > fail at build time so simply omitting it from the dump seems like the best
> > > > bet to me (the alternative being to add a NULL entry explicitly, but I don't
> > > > see what the gains us).
> > > 
> > > Hi Will,
> > > 
> > > thanks for the clarification. FWIW I am happy with your patch.
> > > 
> > > Reviewed-by: Simon Horman <horms at verge.net.au>
> > 
> > Cheers, Simon. What's the usual path for generic kexec code getting into
> > mainline? Do I need to get this queued somewhere?
> 
> I think that Andrew Morton often picks up these kind of patches.

I'll take anything, if I have any chance of vaguely understanding it ;)

> Andrew, can you pick this up if its reposted with you CCed?
> For reference the patch is as follows:
> 
> 
> From: Will Deacon <will.deacon at arm.com>
> 
> kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU configurations
> 
> nommu platforms don't have very interesting swapper_pg_dir pointers and
> usually just #define them to NULL, meaning that we can't include them in
> the vmcoreinfo on the kexec crash path.
> 
> This patch only saves the swapper_pg_dir if we have an MMU.
> 
> Signed-off-by: Will Deacon <will.deacon at arm.com>
> Reviewed-by: Simon Horman <horms at verge.net.au>
> 
> ---
>  kernel/kexec.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 7b08867..cb5d13c 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -1462,7 +1462,9 @@ static int __init crash_save_vmcoreinfo_init(void)
>  
>  	VMCOREINFO_SYMBOL(init_uts_ns);
>  	VMCOREINFO_SYMBOL(node_online_map);
> +#ifdef CONFIG_MMU
>  	VMCOREINFO_SYMBOL(swapper_pg_dir);
> +#endif
>  	VMCOREINFO_SYMBOL(_stext);
>  	VMCOREINFO_SYMBOL(vmlist);

Well, what might be the effects of this patch?  nommu crashfiles will
no longer have the swapper_pg_dir string?  What are the chances that
someone's (badly written!) downstream tool will crash and burn if this
is absent?



From horms at verge.net.au  Mon Feb 27 19:19:28 2012
From: horms at verge.net.au (Simon Horman)
Date: Tue, 28 Feb 2012 09:19:28 +0900
Subject: [PATCH] kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU
 configurations
In-Reply-To: <20120227155643.cafb1c6d.akpm@linux-foundation.org>
References: <1330094447-11900-1-git-send-email-will.deacon@arm.com>
 <20120225023748.GE21429@verge.net.au>
 <20120226225842.GA23028@mudshark.cambridge.arm.com>
 <20120227003727.GA30831@verge.net.au>
 <20120227193054.GB24605@mudshark.cambridge.arm.com>
 <20120227235235.GE24159@verge.net.au>
 <20120227155643.cafb1c6d.akpm@linux-foundation.org>
Message-ID: <20120228001928.GB11325@verge.net.au>

On Mon, Feb 27, 2012 at 03:56:43PM -0800, Andrew Morton wrote:
> On Tue, 28 Feb 2012 08:52:35 +0900
> Simon Horman <horms at verge.net.au> wrote:
> 
> > On Mon, Feb 27, 2012 at 07:30:54PM +0000, Will Deacon wrote:
> > > On Mon, Feb 27, 2012 at 12:37:30AM +0000, Simon Horman wrote:
> > > > On Sun, Feb 26, 2012 at 10:58:42PM +0000, Will Deacon wrote:
> > > > > On Sat, Feb 25, 2012 at 02:37:49AM +0000, Simon Horman wrote:
> > > > > 
> > > > > > might this cover cases where swapper_pg_dir is interesting?
> > > > > 
> > > > > The only case where it's interesting is when you have CONFIG_MMU enabled -
> > > > > otherwise it's always NULL. If it's #defined as NULL, the current code will
> > > > > fail at build time so simply omitting it from the dump seems like the best
> > > > > bet to me (the alternative being to add a NULL entry explicitly, but I don't
> > > > > see what the gains us).
> > > > 
> > > > Hi Will,
> > > > 
> > > > thanks for the clarification. FWIW I am happy with your patch.
> > > > 
> > > > Reviewed-by: Simon Horman <horms at verge.net.au>
> > > 
> > > Cheers, Simon. What's the usual path for generic kexec code getting into
> > > mainline? Do I need to get this queued somewhere?
> > 
> > I think that Andrew Morton often picks up these kind of patches.
> 
> I'll take anything, if I have any chance of vaguely understanding it ;)
> 
> > Andrew, can you pick this up if its reposted with you CCed?
> > For reference the patch is as follows:
> > 
> > 
> > From: Will Deacon <will.deacon at arm.com>
> > 
> > kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU configurations
> > 
> > nommu platforms don't have very interesting swapper_pg_dir pointers and
> > usually just #define them to NULL, meaning that we can't include them in
> > the vmcoreinfo on the kexec crash path.
> > 
> > This patch only saves the swapper_pg_dir if we have an MMU.
> > 
> > Signed-off-by: Will Deacon <will.deacon at arm.com>
> > Reviewed-by: Simon Horman <horms at verge.net.au>
> > 
> > ---
> >  kernel/kexec.c |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/kernel/kexec.c b/kernel/kexec.c
> > index 7b08867..cb5d13c 100644
> > --- a/kernel/kexec.c
> > +++ b/kernel/kexec.c
> > @@ -1462,7 +1462,9 @@ static int __init crash_save_vmcoreinfo_init(void)
> >  
> >  	VMCOREINFO_SYMBOL(init_uts_ns);
> >  	VMCOREINFO_SYMBOL(node_online_map);
> > +#ifdef CONFIG_MMU
> >  	VMCOREINFO_SYMBOL(swapper_pg_dir);
> > +#endif
> >  	VMCOREINFO_SYMBOL(_stext);
> >  	VMCOREINFO_SYMBOL(vmlist);
> 
> Well, what might be the effects of this patch?  nommu crashfiles will
> no longer have the swapper_pg_dir string?  What are the chances that
> someone's (badly written!) downstream tool will crash and burn if this
> is absent?

My understanding is that up until this patch creating a dump
for nonmmu platform wouldn't work.


From akpm at linux-foundation.org  Mon Feb 27 19:26:31 2012
From: akpm at linux-foundation.org (Andrew Morton)
Date: Mon, 27 Feb 2012 16:26:31 -0800
Subject: [PATCH] kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU
 configurations
In-Reply-To: <20120228001928.GB11325@verge.net.au>
References: <1330094447-11900-1-git-send-email-will.deacon@arm.com>
 <20120225023748.GE21429@verge.net.au>
 <20120226225842.GA23028@mudshark.cambridge.arm.com>
 <20120227003727.GA30831@verge.net.au>
 <20120227193054.GB24605@mudshark.cambridge.arm.com>
 <20120227235235.GE24159@verge.net.au>
 <20120227155643.cafb1c6d.akpm@linux-foundation.org>
 <20120228001928.GB11325@verge.net.au>
Message-ID: <20120227162631.55cf014e.akpm@linux-foundation.org>

On Tue, 28 Feb 2012 09:19:28 +0900
Simon Horman <horms at verge.net.au> wrote:

> > > --- a/kernel/kexec.c
> > > +++ b/kernel/kexec.c
> > > @@ -1462,7 +1462,9 @@ static int __init crash_save_vmcoreinfo_init(void)
> > >  
> > >  	VMCOREINFO_SYMBOL(init_uts_ns);
> > >  	VMCOREINFO_SYMBOL(node_online_map);
> > > +#ifdef CONFIG_MMU
> > >  	VMCOREINFO_SYMBOL(swapper_pg_dir);
> > > +#endif
> > >  	VMCOREINFO_SYMBOL(_stext);
> > >  	VMCOREINFO_SYMBOL(vmlist);
> > 
> > Well, what might be the effects of this patch?  nommu crashfiles will
> > no longer have the swapper_pg_dir string?  What are the chances that
> > someone's (badly written!) downstream tool will crash and burn if this
> > is absent?
> 
> My understanding is that up until this patch creating a dump
> for nonmmu platform wouldn't work.

Surprised.  From reading the code I expect it would have emitted 

	SYMBOL(swapper_pg_dir)=0

?


From horms at verge.net.au  Mon Feb 27 19:51:30 2012
From: horms at verge.net.au (Simon Horman)
Date: Tue, 28 Feb 2012 09:51:30 +0900
Subject: [PATCH] kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU
 configurations
In-Reply-To: <20120227162631.55cf014e.akpm@linux-foundation.org>
References: <1330094447-11900-1-git-send-email-will.deacon@arm.com>
 <20120225023748.GE21429@verge.net.au>
 <20120226225842.GA23028@mudshark.cambridge.arm.com>
 <20120227003727.GA30831@verge.net.au>
 <20120227193054.GB24605@mudshark.cambridge.arm.com>
 <20120227235235.GE24159@verge.net.au>
 <20120227155643.cafb1c6d.akpm@linux-foundation.org>
 <20120228001928.GB11325@verge.net.au>
 <20120227162631.55cf014e.akpm@linux-foundation.org>
Message-ID: <20120228005130.GE11325@verge.net.au>

On Mon, Feb 27, 2012 at 04:26:31PM -0800, Andrew Morton wrote:
> On Tue, 28 Feb 2012 09:19:28 +0900
> Simon Horman <horms at verge.net.au> wrote:
> 
> > > > --- a/kernel/kexec.c
> > > > +++ b/kernel/kexec.c
> > > > @@ -1462,7 +1462,9 @@ static int __init crash_save_vmcoreinfo_init(void)
> > > >  
> > > >  	VMCOREINFO_SYMBOL(init_uts_ns);
> > > >  	VMCOREINFO_SYMBOL(node_online_map);
> > > > +#ifdef CONFIG_MMU
> > > >  	VMCOREINFO_SYMBOL(swapper_pg_dir);
> > > > +#endif
> > > >  	VMCOREINFO_SYMBOL(_stext);
> > > >  	VMCOREINFO_SYMBOL(vmlist);
> > > 
> > > Well, what might be the effects of this patch?  nommu crashfiles will
> > > no longer have the swapper_pg_dir string?  What are the chances that
> > > someone's (badly written!) downstream tool will crash and burn if this
> > > is absent?
> > 
> > My understanding is that up until this patch creating a dump
> > for nonmmu platform wouldn't work.
> 
> Surprised.  From reading the code I expect it would have emitted 
> 
> 	SYMBOL(swapper_pg_dir)=0

Hi Andrew,

My understanding from discussion with Will earlier in this thread is that if
CONFIG_MMU is not defined then swapper_pg_dir is NULL and the current code
doesn't compile.

	<quote>
	The only case where it's interesting is when you have CONFIG_MMU
	enabled - otherwise it's always NULL. If it's #defined as NULL, the
	current code will fail at build time so simply omitting it from the
	dump seems like the best bet to me (the alternative being to add a
	NULL entry explicitly, but I don't see what the gains us).
	</quote>



From akpm at linux-foundation.org  Mon Feb 27 20:25:55 2012
From: akpm at linux-foundation.org (Andrew Morton)
Date: Mon, 27 Feb 2012 17:25:55 -0800
Subject: [PATCH] kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU
 configurations
In-Reply-To: <20120228005130.GE11325@verge.net.au>
References: <1330094447-11900-1-git-send-email-will.deacon@arm.com>
 <20120225023748.GE21429@verge.net.au>
 <20120226225842.GA23028@mudshark.cambridge.arm.com>
 <20120227003727.GA30831@verge.net.au>
 <20120227193054.GB24605@mudshark.cambridge.arm.com>
 <20120227235235.GE24159@verge.net.au>
 <20120227155643.cafb1c6d.akpm@linux-foundation.org>
 <20120228001928.GB11325@verge.net.au>
 <20120227162631.55cf014e.akpm@linux-foundation.org>
 <20120228005130.GE11325@verge.net.au>
Message-ID: <20120227172555.46bffedf.akpm@linux-foundation.org>

On Tue, 28 Feb 2012 09:51:30 +0900 Simon Horman <horms at verge.net.au> wrote:

> On Mon, Feb 27, 2012 at 04:26:31PM -0800, Andrew Morton wrote:
> > On Tue, 28 Feb 2012 09:19:28 +0900
> > Simon Horman <horms at verge.net.au> wrote:
> > 
> > > > > --- a/kernel/kexec.c
> > > > > +++ b/kernel/kexec.c
> > > > > @@ -1462,7 +1462,9 @@ static int __init crash_save_vmcoreinfo_init(void)
> > > > >  
> > > > >  	VMCOREINFO_SYMBOL(init_uts_ns);
> > > > >  	VMCOREINFO_SYMBOL(node_online_map);
> > > > > +#ifdef CONFIG_MMU
> > > > >  	VMCOREINFO_SYMBOL(swapper_pg_dir);
> > > > > +#endif
> > > > >  	VMCOREINFO_SYMBOL(_stext);
> > > > >  	VMCOREINFO_SYMBOL(vmlist);
> > > > 
> > > > Well, what might be the effects of this patch?  nommu crashfiles will
> > > > no longer have the swapper_pg_dir string?  What are the chances that
> > > > someone's (badly written!) downstream tool will crash and burn if this
> > > > is absent?
> > > 
> > > My understanding is that up until this patch creating a dump
> > > for nonmmu platform wouldn't work.
> > 
> > Surprised.  From reading the code I expect it would have emitted 
> > 
> > 	SYMBOL(swapper_pg_dir)=0
> 
> Hi Andrew,
> 
> My understanding from discussion with Will earlier in this thread is that if
> CONFIG_MMU is not defined then swapper_pg_dir is NULL and the current code
> doesn't compile.
> 
> 	<quote>
> 	The only case where it's interesting is when you have CONFIG_MMU
> 	enabled - otherwise it's always NULL. If it's #defined as NULL, the
> 	current code will fail at build time so simply omitting it from the
> 	dump seems like the best bet to me (the alternative being to add a
> 	NULL entry explicitly, but I don't see what the gains us).
> 	</quote>

OK.  That's because everything is all screwed up ;)

swapper_pg_dir is normally an array.  But on nommu it is a pointer. 
VMCOREINFO_SYMBOL() wants to take its address (unnecessary on an array)
and this blows up when fed a pointer.


Still, you didn't answer my question!  What effect will the absence of
SYMBOL(swapper_pg_dir)= have upon downstream tools?  If "none" then
sure, let's remove it.  If "explosion" then we should emit a dummy
SYMBOL(swapper_pg_dir)=0 if CONFIG_NOMMU.



From horms at verge.net.au  Mon Feb 27 20:35:27 2012
From: horms at verge.net.au (Simon Horman)
Date: Tue, 28 Feb 2012 10:35:27 +0900
Subject: [PATCH] kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU
 configurations
In-Reply-To: <20120227172555.46bffedf.akpm@linux-foundation.org>
References: <20120225023748.GE21429@verge.net.au>
 <20120226225842.GA23028@mudshark.cambridge.arm.com>
 <20120227003727.GA30831@verge.net.au>
 <20120227193054.GB24605@mudshark.cambridge.arm.com>
 <20120227235235.GE24159@verge.net.au>
 <20120227155643.cafb1c6d.akpm@linux-foundation.org>
 <20120228001928.GB11325@verge.net.au>
 <20120227162631.55cf014e.akpm@linux-foundation.org>
 <20120228005130.GE11325@verge.net.au>
 <20120227172555.46bffedf.akpm@linux-foundation.org>
Message-ID: <20120228013526.GA7913@verge.net.au>

On Mon, Feb 27, 2012 at 05:25:55PM -0800, Andrew Morton wrote:
> On Tue, 28 Feb 2012 09:51:30 +0900 Simon Horman <horms at verge.net.au> wrote:
> 
> > On Mon, Feb 27, 2012 at 04:26:31PM -0800, Andrew Morton wrote:
> > > On Tue, 28 Feb 2012 09:19:28 +0900
> > > Simon Horman <horms at verge.net.au> wrote:
> > > 
> > > > > > --- a/kernel/kexec.c
> > > > > > +++ b/kernel/kexec.c
> > > > > > @@ -1462,7 +1462,9 @@ static int __init crash_save_vmcoreinfo_init(void)
> > > > > >  
> > > > > >  	VMCOREINFO_SYMBOL(init_uts_ns);
> > > > > >  	VMCOREINFO_SYMBOL(node_online_map);
> > > > > > +#ifdef CONFIG_MMU
> > > > > >  	VMCOREINFO_SYMBOL(swapper_pg_dir);
> > > > > > +#endif
> > > > > >  	VMCOREINFO_SYMBOL(_stext);
> > > > > >  	VMCOREINFO_SYMBOL(vmlist);
> > > > > 
> > > > > Well, what might be the effects of this patch?  nommu crashfiles will
> > > > > no longer have the swapper_pg_dir string?  What are the chances that
> > > > > someone's (badly written!) downstream tool will crash and burn if this
> > > > > is absent?
> > > > 
> > > > My understanding is that up until this patch creating a dump
> > > > for nonmmu platform wouldn't work.
> > > 
> > > Surprised.  From reading the code I expect it would have emitted 
> > > 
> > > 	SYMBOL(swapper_pg_dir)=0
> > 
> > Hi Andrew,
> > 
> > My understanding from discussion with Will earlier in this thread is that if
> > CONFIG_MMU is not defined then swapper_pg_dir is NULL and the current code
> > doesn't compile.
> > 
> > 	<quote>
> > 	The only case where it's interesting is when you have CONFIG_MMU
> > 	enabled - otherwise it's always NULL. If it's #defined as NULL, the
> > 	current code will fail at build time so simply omitting it from the
> > 	dump seems like the best bet to me (the alternative being to add a
> > 	NULL entry explicitly, but I don't see what the gains us).
> > 	</quote>
> 
> OK.  That's because everything is all screwed up ;)
> 
> swapper_pg_dir is normally an array.  But on nommu it is a pointer. 
> VMCOREINFO_SYMBOL() wants to take its address (unnecessary on an array)
> and this blows up when fed a pointer.
> 
> 
> Still, you didn't answer my question!  What effect will the absence of
> SYMBOL(swapper_pg_dir)= have upon downstream tools?  If "none" then
> sure, let's remove it.  If "explosion" then we should emit a dummy
> SYMBOL(swapper_pg_dir)=0 if CONFIG_NOMMU.

My thought was that the tools wouldn't be used in the CONFIG_NOMMU case (yet).
But I take your point and I think the answer is that the fallout is unknown.
Emitting a dummy value as you suggest seems reasonable.



From ANDY.KENNEDY at adtran.com  Tue Feb 28 02:24:23 2012
From: ANDY.KENNEDY at adtran.com (ANDY KENNEDY)
Date: Tue, 28 Feb 2012 07:24:23 +0000
Subject: Debugging on MIPS.
Message-ID: <F9C551623D2CBB4C9488801D14F864C610AA6F@ex-mb1.corp.adtran.com>

I got *I hope* the tip from @ ~midnight US Central time:

git clone git://github.com/horms/kexec-tools.git

My issue (in case you have forgotten -- it has been a few months) is
that since version 2.0.1 (a couple steps after that), I cannot use
kexec on my MIPS core with 2.6.36.1.  I get nothing.  I've done a bit of
poking around and I can make the kernel boot, however, command line
parameters are missing.

Comparing 2.0.1 with the tip and looking at kexec_load (via adding in
printf's just before the syscall), I see that entry = 0x0,
nr_segments = 2, (didn't print the segments), and the flags = 0x0.

Running the same command with the tip, I get:

entry = 0x1042d0, nr_segments = 2, flags = 0x00080000.

Interestingly, my bootloader determines that the entry point of this
kernel is 0x104290, but sets this address as a virtual.  So, following
that lead, just before the syscall:

entry += 0x80000000;

Boom, the kernel boots.  I get a kernel panic, however, since it cannot
find my RFS.

Further annoyances are that I changed the #if 0 to 1 around the
following code:

#if 0
        fprintf(stdout, "kexec_load: entry = %p flags = %lx\n", 
                info.entry, info.kexec_flags);
        print_segments(stdout, &info);
#endif

Which would have given me all sorts of cool stuff.  Problem is that it
will only output:

kexec_load: entry = 0x1042d0 flags = 80000
nr_segments = 2 
segment[0].buf   = 0x2b1a6008 
segment[0].bufsz = 377b5c 
segment[0].mem   = 0x100000 
segment[0].m

Even more curious is that after the call to my_load, I can printf()
exactly 16 chars before we lock hard.

Testing this information a bit further on the system, I see that at the
top of my_load, before the memset, I can printf() about 1500 chars
before the lockup.

Something is probing destructively.  Any ideas where I should look?

Thanks,
Andy


From will.deacon at arm.com  Tue Feb 28 04:40:57 2012
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 28 Feb 2012 09:40:57 +0000
Subject: [PATCH] kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU
 configurations
In-Reply-To: <20120228013526.GA7913@verge.net.au>
References: <20120226225842.GA23028@mudshark.cambridge.arm.com>
 <20120227003727.GA30831@verge.net.au>
 <20120227193054.GB24605@mudshark.cambridge.arm.com>
 <20120227235235.GE24159@verge.net.au>
 <20120227155643.cafb1c6d.akpm@linux-foundation.org>
 <20120228001928.GB11325@verge.net.au>
 <20120227162631.55cf014e.akpm@linux-foundation.org>
 <20120228005130.GE11325@verge.net.au>
 <20120227172555.46bffedf.akpm@linux-foundation.org>
 <20120228013526.GA7913@verge.net.au>
Message-ID: <20120228094057.GC25625@mudshark.cambridge.arm.com>

Hi Simon, Andrew,

Sorry for re-joining the thread late, I was sleeping :)

On Tue, Feb 28, 2012 at 01:35:27AM +0000, Simon Horman wrote:
> On Mon, Feb 27, 2012 at 05:25:55PM -0800, Andrew Morton wrote:
> > swapper_pg_dir is normally an array.  But on nommu it is a pointer. 
> > VMCOREINFO_SYMBOL() wants to take its address (unnecessary on an array)
> > and this blows up when fed a pointer.

Yup. It's a fairly dull pointer at that, which is why I chose to remove it in
the nommu case.

> > Still, you didn't answer my question!  What effect will the absence of
> > SYMBOL(swapper_pg_dir)= have upon downstream tools?  If "none" then
> > sure, let's remove it.  If "explosion" then we should emit a dummy
> > SYMBOL(swapper_pg_dir)=0 if CONFIG_NOMMU.
> 
> My thought was that the tools wouldn't be used in the CONFIG_NOMMU case (yet).
> But I take your point and I think the answer is that the fallout is unknown.
> Emitting a dummy value as you suggest seems reasonable.

The reason I didn't choose a dummy value to start with is because there are
plenty of other fields in the dump that are predicated on build-time CONFIG
options. Admittedly, some of these appear to be tagged with length
information, but consider these guys:

#ifndef CONFIG_NEED_MULTIPLE_NODES
        VMCOREINFO_SYMBOL(mem_map);
        VMCOREINFO_SYMBOL(contig_page_data);
#endif

Since the VMCOREINFO_SYMBOL macro stringifies the identifier, I guess userspace
has to treat the whole thing as a map, meaning that we *can* safely remove
elements from it.

So that's my speculation. Maybe somebody on the kexec list can confirm?

Cheers,

Will


From akpm at linux-foundation.org  Tue Feb 28 15:45:54 2012
From: akpm at linux-foundation.org (Andrew Morton)
Date: Tue, 28 Feb 2012 12:45:54 -0800
Subject: [PATCH] kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU
 configurations
In-Reply-To: <20120228094057.GC25625@mudshark.cambridge.arm.com>
References: <20120226225842.GA23028@mudshark.cambridge.arm.com>
 <20120227003727.GA30831@verge.net.au>
 <20120227193054.GB24605@mudshark.cambridge.arm.com>
 <20120227235235.GE24159@verge.net.au>
 <20120227155643.cafb1c6d.akpm@linux-foundation.org>
 <20120228001928.GB11325@verge.net.au>
 <20120227162631.55cf014e.akpm@linux-foundation.org>
 <20120228005130.GE11325@verge.net.au>
 <20120227172555.46bffedf.akpm@linux-foundation.org>
 <20120228013526.GA7913@verge.net.au>
 <20120228094057.GC25625@mudshark.cambridge.arm.com>
Message-ID: <20120228124554.73b4f051.akpm@linux-foundation.org>

On Tue, 28 Feb 2012 09:40:57 +0000
Will Deacon <will.deacon at arm.com> wrote:

> > > Still, you didn't answer my question!  What effect will the absence of
> > > SYMBOL(swapper_pg_dir)= have upon downstream tools?  If "none" then
> > > sure, let's remove it.  If "explosion" then we should emit a dummy
> > > SYMBOL(swapper_pg_dir)=0 if CONFIG_NOMMU.
> > 
> > My thought was that the tools wouldn't be used in the CONFIG_NOMMU case (yet).
> > But I take your point and I think the answer is that the fallout is unknown.
> > Emitting a dummy value as you suggest seems reasonable.
> 
> The reason I didn't choose a dummy value to start with is because there are
> plenty of other fields in the dump that are predicated on build-time CONFIG
> options. Admittedly, some of these appear to be tagged with length
> information, but consider these guys:
> 
> #ifndef CONFIG_NEED_MULTIPLE_NODES
>         VMCOREINFO_SYMBOL(mem_map);
>         VMCOREINFO_SYMBOL(contig_page_data);
> #endif
> 
> Since the VMCOREINFO_SYMBOL macro stringifies the identifier, I guess userspace
> has to treat the whole thing as a map, meaning that we *can* safely remove
> elements from it.
> 
> So that's my speculation. Maybe somebody on the kexec list can confirm?

Yeah, I do think the chance of breaking anything here is small, and in
the unlikely event that something *does* break then a) it deserved to
break ;) and b) the user of that app will be a developer who can
unbreak it.

Let's run with the patch as-is.


From horms at verge.net.au  Tue Feb 28 20:32:57 2012
From: horms at verge.net.au (Simon Horman)
Date: Wed, 29 Feb 2012 10:32:57 +0900
Subject: [PATCH] kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU
 configurations
In-Reply-To: <20120228124554.73b4f051.akpm@linux-foundation.org>
References: <20120227193054.GB24605@mudshark.cambridge.arm.com>
 <20120227235235.GE24159@verge.net.au>
 <20120227155643.cafb1c6d.akpm@linux-foundation.org>
 <20120228001928.GB11325@verge.net.au>
 <20120227162631.55cf014e.akpm@linux-foundation.org>
 <20120228005130.GE11325@verge.net.au>
 <20120227172555.46bffedf.akpm@linux-foundation.org>
 <20120228013526.GA7913@verge.net.au>
 <20120228094057.GC25625@mudshark.cambridge.arm.com>
 <20120228124554.73b4f051.akpm@linux-foundation.org>
Message-ID: <20120229013257.GG6013@verge.net.au>

On Tue, Feb 28, 2012 at 12:45:54PM -0800, Andrew Morton wrote:
> On Tue, 28 Feb 2012 09:40:57 +0000
> Will Deacon <will.deacon at arm.com> wrote:
> 
> > > > Still, you didn't answer my question!  What effect will the absence of
> > > > SYMBOL(swapper_pg_dir)= have upon downstream tools?  If "none" then
> > > > sure, let's remove it.  If "explosion" then we should emit a dummy
> > > > SYMBOL(swapper_pg_dir)=0 if CONFIG_NOMMU.
> > > 
> > > My thought was that the tools wouldn't be used in the CONFIG_NOMMU case (yet).
> > > But I take your point and I think the answer is that the fallout is unknown.
> > > Emitting a dummy value as you suggest seems reasonable.
> > 
> > The reason I didn't choose a dummy value to start with is because there are
> > plenty of other fields in the dump that are predicated on build-time CONFIG
> > options. Admittedly, some of these appear to be tagged with length
> > information, but consider these guys:
> > 
> > #ifndef CONFIG_NEED_MULTIPLE_NODES
> >         VMCOREINFO_SYMBOL(mem_map);
> >         VMCOREINFO_SYMBOL(contig_page_data);
> > #endif
> > 
> > Since the VMCOREINFO_SYMBOL macro stringifies the identifier, I guess userspace
> > has to treat the whole thing as a map, meaning that we *can* safely remove
> > elements from it.
> > 
> > So that's my speculation. Maybe somebody on the kexec list can confirm?
> 
> Yeah, I do think the chance of breaking anything here is small, and in
> the unlikely event that something *does* break then a) it deserved to
> break ;) and b) the user of that app will be a developer who can
> unbreak it.
> 
> Let's run with the patch as-is.

Fine by me :)


From surovegin at google.com  Wed Feb 29 12:21:23 2012
From: surovegin at google.com (Eugene Surovegin)
Date: Wed, 29 Feb 2012 09:21:23 -0800
Subject: [PATCH] kdump: force page alignment for per-CPU crash notes.
Message-ID: <1330536083-13098-1-git-send-email-surovegin@google.com>

Per-CPU allocations are not guaranteed to be physically contiguous.
However, kdump kernel and user-space code assumes that per-CPU
memory, used for saving CPU registers on crash, is.
This can cause corrupted /proc/vmcore in some cases - the main
symptom being huge ELF note section.

Force page alignment for note_buf_t to ensure that this assumption holds.

Signed-off-by: Eugene Surovegin <surovegin at google.com>
CC: Eric Biederman <ebiederm at xmission.com>
CC: Vivek Goyal <vgoyal at redhat.com>
CC: kexec-list <kexec at lists.infradead.org>
---
 kernel/kexec.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/kernel/kexec.c b/kernel/kexec.c
index 7b08867..e641b5c 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -1232,8 +1232,13 @@ void crash_save_cpu(struct pt_regs *regs, int cpu)
 
 static int __init crash_notes_memory_init(void)
 {
-	/* Allocate memory for saving cpu registers. */
-	crash_notes = alloc_percpu(note_buf_t);
+	/* Allocate memory for saving cpu registers.
+	 * Force page alignment to avoid crossing physical page boundary -
+	 * kexec-tools and kernel /proc/vmcore handler assume these per-CPU
+	 * chunks are physically contiguous.
+	 */
+	crash_notes = (note_buf_t __percpu *)__alloc_percpu(sizeof(note_buf_t),
+							    PAGE_SIZE);
 	if (!crash_notes) {
 		printk("Kexec: Memory allocation for saving cpu register"
 		" states failed\n");
-- 
1.7.9.1



From dzickus at redhat.com  Wed Feb 29 15:08:49 2012
From: dzickus at redhat.com (Don Zickus)
Date: Wed, 29 Feb 2012 15:08:49 -0500
Subject: [PATCH] x86, kdump: No need to disable ioapic in crash path
Message-ID: <1330546129-4812-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.

Eric, brought up a point that because the boot code was restructured we may
not need to disable the io apic any more in the crash path.  The original
concern that led to the development of disable_IO_APIC, was that the jiffies
calibration on boot up relied on the PIT timer for reference.  Access
to the PIT required 8259 interrupts to be working.  This wouldn't work
if the ioapic needed to be configured.  So on panic path, the ioapic was
reconfigured to use virtual wire mode to allow the 8259 to passthrough.

Those concerns don't hold true now, thanks to the jiffies calibration code
not needing the PIT.  As a result, we can remove this call and simplify the
locking needed in the panic path.

I tested kdump on an Ivy Bridge platform, a Pentium4 and an old athlon that
did not have an ioapic.  All three were successful.

I also tested using lkdtm that would use jprobes to panic the system when
entering do_IRQ.  The idea was to see how the system reacted with an
interrupt pending in the second kernel.  My core2 quad successfully kdump'd
3 times in a row with no issues.

v2: removed the disable lapic code too
v3: re-add disabling of lapic code

Cc: Eric W. Biederman <ebiederm at xmission.com>
Cc: Vivek Goyal <vgoyal at redhat.com>
Signed-off-by: Don Zickus <dzickus at redhat.com>
---

There are really two problems here.  One is the deadlock of the ioapic_lock
that I describe above.  Removing the code to disable the ioapic seems to
resolve that.

The second issue is handling non-IRQ exceptions like NMIs.  Eric asked me
to include removing the disable lapic code too.  However, because the nmi
watchdog is stil active and kexec zeros out the idt before it jumps to
purgatory, an NMI that comes in during the transition between the first
kernel and second kernel will see an empty idt and reset the cpu.

Leaving the code to disable the lapic in, turns off perf and blocks those NMIs
from happening (though an external NMI would still be an issue but that is no
different than right now).

I tried playing with a stub idt and leaving it in place through the transition
to the second kernel, but I can't quite get it to work correctly.  Spinning in the
first kernel before the purgatory jump catches the idt properly.  Spinning in
purgatory before the second kernel jump doesn't.  I even disabled the zero'ing
out of the idt in the purgatory code.

I would like to get resolution on the ioapic deadlock to fix a customer issue
while working the idt and NMI thing on the side, hence the split of this
patchset.

Hopefully, people recognize there are two issues here and that this patch
resolves the first one and the second one needs more debugging and time.
---
 arch/x86/kernel/crash.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 13ad899..b053cf9 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -96,9 +96,6 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
 	cpu_emergency_svm_disable();
 
 	lapic_shutdown();
-#if defined(CONFIG_X86_IO_APIC)
-	disable_IO_APIC();
-#endif
 #ifdef CONFIG_HPET_TIMER
 	hpet_disable();
 #endif
-- 
1.7.7.6



From ebiederm at xmission.com  Wed Feb 29 18:19:11 2012
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Wed, 29 Feb 2012 15:19:11 -0800
Subject: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path
In-Reply-To: <20120221135934.GF26998@redhat.com> (Don Zickus's message of
 "Tue, 21 Feb 2012 08:59:34 -0500")
References: <CAE9FiQVPnO8-tuPoio0Wxv=8rjdm2tJbBk3+3ystueyYtZn9BA@mail.gmail.com>
 <20120216172735.GX9751@redhat.com>
 <CAE9FiQVhbAM9vjx-uFcuc0ndsUp0aez9_TsQHStje5G5iwYbag@mail.gmail.com>
 <20120216215603.GH9751@redhat.com> <m1y5s2ku36.fsf@fess.ebiederm.org>
 <m1fwe9bpk2.fsf@fess.ebiederm.org> <20120217195430.GO9751@redhat.com>
 <m1y5s07rn3.fsf@fess.ebiederm.org> <20120220151419.GU9751@redhat.com>
 <m1obss39a4.fsf@fess.ebiederm.org> <20120221135934.GF26998@redhat.com>
Message-ID: <m1ipip6xe8.fsf@fess.ebiederm.org>

Don Zickus <dzickus at redhat.com> writes:

> On Tue, Feb 21, 2012 at 12:01:07AM -0800, Eric W. Biederman wrote:
>> Don Zickus <dzickus at redhat.com> writes:
>> 
>> 2> On Fri, Feb 17, 2012 at 07:21:52PM -0800, Eric W. Biederman wrote:
>> >> Don Zickus <dzickus at redhat.com> writes:
>> >> 
>> >> > On Fri, Feb 17, 2012 at 04:41:01AM -0800, Eric W. Biederman wrote:
>> >> >> 
>> >> >> The fix with a guarantee of no more scope creep is to just disable the
>> >> >> nmi watchdog on the kexec on panic path.
>> >> >> 
>> >> >> Don if you have time please figure out is needed to ignore nmi's and
>> >> >> possible record and/or report them while we boot, otherwise please cook
>> >> >> up a patch that just disables the nmi watchdog wherever we are sending
>> >> >> it from (the local apic or the ioapic).
>> >> >
>> >> > Can I keep things even simpler?  The original problem was the deadlock
>> >> > with the ioapic lock.  We fixed that by removing the call to
>> >> > disable_IO_APIC().  Can we just leave the disable_local_APIC calls in
>> >> > there for now?  Is there any real harm?
>> >> 
>> >> > All this rewrite is going to take time which will delay fixing a current
>> >> > problem with kexec on panic, the ioapic deadlock.
>> >> 
>> >> Hmm.
>> >> 
>> >> My apologies I just realized that we can not disable the nmi watchdog
>> >> safely in all cases.  To avoid the deadlock we fundamentally can not
>> >> write to the io_apic, because the locks are the io_apic write path.
>> >> The nmi watchdog can be sourced from either the local apics or the
>> >> io_apics.  To disable the nmi_watchdog we need at least potentially
>> >> to write io_apic.
>> >
>> > I am curious where you see the nmi watchdog being sourced from the ioapic?
>> > I thought I removed that code 3 or 4 releases ago.
>> 
>> In my memory, and in references to the code in comments in various apic
>> related code.  I couldn't figure out what the current code was doing and
>> assumed the implementation was equivalent.  It does look like you
>> removed the code that used the io_apic.  I still haven't figured
>> out just how the new implementation works yet.
>
> It is just a client of perf now.  Perf controls the local apic accesses.
> A lot simpler now.
>
>> 
>> So maybe in the short term we can safely just stomp the timer that
>> triggers the nmi watchdog in the local apic.  Over the long term that
>> feels like it is just asking for trouble.
>
> I can understand that.
>
>> 
>> I wonder if the reason that we have an hpet stomp in that code is
>> for a similar reason.  Did we ever source nmi's from the hpet timer?
>> 
>> >> So it appears to me that the only reasonable and robust thing we can
>> >> do is to ignore nmis in the kexec on panic path.
>> >> 
>> >> So it looks to me that the only path forward at this point is to fix
>> >> the other bug where an unexpected nmi will kill the kexec on panic boot.
>> >> 
>> >> I just took a look at the code in /sbin/kexec and that code does not in
>> >> fact change the idt except when we switch to 16bit mode, which we
>> >> definitely do not do in the kexec on panic case.  So it appears that we
>> >> don't need to coordinate an /sbin/kexec release with a kernel release to
>> >> ignore nmis.
>> >> 
>> >> In fact it looks like we only need to fix the interrupt descriptors
>> >> loaded in machine_kexec_64.c and head64.c to ignore nmis.
>> >> 
>> >> At which point we will have fixed two bugs and have a much more reliable
>> >> kexec on panic implementation.
>> >
>> > Ok.  I'll talk with Vivek about how the can be implemented.
>> 
>> Thanks.  It really doesn't look very hard.  Just a tiny idt with
>> an nmi entry that says iret.
>
> It probably is, except I never hacked on idt code before and my assembly
> isn't that good.  I have been trying to find examples to copy from to give
> it a try.  So far I was using early_idt_handlers with early_printk to see
> if I could capture some printk messages while jumping from the first
> kernel to the second kernel (when the other early_idt_handlers would kick
> in for the second kernel).
>
> Tips?  Better examples?

That is a particularly good example.  When I took a quick look earlier
that is the first place we reload the idt in the kernel boot so that is
one of two places that needs to be modified.

The other place in the reboot code page (which will be a little tricky
because of it's relocatability) needs to have code that roughly says:

kexec_nmi_handler:
        ; Does this vector get any other kind of parameters and saved
        ; registers that we need to restore?
        ; Different types of exceptions handlers have different rules
        ; that I don't remember off the top of my head. call gates, trap
 	; gates, etc.
	iret

kexec_idt:
	.long 0, 0				; IDT entry 0
	.long 0, 0				; IDT entry 1
	.long something, kexec_nmi_handler 	; IDT entry 2 NMI's

You can write to the kexec_idt from C code and for the nmi handler you
just need to make certain all is good.

The code has to be tested and the proper Intel CPU manual should
probably be consulted to make certain you dot your eyes and cross your
t's but we really don't need much code to change on this path.

Eric

p.s. Apologies for the delay I overlooked this message earlier.


From horms at verge.net.au  Wed Feb 29 20:18:11 2012
From: horms at verge.net.au (Simon Horman)
Date: Thu, 1 Mar 2012 10:18:11 +0900
Subject: [PATCH] kdump: force page alignment for per-CPU crash notes.
In-Reply-To: <1330536083-13098-1-git-send-email-surovegin@google.com>
References: <1330536083-13098-1-git-send-email-surovegin@google.com>
Message-ID: <20120301011811.GC16483@verge.net.au>

On Wed, Feb 29, 2012 at 09:21:23AM -0800, Eugene Surovegin wrote:
> Per-CPU allocations are not guaranteed to be physically contiguous.
> However, kdump kernel and user-space code assumes that per-CPU
> memory, used for saving CPU registers on crash, is.
> This can cause corrupted /proc/vmcore in some cases - the main
> symptom being huge ELF note section.
> 
> Force page alignment for note_buf_t to ensure that this assumption holds.

Ouch. I'm surprised there is an allocation on crash, perhaps
it could at least be done earlier? And am I right in thinking
that this change increases the likely hood that the allocation
could fail?

> 
> Signed-off-by: Eugene Surovegin <surovegin at google.com>
> CC: Eric Biederman <ebiederm at xmission.com>
> CC: Vivek Goyal <vgoyal at redhat.com>
> CC: kexec-list <kexec at lists.infradead.org>
> ---
>  kernel/kexec.c |    9 +++++++--
>  1 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 7b08867..e641b5c 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -1232,8 +1232,13 @@ void crash_save_cpu(struct pt_regs *regs, int cpu)
>  
>  static int __init crash_notes_memory_init(void)
>  {
> -	/* Allocate memory for saving cpu registers. */
> -	crash_notes = alloc_percpu(note_buf_t);
> +	/* Allocate memory for saving cpu registers.
> +	 * Force page alignment to avoid crossing physical page boundary -
> +	 * kexec-tools and kernel /proc/vmcore handler assume these per-CPU
> +	 * chunks are physically contiguous.
> +	 */
> +	crash_notes = (note_buf_t __percpu *)__alloc_percpu(sizeof(note_buf_t),
> +							    PAGE_SIZE);
>  	if (!crash_notes) {
>  		printk("Kexec: Memory allocation for saving cpu register"
>  		" states failed\n");
> -- 
> 1.7.9.1
> 
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 


From surovegin at google.com  Wed Feb 29 20:23:10 2012
From: surovegin at google.com (Eugene Surovegin)
Date: Wed, 29 Feb 2012 17:23:10 -0800
Subject: [PATCH] kdump: force page alignment for per-CPU crash notes.
In-Reply-To: <20120301011811.GC16483@verge.net.au>
References: <1330536083-13098-1-git-send-email-surovegin@google.com>
 <20120301011811.GC16483@verge.net.au>
Message-ID: <CANrfoUXd4L2bjBO+L8ZBCkc1dfnZahn39sB25zsrUMqGA5zY5A@mail.gmail.com>

On Wed, Feb 29, 2012 at 5:18 PM, Simon Horman <horms at verge.net.au> wrote:

> On Wed, Feb 29, 2012 at 09:21:23AM -0800, Eugene Surovegin wrote:
> > Per-CPU allocations are not guaranteed to be physically contiguous.
> > However, kdump kernel and user-space code assumes that per-CPU
> > memory, used for saving CPU registers on crash, is.
> > This can cause corrupted /proc/vmcore in some cases - the main
> > symptom being huge ELF note section.
> >
> > Force page alignment for note_buf_t to ensure that this assumption holds.
>
> Ouch. I'm surprised there is an allocation on crash, perhaps
> it could at least be done earlier? And am I right in thinking
> that this change increases the likely hood that the allocation
> could fail?
>

I'm not following. This allocation is done on start-up, not on crash.
If you cannot allocate this much memory on system boot, I'm not sure what
else you can do on this system....

-- 
Eugene
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/kexec/attachments/20120229/bb00c113/attachment-0001.html>

From horms at verge.net.au  Wed Feb 29 20:32:01 2012
From: horms at verge.net.au (Simon Horman)
Date: Thu, 1 Mar 2012 10:32:01 +0900
Subject: [PATCH] kdump: force page alignment for per-CPU crash notes.
In-Reply-To: <CANrfoUXd4L2bjBO+L8ZBCkc1dfnZahn39sB25zsrUMqGA5zY5A@mail.gmail.com>
References: <1330536083-13098-1-git-send-email-surovegin@google.com>
 <20120301011811.GC16483@verge.net.au>
 <CANrfoUXd4L2bjBO+L8ZBCkc1dfnZahn39sB25zsrUMqGA5zY5A@mail.gmail.com>
Message-ID: <20120301013200.GF16483@verge.net.au>

On Wed, Feb 29, 2012 at 05:23:10PM -0800, Eugene Surovegin wrote:
> On Wed, Feb 29, 2012 at 5:18 PM, Simon Horman <horms at verge.net.au> wrote:
> 
> > On Wed, Feb 29, 2012 at 09:21:23AM -0800, Eugene Surovegin wrote:
> > > Per-CPU allocations are not guaranteed to be physically contiguous.
> > > However, kdump kernel and user-space code assumes that per-CPU
> > > memory, used for saving CPU registers on crash, is.
> > > This can cause corrupted /proc/vmcore in some cases - the main
> > > symptom being huge ELF note section.
> > >
> > > Force page alignment for note_buf_t to ensure that this assumption holds.
> >
> > Ouch. I'm surprised there is an allocation on crash, perhaps
> > it could at least be done earlier? And am I right in thinking
> > that this change increases the likely hood that the allocation
> > could fail?
> >
> 
> I'm not following. This allocation is done on start-up, not on crash.
> If you cannot allocate this much memory on system boot, I'm not sure what
> else you can do on this system....

Sorry, my eyes deceived me. You are correct and I agree.

Is it the case that note_buf_t is never larger than PAGE_SIZE?
If so I your patch looks good to me.


From surovegin at google.com  Wed Feb 29 20:39:55 2012
From: surovegin at google.com (Eugene Surovegin)
Date: Wed, 29 Feb 2012 17:39:55 -0800
Subject: [PATCH] kdump: force page alignment for per-CPU crash notes.
In-Reply-To: <20120301013200.GF16483@verge.net.au>
References: <1330536083-13098-1-git-send-email-surovegin@google.com>
 <20120301011811.GC16483@verge.net.au>
 <CANrfoUXd4L2bjBO+L8ZBCkc1dfnZahn39sB25zsrUMqGA5zY5A@mail.gmail.com>
 <20120301013200.GF16483@verge.net.au>
Message-ID: <CANrfoUVTSh6jWckz2jt9+X6E6FSPL5OwqWNrcXchbo1BwkCLgw@mail.gmail.com>

On Wed, Feb 29, 2012 at 5:32 PM, Simon Horman <horms at verge.net.au> wrote:
> On Wed, Feb 29, 2012 at 05:23:10PM -0800, Eugene Surovegin wrote:
>> On Wed, Feb 29, 2012 at 5:18 PM, Simon Horman <horms at verge.net.au> wrote:
>>
>> > On Wed, Feb 29, 2012 at 09:21:23AM -0800, Eugene Surovegin wrote:
>> > > Per-CPU allocations are not guaranteed to be physically contiguous.
>> > > However, kdump kernel and user-space code assumes that per-CPU
>> > > memory, used for saving CPU registers on crash, is.
>> > > This can cause corrupted /proc/vmcore in some cases - the main
>> > > symptom being huge ELF note section.
>> > >
>> > > Force page alignment for note_buf_t to ensure that this assumption holds.
>> >
>> > Ouch. I'm surprised there is an allocation on crash, perhaps
>> > it could at least be done earlier? And am I right in thinking
>> > that this change increases the likely hood that the allocation
>> > could fail?
>> >
>>
>> I'm not following. This allocation is done on start-up, not on crash.
>> If you cannot allocate this much memory on system boot, I'm not sure what
>> else you can do on this system....
>
> Sorry, my eyes deceived me. You are correct and I agree.
>
> Is it the case that note_buf_t is never larger than PAGE_SIZE?
> If so I your patch looks good to me.

Currently, maximum note size is hardcoded in kexec-tools to 1024
(MAX_NOTE_BYTES).
Usually it's way less. IIRC on x86_64 it's 336 bytes.

--
Eugene


From kumagai-atsushi at mxc.nes.nec.co.jp  Wed Feb 29 20:40:49 2012
From: kumagai-atsushi at mxc.nes.nec.co.jp (Atsushi Kumagai)
Date: Thu, 1 Mar 2012 10:40:49 +0900
Subject: makedumpfile-1.4.3: Support for PPC32 architecture.
Message-ID: <20120301104049.01ce685f.kumagai-atsushi@mxc.nes.nec.co.jp>

Hi,

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

Suzuki implemented "Support for PPC32" feature. Thanks, Suzuki.


Changelog:
o New feature
   Commits related to "Support for PPC32"
    - [PATCH v1 1/3] Support for cross building. (by Suzuki K. Poulose) 96f24dc
    - [PATCH v1 2/3][ppc64] Rename the __powerpc__ macro to __powerpc64__ for PPC64. (by Suzuki K. Poulose) 3d8b733
    - [PATCH v1 3/3] Add support for PPC32. (by Suzuki K. Poulose) 9cfcdae
   Other commit
    - [PATCH] Support newer kernels. (by Atsushi Kumagai) 029ebaf

o Bugfix
    - [PATCH] Fix segmentation fault for makedumpfile -x/--split. (by Aruna Balakrishnaiah) 8bc7d44
    - [PATCH] Fix VtoP method for x86 remap allocator. (by Petr Tesarik) 3812217

o TODO
    - Send the patch to the LKML to store some symbols in VMCOREINFO.
      (VtoP method for x86 remap allocator needs some symbols that
       relate to remap allocator.)
    - Support newer kernels (Especially DISCONTIGMEM).


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 d.hatayama at jp.fujitsu.com  Wed Feb 29 20:51:26 2012
From: d.hatayama at jp.fujitsu.com (HATAYAMA Daisuke)
Date: Thu, 01 Mar 2012 10:51:26 +0900 (   )
Subject: [PATCH] kdump: force page alignment for per-CPU crash notes.
In-Reply-To: <CANrfoUVTSh6jWckz2jt9+X6E6FSPL5OwqWNrcXchbo1BwkCLgw@mail.gmail.com>
References: <CANrfoUXd4L2bjBO+L8ZBCkc1dfnZahn39sB25zsrUMqGA5zY5A@mail.gmail.com>
 <20120301013200.GF16483@verge.net.au>
 <CANrfoUVTSh6jWckz2jt9+X6E6FSPL5OwqWNrcXchbo1BwkCLgw@mail.gmail.com>
Message-ID: <20120301.105126.193682835.d.hatayama@jp.fujitsu.com>

From: Eugene Surovegin <surovegin at google.com>
Subject: Re: [PATCH] kdump: force page alignment for per-CPU crash notes.
Date: Wed, 29 Feb 2012 17:39:55 -0800

> On Wed, Feb 29, 2012 at 5:32 PM, Simon Horman <horms at verge.net.au> wrote:
>> On Wed, Feb 29, 2012 at 05:23:10PM -0800, Eugene Surovegin wrote:
>>> On Wed, Feb 29, 2012 at 5:18 PM, Simon Horman <horms at verge.net.au> wrote:
>>>
>>> > On Wed, Feb 29, 2012 at 09:21:23AM -0800, Eugene Surovegin wrote:
>>> > > Per-CPU allocations are not guaranteed to be physically contiguous.
>>> > > However, kdump kernel and user-space code assumes that per-CPU
>>> > > memory, used for saving CPU registers on crash, is.
>>> > > This can cause corrupted /proc/vmcore in some cases - the main
>>> > > symptom being huge ELF note section.
>>> > >
>>> > > Force page alignment for note_buf_t to ensure that this assumption holds.
>>> >
>>> > Ouch. I'm surprised there is an allocation on crash, perhaps
>>> > it could at least be done earlier? And am I right in thinking
>>> > that this change increases the likely hood that the allocation
>>> > could fail?
>>> >
>>>
>>> I'm not following. This allocation is done on start-up, not on crash.
>>> If you cannot allocate this much memory on system boot, I'm not sure what
>>> else you can do on this system....
>>
>> Sorry, my eyes deceived me. You are correct and I agree.
>>
>> Is it the case that note_buf_t is never larger than PAGE_SIZE?
>> If so I your patch looks good to me.
> 
> Currently, maximum note size is hardcoded in kexec-tools to 1024
> (MAX_NOTE_BYTES).
> Usually it's way less. IIRC on x86_64 it's 336 bytes.
> 

This is elf_prstatus and I guess it's mostly equal to registers.

crash> p sizeof(struct elf_prstatus)
$3 = 336
crash> ptype struct elf_prstatus
type = struct elf_prstatus {
    struct elf_siginfo pr_info;
    short int pr_cursig;
    long unsigned int pr_sigpend;
    long unsigned int pr_sighold;
    pid_t pr_pid;
    pid_t pr_ppid;
    pid_t pr_pgrp;
    pid_t pr_sid;
    struct timeval pr_utime;
    struct timeval pr_stime;
    struct timeval pr_cutime;
    struct timeval pr_cstime;
    elf_gregset_t pr_reg; <-- this
    int pr_fpvalid;
}

What kinds of architecture does have so many registers? It's just my
interest. Or possibly other kinds of notes is written here?

Thanks.
HATAYAMA, Daisuke



From surovegin at google.com  Wed Feb 29 20:56:54 2012
From: surovegin at google.com (Eugene Surovegin)
Date: Wed, 29 Feb 2012 17:56:54 -0800
Subject: [PATCH] kdump: force page alignment for per-CPU crash notes.
In-Reply-To: <20120301.105126.193682835.d.hatayama@jp.fujitsu.com>
References: <CANrfoUXd4L2bjBO+L8ZBCkc1dfnZahn39sB25zsrUMqGA5zY5A@mail.gmail.com>
 <20120301013200.GF16483@verge.net.au>
 <CANrfoUVTSh6jWckz2jt9+X6E6FSPL5OwqWNrcXchbo1BwkCLgw@mail.gmail.com>
 <20120301.105126.193682835.d.hatayama@jp.fujitsu.com>
Message-ID: <CANrfoUXGyjXeWSHWXzTq1r9Trd8riSWkF4+DoejJXRBnHkDPvw@mail.gmail.com>

On Wed, Feb 29, 2012 at 5:51 PM, HATAYAMA Daisuke
<d.hatayama at jp.fujitsu.com> wrote:
> From: Eugene Surovegin <surovegin at google.com>
> Subject: Re: [PATCH] kdump: force page alignment for per-CPU crash notes.
> Date: Wed, 29 Feb 2012 17:39:55 -0800
>
>> On Wed, Feb 29, 2012 at 5:32 PM, Simon Horman <horms at verge.net.au> wrote:
>>> On Wed, Feb 29, 2012 at 05:23:10PM -0800, Eugene Surovegin wrote:
>>>> On Wed, Feb 29, 2012 at 5:18 PM, Simon Horman <horms at verge.net.au> wrote:
>>>>
>>>> > On Wed, Feb 29, 2012 at 09:21:23AM -0800, Eugene Surovegin wrote:
>>>> > > Per-CPU allocations are not guaranteed to be physically contiguous.
>>>> > > However, kdump kernel and user-space code assumes that per-CPU
>>>> > > memory, used for saving CPU registers on crash, is.
>>>> > > This can cause corrupted /proc/vmcore in some cases - the main
>>>> > > symptom being huge ELF note section.
>>>> > >
>>>> > > Force page alignment for note_buf_t to ensure that this assumption holds.
>>>> >
>>>> > Ouch. I'm surprised there is an allocation on crash, perhaps
>>>> > it could at least be done earlier? And am I right in thinking
>>>> > that this change increases the likely hood that the allocation
>>>> > could fail?
>>>> >
>>>>
>>>> I'm not following. This allocation is done on start-up, not on crash.
>>>> If you cannot allocate this much memory on system boot, I'm not sure what
>>>> else you can do on this system....
>>>
>>> Sorry, my eyes deceived me. You are correct and I agree.
>>>
>>> Is it the case that note_buf_t is never larger than PAGE_SIZE?
>>> If so I your patch looks good to me.
>>
>> Currently, maximum note size is hardcoded in kexec-tools to 1024
>> (MAX_NOTE_BYTES).
>> Usually it's way less. IIRC on x86_64 it's 336 bytes.
>>
>
> This is elf_prstatus and I guess it's mostly equal to registers.
>
> crash> p sizeof(struct elf_prstatus)
> $3 = 336
> crash> ptype struct elf_prstatus
> type = struct elf_prstatus {
> ? ?struct elf_siginfo pr_info;
> ? ?short int pr_cursig;
> ? ?long unsigned int pr_sigpend;
> ? ?long unsigned int pr_sighold;
> ? ?pid_t pr_pid;
> ? ?pid_t pr_ppid;
> ? ?pid_t pr_pgrp;
> ? ?pid_t pr_sid;
> ? ?struct timeval pr_utime;
> ? ?struct timeval pr_stime;
> ? ?struct timeval pr_cutime;
> ? ?struct timeval pr_cstime;
> ? ?elf_gregset_t pr_reg; <-- this
> ? ?int pr_fpvalid;
> }
>
> What kinds of architecture does have so many registers? It's just my
> interest. Or possibly other kinds of notes is written here?

I'm not sure about other archs, but we don't write there anything
except for 'elf_prstatus' and sentinel "final" note.

--
Eugene


From horms at verge.net.au  Wed Feb 29 21:50:39 2012
From: horms at verge.net.au (Simon Horman)
Date: Thu, 1 Mar 2012 11:50:39 +0900
Subject: [PATCH] kdump: force page alignment for per-CPU crash notes.
In-Reply-To: <20120301.105126.193682835.d.hatayama@jp.fujitsu.com>
References: <CANrfoUXd4L2bjBO+L8ZBCkc1dfnZahn39sB25zsrUMqGA5zY5A@mail.gmail.com>
 <20120301013200.GF16483@verge.net.au>
 <CANrfoUVTSh6jWckz2jt9+X6E6FSPL5OwqWNrcXchbo1BwkCLgw@mail.gmail.com>
 <20120301.105126.193682835.d.hatayama@jp.fujitsu.com>
Message-ID: <20120301025038.GD10053@verge.net.au>

On Thu, Mar 01, 2012 at 10:51:26AM +0900, HATAYAMA Daisuke wrote:
> From: Eugene Surovegin <surovegin at google.com>
> Subject: Re: [PATCH] kdump: force page alignment for per-CPU crash notes.
> Date: Wed, 29 Feb 2012 17:39:55 -0800
> 
> > On Wed, Feb 29, 2012 at 5:32 PM, Simon Horman <horms at verge.net.au> wrote:
> >> On Wed, Feb 29, 2012 at 05:23:10PM -0800, Eugene Surovegin wrote:
> >>> On Wed, Feb 29, 2012 at 5:18 PM, Simon Horman <horms at verge.net.au> wrote:
> >>>
> >>> > On Wed, Feb 29, 2012 at 09:21:23AM -0800, Eugene Surovegin wrote:
> >>> > > Per-CPU allocations are not guaranteed to be physically contiguous.
> >>> > > However, kdump kernel and user-space code assumes that per-CPU
> >>> > > memory, used for saving CPU registers on crash, is.
> >>> > > This can cause corrupted /proc/vmcore in some cases - the main
> >>> > > symptom being huge ELF note section.
> >>> > >
> >>> > > Force page alignment for note_buf_t to ensure that this assumption holds.
> >>> >
> >>> > Ouch. I'm surprised there is an allocation on crash, perhaps
> >>> > it could at least be done earlier? And am I right in thinking
> >>> > that this change increases the likely hood that the allocation
> >>> > could fail?
> >>> >
> >>>
> >>> I'm not following. This allocation is done on start-up, not on crash.
> >>> If you cannot allocate this much memory on system boot, I'm not sure what
> >>> else you can do on this system....
> >>
> >> Sorry, my eyes deceived me. You are correct and I agree.
> >>
> >> Is it the case that note_buf_t is never larger than PAGE_SIZE?
> >> If so I your patch looks good to me.
> > 
> > Currently, maximum note size is hardcoded in kexec-tools to 1024
> > (MAX_NOTE_BYTES).
> > Usually it's way less. IIRC on x86_64 it's 336 bytes.

I presume that MAX_NOTE_BYTES was chosen to be large to
minimise the chance that it would ever need to be changed.

> This is elf_prstatus and I guess it's mostly equal to registers.
> 
> crash> p sizeof(struct elf_prstatus)
> $3 = 336
> crash> ptype struct elf_prstatus
> type = struct elf_prstatus {
>     struct elf_siginfo pr_info;
>     short int pr_cursig;
>     long unsigned int pr_sigpend;
>     long unsigned int pr_sighold;
>     pid_t pr_pid;
>     pid_t pr_ppid;
>     pid_t pr_pgrp;
>     pid_t pr_sid;
>     struct timeval pr_utime;
>     struct timeval pr_stime;
>     struct timeval pr_cutime;
>     struct timeval pr_cstime;
>     elf_gregset_t pr_reg; <-- this
>     int pr_fpvalid;
> }
> 
> What kinds of architecture does have so many registers? It's just my
> interest. Or possibly other kinds of notes is written here?

The winner seems to be ia64 with 128.


From horms at verge.net.au  Wed Feb 29 21:53:29 2012
From: horms at verge.net.au (Simon Horman)
Date: Thu, 1 Mar 2012 11:53:29 +0900
Subject: [PATCH] kdump: force page alignment for per-CPU crash notes.
In-Reply-To: <CANrfoUVTSh6jWckz2jt9+X6E6FSPL5OwqWNrcXchbo1BwkCLgw@mail.gmail.com>
References: <1330536083-13098-1-git-send-email-surovegin@google.com>
 <20120301011811.GC16483@verge.net.au>
 <CANrfoUXd4L2bjBO+L8ZBCkc1dfnZahn39sB25zsrUMqGA5zY5A@mail.gmail.com>
 <20120301013200.GF16483@verge.net.au>
 <CANrfoUVTSh6jWckz2jt9+X6E6FSPL5OwqWNrcXchbo1BwkCLgw@mail.gmail.com>
Message-ID: <20120301025328.GF10053@verge.net.au>

On Wed, Feb 29, 2012 at 05:39:55PM -0800, Eugene Surovegin wrote:
> On Wed, Feb 29, 2012 at 5:32 PM, Simon Horman <horms at verge.net.au> wrote:
> > On Wed, Feb 29, 2012 at 05:23:10PM -0800, Eugene Surovegin wrote:
> >> On Wed, Feb 29, 2012 at 5:18 PM, Simon Horman <horms at verge.net.au> wrote:
> >>
> >> > On Wed, Feb 29, 2012 at 09:21:23AM -0800, Eugene Surovegin wrote:
> >> > > Per-CPU allocations are not guaranteed to be physically contiguous.
> >> > > However, kdump kernel and user-space code assumes that per-CPU
> >> > > memory, used for saving CPU registers on crash, is.
> >> > > This can cause corrupted /proc/vmcore in some cases - the main
> >> > > symptom being huge ELF note section.
> >> > >
> >> > > Force page alignment for note_buf_t to ensure that this assumption holds.
> >> >
> >> > Ouch. I'm surprised there is an allocation on crash, perhaps
> >> > it could at least be done earlier? And am I right in thinking
> >> > that this change increases the likely hood that the allocation
> >> > could fail?
> >> >
> >>
> >> I'm not following. This allocation is done on start-up, not on crash.
> >> If you cannot allocate this much memory on system boot, I'm not sure what
> >> else you can do on this system....
> >
> > Sorry, my eyes deceived me. You are correct and I agree.
> >
> > Is it the case that note_buf_t is never larger than PAGE_SIZE?
> > If so I your patch looks good to me.
> 
> Currently, maximum note size is hardcoded in kexec-tools to 1024
> (MAX_NOTE_BYTES).
> Usually it's way less. IIRC on x86_64 it's 336 bytes.

Ok, understood.

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


