kern/78112: vlan panic due to not initialising parent interface

Gavin Atkinson gavin.atkinson at ury.york.ac.uk
Sat Feb 26 12:00:37 GMT 2005


>Number:         78112
>Category:       kern
>Synopsis:       vlan panic due to not initialising parent interface
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Feb 26 12:00:35 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator:     Gavin Atkinson
>Release:        FreeBSD 5.3-STABLE i386
>Organization:
>Environment:
System: FreeBSD buffy.york.ac.uk 5.3-STABLE FreeBSD 5.3-STABLE #0: Sat Feb 12 20:42:16 GMT 2005 root at buffy.york.ac.uk:/usr/obj/usr/src/sys/BUFFY i386

>Description:

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.

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
lock order reversal
 1st 0xc15f6268 fxp0 (network driver) @ /usr/src/sys/dev/fxp/if_fxp.c:2389
 2nd 0xc14c7ad0 user map (user map) @ /usr/src/sys/vm/vm_map.c:2998
KDB: stack backtrace:
kdb_backtrace(0,ffffffff,c08f7ae0,c08f8a08,c08852ac) at kdb_backtrace+0x29
witness_checkorder(c14c7ad0,9,c083d2a9,bb6) at witness_checkorder+0x54c
_sx_xlock(c14c7ad0,c083d2a9,bb6) at _sx_xlock+0x50
_vm_map_lock_read(c14c7a8c,c083d2a9,bb6,2000046,c1595458) at
_vm_map_lock_read+0x37
vm_map_lookup(cbdf3804,0,2,cbdf3808,cbdf37f8) at vm_map_lookup+0x28
vm_fault(c14c7a8c,0,2,8,c1594450) at vm_fault+0x66
trap_pfault(cbdf38cc,0,0) at trap_pfault+0xf2
trap(c15f0018,cbdf0010,c0630010,c15f6000,c15f6000) at trap+0x335
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc051e966, esp = 0xcbdf390c, ebp = 0xcbdf3918 ---
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 ---


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 have been 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?

I'm also pretty sure that this is not confined only to the fxp driver.

>How-To-Repeat:

Reboot to single user mode and run the following commands:

# ifconfig vlan0 create
# ifconfig vlan0 vlan 123 vlandev fxp0
# ifconfig vlan0 inet 1.2.3.4

>Fix:

Unknown.  Presumably we need to call fxp_init at some point before the
vlan code tries to use the interface, but where this should be called
from and by who I don't know.

>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-bugs mailing list