On Sun, Jan 26, 2003 at 09:51:50PM -0600, Paul Dokas wrote:
> It took a while, but I've finally managed to panic one of my machines.
> It was rebuilding the entire system when it happened:
> 
>   cd /usr/src
>   ./build -T /usr/tools -O /usr/obj -E build
> 
> 
> The following is copied by hand:
> 
> uvm_fault(0xc034dec0, 0xcab74000, 0, 1) -> e
> db> trace
> ffs_truncate(cac06d94,11,c02f07fa,0,cab73ec0) at ffs_truncate+0x88a
> VOP_TRUNCATE(cab81664,0,0,0,ffffffff) at VOP_TRUNCATE+0x49
> ufs_truncate(cac06e24,cac06e5c,cac06e60,c019800d,c02f1500) at ufs_inactive+0xa1
> VOP_INACTIVE(cab81664,cab604c0,cac06f78,7a39c7,ca9eb3dc) at VOP_INACTIVE+0x2e
> vput(cab81664,cab73ec0,800c,0,ca9eb3dc) at vput+0xa2
> ufs_remove(cac06ec0,0,0,ca8153c0,cab604c0) at ufs_remove+0xad
> VOP_REMOVE(ca9eb3dc,cab81664,cac06f1c,2,caa95b2c) at VOP_REMOVE+0x35
> sys_unlink(caa95b2c,cac06f80,cac06f78,c023f01c,bfbf9c72) at sys_unlink+0xc7
> syscall_plain(1f,1f,1f,1f,bfbf9960) at syscall_plain+0xab

I think there was a bug in the ufs_daddr_t change which could cause this.
This should be fixed now.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 24 ans d'experience feront toujours la difference
--