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
On Thu, Jan 9, 2014 at 10:00 AM, Vivek Goyal <[email protected]> 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.
On Thu, Jan 09, 2014 at 04:34:16PM -0500, KOSAKI Motohiro wrote:
> On Thu, Jan 9, 2014 at 10:00 AM, Vivek Goyal <[email protected]> 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
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 <[email protected]> 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.
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.
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 <[email protected]> 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
(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 <[email protected]> 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 [email protected]
> 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 <[email protected]> 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 [email protected]
>> 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