NetBSD Problem Report #51930

From hf@spg.tu-darmstadt.de  Tue Jan 31 10:33:08 2017
Return-Path: <hf@spg.tu-darmstadt.de>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id A3D5A7A169
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 31 Jan 2017 10:33:08 +0000 (UTC)
Message-Id: <201701311032.v0VAWxnu001411@Vertatscha.nt.e-technik.tu-darmstadt.de>
Date: Tue, 31 Jan 2017 11:32:59 +0100 (CET)
From: Hauke Fath <hf@spg.tu-darmstadt.de>
Reply-To: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@NetBSD.org
Cc: Hauke Fath <hf@spg.tu-darmstadt.de>
Subject: LOCKDEBUG kernel panics configuring carp(4) interface 
X-Send-Pr-Version: 3.95

>Number:         51930
>Category:       kern
>Synopsis:       LOCKDEBUG kernel panics configuring carp(4) interface
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jan 31 10:35:00 +0000 2017
>Last-Modified:  Wed Feb 01 11:55:00 +0000 2017
>Originator:     Hauke Fath
>Release:        NetBSD 7.1_RC1
>Organization:
Technische Universitaet Darmstadt
>Environment:


System: NetBSD Vertatscha 7.1_RC1 NetBSD 7.1_RC1 (FIFI-$Revision$) #0: Mon Jan 30 13:58:28 CET 2017 hf@Hochstuhl:/var/obj/netbsd-builds/7/amd64/sys/arch/amd64/compile/FIFI amd64
Architecture: x86_64
Machine: amd64
>Description:

	A LOCKDEBUG kernel run on one of a pair of carp(4) routers
	panics while configuring the first carp(4) interface on a
	physical nic:

[...]
net.inet.carp.preempt: 0 -> 1
net.inet.carp.log: 0 -> 2
wm0: link state DOWN (was UNKNOWN)
Starting network.
Hostname: [redacted]
IPv6 mode: router
Configuring network interfaces: wm0 ixg0 wm4wm4: link state DOWN (was UNKNOWN)
 vlan2 vlan3 vlan7 vlan8 vlan9 vlan10 vlan11 vlan12 carp0 carp2carp2: state transition from: INIT -> to: BACKUP
 carp3carp3: state transition from: INIT -> to: BACKUP
 carp7carp7: state transition from: INIT -> to: BACKUP
 carp8carp8: state transition from: INIT -> to: BACKUP
 carp9carp9: state transition from: INIT -> to: BACKUP
ixg0: link state DOWN (was UP)
 carp10carp10: state transition from: INIT -> to: BACKUP
 carp11carp11: state transition from: INIT -> to: BACKUP
 carp12carp12: state transition from: INIT -> to: BACKUP
 pfsync0.
Adding interface aliases:.
add net default: gateway [redacted]
Waiting for DAD completion for statically configured addresses...
wm0: link state UP (was DOWN)
carp0: state transition from: INIT -> to: BACKUP
Mutex error: lockdebug_wantlock: acquiring sleep lock from interrupt context

lock address : 0xffffffff807d2e50 type     :     sleep/adaptive
initialized  : 0xffffffff803a8bb0
shared holds :                  0 exclusive:                  0
shares wanted:                  0 exclusive:                  0
current cpu  :                  0 last held:                  3
current lwp  : 0xfffffe821e728840 last held: 000000000000000000
last locked  : 0xffffffff803a907a unlocked*: 0xffffffff803a91c6
owner field  : 000000000000000000 wait/spin:                0/0

Turnstile chain at 0xffffffff807665a0.
=> No active turnstile for this lock.

panic: LOCKDEBUG: Mutex error: lockdebug_wantlock: acquiring sleep lock from interrupt context
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x13c
snprintf() at netbsd:snprintf
lockdebug_more() at netbsd:lockdebug_more
mutex_enter() at netbsd:mutex_enter+0x43f
pool_put())))) at netbsd:pool_put+0x33
in6_ifloop_request() at netbsd:in6_ifloop_request+0x160
carp_setroute() at netbsd:carp_setroute+0x51
carp_setrun() at netbsd:carp_setrun+0xfe
carp_carpdev_state() at netbsd:carp_carpdev_state+0xcd
if_link_state_change() at netbsd:if_link_state_change+0x9c
mii_phy_update() at netbsd:mii_phy_update+0x74
igphy_service() at netbsd:igphy_service+0x5b
mii_pollstat() at netbsd:mii_pollstat+0x49
wm_intr() at netbsd:wm_intr+0x659
intr_biglock_wrapper() at netbsd:intr_biglock_wrapper+0x19
Xintr_ioapic_level2() at netbsd:Xintr_ioapic_level2+0xf2
--- interrupt ---
x86_mwait() at netbsd:x86_mwait+0xd
acpicpu_cstate_idle_enter() at netbsd:acpicpu_cstate_idle_enter+0xc2
acpicpu_cstate_idle() at netbsd:acpi^@cpu_cstate_idle+0xb6
idle_loop() at netbsd:idle_loop+0x18c
cpu0: End traceback...
rebooting...


>How-To-Repeat:

	Set up a pair of netbsd-7 machines as redundant carp(4)
	router, boot a LOCKDEBUG kernel.


>Fix:
	No idea.



>Audit-Trail:
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@NetBSD.org
Subject: Re: kern/51930: LOCKDEBUG kernel panics configuring carp(4)
 interface 
Date: Wed, 1 Feb 2017 12:40:49 +0100

 A non-LOCKDEBUG kernel of the same vintage on this router pair will 
 stop routing a few hours after booting. No log messages. A reboot 
 "fixes" the problem for a while. The previous mid-November kernel did 
 not exhibit this "feature".

 Does anybody seriously use carp(4) on NetBSD?

 hauke

>Unformatted:

Home	PR Database Search