Messages in this thread | | | Subject | Re: [bug] SLUB + mm/slab.c boot crash in -rc9 | Date | Tue, 15 Apr 2008 01:31:18 -0700 | From | Yinghai Lu <> |
| |
On Tuesday 15 April 2008 12:08:11 am Ingo Molnar wrote: > > * Pekka Enberg <penberg@cs.helsinki.fi> wrote: > > > On Tue, Apr 15, 2008 at 9:25 AM, Ingo Molnar <mingo@elte.hu> wrote: > > > so it's probably the first few page allocations (setup_cpu_cache()) > > > going wrong already - suggesting a some fundamental borkage in SLAB? > > > > I think it's still pointing to the page allocator and/or setting up > > the zonelists... > > i did a .config bisection and it pinpointed CONFIG_SPARSEMEM=y as the > culprit. Changing it to FLATMEM gives a correctly booting system. > .. > why are there no good debug logs possible in this area? To debug such > bugs we'd need an early dump of the precise layout of all memory maps, > what points where, how large it is, where it is allocated - and then > compare it with how the rest of the system is layed out - looking at > possible overlaps or other bugs. This 8-way box is a pain to debug on, > it takes a long time to boot it up, etc. etc.
so same config 64 bit with SLUB works and only 32bit is broken? or it 2.6.24 with 32bit + sparse + slub is broken already?
YH
| |