Messages in this thread | | | Date | Thu, 25 Nov 2004 20:43:08 +0530 | From | Hariprasad Nellitheertha <> | Subject | Re: [PATCH] kdump: Fix for boot problems on SMP |
| |
Hi Badari,
Badari Pulavarty wrote: > Hari, > > > I have a success case and a failure case to report. > > 1) Success first.. I was able save /proc/vmcore when my machine > paniced (not thro sysrq) and gdb showed the stack correctly :)
Thanks for this news! Reassures us that we are on the right track on making kdump useful for real-life problems.
> > For some reason, gdb failed to show stack correctly, when I > ran it on /proc/vmcore directly, when I am on kxec kernel :(
Does it throw up wrong entries or does it completely fail?
> > # gdb ../l*9/vmlinux vmcore.3 > ... . . . > <0>kexec: opening parachute <<<<<<<<<<*** trying to kexec ?
Yes, this is the kexec call from the crash dump code.
> Unable to handle kernel paging request at virtual address c30a0000
This is the page reserved for storing the register values. Its really strange that it faults here. The page is reserved already during early boot.
> printing eip: > c1039956 > *pde = 00000000 > Oops: 0002 [#2] > SMP > Modules linked in: > CPU: 0 > EIP: 0060:[<c1039956>] Not tainted VLI > EFLAGS: 00010206 (2.6.10-rc2-mm2kexec) > EIP is at __crash_machine_kexec+0x66/0x110 <<<<<<** panic in kexec
The panic is in crash_dump_save_registers() while doing a memcpy. As I mentioned above, it faults on the page reserved to save the registers.
Is it possible I can get the testcase so I can attempt recreating the problem here. Please let me know.
Regards, Hari - 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/
| |