On Sat, 2005-Apr-09 14:51:41 -0500, Ash wrote:
This is consistent with the kernel continuing to run normally but being unable to schedule userland processes - usually due to a deadlock.
Do the caps-lock, num-lock, scroll-lock buttons on a local keyboard still toggle the relevant LEDs?
Assuming the LEDs toggle: Do you have "options DDB" and "options KDB" in your kernel? If so, can you break into DDB? (If not, I think you'll need to build a kernel with DDB). Once the system has hung, you need to enter DDB and run 'ps'. The output from that will give (hopefully) give an indication as to what is going wrong (and where to look next). If you've build the kernel with debugging symbols and got a dump device enabled, "call doadump()" should also generate a crashdump which will be much easier to examine.
Peter,
Thanks for the reply. I should have included this information in my initial e-mail:
I did not have a keyboard connected to the system before either crash. I did plug a keyboard in after the crash out of desperation. The keyboard LEDs were not responsive. However, it's a ps/2 keyboard, which does not get detected by this system unless it's plugged in before the machine POSTs.
I did not have DDB/KDB compiled in my kernel at the time, so I wasn't able to try to break into a debugger from the serial console. Shortly after the second crash I recompiled the kernel with DDB/KDB. Essentially at this point I'm just waiting for another crash to see if I can get get into DDB from the serial console.
I was hoping that someone on the list may have run into a similar issue with 5_4_0 so that I could at least figure out how to reproduce the problem rather than simply waiting for the machine to hang again. Patience is not my greatest virtue :)
-Ash _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
