Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 17 Nov 2002 14:39:29 -0500 (EST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Kris Kennaway <kris@obsecurity.org>
Cc:        current@FreeBSD.org
Subject:   Re: Processes hanging in thrd_sleep
Message-ID:  <Pine.NEB.3.96L.1021117143738.93303E-100000@fledge.watson.org>
In-Reply-To: <20021117105919.GA677@rot13.obsecurity.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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
robert@fledge.watson.org      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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1021117143738.93303E-100000>