I ran into that during heavy builds on one of my boxes a few months ago -- I never really got around to properly debugging it because the UFS file systems promptly ate themselves. Oddly, I had two boxes in particular that this happened on, and none of my others, and it wasn't clear to me if there was a useful pattern. I will try reproducing it sometime this weekend. Basically, the system seemed fairly live, but any attempt to execve() would hang the process in that sleep state. It looked a bit like a VM lock leak followed by piling up on locks into a deadlock staet.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Sun, 17 Nov 2002, Kris Kennaway wrote: > Since upgrading my kernel to today's current (from a couple of weeks > ago) I have had a number of hangs where processes block in the kernel, > usually in the thrd_sleep state (but once one hung in the ufs state). > > e.g: > > > load: 0.01 cmd: cc 708 [ufs] 0.00u 0.00s 0% 56k > > > load: 0.01 cmd: tcsh 709 [thrd_sleep] 0.00u 0.00s 0% 1220k > > I've seen this on my sparc64 box as well as an i386 box. > > Any bright ideas? Anyone feeling guilty? :) > > Kris > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
