NetBSD Problem Report #46118

From  Thu Mar  1 10:34:42 2012
Return-Path: <>
Received: from ( [])
	by (Postfix) with ESMTP id 6BED163CAE9
	for <>; Thu,  1 Mar 2012 10:34:42 +0000 (UTC)
Message-Id: <>
Date: Thu,  1 Mar 2012 11:34:42 +0100 (CET)
From: Holger Weiss <>
Subject: pppoe(4) via axe(4) triggers locking-related panic
X-Send-Pr-Version: 3.95

>Number:         46118
>Category:       kern
>Synopsis:       pppoe(4) via axe(4) triggers locking-related panic
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Mar 01 10:35:00 +0000 2012
>Last-Modified:  Sun Jun 02 00:51:03 +0000 2013
>Originator:     Holger Weiss
>Release:        NetBSD 6.0_BETA (2012-02-29)
Individual Network Berlin e.V.
System: NetBSD 6.0_BETA NetBSD 6.0_BETA (GENERIC) #0: Wed Feb 29 17:02:14 CET 2012 amd64
Architecture: x86_64
Machine: amd64
Initiating a pppoe(4) connection using an axe(4) interface quickly
triggers a "KERNEL_LOCKED_P()" assertion failure in sys/dev/usb/usbdi.c:

| panic: kernel diagnostic assertion "KERNEL_LOCKED_P()" failed: file "/src/netbsd/base/sys/dev/usb/usbdi.c", line 264
| cpu0: Begin traceback...
| kern_assert() at netbsd:kern_assert+0x48
| usbd_transfer() at netbsd:usbd_transfer+0x202
| axe_start() at netbsd:axe_start+0x131
| ifq_enqueue() at netbsd:ifq_enqueue+0x9b
| ether_output() at netbsd:ether_output+0x5ad
| pppoe_output() at netbsd:pppoe_output+0x83
| pppoe_start() at netbsd:pppoe_start+0xd4
| sppp_output() at netbsd:sppp_output+0x3fc
| fr_fastroute() at netbsd:fr_fastroute+0x202
| fr_send_ip() at netbsd:fr_send_ip+0x16f
| fr_send_reset() at netbsd:fr_send_reset+0x199
| fr_check() at netbsd:fr_check+0xca0
| fr_check_wrapper() at netbsd:fr_check_wrapper+0x8f
| pfil_run_hooks() at netbsd:pfil_run_hooks+0x9f
| ip_input() at netbsd:ip_input+0x1ab
| ipintr() at netbsd:ipintr+0x112
| softint_dispatch() at netbsd:softint_dispatch+0xe0
| DDB lost frame for netbsd:Xsoftintr+0x4f, trying 0xfffffe810e68ed70
| Xsoftintr() at netbsd:Xsoftintr+0x4f
| --- interrupt ---
| 0:
| cpu0: End traceback...

Using the axe(4) adapter as a normal LAN interface seems to work just
fine on the same system, and so does using pppoe(4) via wm(4).
Initiate a pppoe(4) connection with an axe(4) interface, e.g.:

	ifconfig axe0 up
	ifconfig pppoe0 create
	pppoectl -e axe0 pppoe0
	pppoectl -f /etc/pppoe/configuration pppoe0
	ifconfig pppoe0 up
Unknwon.  Grab the kernel lock at the appropriate place, I guess?


From: Holger =?iso-8859-1?Q?Wei=DF?= <>
Subject: Re: kern/46118
Date: Wed, 21 Mar 2012 17:04:39 +0100

 FWIW, the following patch makes the panic go away for me, but I have no
 idea whether it's correct (i.e., I don't know where in the call chain
 the locking should be handled):

 Index: sys/dev/usb/if_axe.c
 RCS file: /cvsroot/src/sys/dev/usb/if_axe.c,v
 retrieving revision 1.51
 diff -u -r1.51 if_axe.c
 --- sys/dev/usb/if_axe.c	2 Feb 2012 19:43:07 -0000	1.51
 +++ sys/dev/usb/if_axe.c	21 Mar 2012 07:55:10 -0000
 @@ -1134,7 +1134,9 @@

  	/* Transmit */
 +	KERNEL_LOCK(1, curlwp);
  	err = usbd_transfer(c->axe_xfer);
  	if (err != USBD_IN_PROGRESS) {
  		axe_stop(ifp, 0);
  		return EIO;

State-Changed-From-To: open->feedback
State-Changed-When: Fri, 04 Jan 2013 03:43:31 +0000
Are you able to try -current? The multiprocessorizing of usb should
have fixed this.

From: Holger Weiss <>
To: GNATS Bugs <>
Subject: Re: kern/46118 (pppoe(4) via axe(4) triggers locking-related panic)
Date: Fri, 4 Jan 2013 10:12:09 +0100

 > Are you able to try -current? The multiprocessorizing of usb should
 > have fixed this.

 Not right now, sorry.  As far as I'm concerned, feel free to close the
 PR and I'll re-open it if I manage to reproduce the panic after
 upgrading the box to the new code (which would surprise me, too).

From: David Holland <>
Subject: Re: kern/46118: pppoe(4) via axe(4) triggers locking-related panic
Date: Sun, 2 Jun 2013 00:45:02 +0000

 not sent to gnats


 From: Michael van Elst <>
 Subject: Re: kern/46118: pppoe(4) via axe(4) triggers locking-related panic
 Date: Tue, 26 Mar 2013 13:56:01 +0100

 Locking is supposed to occur on a higher layer. Most calls into
 an if_start routine come through ifq_enqueue() which protects
 the if_start routine by aquiring the kernel lock.

 Some code however does not use ifq_enqueue() but calls if_start
 directly, and none if it cares about the kernel lock. In particular:

 - ppp / pppoe
 - sl
 - strip
 - ieee1394
 - bridge
 - vlan

 netipsec and net80211 might have similar problem paths.

                                 Michael van Elst
                                 "A potential Snark may lurk in every tree."

State-Changed-From-To: feedback->open
State-Changed-When: Sun, 02 Jun 2013 00:51:03 +0000
submitter couldn't test my theory/guess


NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD:,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.