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