--m51xatjYGsM+13rf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 27, 2007 at 03:22:10PM -0800, Tom Spindler wrote:
> Here's the results. (I had to boot into multiuser mode, which was kind
> of annoying; didn't seem to work in singleuser.)

Didn't seem to fail, you mean? :-)

> db> ps/l
>   PID         LID S     FLAGS       STRUCT LWP *            UAREA * WAIT =
      =20
>  116           1 3 0x1000004         0xceff11c0         0xcd22ece0 vnlock
>  1054          1 3      0x84         0xceff1340         0xcd04ece0 pause
>  977           1 3      0x84         0xceff1ac0         0xcc3aece0 ttyin
>  855           1 3      0x84         0xcb1b3020         0xcc65ece0 ttyin
>  1039          1 3      0x84         0xcb1b34a0         0xcbe6ece0 wait
>  946           1 3      0x84         0xcb1b37a0         0xcbca8ce0 ttyin
>  1013          1 3      0x84         0xceff14c0         0xcce7ece0 nanoslp
>  1050          1 3      0x84         0xceff17c0         0xccc1ece0 select
>  1023          1 3      0x84         0xceff1640         0xccd0ece0 select
>  952           1 3      0x84         0xceff1940         0xcc82ece0 select
>  764           1 3      0x84         0xceff1dc0         0xcc74ece0 select
>  726           1 3      0x84         0xcb1b31a0         0xcc59ece0 pause
>  435           1 2       0x4         0xcb1b3320         0xcc4aece0=20
>  349           1 3      0x84         0xcb1b3620         0xcbcacce0 select
>  91            1 3     0x204         0xceff1c40         0xcc98ece0 physiod
>  14            1 3     0x204         0xcb1b3920         0xcbca4ce0 aiodon=
ed
>  13            1 3     0x204         0xcb1b3aa0         0xcbca1ce0 syncer
>  12            1 3     0x204         0xcb1b3c20         0xcbc9ece0 pgdaem=
on
>  11            1 3     0x204         0xcb1b3da0         0xcbc99ce0 sccomp
>  10            1 3     0x204         0xcb1ac000         0xcbc93ce0 apmev
>  9             1 3     0x284         0xcb1ac180         0xcbc90ce0 fwprobe
> db> t/a 0xceff11c0
> trace: pid 116 lid 1 at 0xcd22e9fc
> sleepq_switch(0,0,cd1b7c74,c0363964,0) at netbsd:sleepq_switch+0x53
> ltsleep(cd1b7c74,14,c0363964,0,cd1b7c74) at netbsd:ltsleep+0x13b
> acquire(0,40500,c019de46,0,74) at netbsd:acquire+0x104
> _lockmgr(cd1b7c74,10002,cd1b7bec,c0386930,937) at netbsd:_lockmgr+0x9bb

Ok, this looks like normal vnode lock aquisition.

What we need to know is which process holds this vnode lock, and what it=20
is sleeping on.

> ufs_lock(cd22eb60,cd22eb94,cf0b2334,cd22ebb8,0) at netbsd:ufs_lock+0x3a
> VOP_LOCK(cd1b7bec,10002,2b7,0,5) at netbsd:VOP_LOCK+0x23
> vn_lock(cd1b7bec,20002,200,0,cf0b3a88) at netbsd:vn_lock+0x96
> vn_close(cd1b7bec,5,cf0b2334,ceff11c0,ceff11c0) at netbsd:vn_close+0x21
> vn_closefile(cf0b3a88,ceff11c0,5b3,0,0) at netbsd:vn_closefile+0x1a
> closef(cf0b3a88,ceff11c0,cd22ec68,cd22ece0,8054000) at netbsd:closef+0x17c
> syscall_plain() at netbsd:syscall_plain+0xb4
> --- syscall (number 6) ---
> 0xbbb191fb:
> db> show lock ufs_hashlock

Doesn't really matter, you're in a normal vnode call path.

Take care,

Bill

--m51xatjYGsM+13rf
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFF5NixWz+3JHUci9cRAgP/AKCXYYX+MYbluSwauRiXYanNc8hz8QCfVSTo
zP3spq2ed3Xtajb2NNguGg0=
=CQeY
-----END PGP SIGNATURE-----

--m51xatjYGsM+13rf--