kexec boot regression
in [Kernel]
|
Prev: [mmotm][PATCH 4/5] mm : add lowmem detection logic
Next: move eject code from zd1211rw to usb-storage
From: Jens Axboe on 15 Dec 2009 14:50 On Tue, Dec 15 2009, Yinghai Lu wrote: > [PATCH] x86/pci: intel ioh bus num reg accessing fix > > it is above 0x100, so if mmconf is not enable, need to skip it This works, it kexecs kernels fine. But since 2.6.32 doesn't have the mmconf problem to begin with, are we now just working around the issue? SRAT still reports issues, numa doesn't work. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai Lu on 15 Dec 2009 14:50 Jens Axboe wrote: > On Tue, Dec 15 2009, Yinghai Lu wrote: >> [PATCH] x86/pci: intel ioh bus num reg accessing fix >> >> it is above 0x100, so if mmconf is not enable, need to skip it > > This works, it kexecs kernels fine. But since 2.6.32 doesn't have the > mmconf problem to begin with, are we now just working around the issue? > SRAT still reports issues, numa doesn't work. that patch will be bullet proof... we need it. also still need to figure out why memmap range is not passed properly. do you mean 2.6.32 kexec 2.6.32 it have worked mmconf and numa in second kernel? YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai Lu on 15 Dec 2009 14:50 Jens Axboe wrote: > On Tue, Dec 15 2009, Yinghai Lu wrote: >> Jens Axboe wrote: >>> On Tue, Dec 15 2009, Yinghai Lu wrote: >>>> [ 13.018720] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000) >>>> >>>> [ 13.100724] [Firmware Bug]: PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] not reserved in ACPI motherboard resources >>> On a "normal" non-kexec boot, I get: >>> >>> [ 12.173583] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000) >>> [ 12.184075] PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] reserved in E820 >>> [ 12.216874] PCI: Using configuration type 1 for base access >>> >> can you run following scripts in first kernel? >> >> cd /sys/firmware/memmap >> for dir in * ; do >> start=$(cat $dir/start) >> end=$(cat $dir/end) >> type=$(cat $dir/type) >> printf "%016x-%016x (%s)\n" $start $[ $end +1] "$type" >> /tmp/memmap.txt >> done >> >> and send out /tmp/memmap.txt > > Below. > >> what is your kexec tools version? could be too old? > > It says: > > kexec-tools-testing 20080324 released 24th March 2008 > > > 0000000000000000-0000000000098800 (System RAM) > 0000000000098800-00000000000a0000 (reserved) > 0000000079301000-0000000079303000 (reserved) > 0000000079303000-0000000079305000 (ACPI Tables) > 0000000079305000-0000000079310000 (reserved) > 0000000079310000-0000000079314000 (ACPI Tables) > 0000000079314000-0000000079319000 (reserved) > 0000000079319000-0000000079336000 (ACPI Tables) > 0000000079336000-0000000079358000 (reserved) > 0000000079358000-0000000079388000 (ACPI Tables) > 0000000079388000-00000000793c9000 (reserved) > 00000000793c9000-000000007968f000 (ACPI Tables) > 00000000000e0000-0000000000100000 (reserved) > 000000007968f000-00000000796bb000 (reserved) > 00000000796bb000-00000000799d8000 (ACPI Tables) > 00000000799d8000-0000000079bd8000 (ACPI Non-volatile Storage) > 0000000079bd8000-0000000079d8b000 (ACPI Tables) > 0000000079d8b000-0000000079d8c000 (reserved) > 0000000079d8c000-0000000079dc8000 (ACPI Tables) > 0000000079dc8000-0000000079dcb000 (reserved) > 0000000079dcb000-0000000079e1c000 (ACPI Tables) > 0000000079e1c000-0000000079e87000 (reserved) > 0000000079e87000-000000007bd5f000 (ACPI Tables) > 0000000000100000-0000000078c59000 (System RAM) > 000000007bd5f000-000000007be4f000 (reserved) > 000000007be4f000-000000007bf87000 (ACPI Tables) so following ranges are not passed to second kernel by kexec? > 000000007bf87000-000000007bfcf000 (ACPI Non-volatile Storage) > 000000007bfcf000-000000007bfff000 (ACPI Tables) > 000000007bfff000-0000000090000000 (reserved) > 00000000fc000000-00000000fd000000 (reserved) > 00000000fed1c000-00000000fed20000 (reserved) > 00000000ff000000-0000000100000000 (reserved) > 0000000100000000-0000001080000000 (System RAM) > 0000000078c59000-0000000078e6d000 (ACPI Non-volatile Storage) > 0000000078e6d000-000000007924e000 (ACPI Tables) > 000000007924e000-00000000792c2000 (reserved) > 00000000792c2000-00000000792d2000 (ACPI Tables) > 00000000792d2000-00000000792e7000 (reserved) > 00000000792e7000-0000000079301000 (ACPI Tables) > second kernel only get [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000100 - 0000000000098800 (usable) [ 0.000000] BIOS-e820: 0000000000098800 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 0000000078c63000 (usable) [ 0.000000] BIOS-e820: 0000000078c63000 - 0000000078e77000 (ACPI NVS) [ 0.000000] BIOS-e820: 0000000078e77000 - 000000007924e000 (ACPI data) [ 0.000000] BIOS-e820: 000000007924e000 - 00000000792c2000 (reserved) [ 0.000000] BIOS-e820: 00000000792c2000 - 00000000792d2000 (ACPI data) [ 0.000000] BIOS-e820: 00000000792d2000 - 00000000792e7000 (reserved) [ 0.000000] BIOS-e820: 00000000792e7000 - 0000000079301000 (ACPI data) [ 0.000000] BIOS-e820: 0000000079301000 - 0000000079303000 (reserved) [ 0.000000] BIOS-e820: 0000000079303000 - 0000000079305000 (ACPI data) [ 0.000000] BIOS-e820: 0000000079305000 - 0000000079310000 (reserved) [ 0.000000] BIOS-e820: 0000000079310000 - 0000000079314000 (ACPI data) [ 0.000000] BIOS-e820: 0000000079314000 - 0000000079319000 (reserved) [ 0.000000] BIOS-e820: 0000000079319000 - 0000000079336000 (ACPI data) [ 0.000000] BIOS-e820: 0000000079336000 - 0000000079358000 (reserved) [ 0.000000] BIOS-e820: 0000000079358000 - 0000000079388000 (ACPI data) [ 0.000000] BIOS-e820: 0000000079388000 - 00000000793c9000 (reserved) [ 0.000000] BIOS-e820: 00000000793c9000 - 000000007968f000 (ACPI data) [ 0.000000] BIOS-e820: 000000007968f000 - 00000000796bb000 (reserved) [ 0.000000] BIOS-e820: 00000000796bb000 - 00000000799d8000 (ACPI data) [ 0.000000] BIOS-e820: 00000000799d8000 - 0000000079bd8000 (ACPI NVS) [ 0.000000] BIOS-e820: 0000000079bd8000 - 0000000079d87000 (ACPI data) [ 0.000000] BIOS-e820: 0000000079d87000 - 0000000079d8a000 (reserved) [ 0.000000] BIOS-e820: 0000000079d8a000 - 0000000079dca000 (ACPI data) [ 0.000000] BIOS-e820: 0000000079dca000 - 0000000079dcb000 (reserved) [ 0.000000] BIOS-e820: 0000000079dcb000 - 0000000079e1c000 (ACPI data) [ 0.000000] BIOS-e820: 0000000079e1c000 - 0000000079e87000 (reserved) [ 0.000000] BIOS-e820: 0000000079e87000 - 000000007bd5f000 (ACPI data) [ 0.000000] BIOS-e820: 000000007bd5f000 - 000000007be4f000 (reserved) [ 0.000000] BIOS-e820: 000000007be4f000 - 000000007bf87000 (ACPI data) so mmconf range is not reserved, and some ACPI data > 0000000078c59000-0000000078e6d000 (ACPI Non-volatile Storage) 0000000078c59000 - 0000000078c63000 get currupted... YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jens Axboe on 15 Dec 2009 14:50 On Tue, Dec 15 2009, Yinghai Lu wrote: > Jens Axboe wrote: > > On Tue, Dec 15 2009, Yinghai Lu wrote: > >> Jens Axboe wrote: > >>> On Tue, Dec 15 2009, Yinghai Lu wrote: > >>>> [ 13.018720] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000) > >>>> > >>>> [ 13.100724] [Firmware Bug]: PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] not reserved in ACPI motherboard resources > >>> On a "normal" non-kexec boot, I get: > >>> > >>> [ 12.173583] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000) > >>> [ 12.184075] PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] reserved in E820 > >>> [ 12.216874] PCI: Using configuration type 1 for base access > >>> > >> can you run following scripts in first kernel? > >> > >> cd /sys/firmware/memmap > >> for dir in * ; do > >> start=$(cat $dir/start) > >> end=$(cat $dir/end) > >> type=$(cat $dir/type) > >> printf "%016x-%016x (%s)\n" $start $[ $end +1] "$type" >> /tmp/memmap.txt > >> done > >> > >> and send out /tmp/memmap.txt > > > > Below. > > > >> what is your kexec tools version? could be too old? > > > > It says: > > > > kexec-tools-testing 20080324 released 24th March 2008 > > > > > > 0000000000000000-0000000000098800 (System RAM) > > 0000000000098800-00000000000a0000 (reserved) > > 0000000079301000-0000000079303000 (reserved) > > 0000000079303000-0000000079305000 (ACPI Tables) > > 0000000079305000-0000000079310000 (reserved) > > 0000000079310000-0000000079314000 (ACPI Tables) > > 0000000079314000-0000000079319000 (reserved) > > 0000000079319000-0000000079336000 (ACPI Tables) > > 0000000079336000-0000000079358000 (reserved) > > 0000000079358000-0000000079388000 (ACPI Tables) > > 0000000079388000-00000000793c9000 (reserved) > > 00000000793c9000-000000007968f000 (ACPI Tables) > > 00000000000e0000-0000000000100000 (reserved) > > 000000007968f000-00000000796bb000 (reserved) > > 00000000796bb000-00000000799d8000 (ACPI Tables) > > 00000000799d8000-0000000079bd8000 (ACPI Non-volatile Storage) > > 0000000079bd8000-0000000079d8b000 (ACPI Tables) > > 0000000079d8b000-0000000079d8c000 (reserved) > > 0000000079d8c000-0000000079dc8000 (ACPI Tables) > > 0000000079dc8000-0000000079dcb000 (reserved) > > 0000000079dcb000-0000000079e1c000 (ACPI Tables) > > 0000000079e1c000-0000000079e87000 (reserved) > > 0000000079e87000-000000007bd5f000 (ACPI Tables) > > 0000000000100000-0000000078c59000 (System RAM) > > 000000007bd5f000-000000007be4f000 (reserved) > > 000000007be4f000-000000007bf87000 (ACPI Tables) > > so following ranges are not passed to second kernel by kexec? I have the following addition to my kexec kernel command line: memmap=62G(a)4G since that last big 62G RAM entry doesn't show up without it, that's why you see a user defined e820 map as well in the boot logs. So a kexec'ed kernel is missing at least that entry. I just tried with the latest and greatest kexec-tools (2.0.1) and there's no difference. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai Lu on 15 Dec 2009 15:00
Jens Axboe wrote: > On Tue, Dec 15 2009, Yinghai Lu wrote: >> Jens Axboe wrote: >>> On Tue, Dec 15 2009, Yinghai Lu wrote: >>>> [PATCH] x86/pci: intel ioh bus num reg accessing fix >>>> >>>> it is above 0x100, so if mmconf is not enable, need to skip it >>> This works, it kexecs kernels fine. But since 2.6.32 doesn't have the >>> mmconf problem to begin with, are we now just working around the issue? >>> SRAT still reports issues, numa doesn't work. >> that patch will be bullet proof... we need it. >> >> also still need to figure out why memmap range is not passed properly. >> >> do you mean 2.6.32 kexec 2.6.32 it have worked mmconf and numa in >> second kernel? > > Yes, 2.6.32 booted and 2.6.32 kexec'ed works just fine, no SRAT > complaints and NUMA works fine. > how about current kernel booted and 2.6.32 kexec'ed works just fine, no SRAT complaints and NUMA works fine. ? YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |