Norman, Thank you for the configuration settings. I will try those tomorrow. Funny that BSD/OS ran for so long without hard locks. Since Linux is aggressive in using memory, I was thinking it could be a memory (RAM) issue. So I am running memtest86 3.1 overnight on the machine to grill the RAM. If there are no memory errors detected I'll try those settings tomorrow. I have a console cable. I'm assuming I just connect it to Com1 and watch? I'll try it tomorrow. I use console cables all the time for network devices and Suns, but not much for x86 boxes (which this is). On the one hand this is frustrating, but on the other, that's how you learn, right?!? Thanks again, <> Jim > -----Original Message----- > On Thu, Mar 18, 2004 at 06:53:38PM -0500, Small, Jim wrote: > > I've tried only using one NIC that doesn't share any IRQs (no bridging > or > > shared interrupts). Like I said, this box ran for months without > locking > > running BSD/OS. What could be causing it to hard lock? > > > > Is there some kernel option I can use to help debug the problem? Are > there > > any troublesome modules I should eliminate? > > You could try enabling the sysreq key. That is, in /etc/sysctl.conf, > set this: > > # Controls the System Request debugging functionality of the kernel > kernel.sysrq = 1 > > then run "sysctl -p" > > Then, when the system hangs, on the console hit 'alt-prntscrn-P' to > see where the processors are locked. alt-prntscrn-H will show you other > commands you might want to try. A serial console is needed to collect > or view all the output. > > Setting NMI watchdog could also be helpful. Do that by putting > "nmi_watchdog=1" in the options of the kernel line in grub.conf. > The system should oops if it locks up.
