Config NO_BOOTMEM breaks my amd64 box
in [Kernel]
|
From: H. Peter Anvin on 31 Mar 2010 18:40 On 03/31/2010 02:14 PM, Dave Airlie wrote: > 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. Hi Dave, The only bug report I remember getting from you had no details and was in reply to another bug report which was, indeed, addressed, so we had every reason to believe it was being dealt with with the patchset which did indeed go into -rc3 (and does address a problem with initramfs in particular cases.) Clearly James Morris' problem is something unrelated, and regardless of course of action we need to track it down. If you also are having problems with -rc3 we would really appreciate as much detail as possible -- boot logs at the very minimum -- so we have a chance to at all track down the problems that do exist. -hpa -- 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:50 On 03/31/2010 03:41 PM, Ingo Molnar wrote: > > * Yinghai Lu <yinghai(a)kernel.org> wrote: > >> 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 > > Well and that whole #ifdeffery is disgusting as well - even if the goal was to > remove CONFIG_NO_BOOTMEM ASAP. > > Please learn to use proper intermediate helper functions and at minimum put > the conversion ugliness somewhere that doesnt intrude our daily flow in .c > files. The best rule is to _never ever_ put an #ifdef construct into a .c > file. It doesnt matter what the goal if the #ifdef is - such ugliness in code > is never justified. > if you agree that i can have one nobootmem.c in mm/ Thanks 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: Ingo Molnar on 31 Mar 2010 18:50 * Yinghai Lu <yinghai(a)kernel.org> wrote: > 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 Well and that whole #ifdeffery is disgusting as well - even if the goal was to remove CONFIG_NO_BOOTMEM ASAP. Please learn to use proper intermediate helper functions and at minimum put the conversion ugliness somewhere that doesnt intrude our daily flow in .c files. The best rule is to _never ever_ put an #ifdef construct into a .c file. It doesnt matter what the goal if the #ifdef is - such ugliness in code is never justified. 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: James Morris on 31 Mar 2010 19:00 On Wed, 31 Mar 2010, Ingo Molnar wrote: > > > > 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)? I don't have the old boot logs, and have since upgraded the system further. IIRC, the boot was failing after not being able to find the root fs (ext3/lvm/raid0). I thought it was a dracut issue, but it seemed to be fixed by enabling bootmem. > 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? In this case, in the last few days (also when I first saw or noticed the bootmem option). I was booting relatively recent linus kernels during the merge window, although my main work was being done on an older upstream kernel. -- James Morris <jmorris(a)namei.org> -- 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 19:10
* James Morris <jmorris(a)namei.org> wrote: > On Wed, 31 Mar 2010, Ingo Molnar wrote: > > > > > > > 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)? > > I don't have the old boot logs, and have since upgraded the system > further. Please, could you send any bootlog then that we could work from? That way we could check the memory layout and guess the rough shape of the early allocations, etc. > IIRC, the boot was failing after not being able to find the root fs > (ext3/lvm/raid0). I thought it was a dracut issue, but it seemed to be > fixed by enabling bootmem. Ok - initrd unpack failing or initial mount failing is consistent with the initrd getting corrupted by overlapping early reservations due to allocator bug. > > 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? > > In this case, in the last few days (also when I first saw or noticed the > bootmem option). I was booting relatively recent linus kernels during the > merge window, although my main work was being done on an older upstream > kernel. Ok, so it's not an old regression but possibly a bug in one of the fixes. Not good. 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/ |