From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Brian King <brking@linux.vnet.ibm.com>,
linuxppc-dev@ozlabs.org, Pekka Enberg <penberg@cs.helsinki.fi>,
Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: Boot failure on the powerstation with 2.6.30 latest
Date: Tue, 23 Jun 2009 08:25:55 +1000 [thread overview]
Message-ID: <1245709555.20062.12.camel@pasglop> (raw)
In-Reply-To: <1245708236.17035.2.camel@mulgrave.site>
> 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@cs.helsinki.fi>
> Date: Wed Jun 10 19:40:04 2009 +0300
>
> slab: setup allocators earlier in the boot sequence
>
> James
>
next prev parent reply other threads:[~2009-06-22 22:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-22 15:16 Boot failure on the powerstation with 2.6.30 latest James Bottomley
2009-06-22 16:11 ` Brian King
2009-06-22 22:03 ` James Bottomley
2009-06-22 22:25 ` Benjamin Herrenschmidt [this message]
2009-06-22 22:21 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1245709555.20062.12.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=brking@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=penberg@cs.helsinki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.