* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
