User: Password:
|
|
Subscribe / Log in / New account

Re: Config NO_BOOTMEM breaks my amd64 box

From:  Ingo Molnar <mingo-AT-elte.hu>
To:  Dave Airlie <airlied-AT-gmail.com>
Subject:  Re: Config NO_BOOTMEM breaks my amd64 box
Date:  Wed, 31 Mar 2010 23:47:01 +0200
Cc:  James Morris <jmorris-AT-namei.org>, "H. Peter Anvin" <hpa-AT-zytor.com>, Yinghai Lu <yinghai-AT-kernel.org>, linux-kernel-AT-vger.kernel.org, airlied-AT-linux.ie, Thomas Gleixner <tglx-AT-linutronix.de>, Linus Torvalds <torvalds-AT-linux-foundation.org>, Pekka Enberg <penberg-AT-cs.helsinki.fi>
Archive-link:  Article, Thread


* Dave Airlie <airlied@gmail.com> wrote:

> On Thu, Apr 1, 2010 at 4:59 AM, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > * James Morris <jmorris@namei.org> wrote:
> >
> >> On Tue, 30 Mar 2010, H. Peter Anvin wrote:
> >>
> >> > On 03/30/2010 09:49 PM, James Morris wrote:
> >> > >
> >> > > Please make NO_BOOTMEM default to n, at least for amd64, where I've found
> >> > > that it leads to all kinds of strange, undebuggable boot hangs and errors
> >> > > (with relatively current Fedora development userland).
> >> >
> >> > Have you tested it with the latest fixes that are now in Linus' tree (-rc3)?
> >>
> >> Yes, it was happening with -rc3.
> >
> > Could you please send the bootlog that Yinghai asked for, plus also one that
> > you get with NO_BOOTMEM turned off (for comparison)?
> >
> > Also, when did you first hit this bug? This code has been upstream for almost
> > a month, and it was in linux-next before that - so you should have hit this
> > much sooner. A rough timeframe would suffice. I suppose you were booting
> > upstream kernels during the merge window as well?
> 
> A default y config option causing regressions still at rc3? and you guys 
> keep going? This is the sort of shit Linus would flame me for a day or two 
> for,
> 
> Can we get some f'ing consistency here?

Note, without trying to defend the bootmem conversion itself, which didnt work 
out well, this is not some optional new driver feature that was default-y 
randomly but it was an infrastructure change that was to be made unconditional 
in .35.

The flag was basically a testing/debug flag to allow the old code to be used 
too, in case the new code was buggy. This is what helped James to report this 
today, instead of forcing James through a very difficult ~14-reboot bisection.

Thanks,

	Ingo


(Log in to post comments)


Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds