Cc: <linux-kernel@...>, Frank Ch. Eigler <fche@...>, Roland McGrath <roland@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Linus Torvalds <torvalds@...>, Andrew Morton <akpm@...>
well, this is a small detail, but still you are wrong, and on a
correctly working system this will not occur. (if yes, tell me how)
KGDB does a very straightforward "all CPUs enter controlled state"
transition when the session begins, and at the end an "all CPUs
continue" transition.
I'm not sure what you mean exactly under "stopping all CPUs for
indefinite amount of time" (your statement is sufficiently vague to be
hard to counter via specifics) - that does not happen, unless the system
is so buggy that a CPU is not able to process an NMI anymore [which is
rather rare] - in that case the whole system is likely locked up anyway.
In that case the simplest and safest behavior is what kgdb-light does
currently: it will only proceed if all CPUs have responded. Note that
you are wrong to suggest that "KGDB locks up", the system _has already
locked up_.
yes, we could "time out" and force a KGDB session even if some CPUs do
not respond. But it's obviously not a completely safe system state,
because other CPUs might be changing things under the feet of the
debugger. So the safest first-level approach is to not enter the
debugger in this case.
Ingo
--
