NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/52587: NetBSD 8 panic after a few days of uptime

The following reply was made to PR kern/52587; it has been noted by GNATS.

From: Ryota Ozaki <>
Cc: "" <>,,,
Subject: Re: kern/52587: NetBSD 8 panic after a few days of uptime
Date: Mon, 2 Oct 2017 17:01:07 +0900

 On Sun, Oct 1, 2017 at 7:25 PM,  <> wrote:
 >>Number:         52587
 >>Category:       kern
 >>Synopsis:       NetBSD 8 panic after a few days of uptime
 >>Confidential:   no
 >>Severity:       serious
 >>Priority:       medium
 >>Responsible:    kern-bug-people
 >>State:          open
 >>Class:          sw-bug
 >>Submitter-Id:   net
 >>Arrival-Date:   Sun Oct 01 10:25:01 +0000 2017
 >>Originator:     Dominik Bialy
 >>Release:        NetBSD 8.0_BETA
 > Underlegend Networks
 > System: NetBSD yenn 8.0_BETA NetBSD 8.0_BETA (YENN) #0: Fri Sep 15 12:57:31 UTC 2017 builds@yenn:/var/obj/sys/arch/amd64/compile/YENN amd64
 > Architecture: x86_64
 > Machine: amd64
 >         After a few days of uptime the server paniced.
 > panic: kernel diagnostic assertion "(psref->psref_cpu == curcpu())" failed: file "/usr/src/sys/kern/subr_psref.c", line 296 passive reference transferred from CPU 1 to CPU 0
 > cpu0: Begin traceback...
 > vpanic() at netbsd:vpanic+0x140
 > ch_voltag_convert_in() at netbsd:ch_voltag_convert_in
 > psref_release() at netbsd:psref_release+0x1ee
 > bridge_input() at netbsd:bridge_input+0x8a3
 > tap_dev_write.isra.7() at netbsd:tap_dev_write.isra.7+0x12d
 > cdev_write() at netbsd:cdev_write+0x70
 > spec_write() at netbsd:spec_write+0xb2
 > VOP_WRITE() at netbsd:VOP_WRITE+0x37
 > vn_write() at netbsd:vn_write+0xec
 > dofilewrite() at netbsd:dofilewrite+0x97
 > sys_write() at netbsd:sys_write+0x5f
 > syscall() at netbsd:syscall+0x1d8
 > --- syscall (number 4) ---
 > 71835583dfda:
 > cpu0: End traceback...
 >         There is OpenVPN/tap set up on the server, if this matters.  The CPU is AMD Athlon 64 X2.
 >         Don't know...
 >         None known... Maybe disabling second core would be a workaround.
 I fixed the issue in -current and requested a pullup to -8 branch.
 So 8.0_BETA will soon fix the issue. If you want the fix right now,
 please apply r1.135 of src/sys/net/if_bridge.c to your kernel by hand.
 Thank you for the report,

Home | Main Index | Thread Index | Old Index