[PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec

[PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec

[Prarit Bhargava]

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

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);
-- 
1.7.9.3

Re: [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec

[Rafael J. Wysocki]

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

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec

[Vivek Goyal]

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

Re: [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec

[Vivek Goyal]

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

Re: [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec

[Vivek Goyal]

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

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec

[KOSAKI Motohiro]

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.

Re: [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec

[KOSAKI Motohiro]

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.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec

[Vivek Goyal]

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

Re: [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec

[Vivek Goyal]

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


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec

[Prarit Bhargava]

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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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.

Re: [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec

[Prarit Bhargava]

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.

Re: [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec

[Prarit Bhargava]

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.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec

[Rafael J. Wysocki]

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!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec

[Rafael J. Wysocki]

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!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec

[Rafael J. Wysocki]

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

Re: [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec

[Rafael J. Wysocki]

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


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec

[Yasuaki Ishimatsu]

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

Re: [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec

[Yasuaki Ishimatsu]

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

Re: [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec

[Yasuaki Ishimatsu]

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



_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec

[Prarit Bhargava]

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

Re: [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec

[Prarit Bhargava]

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

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec

[Vivek Goyal]

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

Re: [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec

[Vivek Goyal]

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

Re: [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec

[Vivek Goyal]

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

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec