All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>,
	Kexec Mailing List <kexec@lists.infradead.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	linux kernel mailing list <linux-kernel@vger.kernel.org>,
	linux-acpi@vger.kernel.org, Dave Young <dyoung@redhat.com>,
	Len Brown <lenb@kernel.org>
Subject: Re: [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec
Date: Thu, 9 Jan 2014 16:44:25 -0500	[thread overview]
Message-ID: <20140109214425.GD12111@redhat.com> (raw)
In-Reply-To: <CAHGf_=oaPZNE8tVsZ1C1z3mHee8MK6CkuZ0YBTcJpRrTWgVn6g@mail.gmail.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com>
To: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Prarit Bhargava <prarit@redhat.com>,
	linux-acpi@vger.kernel.org, Len Brown <lenb@kernel.org>,
	linux kernel mailing list <linux-kernel@vger.kernel.org>,
	Dave Young <dyoung@redhat.com>,
	Kexec Mailing List <kexec@lists.infradead.org>
Subject: Re: [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec
Date: Thu, 9 Jan 2014 16:44:25 -0500	[thread overview]
Message-ID: <20140109214425.GD12111@redhat.com> (raw)
In-Reply-To: <CAHGf_=oaPZNE8tVsZ1C1z3mHee8MK6CkuZ0YBTcJpRrTWgVn6g@mail.gmail.com>

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


  reply	other threads:[~2014-01-09 21:44 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-08 22:29 [PATCH] acpi memory hotplug, add parameter to disable memory hotplug for kexec Prarit Bhargava
2014-01-08 23:00 ` Rafael J. Wysocki
2014-01-09 15:00   ` Vivek Goyal
2014-01-09 15:00     ` Vivek Goyal
2014-01-09 15:00     ` Vivek Goyal
2014-01-09 21:34     ` KOSAKI Motohiro
2014-01-09 21:34       ` KOSAKI Motohiro
2014-01-09 21:44       ` Vivek Goyal [this message]
2014-01-09 21:44         ` Vivek Goyal
2014-01-10  1:04         ` Prarit Bhargava
2014-01-10  1:04           ` Prarit Bhargava
2014-01-10  1:04           ` Prarit Bhargava
2014-01-10  1:35         ` Rafael J. Wysocki
2014-01-10  1:35           ` Rafael J. Wysocki
2014-01-10  3:57         ` Yasuaki Ishimatsu
2014-01-10  3:57           ` Yasuaki Ishimatsu
2014-01-10  3:57           ` Yasuaki Ishimatsu
2014-01-10 11:01           ` Prarit Bhargava
2014-01-10 11:01             ` Prarit Bhargava
2014-01-10  1:31     ` Rafael J. Wysocki
2014-01-10  1:31       ` Rafael J. Wysocki
2014-01-10 14:38       ` Vivek Goyal
2014-01-10 14:38         ` Vivek Goyal
2014-01-10 14:38         ` Vivek Goyal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140109214425.GD12111@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=dyoung@redhat.com \
    --cc=kexec@lists.infradead.org \
    --cc=kosaki.motohiro@gmail.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=prarit@redhat.com \
    --cc=rjw@rjwysocki.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.