Re: [PATCH] Fix x86 initialization for {hard, soft}irq_ctx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




----- 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



[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux