Re: page fault with NetBSD 4.0 with 4.5TB filesystem

[Stephen Borrill <netbsd%precedence.co.uk@localhost>]

On Thu, 25 Sep 2008, Juergen Hannken-Illjes wrote:
> On Thu, Sep 25, 2008 at 09:51:12AM +0100, Stephen Borrill wrote:
> > As described in
> > http://mail-index.netbsd.org/netbsd-users/2008/09/23/msg002009.html I've
> > got a 4.5TB FFSv2 filesystem at a customer's site on NetBSD 4.0. I've
> > managed to recreate the problem that made them power-cycle:
> >
> > uvm_fault(0xc0a1ca00, 0xdeec0000, 1) -> 0xe
> > kernel: supervisor trap page fault, code=0
> > Stopped in pid 5959.1 (chmod) at        netbsd:ffs_snapremove+0x3b0: movl
> > 0
> > (%ebx,%edx,1),%esi
> > db> bt
> > ffs_snapremove(d51b9f18,0,feeebb7,0,1000) at netbsd:ffs_snapremove+0x3b0
> > ffs_truncate(d51b9f18,0,0,0,ffffffff) at netbsd:ffs_truncate+0xe50
> > ufs_inactive(d4a85b40,7c9ce412,cc873200,c07a63a0,d51b9f18) at
> > netbsd:ufs_inactive+0x23d
> > VOP_INACTIVE(d51b9f18,d3d0f5c8,d4a85c2c,c048e9a6,d51b9f18) at
> > netbsd:VOP_INACTIVE+0x25
> > vput(d51b9f18,d4a85b74,d3d0f5c8,c07a6460,130b) at netbsd:vput+0x6e
> > sys___lstat30(d3d0f5c8,d4a85c48,d4a85c68,246,0) at netbsd:sys___lstat30+0x86
> > syscall_plain() at netbsd:syscall_plain+0x149
> > --- syscall (number 389) ---
> > 0xbbbb5e4b:
> >
> > So before I reboot and check out Christos' fsck patch, is there any more
> > information I can extract from ddb that might be of use?
>
> The vnode/inode its trying to snapremove would be good:
>
>         show vnode 0xd51b9f18

db> show vnode 0xd51b9f18
OBJECT 0xd51b9f18: locked=0, pgops=0xc099db2c, npages=0, refs=0

NODE flags 4080<LOCKSWORK,ONWORKLIST>
mp 0xc235a000 numoutput 0 size 0xb5ce9ef04acb88f0
data 0xd51ad1c0 usecount 0 writecount 0 holdcnt 2567 numoutput 0
tag VT_UFS(1) type UNKNOWN(0) mount 0xc235a000 typedata 0x0

>       call VOP_PRINT(0xd51b9f18)

db> call VOP_PRINT(0xd51b9f18)
tag VT_UFS, ino 267316151, on dev 19, 11 flags 0x6, effnlink -8719, nlink 
-8719
        mode 077733, owner -1693292274, group -2076333050, size 
-5346160952758007568 lock type vnlock: EXCL (count 1) by
pid 5959.10

That all looks rather negative to me :-/

--
Stephen