fxp0 and vlan panic
John Baldwin
jhb at FreeBSD.org
Tue Feb 8 19:22:18 GMT 2005
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 <jhb at FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
More information about the freebsd-current
mailing list