>> (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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
