Config NO_BOOTMEM breaks my amd64 box
in [Kernel]
|
From: Ingo Molnar on 31 Mar 2010 15:00 * James Morris <jmorris(a)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? We can flip the default around if there's no fix available based on the bootlogs. (Plus the help text should definitely be improved.) Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dave Airlie on 31 Mar 2010 17:20 On Thu, Apr 1, 2010 at 4:59 AM, Ingo Molnar <mingo(a)elte.hu> wrote: > > * James Morris <jmorris(a)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? > > We can flip the default around if there's no fix available based on the > bootlogs. (Plus the help text should definitely be improved.) > Are you testing this btw with initramfs/initrds? I suspect lots of testing is being done by people on monolithic kernels, this is just a misc guess, considering I couldn't boot from when this landed until rc3 with this option on a basic 32-bit install on a dual-core 64-bit CPU, it suggested a hole of some sort in the test coverage. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai Lu on 31 Mar 2010 18:10 On 03/31/2010 02:14 PM, Dave Airlie wrote: > On Thu, Apr 1, 2010 at 4:59 AM, Ingo Molnar <mingo(a)elte.hu> wrote: >> >> * James Morris <jmorris(a)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? >> >> We can flip the default around if there's no fix available based on the >> bootlogs. (Plus the help text should definitely be improved.) >> > > Are you testing this btw with initramfs/initrds? I suspect lots of testing > is being done by people on monolithic kernels, this is just a misc guess, > considering I couldn't boot from when this landed until rc3 with this option > on a basic 32-bit install on a dual-core 64-bit CPU, it suggested a > hole of some sort > in the test coverage. so -rc3 is working your setup? Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai Lu on 31 Mar 2010 18:20 On 03/31/2010 03:13 PM, Ingo Molnar wrote: > > * Yinghai Lu <yinghai(a)kernel.org> wrote: > >> --- linux-2.6.orig/arch/x86/mm/init_32.c >> +++ linux-2.6/arch/x86/mm/init_32.c >> @@ -875,7 +875,12 @@ void __init mem_init(void) >> BUG_ON(!mem_map); >> #endif >> /* this will put all low memory onto the freelists */ >> +#if defined(CONFIG_NO_BOOTMEM) && defined(MAX_NUMNODES) >> + /* In case some 32bit systems don't have RAM installed on node0 */ >> + totalram_pages += free_all_memory_core_early(MAX_NUMNODES); > > (Note: tab whitespace damage) > >> +#else >> totalram_pages += free_all_bootmem(); > > So we get into this branch if CONFIG_NO_BOOTMEM is enabled but MAX_NUMNODES is > not defined? Doesnt look right. yes. free_all_bootmem() will call free_all_memory_core_early(NODE_DATA(0)->node_id); Thanks Yinghai Lu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 31 Mar 2010 18:20
* Yinghai Lu <yinghai(a)kernel.org> wrote: > --- linux-2.6.orig/arch/x86/mm/init_32.c > +++ linux-2.6/arch/x86/mm/init_32.c > @@ -875,7 +875,12 @@ void __init mem_init(void) > BUG_ON(!mem_map); > #endif > /* this will put all low memory onto the freelists */ > +#if defined(CONFIG_NO_BOOTMEM) && defined(MAX_NUMNODES) > + /* In case some 32bit systems don't have RAM installed on node0 */ > + totalram_pages += free_all_memory_core_early(MAX_NUMNODES); (Note: tab whitespace damage) > +#else > totalram_pages += free_all_bootmem(); So we get into this branch if CONFIG_NO_BOOTMEM is enabled but MAX_NUMNODES is not defined? Doesnt look right. > +#endif Btw., and i said this before, i absolutely hate the CONFIG_NO_BOOTMEM naming as well (a negative in the option), but it is was what expresses the 'this is where we want to go' state better and thus CONFIG_NO_BOOTMEM removal will be a straight removal instead of a removal of the inverse. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |