Re: [Fastboot] Re: Kdump Testing

["Randy.Dunlap" <rddunlap@osdl.org>]

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.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/