All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Jan Beulich <JBeulich@novell.com>
Cc: David Rientjes <rientjes@google.com>, Tejun Heo <tj@kernel.org>,
	tglx@linutronix.de, linux-kernel@vger.kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH] x86: unify "numa=" command line option handling
Date: Fri, 7 Jan 2011 15:22:03 +0100	[thread overview]
Message-ID: <20110107142203.GA12773@elte.hu> (raw)
In-Reply-To: <4D272413020000780002B009@vpn.id2.novell.com>


* Jan Beulich <JBeulich@novell.com> wrote:

> >>> On 07.01.11 at 13:57, Ingo Molnar <mingo@elte.hu> wrote:
> 
> > * Jan Beulich <JBeulich@novell.com> wrote:
> > 
> >> >>> On 07.01.11 at 10:58, David Rientjes <rientjes@google.com> wrote:
> >> > On Fri, 7 Jan 2011, Jan Beulich wrote:
> >> > 
> >> >> However, the problem my patch addresses has been long standing
> >> >> (I noted it with our .32 based kernel, but according to my looking at
> >> >> the code it would go back to at least .27), so I'd like to ask for it to
> >> >> be merged independently (and I should probably have copied stable
> >> >> too), unless (quite unlikely) Tejun's merge is intended to also be
> >> >> applied to stable kernels.
> >> >> 
> >> > 
> >> > I don't think this should be targeted to -stable since it's not a bugfix; 
> >> > this is adding a feature that allows you to disable acpi parsing of the 
> >> > SRAT on i386.
> >> 
> >> How is this not a bug fix if it allows a system to boot that previously
> >> didn't?
> > 
> > btw., that's an absolutely key piece of information that REALLY should have 
> > been 
> > included in the changelog of the first patch. It is more important than all 
> > of the 
> > changelog.
> 
> Quoting that text: "In order to be able to suppress the use of SRAT
> tables that 32-bit Linux can't deal with (possibly leading to a non-
> bootable system, without disabling ACPI altogether), move the
> "numa=" option handling to common code."
> 
> To me it says just that. And of course, not every system with a
> not understood SRAT would be yielded non-bootable, hence the
> wording "possibly leading to ...".


Your -stable comment above made it appear to me as if you knew about a specific 
system that crashed this way? As long as it's only theoretical i'm not sure it 
warrants a -stable backport.

Thanks,

	Ingo

  reply	other threads:[~2011-01-07 14:22 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-06 17:02 [PATCH] x86: unify "numa=" command line option handling Jan Beulich
2011-01-06 20:36 ` David Rientjes
2011-01-07  7:51   ` Jan Beulich
2011-01-07  9:58     ` David Rientjes
2011-01-07 10:06       ` Jan Beulich
2011-01-07 12:57         ` Ingo Molnar
2011-01-07 13:32           ` Jan Beulich
2011-01-07 14:22             ` Ingo Molnar [this message]
2011-01-07 14:26               ` Jan Beulich
2011-01-07 15:12                 ` Ingo Molnar
2011-01-07 19:55                   ` David Rientjes
2011-01-10  8:14                     ` Jan Beulich
2011-01-07 20:37     ` Tejun Heo
2011-01-07 20:33   ` Tejun Heo
2011-01-07 20:36     ` David Rientjes
2011-01-07 20:43       ` Tejun Heo
2011-01-07 20:46         ` David Rientjes

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=20110107142203.GA12773@elte.hu \
    --to=mingo@elte.hu \
    --cc=JBeulich@novell.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rientjes@google.com \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    /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.