[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100331214701.GA27833@elte.hu>
Date: Wed, 31 Mar 2010 23:47:01 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Dave Airlie <airlied@...il.com>
Cc: James Morris <jmorris@...ei.org>, "H. Peter Anvin" <hpa@...or.com>,
Yinghai Lu <yinghai@...nel.org>, linux-kernel@...r.kernel.org,
airlied@...ux.ie, Thomas Gleixner <tglx@...utronix.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Pekka Enberg <penberg@...helsinki.fi>
Subject: Re: Config NO_BOOTMEM breaks my amd64 box
* Dave Airlie <airlied@...il.com> wrote:
> On Thu, Apr 1, 2010 at 4:59 AM, Ingo Molnar <mingo@...e.hu> wrote:
> >
> > * James Morris <jmorris@...ei.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists