On Thu, 28 Apr 2005 17:14:16 +0530
Vivek Goyal <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
