* Linus Torvalds <torvalds@linux-foundation.org> wrote:

quoted text
> In other words, is it perhaps possible to just *get*rid*of* that 
> "kgdb_active" and "nmicallback" and the whole multi-CPU roundup? Just 
> use a kgdb spinlock around the stuff that actually sends and receives 
> individual packets, and expect the debugger side to sort them out 
> (yeah, I suspect this involves having to add the CPU ID to each 
> packet).

i actually think that the notion of "stopping all system state" is 
rather intuitive from a debugging POV: when you have a bug trigger 
somewhere then getting an NMI to all CPUs and stopping them dead in 
their tracks preserves us the system in its most useful state.

also, when using kgdb to "look at system state" it's best to have as 
little "unrelated" activity as possible.

the timeout argument brought up by Andi was IMO really just pulled here 
by its hair, it never happened to me in practice and i was surprised it 
even came up. (i never before saw "KGDB roundup" fail - and i tried it 
on an 8-way system too) I think the memory-access routine cleanups were 
far more interesting from a failure scenario POV. Maybe Andrew could 
shed some light on his experience and preference here - he's been using 
KGDB for many years.

	Ingo
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/