panic: spin lock held too long (w/ backtrace)

[Kris Kennaway]

On Thu, May 10, 2007 at 07:44:37PM -0600, Scott Swanson wrote:
> >> (kgdb) proc 18303
> >> (kgdb) bt
> >> #0  0xc0644f5b in sched_switch (td=0xc95a5900, newtd=0xc92aad80,
> >> flags=0) at /usr/src/sys/kern/sched_4bsd.c:973
> >> #1  0xeaa6dcb4 in ?? ()
> >> #2  0x00000001 in ?? ()
> >> #3  0x0ee2c000 in ?? ()
> >> #4  0x00000000 in ?? ()
> >> #5  0x00004000 in ?? ()
> >> #6  0x00000000 in ?? ()
> >> #7  0x00000000 in ?? ()
> >> #8  0xc95a5900 in ?? ()
> >> #9  0xeaa6dd30 in ?? ()
> >> #10 0xc081a8fb in syscall (frame=Cannot access memory at address 0x4008
> >> ) at /usr/src/sys/i386/i386/trap.c:983
> >> Previous frame inner to this frame (corrupt stack?)
> > 
> > Garbage :(  Are you using any modules?
> > 
> > Kris
> 
> Well, I do have ASR_COMPAT enabled in the kernel to monitor the Adaptec
> 2010S controller.
> 
> # asr old ioctls support, needed by raidutils
> options         ASR_COMPAT
> 
> In retrospect I guess I should have started investigating there first.
> Is there a good way to determine if this is actually the problem without
> just recompiling the kernel and hoping for the best?
> 
> I see that it is still listed in NOTES, but maybe this option should now
> be avoided?

Dunno how this answers my question so I'll retry :) Are you using any
.ko modules for things not compiled into your kernel?  It's the only
way I can think of to get a nonsense backtrace like that (you have to
do more work to trace kernels with modules loaded).  Check kldstat.

Kris