| Message ID | 1389220181-14474-1-git-send-email-prarit@redhat.com (mailing list archive) |
|---|---|
| State | Rejected, archived |
| Headers | show |
On Wednesday, January 08, 2014 05:29:41 PM Prarit Bhargava wrote: > When booting a kexec/kdump kernel on a system that has specific memory hotplug > regions the boot will fail with warnings like: > > [ 2.939467] swapper/0: page allocation failure: order:9, mode:0x84d0 > [ 2.946564] CPU: 0 PID: 1 Comm: swapper/0 Not tainted > 3.10.0-65.el7.x86_64 #1 > [ 2.954532] Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS > QSSC-S4R.QCI.01.00.S013.032920111005 03/29/2011 > [ 2.964926] 0000000000000000 ffff8800341bd8c8 ffffffff815bcc67 > ffff8800341bd950 > [ 2.973224] ffffffff8113b1a0 ffff880036339b00 0000000000000009 > 00000000000084d0 > [ 2.981523] ffff8800341bd950 ffffffff815b87ee 0000000000000000 > 0000000000000200 > [ 2.989821] Call Trace: > [ 2.992560] [<ffffffff815bcc67>] dump_stack+0x19/0x1b > [ 2.998300] [<ffffffff8113b1a0>] warn_alloc_failed+0xf0/0x160 > [ 3.004817] [<ffffffff815b87ee>] ? > __alloc_pages_direct_compact+0xac/0x196 > [ 3.012594] [<ffffffff8113f14f>] __alloc_pages_nodemask+0x7ff/0xa00 > [ 3.019692] [<ffffffff815b417c>] vmemmap_alloc_block+0x62/0xba > [ 3.026303] [<ffffffff815b41e9>] vmemmap_alloc_block_buf+0x15/0x3b > [ 3.033302] [<ffffffff815b1ff6>] vmemmap_populate+0xb4/0x21b > [ 3.039718] [<ffffffff815b461d>] sparse_mem_map_populate+0x27/0x35 > [ 3.046717] [<ffffffff815b400f>] sparse_add_one_section+0x7a/0x185 > [ 3.053720] [<ffffffff815a1e9f>] __add_pages+0xaf/0x240 > [ 3.059656] [<ffffffff81047359>] arch_add_memory+0x59/0xd0 > [ 3.065877] [<ffffffff815a21d9>] add_memory+0xb9/0x1b0 > [ 3.071713] [<ffffffff81333b9c>] acpi_memory_device_add+0x18d/0x26d > [ 3.078813] [<ffffffff81309a01>] acpi_bus_device_attach+0x7d/0xcd > [ 3.085719] [<ffffffff8132379d>] acpi_ns_walk_namespace+0xc8/0x17f > [ 3.092716] [<ffffffff81309984>] ? acpi_bus_type_and_status+0x90/0x90 > [ 3.100004] [<ffffffff81309984>] ? acpi_bus_type_and_status+0x90/0x90 > [ 3.107293] [<ffffffff81323c8c>] acpi_walk_namespace+0x95/0xc5 > [ 3.113904] [<ffffffff8130a6d6>] acpi_bus_scan+0x8b/0x9d > [ 3.119933] [<ffffffff81a2019a>] acpi_scan_init+0x63/0x160 > [ 3.126153] [<ffffffff81a1ffb5>] acpi_init+0x25d/0x2a6 > [ 3.131987] [<ffffffff81a1fd58>] ? acpi_sleep_proc_init+0x2a/0x2a > [ 3.138889] [<ffffffff810020e2>] do_one_initcall+0xe2/0x190 > [ 3.145210] [<ffffffff819e20c4>] kernel_init_freeable+0x17c/0x207 > [ 3.152111] [<ffffffff819e18d0>] ? do_early_param+0x88/0x88 > [ 3.158430] [<ffffffff8159fea0>] ? rest_init+0x80/0x80 > [ 3.164264] [<ffffffff8159feae>] kernel_init+0xe/0x180 > [ 3.170097] [<ffffffff815cca2c>] ret_from_fork+0x7c/0xb0 > [ 3.176123] [<ffffffff8159fea0>] ? rest_init+0x80/0x80 > [ 3.181956] Mem-Info: > [ 3.184490] Node 0 DMA per-cpu: > [ 3.188007] CPU 0: hi: 0, btch: 1 usd: 0 > [ 3.193353] Node 0 DMA32 per-cpu: > [ 3.197060] CPU 0: hi: 42, btch: 7 usd: 0 > [ 3.202410] active_anon:0 inactive_anon:0 isolated_anon:0 > [ 3.202410] active_file:0 inactive_file:0 isolated_file:0 > [ 3.202410] unevictable:0 dirty:0 writeback:0 unstable:0 > [ 3.202410] free:872 slab_reclaimable:13 slab_unreclaimable:1880 > [ 3.202410] mapped:0 shmem:0 pagetables:0 bounce:0 > [ 3.202410] free_cma:0 > > because the system has run out of memory at boot time. This occurs > because of the following sequence in the boot: > > Main kernel boots and sets E820 map. The second kernel is booted with a > map generated by the kdump service using memmap= and memmap=exactmap. > These parameters are added to the kernel parameters of the kexec/kdump > kernel. The kexec/kdump kernel has limited memory resources so as not > to severely impact the main kernel. > > The system then panics and the kdump/kexec kernel boots. During this boot > ACPi is initialized and the kernel (as can be seen above) Which is a bug. You're not supposed to initialize ACPI twice in a row. > traverses the ACPI namespace and finds an entry for a memory device to be hotadded. > > ie) > > [ 3.053720] [<ffffffff815a1e9f>] __add_pages+0xaf/0x240 > [ 3.059656] [<ffffffff81047359>] arch_add_memory+0x59/0xd0 > [ 3.065877] [<ffffffff815a21d9>] add_memory+0xb9/0x1b0 > [ 3.071713] [<ffffffff81333b9c>] acpi_memory_device_add+0x18d/0x26d > [ 3.078813] [<ffffffff81309a01>] acpi_bus_device_attach+0x7d/0xcd > [ 3.085719] [<ffffffff8132379d>] acpi_ns_walk_namespace+0xc8/0x17f > [ 3.092716] [<ffffffff81309984>] ? acpi_bus_type_and_status+0x90/0x90 > [ 3.100004] [<ffffffff81309984>] ? acpi_bus_type_and_status+0x90/0x90 > [ 3.107293] [<ffffffff81323c8c>] acpi_walk_namespace+0x95/0xc5 > [ 3.113904] [<ffffffff8130a6d6>] acpi_bus_scan+0x8b/0x9d > [ 3.119933] [<ffffffff81a2019a>] acpi_scan_init+0x63/0x160 > [ 3.126153] [<ffffffff81a1ffb5>] acpi_init+0x25d/0x2a6 > > At this point the kernel adds page table information and the the kexec/kdump > kernel runs out of memory. > > This patchset resolves the problem by adding a kernel parameter, > no_memory_hotplug, to disable ACPI memory hotplug. It can be added by default > as a parameter to the kexec/kdump kernel so the kernel boots correctly. This problem is specific to kexec/kdump, so please don't add *generic* command line parameters to address this. Thanks! > Signed-off-by: Prarit Bhargava <prarit@redhat.com> > Cc: Vivek Goyal <vgoyal@redhat.com> > Cc: Len Brown <lenb@kernel.org> > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> > --- > Documentation/kernel-parameters.txt | 3 +++ > drivers/acpi/acpi_memhotplug.c | 12 ++++++++++++ > 2 files changed, 15 insertions(+) > > diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt > index b9e9bd8..df256cc 100644 > --- a/Documentation/kernel-parameters.txt > +++ b/Documentation/kernel-parameters.txt > @@ -2117,6 +2117,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted. > > nomce [X86-32] Machine Check Exception > > + no_memory_hotplug [ACPI] Disable memory hotplug. Useful for kexec > + and kdump kernels. > + > nomfgpt [X86-32] Disable Multi-Function General Purpose > Timer usage (for AMD Geode machines). > > diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c > index 551dad7..cbd328f 100644 > --- a/drivers/acpi/acpi_memhotplug.c > +++ b/drivers/acpi/acpi_memhotplug.c > @@ -361,7 +361,19 @@ static void acpi_memory_device_remove(struct acpi_device *device) > acpi_memory_device_free(mem_device); > } > > +static int no_memory_hotplug; > + > void __init acpi_memory_hotplug_init(void) > { > + if (no_memory_hotplug) > + return; > + > acpi_scan_add_handler_with_hotplug(&memory_device_handler, "memory"); > } > + > +static int __init disable_memory_hotplug(char *str) > +{ > + no_memory_hotplug = 1; > + return 1; > +} > +__setup("no_memory_hotplug", disable_memory_hotplug); >
On Thu, Jan 09, 2014 at 12:00:29AM +0100, Rafael J. Wysocki wrote: [..] > > The system then panics and the kdump/kexec kernel boots. During this boot > > ACPi is initialized and the kernel (as can be seen above) > > Which is a bug. You're not supposed to initialize ACPI twice in a row. [CC lkml, kexec mailing list, dave young] It is a fresh instance of kernel booting and it is initializing its data structures fresh. It is *not* re-initializing ACPI in same kernel. > > This patchset resolves the problem by adding a kernel parameter, > > no_memory_hotplug, to disable ACPI memory hotplug. It can be added by default > > as a parameter to the kexec/kdump kernel so the kernel boots correctly. > > This problem is specific to kexec/kdump, so please don't add *generic* command > line parameters to address this. > There are other command line options to solve kdump problems. In general one might want to disable memory hogplug on the fly even if it is compiled in the kernel. So it can act as a good debugging aid. Secondly, it can be specified with memmap=exactmap and mem=X paramters to make sure no memory is hot added in the system. So I can see other usages of this parameter. To me it makes sense to have a separate command line option to disable memory hotplug feature on the fly. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jan 9, 2014 at 10:00 AM, Vivek Goyal <vgoyal@redhat.com> wrote: > On Thu, Jan 09, 2014 at 12:00:29AM +0100, Rafael J. Wysocki wrote: > > [..] >> > The system then panics and the kdump/kexec kernel boots. During this boot >> > ACPi is initialized and the kernel (as can be seen above) >> >> Which is a bug. You're not supposed to initialize ACPI twice in a row. > > [CC lkml, kexec mailing list, dave young] > > It is a fresh instance of kernel booting and it is initializing its data > structures fresh. It is *not* re-initializing ACPI in same kernel. > >> > This patchset resolves the problem by adding a kernel parameter, >> > no_memory_hotplug, to disable ACPI memory hotplug. It can be added by default >> > as a parameter to the kexec/kdump kernel so the kernel boots correctly. >> >> This problem is specific to kexec/kdump, so please don't add *generic* command >> line parameters to address this. >> > > There are other command line options to solve kdump problems. In general > one might want to disable memory hogplug on the fly even if it is compiled > in the kernel. So it can act as a good debugging aid. > > Secondly, it can be specified with memmap=exactmap and mem=X paramters to > make sure no memory is hot added in the system. > > So I can see other usages of this parameter. To me it makes sense to have > a separate command line option to disable memory hotplug feature on the > fly. I'm ok this option. But note, even if this option is specified, SH, Power and S390 still be able to use memory hotplug because their firmware are totally different from ACPI. Maybe, adding acpi prefix provides good clarification. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jan 09, 2014 at 04:34:16PM -0500, KOSAKI Motohiro wrote: > On Thu, Jan 9, 2014 at 10:00 AM, Vivek Goyal <vgoyal@redhat.com> wrote: > > On Thu, Jan 09, 2014 at 12:00:29AM +0100, Rafael J. Wysocki wrote: > > > > [..] > >> > The system then panics and the kdump/kexec kernel boots. During this boot > >> > ACPi is initialized and the kernel (as can be seen above) > >> > >> Which is a bug. You're not supposed to initialize ACPI twice in a row. > > > > [CC lkml, kexec mailing list, dave young] > > > > It is a fresh instance of kernel booting and it is initializing its data > > structures fresh. It is *not* re-initializing ACPI in same kernel. > > > >> > This patchset resolves the problem by adding a kernel parameter, > >> > no_memory_hotplug, to disable ACPI memory hotplug. It can be added by default > >> > as a parameter to the kexec/kdump kernel so the kernel boots correctly. > >> > >> This problem is specific to kexec/kdump, so please don't add *generic* command > >> line parameters to address this. > >> > > > > There are other command line options to solve kdump problems. In general > > one might want to disable memory hogplug on the fly even if it is compiled > > in the kernel. So it can act as a good debugging aid. > > > > Secondly, it can be specified with memmap=exactmap and mem=X paramters to > > make sure no memory is hot added in the system. > > > > So I can see other usages of this parameter. To me it makes sense to have > > a separate command line option to disable memory hotplug feature on the > > fly. > > I'm ok this option. But note, even if this option is specified, SH, > Power and S390 still > be able to use memory hotplug because their firmware are totally > different from ACPI. > > Maybe, adding acpi prefix provides good clarification. Makes sense. Something like "acpi_no_memhotplug" or "acpi_disable_memhotplug" or something else. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/09/2014 04:44 PM, Vivek Goyal wrote: > On Thu, Jan 09, 2014 at 04:34:16PM -0500, KOSAKI Motohiro wrote: >> On Thu, Jan 9, 2014 at 10:00 AM, Vivek Goyal <vgoyal@redhat.com> wrote: >>> On Thu, Jan 09, 2014 at 12:00:29AM +0100, Rafael J. Wysocki wrote: > > Makes sense. Something like "acpi_no_memhotplug" or "acpi_disable_memhotplug" > or something else. > FWIW ... after thinking about it and some of the other debug I've had to do, maybe acpi=no_memhotplug and acpi=no_cpuhotplug are in order here. I've had to disable both during hardware enablement debug and it seems that it "fits" the current acpi disabling scheme. Unless, of course, Rafael still objects. P. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday, January 09, 2014 10:00:53 AM Vivek Goyal wrote: > On Thu, Jan 09, 2014 at 12:00:29AM +0100, Rafael J. Wysocki wrote: > > [..] > > > The system then panics and the kdump/kexec kernel boots. During this boot > > > ACPi is initialized and the kernel (as can be seen above) > > > > Which is a bug. You're not supposed to initialize ACPI twice in a row. > > [CC lkml, kexec mailing list, dave young] > > It is a fresh instance of kernel booting and it is initializing its data > structures fresh. It is *not* re-initializing ACPI in same kernel. I know. The problem is that the BIOS is generally not stateless and it remebers stuff. In particular, there are a few handshakes done during the ACPI initialization and they cannot be repeated without resetting the BIOS to the initial state, which basically means a reboot. That is kind of orthogonal to the problem at hand, though. > > > This patchset resolves the problem by adding a kernel parameter, > > > no_memory_hotplug, to disable ACPI memory hotplug. It can be added by default > > > as a parameter to the kexec/kdump kernel so the kernel boots correctly. > > > > This problem is specific to kexec/kdump, so please don't add *generic* command > > line parameters to address this. > > > > There are other command line options to solve kdump problems. In general > one might want to disable memory hogplug on the fly even if it is compiled > in the kernel. So it can act as a good debugging aid. > > Secondly, it can be specified with memmap=exactmap and mem=X paramters to > make sure no memory is hot added in the system. > > So I can see other usages of this parameter. To me it makes sense to have > a separate command line option to disable memory hotplug feature on the > fly. Well, if there are other uses, then fine. Thanks!
On Thursday, January 09, 2014 04:44:25 PM Vivek Goyal wrote: > On Thu, Jan 09, 2014 at 04:34:16PM -0500, KOSAKI Motohiro wrote: > > On Thu, Jan 9, 2014 at 10:00 AM, Vivek Goyal <vgoyal@redhat.com> wrote: > > > On Thu, Jan 09, 2014 at 12:00:29AM +0100, Rafael J. Wysocki wrote: > > > > > > [..] > > >> > The system then panics and the kdump/kexec kernel boots. During this boot > > >> > ACPi is initialized and the kernel (as can be seen above) > > >> > > >> Which is a bug. You're not supposed to initialize ACPI twice in a row. > > > > > > [CC lkml, kexec mailing list, dave young] > > > > > > It is a fresh instance of kernel booting and it is initializing its data > > > structures fresh. It is *not* re-initializing ACPI in same kernel. > > > > > >> > This patchset resolves the problem by adding a kernel parameter, > > >> > no_memory_hotplug, to disable ACPI memory hotplug. It can be added by default > > >> > as a parameter to the kexec/kdump kernel so the kernel boots correctly. > > >> > > >> This problem is specific to kexec/kdump, so please don't add *generic* command > > >> line parameters to address this. > > >> > > > > > > There are other command line options to solve kdump problems. In general > > > one might want to disable memory hogplug on the fly even if it is compiled > > > in the kernel. So it can act as a good debugging aid. > > > > > > Secondly, it can be specified with memmap=exactmap and mem=X paramters to > > > make sure no memory is hot added in the system. > > > > > > So I can see other usages of this parameter. To me it makes sense to have > > > a separate command line option to disable memory hotplug feature on the > > > fly. > > > > I'm ok this option. But note, even if this option is specified, SH, > > Power and S390 still > > be able to use memory hotplug because their firmware are totally > > different from ACPI. > > > > Maybe, adding acpi prefix provides good clarification. > > Makes sense. Something like "acpi_no_memhotplug" or "acpi_disable_memhotplug" > or something else. acpi_no_memhotplug would make more sense. That said if you make memmap=exactmap disable the memhotplug driver, the existing kexec/kdump users won't need to be updated. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
(2014/01/10 6:44), Vivek Goyal wrote: > On Thu, Jan 09, 2014 at 04:34:16PM -0500, KOSAKI Motohiro wrote: >> On Thu, Jan 9, 2014 at 10:00 AM, Vivek Goyal <vgoyal@redhat.com> wrote: >>> On Thu, Jan 09, 2014 at 12:00:29AM +0100, Rafael J. Wysocki wrote: >>> >>> [..] >>>>> The system then panics and the kdump/kexec kernel boots. During this boot >>>>> ACPi is initialized and the kernel (as can be seen above) >>>> >>>> Which is a bug. You're not supposed to initialize ACPI twice in a row. >>> >>> [CC lkml, kexec mailing list, dave young] >>> >>> It is a fresh instance of kernel booting and it is initializing its data >>> structures fresh. It is *not* re-initializing ACPI in same kernel. >>> >>>>> This patchset resolves the problem by adding a kernel parameter, >>>>> no_memory_hotplug, to disable ACPI memory hotplug. It can be added by default >>>>> as a parameter to the kexec/kdump kernel so the kernel boots correctly. >>>> >>>> This problem is specific to kexec/kdump, so please don't add *generic* command >>>> line parameters to address this. >>>> >>> >>> There are other command line options to solve kdump problems. In general >>> one might want to disable memory hogplug on the fly even if it is compiled >>> in the kernel. So it can act as a good debugging aid. >>> >>> Secondly, it can be specified with memmap=exactmap and mem=X paramters to >>> make sure no memory is hot added in the system. >>> >>> So I can see other usages of this parameter. To me it makes sense to have >>> a separate command line option to disable memory hotplug feature on the >>> fly. >> >> I'm ok this option. But note, even if this option is specified, SH, >> Power and S390 still >> be able to use memory hotplug because their firmware are totally >> different from ACPI. >> >> Maybe, adding acpi prefix provides good clarification. > > Makes sense. Something like "acpi_no_memhotplug" or "acpi_disable_memhotplug" > or something else. I like Prarit's patch and the boot option name. If it is updated, I'll test it. Thanks, Yasuaki Ishimatsu > > Thanks > Vivek > > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/09/2014 10:57 PM, Yasuaki Ishimatsu wrote: > (2014/01/10 6:44), Vivek Goyal wrote: >> On Thu, Jan 09, 2014 at 04:34:16PM -0500, KOSAKI Motohiro wrote: >>> On Thu, Jan 9, 2014 at 10:00 AM, Vivek Goyal <vgoyal@redhat.com> wrote: >>>> On Thu, Jan 09, 2014 at 12:00:29AM +0100, Rafael J. Wysocki wrote: >>>> >>>> [..] >>>>>> The system then panics and the kdump/kexec kernel boots. During this boot >>>>>> ACPi is initialized and the kernel (as can be seen above) >>>>> >>>>> Which is a bug. You're not supposed to initialize ACPI twice in a row. >>>> >>>> [CC lkml, kexec mailing list, dave young] >>>> >>>> It is a fresh instance of kernel booting and it is initializing its data >>>> structures fresh. It is *not* re-initializing ACPI in same kernel. >>>> >>>>>> This patchset resolves the problem by adding a kernel parameter, >>>>>> no_memory_hotplug, to disable ACPI memory hotplug. It can be added by >>>>>> default >>>>>> as a parameter to the kexec/kdump kernel so the kernel boots correctly. >>>>> >>>>> This problem is specific to kexec/kdump, so please don't add *generic* command >>>>> line parameters to address this. >>>>> >>>> >>>> There are other command line options to solve kdump problems. In general >>>> one might want to disable memory hogplug on the fly even if it is compiled >>>> in the kernel. So it can act as a good debugging aid. >>>> >>>> Secondly, it can be specified with memmap=exactmap and mem=X paramters to >>>> make sure no memory is hot added in the system. >>>> >>>> So I can see other usages of this parameter. To me it makes sense to have >>>> a separate command line option to disable memory hotplug feature on the >>>> fly. >>> >>> I'm ok this option. But note, even if this option is specified, SH, >>> Power and S390 still >>> be able to use memory hotplug because their firmware are totally >>> different from ACPI. >>> >>> Maybe, adding acpi prefix provides good clarification. >> > >> Makes sense. Something like "acpi_no_memhotplug" or "acpi_disable_memhotplug" >> or something else. > > I like Prarit's patch and the boot option name. If it is updated, > I'll test it. I'm going with "acpi_no_memhotplug" and I'm testing across several systems right now. Will send out a new patch shortly. P. > > Thanks, > Yasuaki Ishimatsu > >> >> Thanks >> Vivek >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jan 10, 2014 at 02:31:31AM +0100, Rafael J. Wysocki wrote: [..] > > It is a fresh instance of kernel booting and it is initializing its data > > structures fresh. It is *not* re-initializing ACPI in same kernel. > > I know. The problem is that the BIOS is generally not stateless and it > remebers stuff. In particular, there are a few handshakes done during the ACPI > initialization and they cannot be repeated without resetting the BIOS to the > initial state, which basically means a reboot. Agreed that stateless BIOS in general would be a problem with kexec. We already face that issue with UEFI where we can't call set virtual address map again in second kernel and kexec did not work with UEFI for so many years. Thanks to Dave, Borislav and Matt that it will soon be working and we will be passing mappings to second kernel. So even in case of ACPI, if there are things which can't be re-initiliazed in second kernel, we will have to figure that out and selectively fix it by passing that info to second kernel and not ask second kernel to reinitialize it, instead of disabling ACPI completely. > > That is kind of orthogonal to the problem at hand, though. Agreed. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index b9e9bd8..df256cc 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2117,6 +2117,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted. nomce [X86-32] Machine Check Exception + no_memory_hotplug [ACPI] Disable memory hotplug. Useful for kexec + and kdump kernels. + nomfgpt [X86-32] Disable Multi-Function General Purpose Timer usage (for AMD Geode machines). diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c index 551dad7..cbd328f 100644 --- a/drivers/acpi/acpi_memhotplug.c +++ b/drivers/acpi/acpi_memhotplug.c @@ -361,7 +361,19 @@ static void acpi_memory_device_remove(struct acpi_device *device) acpi_memory_device_free(mem_device); } +static int no_memory_hotplug; + void __init acpi_memory_hotplug_init(void) { + if (no_memory_hotplug) + return; + acpi_scan_add_handler_with_hotplug(&memory_device_handler, "memory"); } + +static int __init disable_memory_hotplug(char *str) +{ + no_memory_hotplug = 1; + return 1; +} +__setup("no_memory_hotplug", disable_memory_hotplug);
When booting a kexec/kdump kernel on a system that has specific memory hotplug regions the boot will fail with warnings like: [ 2.939467] swapper/0: page allocation failure: order:9, mode:0x84d0 [ 2.946564] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-65.el7.x86_64 #1 [ 2.954532] Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS QSSC-S4R.QCI.01.00.S013.032920111005 03/29/2011 [ 2.964926] 0000000000000000 ffff8800341bd8c8 ffffffff815bcc67 ffff8800341bd950 [ 2.973224] ffffffff8113b1a0 ffff880036339b00 0000000000000009 00000000000084d0 [ 2.981523] ffff8800341bd950 ffffffff815b87ee 0000000000000000 0000000000000200 [ 2.989821] Call Trace: [ 2.992560] [<ffffffff815bcc67>] dump_stack+0x19/0x1b [ 2.998300] [<ffffffff8113b1a0>] warn_alloc_failed+0xf0/0x160 [ 3.004817] [<ffffffff815b87ee>] ? __alloc_pages_direct_compact+0xac/0x196 [ 3.012594] [<ffffffff8113f14f>] __alloc_pages_nodemask+0x7ff/0xa00 [ 3.019692] [<ffffffff815b417c>] vmemmap_alloc_block+0x62/0xba [ 3.026303] [<ffffffff815b41e9>] vmemmap_alloc_block_buf+0x15/0x3b [ 3.033302] [<ffffffff815b1ff6>] vmemmap_populate+0xb4/0x21b [ 3.039718] [<ffffffff815b461d>] sparse_mem_map_populate+0x27/0x35 [ 3.046717] [<ffffffff815b400f>] sparse_add_one_section+0x7a/0x185 [ 3.053720] [<ffffffff815a1e9f>] __add_pages+0xaf/0x240 [ 3.059656] [<ffffffff81047359>] arch_add_memory+0x59/0xd0 [ 3.065877] [<ffffffff815a21d9>] add_memory+0xb9/0x1b0 [ 3.071713] [<ffffffff81333b9c>] acpi_memory_device_add+0x18d/0x26d [ 3.078813] [<ffffffff81309a01>] acpi_bus_device_attach+0x7d/0xcd [ 3.085719] [<ffffffff8132379d>] acpi_ns_walk_namespace+0xc8/0x17f [ 3.092716] [<ffffffff81309984>] ? acpi_bus_type_and_status+0x90/0x90 [ 3.100004] [<ffffffff81309984>] ? acpi_bus_type_and_status+0x90/0x90 [ 3.107293] [<ffffffff81323c8c>] acpi_walk_namespace+0x95/0xc5 [ 3.113904] [<ffffffff8130a6d6>] acpi_bus_scan+0x8b/0x9d [ 3.119933] [<ffffffff81a2019a>] acpi_scan_init+0x63/0x160 [ 3.126153] [<ffffffff81a1ffb5>] acpi_init+0x25d/0x2a6 [ 3.131987] [<ffffffff81a1fd58>] ? acpi_sleep_proc_init+0x2a/0x2a [ 3.138889] [<ffffffff810020e2>] do_one_initcall+0xe2/0x190 [ 3.145210] [<ffffffff819e20c4>] kernel_init_freeable+0x17c/0x207 [ 3.152111] [<ffffffff819e18d0>] ? do_early_param+0x88/0x88 [ 3.158430] [<ffffffff8159fea0>] ? rest_init+0x80/0x80 [ 3.164264] [<ffffffff8159feae>] kernel_init+0xe/0x180 [ 3.170097] [<ffffffff815cca2c>] ret_from_fork+0x7c/0xb0 [ 3.176123] [<ffffffff8159fea0>] ? rest_init+0x80/0x80 [ 3.181956] Mem-Info: [ 3.184490] Node 0 DMA per-cpu: [ 3.188007] CPU 0: hi: 0, btch: 1 usd: 0 [ 3.193353] Node 0 DMA32 per-cpu: [ 3.197060] CPU 0: hi: 42, btch: 7 usd: 0 [ 3.202410] active_anon:0 inactive_anon:0 isolated_anon:0 [ 3.202410] active_file:0 inactive_file:0 isolated_file:0 [ 3.202410] unevictable:0 dirty:0 writeback:0 unstable:0 [ 3.202410] free:872 slab_reclaimable:13 slab_unreclaimable:1880 [ 3.202410] mapped:0 shmem:0 pagetables:0 bounce:0 [ 3.202410] free_cma:0 because the system has run out of memory at boot time. This occurs because of the following sequence in the boot: Main kernel boots and sets E820 map. The second kernel is booted with a map generated by the kdump service using memmap= and memmap=exactmap. These parameters are added to the kernel parameters of the kexec/kdump kernel. The kexec/kdump kernel has limited memory resources so as not to severely impact the main kernel. The system then panics and the kdump/kexec kernel boots. During this boot ACPi is initialized and the kernel (as can be seen above) traverses the ACPI namespace and finds an entry for a memory device to be hotadded. ie) [ 3.053720] [<ffffffff815a1e9f>] __add_pages+0xaf/0x240 [ 3.059656] [<ffffffff81047359>] arch_add_memory+0x59/0xd0 [ 3.065877] [<ffffffff815a21d9>] add_memory+0xb9/0x1b0 [ 3.071713] [<ffffffff81333b9c>] acpi_memory_device_add+0x18d/0x26d [ 3.078813] [<ffffffff81309a01>] acpi_bus_device_attach+0x7d/0xcd [ 3.085719] [<ffffffff8132379d>] acpi_ns_walk_namespace+0xc8/0x17f [ 3.092716] [<ffffffff81309984>] ? acpi_bus_type_and_status+0x90/0x90 [ 3.100004] [<ffffffff81309984>] ? acpi_bus_type_and_status+0x90/0x90 [ 3.107293] [<ffffffff81323c8c>] acpi_walk_namespace+0x95/0xc5 [ 3.113904] [<ffffffff8130a6d6>] acpi_bus_scan+0x8b/0x9d [ 3.119933] [<ffffffff81a2019a>] acpi_scan_init+0x63/0x160 [ 3.126153] [<ffffffff81a1ffb5>] acpi_init+0x25d/0x2a6 At this point the kernel adds page table information and the the kexec/kdump kernel runs out of memory. This patchset resolves the problem by adding a kernel parameter, no_memory_hotplug, to disable ACPI memory hotplug. It can be added by default as a parameter to the kexec/kdump kernel so the kernel boots correctly. Signed-off-by: Prarit Bhargava <prarit@redhat.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Len Brown <lenb@kernel.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> --- Documentation/kernel-parameters.txt | 3 +++ drivers/acpi/acpi_memhotplug.c | 12 ++++++++++++ 2 files changed, 15 insertions(+)