--TeJTyD9hb8KJN2Jy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 07, 2005 at 07:42:36PM +0100, Manuel Bouyer wrote:
> On Mon, Feb 07, 2005 at 09:49:41AM -0800, Bill Studenmund wrote:
> > All I can think to do is further discuss this on tech-kern.
> >=20
> > Oh, I think all the processes in vnlock aren't the core problem. Someth=
ing=20
> > else has a vnlock and is waiting for some other resource that isn't the=
re.=20
> > Then everything else piles up on the different vnlocks.
>=20
> Could something with a vnlock try to allocate a new vnode ? If so this
> is probably the source of the problem.

I doubt it. It could be true, but I expect it's more likely that the vnode=
=20
is locked while the fs is trying to do something that's blocking for=20
memory. Then something else ends up waiting on that vnode lock, then=20
something else on the second one, and then you run the race for root. Once=
=20
the race is done, the root vnode's locked and everything that looks up a=20
path begining with "/" gets to wait. :-|

Take care,

Bill

--TeJTyD9hb8KJN2Jy
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFCB7xGWz+3JHUci9cRAipbAJ4kMCTYBFP3d4SAXj39AKI2y3CiKgCgiozS
SBcEVW8V9/x5mVWb28Wh/a8=
=6C7V
-----END PGP SIGNATURE-----

--TeJTyD9hb8KJN2Jy--