From owner-freebsd-current@FreeBSD.ORG Tue Feb 8 19:22:18 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 346E616A4CE for ; Tue, 8 Feb 2005 19:22:18 +0000 (GMT) Received: from mail21.sea5.speakeasy.net (mail21.sea5.speakeasy.net [69.17.117.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA2D843D1D for ; Tue, 8 Feb 2005 19:22:17 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 15892 invoked from network); 8 Feb 2005 19:22:17 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 8 Feb 2005 19:22:16 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j18JM9tw096010; Tue, 8 Feb 2005 14:22:10 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Tue, 8 Feb 2005 14:23:11 -0500 User-Agent: KMail/1.6.2 References: <1107887237.793.26.camel@buffy.york.ac.uk> <20050208110426.H2666@carver.gumbysoft.com> In-Reply-To: <20050208110426.H2666@carver.gumbysoft.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200502081423.11915.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx Subject: Re: fxp0 and vlan panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2005 19:22:18 -0000 On Tuesday 08 February 2005 02:06 pm, Doug White wrote: > On Tue, 8 Feb 2005, Gavin Atkinson wrote: > > Hey, > > > > There's an easily reproduceable panic involving configuring vlans on fxp > > cards. I've recreated it in single user mode on a top-of-tree -CURRENT > > machine as well as on a 5.3-STABLE machine. > > This is a WITNESS warning, not a panic. Unless you have witness panics > enabled, which is strongly not recommended unless you're actively > debugging the issue. Umm, it's a panic, too. This warning now gets triggered by witness when we get a page fault while holding a lock. I've thought about just forcing all such page faults to be fatal via a patch like this to avoid the spurious LOR: Index: trap.c =================================================================== RCS file: /usr/cvs/src/sys/i386/i386/trap.c,v retrieving revision 1.270 diff -u -r1.270 trap.c --- trap.c 16 Nov 2004 20:42:31 -0000 1.270 +++ trap.c 19 Jan 2005 22:44:18 -0000 @@ -238,7 +238,7 @@ * to the debugger. */ eva = rcr2(); - if (td->td_critnest == 0) + if (td->td_critnest == 0 && td->td_sleeplocks == NULL) enable_intr(); else trap_fatal(&frame, eva); > > Enter full pathname of shell or RETURN for /bin/sh: > > # ifconfig vlan0 create > > # ifconfig vlan0 vlan 123 vlandev fxp0 > > # ifconfig vlan0 inet 1.2.3.4 > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0x0 > > fault code = supervisor write, page not present > > instruction pointer = 0x8:0xc051e966 > > stack pointer = 0x10:0xcbdf390c > > frame pointer = 0x10:0xcbdf3918 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, def32 1, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 56 (ifconfig) > > [thread pid 56 tid 100043 ] > > Stopped at fxp_mc_setup+0x62: movw $0,0(%eax) > > db> > > db> tr > > Tracing pid 56 tid 100043 td 0xc1594450 > > fxp_mc_setup(c15f6000) at fxp_mc_setup+0x62 > > fxp_ioctl(c15f6000,80206931,0) at fxp_ioctl+0x112 > > if_addmulti(c15f6000,cbdf3980,cbdf397c,c1667d48,cbdf3988) at > > if_addmulti+0x223 vlan_setmulti(c1667c40,cbdf39fc,c060a5d5,c088cd80,40) > > at vlan_setmulti+0x139 vlan_ioctl(c1733800,80206931,0) at vlan_ioctl+0x3e > > if_addmulti(c1733800,cbdf3a4c,cbdf3a48,cbdf3a4c,1c) at if_addmulti+0x223 > > in6_addmulti(cbdf3a9c,c1733800,cbdf3a94) at in6_addmulti+0x4c > > in6_update_ifa(c1733800,cbdf3b9c,0) at in6_update_ifa+0x4ce > > in6_ifattach_linklocal(c1733800,0) at in6_ifattach_linklocal+0xe5 > > in6_ifattach(c1733800,0,8040691a,8040691a,0) at in6_ifattach+0xa9 > > in6_if_up(c1733800) at in6_if_up+0x13 > > ifioctl(c173da60,8040691a,c1667dc0,c1594450,0) at ifioctl+0x1f8 > > soo_ioctl(c1724708,8040691a,c1667dc0,c14b9780,c1594450) at > > soo_ioctl+0x2db ioctl(c1594450,cbdf3d14,3,2,282) at ioctl+0x370 > > syscall(2f,2f,2f,80543a0,1) at syscall+0x213 > > Xint0x80_syscall() at Xint0x80_syscall+0x1f > > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x280c44f3, esp = > > 0xbfbfe5cc, ebp = 0xbfbfee18 --- > > > > fxp_mc_setup+0x62 seems to correspond to the following code in > > sys/dev/fxp/if_fxp.c: (line 2554) > > > > > > /* > > * Add a NOP command with interrupt so that we are > > notified * when all TX commands have been processed. > > */ > > txp = sc->fxp_desc.tx_last->tx_next; > > txp->tx_mbuf = NULL; > > --> txp->tx_cb->cb_status = 0; > > txp->tx_cb->cb_command = htole16(FXP_CB_COMMAND_NOP | > > FXP_CB_COMMAND_S | FXP_CB_COMMAND_I); > > > > txp->tx_cb is NULL at this point. This seems to be because fxp_init() > > has never been called. (both validated by instrumenting the code in > > question) > > > > Note also that the panic does not seem to occur if you do anything with > > fxp0 before doing something with the vlans. For example, assigning it > > an address, or even just bringing it up seems to prevent the panic. > > > > In this situation, where should fxp_init be called from? Presumably > > it's not the responsibility of the vlan code - as when it gets called we > > could already be using the interface and reinitialising it wouldn't be a > > nice thing to do. But then, what should be initialising it? > > > > And as an aside, is the detour via inet6 correct for what is entirely > > inet4? Good analysis, but I don't have any answers for you. :( Try bugging rwatson@ maybe? :-) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org