[<prev] [next>] [day] [month] [year] [list]
Message-Id: <1245709555.20062.12.camel@pasglop>
Date: Tue, 23 Jun 2009 08:25:55 +1000
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: James Bottomley <James.Bottomley@...senPartnership.com>
Cc: Brian King <brking@...ux.vnet.ibm.com>, linuxppc-dev@...abs.org,
Pekka Enberg <penberg@...helsinki.fi>,
Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: Re: Boot failure on the powerstation with 2.6.30 latest
> 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 <penberg@...helsinki.fi>
> Date: Wed Jun 10 19:40:04 2009 +0300
>
> slab: setup allocators earlier in the boot sequence
>
> James
>
--
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