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

Scott Swanson scotts at inetz.com
Fri May 11 01:44:42 UTC 2007


>> (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?

Regards;
Scott




More information about the freebsd-stable mailing list