On 2017/03/15 14:11, Masanobu SAITOH wrote:
On 2017/03/15 0:30, Jaromír Doleček wrote:Yes, this panic is already fixed in -current: panic: kernel diagnostic assertion "!(bp->b_oflags & BO_DELWRI)" failed: file "../../../../kern/vfs_wapbl.c", line 1142 JaromirIt still panics for me. New output with two printf()s:boot device: wd0 root on wd0a dumps on wd0b root file system type: ffs kern.module.path=/stand/amd64/7.99.66/modules Wed Mar 15 14:05:38 JST 2017 Starting root file system check: /dev/rwd0a: file system is clean; not checking ffs_mount: path "/" flags 0x6015040 ffs_wapbl_start: sbupdate panic: kernel diagnostic assertion "!(bp->b_oflags & BO_DELWRI)" failed: file "../../../../kern/vfs_wapbl.c", line 1142 fatal breakpoint trap in supervisor mode trap type 1 code 0 rip 0xffffffff80215455 cs 0x8 rflags 0x246 cr2 0x75db2c768548 ilevel 0 rsp 0xfffffe812099eaf0 curlwp 0xfffffe847b7ba0a0 pid 30.1 lowest kstack 0xfffffe812099b2c0 Stopped in pid 30.1 (mount_ffs) at netbsd:breakpoint+0x5: leave db{0}> trace breakpoint() at netbsd:breakpoint+0x5 vpanic() at netbsd:vpanic+0x140 ch_voltag_convert_in() at netbsd:ch_voltag_convert_in wapbl_add_buf() at netbsd:wapbl_add_buf+0x134 bdwrite() at netbsd:bdwrite+0xbd bwrite() at netbsd:bwrite+0x95 ffs_sbupdate() at netbsd:ffs_sbupdate+0x1b9 ffs_wapbl_start() at netbsd:ffs_wapbl_start+0x188 ffs_mount() at netbsd:ffs_mount+0x50a VFS_MOUNT() at netbsd:VFS_MOUNT+0x34 do_sys_mount() at netbsd:do_sys_mount+0x5ee sys___mount50() at netbsd:sys___mount50+0x33 syscall() at netbsd:syscall+0x1ed --- syscall (number 410) --- 7938d028989a: db{0}>And,Please attach your /etc/fstab.My root filesystem has both log and async option./dev/wd0a / ffs rw,async,noatime 1 1 <==== don't panic #/dev/wd0a / ffs rw,log,async,noatime 1 1 <==== do panicI've noticed that only log option doesn't cause panic. If both log and async is set, it panics.
mount(8) says:
log (FFS only) Mount the file system with wapbl(4) meta-
data journaling, also known simply as logging. It
provides rapid metadata updates and eliminates the
need to check file system consistency after a system
outage. A file system mounted with log can not be
mounted with async.
Isn't it checked when mounting?
2017-03-14 9:04 GMT+01:00 Frank Kardel <kardel%netbsd.org@localhost>:Hmm, I think ch_voltag_convert_in() is a red herring, Both panics contextually match the higher parts of the stack traces. So I would disregard the ch_voltag_convert_in() part here and conclude it is two distinct panics. One relates to psref corruption in network code and the other to wapbl and possibly recent mount update (-u) changes, Other ideas ? Frank On 03/14/17 08:56, Masanobu SAITOH wrote:Hi. On 2017/03/14 16:36, Frank Kardel wrote:Has anyone seen this panic recently? Seen in -current-20170311, i386, Soekris 6501. panic: kernel diagnostic assertion "next != _PSLIST_POISON" failed: file "/fs/raid2a/src/NetBSD/cur/src/sys/sys/pslist.h", line 270 cpu0: Begin traceback... vpanic(c0cb1784,dba43dac,dba43e2c,c09e0d1e,c0cb1784,c0cb16d3,c0cb681b,c0cb6458,10e,a8) at netbsd:vpanic+0x121 ch_voltag_convert_in(c0cb1784,c0cb16d3,c0cb681b,c0cb6458,10e,a8,0,c3d70578,c09e0988,c3d70348) at netbsd:ch_voltag_convert_in sysctl_iflist(4,cbd8cf60,c7,cbd8cff9,c33c06c0,c7,c090f986,0,cbd8cf60,a43e90) at c09e0d1e sysctl_rtable(dba43f0c,3,afe01000,dba43efc,0,0,dba43f00,c3de1560,c3c11c0c,3) at c09e129c sysctl_dispatch(dba43f00,6,afe01000,dba43efc,0,0,dba43f00,c3de1560,c3c11c0c,dba43efc) at netbsd:sysctl_dispatch+0xbd sys___sysctl(c3de1560,dba43f68,dba43f60,7dd51000,c3de1560,dba43f60,dba43f68,0,0,b0094fb0) at netbsd:sys___sysctl+0xe3 syscall() at netbsd:syscall+0x257 --- syscall (number 202) --- b00736f7: cpu0: End traceback... FrankYesterday I sent the following mail to current-users@ but it haven't delivered yet...I updated my machine's kernel which was made from 1 hour ago's -current source. It paniced. It's reproducible./dev/rwd0a: file system is clean; not checking panic: kernel diagnostic assertion "!(bp->b_oflags & BO_DELWRI)" failed: file "../../../../kern/vfs_wapbl.c", line 1142 fatal breakpoint trap in supervisor mode trap type 1 code 0 rip 0xffffffff80215455 cs 0x8 rflags 0x246 cr2 0x770e1f2ae190 ilevel 0 rsp 0xfffffe8120956b00 curlwp 0xfffffe847b8820a0 pid 30.1 lowest kstack 0xfffffe81209532c0 Stopped in pid 30.1 (mount_ffs) at netbsd:breakpoint+0x5: leave db{15}> trace breakpoint() at netbsd:breakpoint+0x5 vpanic() at netbsd:vpanic+0x140 ch_voltag_convert_in() at netbsd:ch_voltag_convert_in wapbl_add_buf() at netbsd:wapbl_add_buf+0x133 bdwrite() at netbsd:bdwrite+0xbd bwrite() at netbsd:bwrite+0x95 ffs_sbupdate() at netbsd:ffs_sbupdate+0x1b9 ffs_wapbl_start() at netbsd:ffs_wapbl_start+0x177 ffs_mount() at netbsd:ffs_mount+0x4e9 VFS_MOUNT() at netbsd:VFS_MOUNT+0x34 do_sys_mount() at netbsd:do_sys_mount+0x5ee sys___mount50() at netbsd:sys___mount50+0x33 syscall() at netbsd:syscall+0x1ed --- syscall (number 410) --- 770e1f28989a: db{15}>At least five days ago's kernel worked without this proble,Both panics include ch_voltag_convert_in()
--
-----------------------------------------------
SAITOH Masanobu (msaitoh%execsw.org@localhost
msaitoh%netbsd.org@localhost)