Re: [Fastboot] Re: Kdump Testing

[ebiederm@xmission.com (Eric W. Biederman)]

"Randy.Dunlap" <rddunlap@osdl.org> writes:

> On Thu, 28 Apr 2005 17:14:16 +0530
> Vivek Goyal <vgoyal@in.ibm.com> wrote:
> 
> > > > Can you post a full serial console output of second kernel? That would
> help.
> 
> > > 
> > > I did another test run, same kernels (both running and recovery).
> > > The recovery kernel got a little further this time, still had
> > > Badness and a BUG.
> > > 
> > > ---
> > 
> > Ok. I am also able to see this slab corruption occurring on my machine. I can
> 
> > get away with the problem if I disable cachefs support. 
> > 
> > Infact, I can reproduce the problem if I boot capture kernel normally through
> 
> > BIOS with commandline "mem=64M". Looks like it is generic problem and not
> > associated with kexec/kdump. Cachefs might be doing some corruption.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Wheeeeeeeeee.  Great, we (I) can do without cachefs,
> and when I do that, kexec + kdump works.
> First time that I've seen kdump work.  :)
> 
> -rw-r--r--  1 root root 1.0G Apr 28 08:41 oldmem.0428
> -r--------  1 root root 960M Apr 28 08:36 vmcore.0428
> 
> My (crashing/panic) kernel is built without -g, but gdb
> can still tell me this much:
> 
> (gdb) bt
> #0  0xc010ef95 in crash_get_current_regs ()
> #1  0x00000000 in ?? ()
> #2  0xee821ea0 in ?? ()
> #3  0xee821ea0 in ?? ()
> #4  0xee821ea0 in ?? ()
> #5  0x00000046 in ?? ()
> #6  0x00000000 in ?? ()
> #7  0x00000000 in ?? ()
> #8  0x00000000 in ?? ()
> #9  0xee82c000 in ?? ()
> #10 0x00000000 in ?? ()
> #11 0xc010ed38 in machine_kexec ()
> 
> 
> Thanks for following up, tracking, working on this.

Congratulations everyone.  The good really good news is when the
recovery kernel failed it failed early enough it did not make things
worse.  It is good to see that prediction confirmed :)

Eric