Re: panic: kernel diagnostic assertion "next != _PSLIST_POISON"

2017-03-14 Thread Masanobu SAITOH

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

Jaromir


 It 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 0x80215455 cs 0x8 rflags 0x246 cr2 
0x75db2c768548 ilevel 0 rsp 0xfe812099eaf0
curlwp 0xfe847b7ba0a0 pid 30.1 lowest kstack 0xfe812099b2c0
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 panic


I'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 :

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...

Frank



Yesterday 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 0x80215455 cs 0x8 rflags 0x246 cr2
0x770e1f2ae190 ilevel 0 rsp 0xfe8120956b00
curlwp 0xfe847b8820a0 pid 30.1 lowest kstack 0xfe81209532c0
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 

Re: panic: kernel diagnostic assertion "next != _PSLIST_POISON"

2017-03-14 Thread Masanobu SAITOH

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

Jaromir


 It 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 0x80215455 cs 0x8 rflags 0x246 cr2 
0x75db2c768548 ilevel 0 rsp 0xfe812099eaf0
curlwp 0xfe847b7ba0a0 pid 30.1 lowest kstack 0xfe812099b2c0
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 panic


I've noticed that only log option doesn't cause panic.
If both log and async is set, it panics.



2017-03-14 9:04 GMT+01:00 Frank Kardel :

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...

Frank



Yesterday 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 0x80215455 cs 0x8 rflags 0x246 cr2
0x770e1f2ae190 ilevel 0 rsp 0xfe8120956b00
curlwp 0xfe847b8820a0 pid 30.1 lowest kstack 0xfe81209532c0
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 (msai...@execsw.org
 

Re: panic: kernel diagnostic assertion "next != _PSLIST_POISON"

2017-03-14 Thread Jaromír Doleček
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

Jaromir

2017-03-14 9:04 GMT+01:00 Frank Kardel :
> 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...
>>>
>>> Frank
>>
>>
>> Yesterday 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 0x80215455 cs 0x8 rflags 0x246 cr2
 0x770e1f2ae190 ilevel 0 rsp 0xfe8120956b00
 curlwp 0xfe847b8820a0 pid 30.1 lowest kstack 0xfe81209532c0
 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()
>>
>


Automated report: NetBSD-current/i386 build failure

2017-03-14 Thread NetBSD Test Fixture
This is an automatically generated notice of a NetBSD-current/i386
build failure.

The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2017.03.14.09.04.16.

An extract from the build.sh output follows:

--- murmurhash.o ---
#   compile  kern/murmurhash.o
/tmp/bracket/build/2017.03.14.09.04.16-i386/tools/bin/i486--netbsdelf-gcc 
-Wall -Wmissing-prototypes -Wstrict-prototypes -Os -ffreestanding 
-fomit-frame-pointer -fno-unwind-tables  -fno-asynchronous-unwind-tables 
-fno-exceptions   -std=gnu99   -Werror  -march=i386 -mtune=i386  
--sysroot=/tmp/bracket/build/2017.03.14.09.04.16-i386/destdir 
-I/tmp/bracket/build/2017.03.14.09.04.16-i386/src/sys/arch/i386/stand/bootxx/bootxx_ext2fs/../../../../../lib/libkern/arch/i386
 --sysroot=/tmp/bracket/build/2017.03.14.09.04.16-i386/destdir -DBOOTXX -I 
/tmp/bracket/build/2017.03.14.09.04.16-i386/src/sys/arch/i386/stand/bootxx/bootxx_ext2fs/../../lib
 -I 
/tmp/bracket/build/2017.03.14.09.04.16-i386/obj/sys/arch/i386/stand/bootxx/bootxx_ext2fs
 -DBOOTXX_SECTORS=15 -DPRIMARY_LOAD_ADDRESS=0x1000 
-DSECONDARY_LOAD_ADDRESS=0x1 -DXXfs_open=ext2fs_open 
-DXXfs_close=ext2fs_close -DXXfs_read=ext2fs_read -DXXfs_stat=ext2fs_stat 
-DFS=ext2fs -DNO_LBA_CHECK -DEPIA_HACK -nostdinc -D_STANDALONE -I/tmp/bracket/bu
 
ild/2017.03.14.09.04.16-i386/src/sys/arch/i386/stand/bootxx/bootxx_ext2fs/../../../../..
 -DLIBSA_SINGLE_FILESYSTEM=xxfs -DLIBSA_NO_TWIDDLE -DLIBSA_NO_FD_CHECKING 
-DLIBSA_NO_RAW_ACCESS -DLIBSA_NO_FS_WRITE -DLIBSA_NO_FS_SEEK 
-DLIBSA_SINGLE_DEVICE=blkdev -DLIBKERN_OPTIMISE_SPACE 
-D"blkdevioctl(x,y,z)=EINVAL" -D"blkdevclose(f)=0" 
-D"devopen(f,n,fl)=(*(fl)=(void *)n,0)" -DLIBSA_NO_DISKLABEL_MSGS 
-I/tmp/bracket/build/2017.03.14.09.04.16-i386/src/sys/arch/i386/stand/bootxx/bootxx_ext2fs/../../../../../lib/libkern/../../../common/lib/libc/quad
 
-I/tmp/bracket/build/2017.03.14.09.04.16-i386/src/sys/arch/i386/stand/bootxx/bootxx_ext2fs/../../../../../lib/libkern/../../../common/lib/libc/string
 
-I/tmp/bracket/build/2017.03.14.09.04.16-i386/src/sys/arch/i386/stand/bootxx/bootxx_ext2fs/../../../../../lib/libkern/../../../common/lib/libc/arch/i386/string
  
-I/tmp/bracket/build/2017.03.14.09.04.16-i386/src/sys/arch/i386/stand/bootxx/bootxx_ext2fs/../../../../../lib/libkern/../../../common/lib/libc/q
 uad -I/tmp/bracket/build/2017.03.14.09.04.16-i386/src/sys--- 
dependall-usr.sbin ---
/tmp/bracket/build/2017.03.14.09.04.16-i386/destdir/usr/lib/librumpnet.so: 
undefined reference to `rumpns_if_acquire'
/tmp/bracket/build/2017.03.14.09.04.16-i386/destdir/usr/lib/librumpnet.so: 
undefined reference to `rumpns_if_put'
collect2: error: ld returned 1 exit status
*** [rump_nfs] Error code 1
nbmake[8]: stopped in 
/tmp/bracket/build/2017.03.14.09.04.16-i386/src/usr.sbin/puffs/rump_nfs
--- dependall-sys ---

The following commits were made between the last successful build and
the failed build:

2017.03.14.08.09.31 msaitoh src/sys/dev/pci/pci_subr.c,v 1.163
2017.03.14.08.11.09 ozaki-r src/sys/net/rtsock.c,v 1.205
2017.03.14.08.20.11 msaitoh src/sys/dev/pci/pci_subr.c,v 1.164
2017.03.14.08.20.11 msaitoh src/sys/dev/pci/pcireg.h,v 1.122
2017.03.14.08.25.35 msaitoh src/sys/dev/pci/pci_subr.c,v 1.165
2017.03.14.08.27.13 msaitoh src/sys/dev/pci/pci_subr.c,v 1.166
2017.03.14.08.35.55 ozaki-r src/sys/net/rtsock.c,v 1.206
2017.03.14.09.03.08 ozaki-r src/sys/altq/altq_subr.c,v 1.33
2017.03.14.09.03.08 ozaki-r src/sys/compat/common/uipc_syscalls_40.c,v 1.13
2017.03.14.09.03.08 ozaki-r src/sys/compat/linux/common/linux_socket.c,v 
1.138
2017.03.14.09.03.08 ozaki-r 
src/sys/compat/linux32/common/linux32_socket.c,v 1.27
2017.03.14.09.03.08 ozaki-r src/sys/dist/pf/net/pf_if.c,v 1.33
2017.03.14.09.03.08 ozaki-r src/sys/kern/uipc_mbuf.c,v 1.171
2017.03.14.09.03.08 ozaki-r src/sys/net/if.c,v 1.385
2017.03.14.09.03.08 ozaki-r src/sys/net/if.h,v 1.236
2017.03.14.09.03.08 ozaki-r src/sys/net/rtsock.c,v 1.207
2017.03.14.09.03.08 ozaki-r src/sys/netinet/ip_carp.c,v 1.86
2017.03.14.09.03.09 ozaki-r src/sys/rump/librump/rumpnet/net_stub.c,v 1.25
2017.03.14.09.04.16 ozaki-r src/sys/sys/param.h,v 1.533

Log files can be found at:


http://releng.NetBSD.org/b5reports/i386/commits-2017.03.html#2017.03.14.09.04.16


Re: panic: kernel diagnostic assertion "next != _PSLIST_POISON"

2017-03-14 Thread Frank Kardel

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...

Frank


Yesterday 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 0x80215455 cs 0x8 rflags 0x246 cr2 
0x770e1f2ae190 ilevel 0 rsp 0xfe8120956b00

curlwp 0xfe847b8820a0 pid 30.1 lowest kstack 0xfe81209532c0
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()





Re: panic: kernel diagnostic assertion "next != _PSLIST_POISON"

2017-03-14 Thread Masanobu SAITOH

On 2017/03/14 17:15, Ryota Ozaki wrote:

Hi,

On Tue, Mar 14, 2017 at 4:36 PM, 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...


I committed a possible fix. Could you update your kernel and see
if the panic is fixed?

Thanks,
  ozaki-r


 For me, it still panics. Trace is the same as before:


Starting root file system check:
/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 0x80215455 cs 0x8 rflags 0x246 cr2 
0x7caa0deae190 ilevel 0 rsp 0xfe8120997b00
curlwp 0xfe847b8180a0 pid 30.1 lowest kstack 0xfe81209942c0
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+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) ---
7caa0de8989a:
db{0}>




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)


Re: panic: kernel diagnostic assertion "next != _PSLIST_POISON"

2017-03-14 Thread Masanobu SAITOH

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...

Frank


Yesterday 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 0x80215455 cs 0x8 rflags 0x246 cr2 
0x770e1f2ae190 ilevel 0 rsp 0xfe8120956b00
curlwp 0xfe847b8820a0 pid 30.1 lowest kstack 0xfe81209532c0
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 (msai...@execsw.org
 msai...@netbsd.org)