* Andi Kleen <andi@firstfloor.org> wrote: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 --
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Ingo Molnar | Re: [RFT] x86 acpi: normalize segment descriptor register on resume |
| Andrew Morton | -mm merge plans for 2.6.23 |
| Greg Kroah-Hartman | [PATCH 004/196] Chinese: add translation of SubmittingPatches |
git: | |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| David Miller | Re: [GIT]: Networking |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Ingo Molnar | [bug] stuck localhost TCP connections, v2.6.26-rc3+ |
