Messages in this thread | | | Subject | Re: [PATCH] kdump: Fix for boot problems on SMP | From | Badari Pulavarty <> | Date | 24 Nov 2004 12:07:58 -0800 |
| |
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 :)
For some reason, gdb failed to show stack correctly, when I ran it on /proc/vmcore directly, when I am on kxec kernel :(
# gdb ../l*9/vmlinux vmcore.3 ... Core was generated by `root=/dev/sda2 dump init 1 memmap=exactmap memmap=640k@0 memmap=32M@16M console='. #0 crash_get_current_regs (regs=0xc050b000) at arch/i386/kernel/crash_dump.c:98 98 } (gdb) bt #0 crash_get_current_regs (regs=0xc050b000) at arch/i386/kernel/crash_dump.c:98 #1 0xc0139986 in __crash_machine_kexec () at kernel/crash.c:83 #2 0xc011b2aa in panic (fmt=0xc050b000 "") at include/linux/crash_dump.h:21 #3 0xc0104ed5 in die (str=0x0, regs=0x1, err=2) at arch/i386/kernel/traps.c:392 #4 0xc0113ad2 in do_page_fault (regs=0xd4937edc, error_code=2) at arch/i386/mm/fault.c:480 #5 0xc0104707 in error_code () at /tmp/ccK5IM1b.s:2135 #6 0xc017a55e in aio_put_req (req=0x0) at fs/aio.c:529 #7 0xc017ba0d in io_submit_one (ctx=0xd46fddc0, user_iocb=0xbfffecb0, iocb=0xf75af124) at fs/aio.c:1551 #8 0xc017baf1 in sys_io_submit (ctx_id=3226513408, nr=32, iocbpp=0xbfffec30) at fs/aio.c:1609 #9 0xc0103c63 in syscall_call () at /tmp/ccK5IM1b.s:1946 #10 0xc0407220 in default_exec_domain () (gdb) q
2) Failure case:
When I recreated the panic again, it tried to run kexec() and ran into exception in kexec() code, and machine hung.
Here is the console output:
Unable to handle kernel NULL pointer dereference at virtual address 00000020 printing eip: c128c044 *pde = 00000000 Oops: 0002 [#1] SMP Modules linked in: CPU: 0 EIP: 0060:[<c128c044>] Not tainted VLI EFLAGS: 00010086 (2.6.10-rc2-mm2kexec) EIP is at _spin_lock_irq+0x4/0x20 <<<<<<<<<**** my original panic eax: 00000020 ebx: c2dd77e0 ecx: c2821bb0 edx: c2821b80 esi: 00000020 edi: 00000000 ebp: c1dd9f10 esp: c1dd9f10 ds: 007b es: 007b ss: 0068 Process aio_tio (pid: 8084, threadinfo=c1dd8000 task=c2110570) Stack: c1dd9f2c c107a56e c1dd9f18 c1dd9f18 c2821ba0 c2dd77e0 c1dd9f70 c1dd9f54 c107ba1d c2821b80 00000000 00000000 bfffecb0 c2821b80 c2821b80 00000000 bfffec30 c1dd9fbc c107bb01 c1dd9f70 bfffecb0 00000040 bfffecb0 00000000 Call Trace: [<c1004aaf>] show_stack+0x7f/0xa0 [<c1004c5e>] show_registers+0x15e/0x1c0 [<c1004e62>] die+0xf2/0x180 [<c1013ad2>] do_page_fault+0x3b2/0x710 [<c1004707>] error_code+0x2b/0x30 [<c107a56e>] aio_put_req+0x1e/0x90 [<c107ba1d>] io_submit_one+0x20d/0x250 [<c107bb01>] sys_io_submit+0xa1/0x110 [<c1003c63>] syscall_call+0x7/0xb Code: fe 0a 79 12 a9 00 02 00 00 74 01 fb f3 90 80 3a 00 7e f9 fa eb e9 5d c3 90 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 55 89 e5 fa <f0> fe 08 79 09 f3 90 80 38 00 7e f9 eb f2 5d c3 8d b6 00 00 00 <0>Fatal exception: panic in 5 seconds Kernel panic - not syncing: Fatal exception <0>kexec: opening parachute <<<<<<<<<<*** trying to kexec ? Unable to handle kernel paging request at virtual address c30a0000 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 eax: 00005400 ebx: c2003180 ecx: 000001e0 edx: 00000001 esi: c140b000 edi: c30a0000 ebp: c1dd9d98 esp: c1dd9d80 ds: 007b es: 007b ss: 0068 Process aio_tio (pid: 8084, threadinfo=c1dd8000 task=c2110570) Stack: c140b000 c1dd9d94 c1dd9d98 c1dd8000 c1dd9edc c12a01d5 c1dd9db4 c101b2aa 00000000 c140c380 c129e8dd c1dd9dc0 c1dd8000 c1dd9df8 c1004ed5 c129e8ce 00000001 c1dd9dcc 00000001 c1dd9edc c12a01d5 00000002 000000ff 0000000b Call Trace: [<c1004aaf>] show_stack+0x7f/0xa0 [<c1004c5e>] show_registers+0x15e/0x1c0 [<c1004e62>] die+0xf2/0x180 [<c1013ad2>] do_page_fault+0x3b2/0x710 [<c1004707>] error_code+0x2b/0x30 [<c101b2aa>] panic+0x5a/0x120 [<c1004ed5>] die+0x165/0x180 [<c1013ad2>] do_page_fault+0x3b2/0x710 [<c1004707>] error_code+0x2b/0x30 [<c107a56e>] aio_put_req+0x1e/0x90 [<c107ba1d>] io_submit_one+0x20d/0x250 [<c107bb01>] sys_io_submit+0xa1/0x110 [<c1003c63>] syscall_call+0x7/0xb Code: 2a c1 be 01 00 00 00 89 35 a4 c7 40 c1 e8 03 22 fe ff 8b 0d a4 c7 40 c1 85 c9 75 6c bf 00 00 0a c3 be 00 b0 40 c1 b9 e0 01 00 00 <f3> a5 c7 04 24 80 07 0a c3 c7 44 24 04 80 b7 40 c1 c7 44 24 08 <0>Fatal exception: panic in 5 seconds
Thanks, Badari
On Tue, 2004-11-23 at 10:15, Hariprasad Nellitheertha wrote: > Hi Badari, > > Badari Pulavarty wrote: > > More info testing results... > > > > gdb is not showing the stack info properly, on my saved vmcore. > > I thought vmlinux is not matching the vmcore, so I verified that > > vmcore and vmlinux matchup. But still no luck... > > I will try to recreate this using the 'sysrq' method you described in > the earlier mail. Will let you know my findings asap. > > Thanks very much for trying kdump! > > 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/
| |