>> So, if you disable 'sysctl_hardlockup_all_cpu_backtrace' and enable >> 'hardlockup_panic', you should be able to achieve what you want, no? >> >> But you mentioned you wanted to recover? Hence avoiding the panic? >> >> Cheers, >> Don >> > > Yes. Avoiding the panic is what I wanted to do. These flags work at > catching the bug as you suggest, however, it does not allow you to > step out of the hard lockup detector into the offending code, which is > what a breakpoint does for you here. We almost need an explicit call > to enter a debugger here. I need to go off and rethink this some > more. > > :-) > > Jeff >
Hi Don, I've decided to maintain this capability in the MDB debugger patch series I distribute from the MDB Debugger tree on github. All the wonderful feedback and discussion has really helped me understand what's required here and exposed some issues in native Linux for some folks to think about. I am not certain this type of change belongs in native Linux since linux has no in-kernel debugger that provides disassembly -- it has a device driver that talks to a remote user space application called GDB and a headless debug dump tool called kdb. So unless there is a native in-kernel debugger in Linux such a change is sort of pointless and from what I have gathered, the x86 folks are not interested in fixing the entry code and other areas to allow a full blown kernel debugger unless I just go and patch that myself in my tree. This has been very helpful in helping me to understand what types of changes should be submitted here and are helpful. Jeff
