> > > If you lean on the keyboard, or if you set up the network adapters > > > as "entropy" sources, does the problem fix itself? > > > > If you're thinking it's /dev/random blocking on him, 5.0's output never > > blocks. Its output is a PRNG periodically seeded from random data, > > including interrupt timings and LAN traffic by default. > > Mostly, I was thinking that the other suggestions (WITNESS, > INVARIANTS, malloc flags) didn't really have any chance of > being the cause of the lock-ups, and without some message on > the console, it's unlikely that it was a driver tiemout, either.
No messages on console. > If it's long enough to pause the console noticibly, the next > thing to try is breaking to the debugger -- which might require > an NMI card -- to see what code it's stuck in during the pause. It's noticeable - if you type under heavy load in console, you experience similar to ssh lag - you can't see what you type, but it appears a second later to the screen. I've spoken about this issue on IRC for a few times, and ran into a guy who said he was experiencing similar problems on 5.0-REL. Just to let you know. I've tried adding HR< to malloc.conf and removing ALL unneccessary options from the kernel, no help. Atte Peltomäki http://kameli.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
