[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <19f34abd0807110800o5b283f00n4be7449ed3b06e5a@mail.gmail.com>
Date: Fri, 11 Jul 2008 17:00:42 +0200
From: "Vegard Nossum" <vegard.nossum@...il.com>
To: "Török Edwin" <edwintorok@...il.com>
Cc: "Ingo Molnar" <mingo@...e.hu>, "Takashi Iwai" <tiwai@...e.de>,
linux-next@...r.kernel.org,
"Linux Kernel" <linux-kernel@...r.kernel.org>
Subject: Re: today's linux-next fails to boot
> On Fri, Jul 11, 2008 at 4:48 PM, Török Edwin <edwintorok@...il.com> wrote:
>>> One really simple way of getting some more info out of this is to take
>>> the EIP value (here c0181ca0) and run it through addr2line:
>>>
>>> $ addr2line -e vmlinux -i c0181ca0
>>
>> Thanks for the hint, I rebuilt a failing kernel, and this is what
>> addr2line says:
>>
>> $ addr2line -e vmlinux -i c0181ca0
>>
>> ??:0
>> $ addr2line -e vmlinux -f c0181ca0
>> kmem_cache_alloc
>> ??:0
BTW, did the new kernel fail in exactly the same place? If not, you
should also replace the EIP in the new crash report on the addr2line
command line, so in general: addr2line -e vmlinux -f -i <EIP here>.
(I don't think it really makes sense for the kernel to crash in
kmem_cache_alloc() this early in the boot process, so I'm guessing you
have a different EIP.)
(Also don't rebuild a bad kernel just to try this out again, but if
you happen to run across another bad one for example during bisection,
you can try it then.)
Vegard
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
Powered by blists - more mailing lists