----- "Hu Tao" <hutao@xxxxxxxxxxxxxx> wrote: > Hi Dave, > > When we run into exception stack(test module attached) and take a > dumpfile by virsh dump, it seems crash doesn't show backtrace > properly. Did you forcibly crash the kernel first? Or did you essentially take a "live dump"? Dave > crash shows: > > crash> bt -a > PID: 1115 TASK: ffff88001e082d60 CPU: 0 COMMAND: "bash" > #0 [ffff88001f8a3c58] schedule at ffffffff813e9a41 > #1 [ffff88001f8a3c60] _raw_spin_unlock at ffffffff813eb486 > #2 [ffff88001f8a3c70] vt_console_print at ffffffff8123fc17 > #3 [ffff88001f8a3cf0] _raw_spin_unlock_irqrestore at ffffffff813eb4c3 > #4 [ffff88001f8a3d10] _raw_spin_unlock_irqrestore at ffffffff813eb4c3 > #5 [ffff88001f8a3d20] release_console_sem at ffffffff8103c6a6 > #6 [ffff88001f8a3d50] vprintk at ffffffff8103cca0 > #7 [ffff88001f8a3df0] printk at ffffffff813e90e4 > #8 [ffff88001f8a3e50] __handle_sysrq at ffffffff8124585d > #9 [ffff88001f8a3e90] write_sysrq_trigger at ffffffff8124593f > #10 [ffff88001f8a3eb0] proc_reg_write at ffffffff8112b9f0 > #11 [ffff88001f8a3f00] vfs_write at ffffffff810e9101 > #12 [ffff88001f8a3f40] sys_write at ffffffff810e9213 > #13 [ffff88001f8a3f80] system_call_fastpath at ffffffff81002a82 > RIP: 00007f26509b2200 RSP: 00007fff188c9900 RFLAGS: 00010206 > RAX: 0000000000000001 RBX: ffffffff81002a82 RCX: > 0000000000000400 > RDX: 0000000000000002 RSI: 00007f2651293000 RDI: > 0000000000000001 > RBP: 00007f2651293000 R8: 000000000000000a R9: > 00007f2651296700 > R10: 00000000ffffffff R11: 0000000000000246 R12: > 00007f2650c57780 > R13: 0000000000000002 R14: 0000000000000002 R15: > 0000000000000000 > ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b > > > The module's output: > > [root@localhost ~]# insmod km_kprobe.ko > kprobe registered > [root@localhost ~]# echo q > /proc/sysrq-trigger > SysRq : Show clockevent devices & pending hrtimers (no others) > post_handler will loop. > Pid: 1116, comm: bash Not tainted 2.6.36-rc6-00140-g183b469-dirty #5 > Call Trace: > <#DB> ffff880001a09da0 [<ffffffff8124552e>] ? > sysrq_handle_show_timers+0x1/0xb > ffff880001a09dc0 [<ffffffffa00ea017>] handler_post+0x17/0x1c > [km_kprobe] > ffff880001a09dd0 [<ffffffff813edb44>] > kprobe_exceptions_notify+0x376/0x460 > ffff880001a09df0 [<ffffffff8124552d>] ? > sysrq_handle_show_timers+0x0/0xb > ffff880001a09e00 [<ffffffff813ed971>] ? > kprobe_exceptions_notify+0x1a3/0x460 > ffff880001a09e40 [<ffffffff813ee7e7>] > notifier_call_chain+0x32/0x5e > ffff880001a09e80 [<ffffffff813ee850>] > __atomic_notifier_call_chain+0x3d/0x6b > ffff880001a09ec0 [<ffffffff813ee88d>] > atomic_notifier_call_chain+0xf/0x11 > ffff880001a09ed0 [<ffffffff813ee8bd>] notify_die+0x2e/0x30 > ffff880001a09f00 [<ffffffff813ec035>] do_debug+0x93/0x156 > ffff880001a09f50 [<ffffffff813ebbb8>] debug+0x28/0x40 > ffff880001a09fd8 [<ffffffff8124552e>] ? > sysrq_handle_show_timers+0x1/0xb > <<EOE>> ffff88001d99fe50 [<ffffffff8124585d>] ? > __handle_sysrq+0xba/0x156 > ffff88001d99fe90 [<ffffffff8124593f>] > write_sysrq_trigger+0x46/0x4e > ffff88001d99fea0 [<ffffffff812458f9>] ? > write_sysrq_trigger+0x0/0x4e > ffff88001d99feb0 [<ffffffff8112b9f0>] proc_reg_write+0x8d/0xac > ffff88001d99ff00 [<ffffffff810e9101>] vfs_write+0xa9/0x105 > ffff88001d99ff40 [<ffffffff810e9213>] sys_write+0x45/0x69 > ffff88001d99ff80 [<ffffffff81002a82>] > system_call_fastpath+0x16/0x1b > > Notice that two backtrace output differ from <<EOE>>, crash doesn't > show > exception stack frames. Although crash does check exception stack > against sp, but the problem seems to be we can't get right sp value > (ffff880001a09da0 in this example) from the dump file. Am I right? Is > there any we can get right sp value from dump file? > > I did a manually check on these stack frames using crash on the dump > file(rd then sym), and the stack contents are the same as the > module's > output. > > BTW, bt -S ffff880001a09da0 causes crash to seg fault. > > -- > Thanks, > Hu Tao -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
