> Actually, no, reverting that one doesn't fix it. > > A full run of git bisect turns up this commit as the culprit; I'll make > a fuss on lkml:
I haven't had the full log of that boot failure, but reverting the patch Brian suggested won't work well indeed, as I said, from the moment slab is initialized, page table allocations will use kmem caches which are initialized by pgtable_cache_init(). So the problem does indeed seem to be another fallover of moving the allocator initialization earlier. I'm working from home today but I'll see if I can get somebody in the office to wire up the powerstation (got disconnected for some reason last week) for me so I can have a look. The mutex issue Brian noticed will definitely break _any_ kmem_cache operation anyway, so that's one bug that need fixing at least (well, provided Brian analysis is right, I didn't have a chance to look myself yet :-) Cheers, Ben. > 83b519e8b9572c319c8e0c615ee5dd7272856090 is first bad commit > commit 83b519e8b9572c319c8e0c615ee5dd7272856090 > Author: Pekka Enberg <penb...@cs.helsinki.fi> > Date: Wed Jun 10 19:40:04 2009 +0300 > > slab: setup allocators earlier in the boot sequence > > James > _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
