Debugging Spinlocks on SMP via KDB
Scott Lurndal
slurn at nanobiz.com
Tue Jul 18 09:32:45 PDT 2000
>
> Howdy folks..
>
> I'm trying to debug a spinlock problem using kdb v0.6-2.2.13. Here is a
> basic summary of the problem.
>
> When my driver is compiled as part of the resident kernel (i.e. not a
> module) on an SMP box, the same
> CPU comes along and tries to acquire a lock it already has. I, of course,
> panic the system. My question
> is more or less a theory question.
If this is a bohr bug (as opposed to a heisenbug), i.e. the bug is
reproducible 100% of the time, you can set a breakpoint on the spinlock
spin code (i.e. after it has been determined that the caller must spin)
and examine the saved state (the thread which owns the lock). You will
be able to acquire stack tracebacks for all involved threads, albeit
module symbols may be incomplete.
You must use the breakpoint if the spin lock disables interrupts because
you will otherwise be unable to enter the kernel debugger, unless your
hardware exposes an NMI button.
scott
>
> Is it possible to use kdb to look at a given thread at the time the system
> panics?
> It is my hopes that I can squirrel away the thread of the process that has
> the lock
> and the thread of the process trying to acquire the lock and look at them in
> parallel
> to determine the conditions under which this is happening.
>
> I'm fairly new to kernel level debuggers and any help would be greatly
> appreciated.
>
> Brian M. Boerner
> System Software Developer
> Adaptec, Inc.
> Nashua, NH 03060
> (603) 579-4625
>
More information about the kdb
mailing list