Possibly.
I respectfully disagree with his opinion, as using notifier chains
assumes more of the kernel works. Although following it's argument
to it's logical conclusion we should call crash_kexec as the very
first thing inside of panic. Given how much state something like
bust_spinlocks messes up that might not be a bad idea.
It does make adding an alternative debug mechanism in there difficult.
Does anyone know if this also affects kgdb?
Hmm. Tricky. These appear to be two code bases with a completely different
philosophy on what errors are being avoided.
The kexec on panic assumption is that the kernel is broken and we better not
touch it something horrible has gone wrong. And this is the reason why
kexec on panic is replacing lkcd. Because the strong assumption results
in more errors getting captured with less likely hood of messing up your
system.
The kdb assumption appears to be that the kernel is mostly ok, and that there
are just some specific thing that is wrong.
The easiest way I can think to resolve this is for kdb to simply set
a break point at the entry point of panic() when it initializes. Then
it wouldn't even need to be on the panic_list. That approach would probably
even give better debug information because you would not have the effects
of bust_spinlocks to undo.
Is there some reason why kdb doesn't want to hook panic with a some
kind of break point?
Eric
-
