On Sun, Nov 17, 2002 at 03:41:36PM -0600, Alan L. Cox wrote:
> This late-night commit might help:
>
> jeff2002/11/17 01:33:00 PST
>
> Modified files:
> sys/kern kern_exec.c
> Log:
>- Release the imgp vnode prior to freeing exec_map resources to avoid
> deadlo
This late-night commit might help:
jeff2002/11/17 01:33:00 PST
Modified files:
sys/kern kern_exec.c
Log:
- Release the imgp vnode prior to freeing exec_map resources to avoid
deadlock.
Revision ChangesPath
1.200 +4 -4 src/sys/kern/kern_exe
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
On Sun, Nov 17, 2002 at 02:59:19AM -0800, 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:
>
> > loa
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 [t
