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