----- Original Message ----- > > > ----- Original Message ----- > > Dave Anderson <anderson@xxxxxxxxxx> writes: > > > > >> >> crash> bt > > >> >> PID: 0 TASK: c1da8b00 CPU: 0 COMMAND: "swapper/0" > > >> >> #0 [c1da1f60] __schedule at c19fe305 > > >> >> #1 [c1da1fa0] schedule at c19febb3 > > >> >> #2 [c1da1fac] schedule_preempt_disabled at c19ff0a2 > > >> >> #3 [c1da1fb4] cpu_startup_entry at c10a9580 > > >> >> crash> bt 45 > > >> >> PID: 45 TASK: f57d3a00 CPU: 3 COMMAND: "kworker/3:1" > > >> >> bt: cannot resolve stack trace: > > >> >> bt: Task in user space -- no backtrace > > >> >> > > >> >> In above case, looks like failed to detect panic cpu, and "bt 45" > > >> >> also > > >> >> not working. > > >> > > >> crash> bt 45 > > >> PID: 45 TASK: f57d3a00 CPU: 3 COMMAND: "kworker/3:1" > > >> bt: cannot resolve stack trace: > > >> bt: Task in user space -- no backtrace > > > > Debugged this case. The root cause is nested stack of softirq => > > hardirq. Now doesn't handle it correctly, and the patch attacked. > > > > BTW, with this patch, "bt -t" seems to be working at least. "bt" is > > failed sometime by confusion of stack-frame detection, this one is > > harder to fix. > > OK thanks, I'll give this patch a test run. Queued for crash-7.1.8: https://github.com/crash-utility/crash/commit/fc9c517acddda878319774298ccb2ffc3c55f71f Thanks, Dave > > > > > [BTW, current x86_get_pc() uses inactive_task_frame_ret_addr to get > > pc. However, inactive_task_frame is only valid if task is sleeping > > state. (running task may overwrite inactive_task_frame already.) I'm > > not sure whether we should check is_task_active() or not. Even if > > checking is_task_active(), we can't get pc correctly anyway.] > > Well, x86_get_pc() should only be called in the case of sleeping > tasks because each dumpfile type has its own function to try to > find the active task registers. For example, on a kdump: > > cmd_bt() > back_trace() > get_kdump_regs() > get_netdump_regs() > get_netdump_regs_x86() > > get_netdump_regs_x86() *should* find the starting point hooks. > If it fails to do so, it will default to machdep->get_stack_frame() > and ultimately x86_get_pc(). So if it gets there, the backtrace > is pretty much guaranteed to be invalid. > > Thanks, > Dave > > > > Thanks. > > -- > > OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> > > > > > > > > [Text Documents:p1-fix-x86-nest-stack.patch] > > > > -- > Crash-utility mailing list > Crash-utility@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/crash-utility -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
