Messages in this thread | | | Date | Thu, 28 Apr 2005 09:11:19 -0700 | From | "Randy.Dunlap" <> | Subject | Re: [Fastboot] Re: Kdump Testing |
| |
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/
| |