[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101207105053.GA2803@redhat.com>
Date: Tue, 7 Dec 2010 11:50:54 +0100
From: Stanislaw Gruszka <sgruszka@...hat.com>
To: Yinghai Lu <yinghai@...nel.org>, "H. Peter Anvin" <hpa@...or.com>
Cc: Maxim Uvarov <muvarov@...il.com>, kexec@...ts.infradead.org,
linux-kernel@...r.kernel.org, Neil Horman <nhorman@...hat.com>
Subject: Re: kdump broken on 2.6.37-rc4
On Fri, Dec 03, 2010 at 12:54:01PM -0500, Neil Horman wrote:
> On Fri, Dec 03, 2010 at 06:11:48PM +0100, Stanislaw Gruszka wrote:
> > On Fri, Dec 03, 2010 at 06:46:09PM +0300, Maxim Uvarov wrote:
> > > 2010/12/3 Stanislaw Gruszka <sgruszka@...hat.com>:
> > > > On my T-60 laptop, i686 system with 2.6.37-rc4 kernel,
> > > > "echo c > /proc/sysrq-trigger" just hung the system. Kdump
> > > > works on 2.6.36. Is this known issue? If not, what info
> > > > I should provide to solve it (I think the easiest way
> > > > to solve the problem would be bisect) ?
> > > >
> > > > Stanislaw
> > > >
> > >
> > > I tested x86 QEMU yesterday with the latest git. It worked.
> > > Might be something target specific.., What does console print?
> >
> > Here is the photo
> > http://people.redhat.com/sgruszka/20101203_005.jpg
> >
> > There are two BUGs, first "sleeping function called from invalid
> > context" and then "unable to handle null pointer dereference".
> >
> The warning about sleeping is an artifact of the fact that we panic the box with
> irqs disabled I think (although I would think the fault handler would have
> re-enabled them properly). Not sure what the NULL pointer is from
NULL pointer dereferece is ok, that's the way sysrq_handle_crash
trigger a crash. Problem here is that secondary kdump kernel hung at
start.
Bisection shows that bad commit is
commit 72d7c3b33c980843e756681fb4867dc1efd62a76
Author: Yinghai Lu <yinghai@...nel.org>
Date: Wed Aug 25 13:39:17 2010 -0700
x86: Use memblock to replace early_res
Before commit kdump work. After it kernel doesn't compile (!?!). I fixed
compilation, but sill crash kernel can not be even loaded, I fixed that
using hunks from 9f4c13964b58608fbce05540743281ea3146c0e8 "x86, memblock:
Fix crashkernel allocation". After that crash kernel can be loaded, but
it hung at start, what is the problem that still happen in -rc4.
I'm attaching config, hope this is enough to fix.
Stanislaw
View attachment "t60.config" of type "text/plain" (72827 bytes)
Powered by blists - more mailing lists