Ahh, so, kdb is keyed off of threads not pids or proc entries.
That's really helpful, the only problem being, setting a break
point every time the spinlock code is called, slows it down so
much that we never see the panic. We thought that if the
debugger is keyed off of thread ids, then we can grab that somehow
and simply add it to the spinlock structure. Saving the state of
the thread that has the lock and the thread that wants the lock.
-bmb-
> -----Original Message-----
> From: Scott Lurndal [mailto:slurn@xxxxxxxxxxx]
> Sent: Tuesday, July 18, 2000 12:33 PM
> To: Boerner, Brian
> Cc: kdb@xxxxxxxxxxx
> Subject: Re: Debugging Spinlocks on SMP via KDB
>
>
> >
> > 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
> >
>
|