On 8/21/05, Chuck Silvers <chuq@chuq.com> wrote:
> I looked into this, the problem is a race between VOP_REVOKE() and VOP_IO=
CTL().
> there's another thread in the dump doing:
>=20
> #0  0xca62b948 in ?? ()
> #1  0xc02a151b in bpendtsleep ()
> #2  0xc02cd007 in biowait ()
> #3  0xc022eaf3 in ffs_update ()
> #4  0xc02dd39c in VOP_UPDATE ()
> #5  0xc025b7c3 in ufs_reclaim ()
> #6  0xc0243b39 in ffs_reclaim ()
> #7  0xc02dd08c in VOP_RECLAIM ()
> #8  0xc02d2557 in vclean ()
> #9  0xc02d2972 in vgonel ()
> #10 0xc02de417 in genfs_revoke ()
> #11 0xc02dcd80 in VOP_REVOKE ()
> #12 0xc028d338 in exit1 ()
> #13 0xc029c7d2 in postsig ()
> #14 0xc0339ba0 in syscall_plain ()

From what I've read in this thread, this looks like a possible
explanation for this panic I saw two days ago:

uvm_fault(0xcae689a0, 0, 0, 1) -> 0xe
#0 spec_ioctl +0xe
#1 VOP_IOCTl +0x40
#2 cttyioctl +0x52
#3 spec_ioctl +0x46
#4 VOP_IOCTL +0x40
#5 vn_ioctl +0x9e
#6 sys_ioctl +0x12e

It also died in the line Christos mentioned.

--=20
Julio M. Merino Vidal <jmmv84@gmail.com>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/