Dave Anderson <anderson(a)redhat.com> 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.
[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.]
Thanks.
--
OGAWA Hirofumi <hirofumi(a)mail.parknet.co.jp>