Re: port-macppc/51938: Reproducible kernel panics caused by basic ffs file system operations (e.g. chown) on macppc

["David H. Gutteridge" <dhgutteridge%sympatico.ca@localhost>]

The following reply was made to PR port-macppc/51938; it has been noted by GNATS.

From: "David H. Gutteridge" <dhgutteridge%sympatico.ca@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: port-macppc/51938: Reproducible kernel panics caused by basic
 ffs file system operations (e.g. chown) on macppc
Date: Mon, 06 Feb 2017 16:03:00 -0500

 On Sat, 2017-02-04 at 23:45 +0000, David Holland wrote:
 > Can you try to repeat it with ufs_lookup.c compiled with -O0?
 
 I re-tested with ufs_lookup.c compiled with -O0, and I still get
 panics, but they're more varied and slightly less frequent.
 
 The first time I retried the chown test, I ended up with this instead:
 
 trap: pid 293.1 (chown): user write DSI trap @ 0xd8344000 by 0xfdf5371c
 (DSISR 0x42000000, err=12)
 UVM: pid 293.1 (chown), uid 0 killed: out of swap
 
 The second time I retried the same chown test, it resulted in another
 panic:
 
 panic: kernel diagnostic assertion "newsize != VSIZENOTSET && newsize >=
 0" failed: file "/home/disciple/netbsd-current/src/sys/uvm/uvm_vnode.c", 
 line 351
 Stopped in pid 111.1 (chown) at netbsd:vpanic+0x140:    addi    r4,  r0,
 0x0
 0x100e0960: at kern_assert+0x68
 0x100e09a0: at uvm_vnp_setsize+0x6c
 0x100e09c0: at ffs_loadvnode+0xfc
 0x100e0a00: at vcache_get+0x3cc
 0x100e0a80: at ufs_getino+0xa0
 0x100e0ab0: at ufs_lookup+0xc8c
 0x100e0ba0: at VOP_LOOKUP+0x44
 0x100e0bd0: at lookup_once+0x1d8
 0x100e0c30: at namei_tryemulroot+0x4b4
 0x100e0d00: at namei+0x34
 0x100e0d40: at fd_nameiat.isra.2+0x7c
 0x100e0d70: at do_sys_statat+0x90
 0x100e0de0: at sys___stat50+0x24
 0x100e0ea0: at syscall+0x300
 0x100e0f20: user SC trap #439 by 0xfdf4c5a4: srr1=0xd032
 Â Â Â Â Â Â Â Â Â Â Â Â r1=0xffffe570 cr=0x44822488 xer=0x20000000 ctr=0xfdf4c59c
 
 Another invocation of pkgclean resulted in a kernel panic with a trace
 quite similar to the original one I reported, except in between
 ufs_lookup() and panic(), there's a call to ufs_dirbad().
 
 I should also mention, WAPBL logging is not enabled on the machine,
 and I haven't encountered any ICEs that would suggest bad RAM when
 compiling packages from pkgsrc. (The hard drive is original to the
 machine, though, and could be suspect, I suppose.)
 
 Dave