Subject: Re: FFS related panic
To: None <current-users@netbsd.org>
From: Jukka Salmi <j+nbsd@2004.salmi.ch>
List: current-users
Date: 12/16/2004 23:15:49
Hmm, FFS is not to blame here... one of the recent NFS related changes
(commited by yamt@ on 2004/12/14, [1] and [2]) causes the panic. I'll
send a PR about this.
Cheers, Jukka
[1] http://mail-index.netbsd.org/source-changes/2004/12/14/0012.html
[2] http://mail-index.netbsd.org/source-changes/2004/12/14/0013.html
Jukka Salmi --> current-users (2004-12-16 02:13:36 +0100):
> Hi,
>
> using current sources on i386 I get filesystem related panics with a
> newly created FFS on a compact flash card. This happens on a netbooted
> Soekris net4501, no matter whether it's running a GENERIC or a NET4501
> kernel. This definitely did not happen with -current when I tried last
> (about a month ago), and it does not happen when running a netbsd-2-0
> kernel.
>
> Some examples (/mnt/cf is the 4.2BSD fs on the CF; the remaining
> filesystems are mounted via NFS):
>
> # cp -p /usr/mdec/boot /mnt/cf
> # panic: genfs: bad op
> Stopped in pid 8.1 (ioflush) at netbsd:cpu_Debugger+0x4: popl %ebp
> db> tr
> cpu_Debugger(c057f754,c056e600,c2e30e00,c36f3e54,c01f217e) at netbsd:cpu_Debugger+0x4
> panic(c028d5fa,c36f3e68,c01f0cdc,c36f3e60,c0269cc0) at netbsd:panic+0xa9
> genfs_nullop(c36f3e60,c0269cc0,c057f754,c36f3e8c,c0194e9e) at netbsd:genfs_nullop
> VOP_BWRITE(c057f754,c056e000,0,0,0) at netbsd:VOP_BWRITE+0x24
> ffs_sbupdate(c0538000,3,c01f12ca,c36f3ea4,c056e000) at netbsd:ffs_sbupdate+0xad
> ffs_cgupdate(c0538000,3,0,0,0) at netbsd:ffs_cgupdate+0x24
> ffs_sync(c0580000,3,c2e1e000,c36cbb28,c0580000) at netbsd:ffs_sync+0x1bb
> sync_fsync(c36f3f20,c026a100,c390e204,c2e1e000,8) at netbsd:sync_fsync+0x80
> VOP_FSYNC(c390e204,c2e1e000,8,0,0) at netbsd:VOP_FSYNC+0x4c
> sched_sync(c36d439c,334000,33b000,0,c0100321) at netbsd:sched_sync+0xe5
> db>
>
> one restart later:
>
> # umount /mnt/cf
> panic: genfs: bad op
> Stopped in pid 433.1 (umount) at netbsd:cpu_Debugger+0x4: popl %ebp
> db> tr
> cpu_Debugger(c0580cac,0,c376d3f4,c370cddc,c01f217e) at netbsd:cpu_Debugger+0x4
> panic(c028d5fa,c370cdf0,c01f0cdc,c370cde8,c0269cc0) at netbsd:panic+0xa9
> genfs_nullop(c370cde8,c0269cc0,c0580cac,c370ce0c,c01e88ab) at netbsd:genfs_nullop
> VOP_BWRITE(c0580cac,1,0,0,c0583000) at netbsd:VOP_BWRITE+0x24
> vflushbuf(c376d3f4,1,c370ce58,c01f107e,c370ce28) at netbsd:vflushbuf+0xb0
> spec_fsync(c370ce28,c026a100,c376d3f4,c2e1e0fc,1) at netbsd:spec_fsync+0x1c
> VOP_FSYNC(c376d3f4,c2e1e0fc,1,0,0) at netbsd:VOP_FSYNC+0x4c
> ffs_flushfiles(c0583000,0,c370d004,0,c370d004) at netbsd:ffs_flushfiles+0x81
> ffs_unmount(c0583000,0,c370d004,0,c370cf68) at netbsd:ffs_unmount+0x3a
> dounmount(c0583000,0,c370d004,c370d004,bfbfe6a0) at netbsd:dounmount+0xe3
> sys_unmount(c36d4528,c370cf70,c370cf68,0,0) at netbsd:sys_unmount+0xf2
> syscall_plain() at netbsd:syscall_plain+0x95
> --- syscall (number 22) ---
> 0x4807c78b:
> db>
>
> It seems to be easily reproducible:
>
> # mount /mnt/cf
> # echo test >/mnt/cf/file
> # sync
> panic: genfs: bad op
> Stopped in pid 380.1 (sync) at netbsd:cpu_Debugger+0x4: popl %ebp
> db> tr
> cpu_Debugger(c057f564,0,c36d9000,c38c3e6c,c01f217e) at netbsd:cpu_Debugger+0x4
> panic(c028d5fa,c38c3e80,c01f0cdc,c38c3e78,c0269cc0) at netbsd:panic+0xa9
> genfs_nullop(c38c3e78,c0269cc0,c057f564,c38c3e9c,c01e88ab) at netbsd:genfs_nullop
> VOP_BWRITE(c057f564,0,0,c0538c00,c053a000) at netbsd:VOP_BWRITE+0x24
> vflushbuf(c36d9000,0,c38c3ee8,c01f107e,c38c3eb8) at netbsd:vflushbuf+0xb0
> spec_fsync(c38c3eb8,c026a100,c36d9000,c2e1e0fc,0) at netbsd:spec_fsync+0x1c
> VOP_FSYNC(c36d9000,c2e1e0fc,0,0,0) at netbsd:VOP_FSYNC+0x4c
> ffs_sync(c057e000,2,c2e1e0fc,c370d664,c057e000) at netbsd:ffs_sync+0x16a
> sys_sync(c36d4738,c38c3f70,c38c3f68,0,0) at netbsd:sys_sync+0x8b
> syscall_plain() at netbsd:syscall_plain+0x95
> --- syscall (number 36) ---
> 0x4807b07f:
> db>
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~