Bug #1453

Multiple instances of tap0 and panic when destroying

Added by rumcic about 7 years ago. Updated about 7 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:alexh% Done:


Target version:-


Had a tap0 configured through rc.conf at boot-time, and started a vkernel
with -I tap0:bridge0.
When I did this, I noticed that another tap0 was created (doing "ifconfig"
showed 2 tap0 devices with different MAC addresses), so I did a "ifconfig tap0
destroy" and got a panic.

The kernel.X and vmcore.X are at leaf:~rumko/crash/tap/, sources used from
approximately 13:00 CEST today.

Unread portion of the kernel message buffer:
panic: Bad link elm 0xd2721368 next->prev != elm
mp_lock = 00000001; cpuid = 1
Trace beginning at frame 0xdde4a960
panic(dde4a984,dd4d8300,c39093a0,dd490398,dde4a990) at panic+0x14d
panic(c04088a4,d2721368,dd4d8300,dd4903a4,dde4aaac) at panic+0x14d
eventhandler_deregister(c39093a0,d2721368) at eventhandler_deregister+0x31
pfi_detach_ifnet(dd490398) at pfi_detach_ifnet+0xc0
pfi_detach_ifnet_event(0,dd490398,d2720f30,c0451e20,dd490398) at
if_detach(dd490398,dd490398) at if_detach+0x2b
ether_ifdetach(dd490398,dd490398,0,dd490398,0) at ether_ifdetach+0x2b
tapdestroy(c0453240,dde4ac1c,dde4ab44,c026a88e,dd490398) at tapdestroy+0x66
tap_clone_destroy(dd490398,0,dde4ac1c,dde4ac1c,dde4abc4) at
if_clone_destroy(dde4ac1c,dd4dd000,0,0,dde4aba8) at if_clone_destroy+0x45
ifioctl(dd412e00,80206979,dde4ac1c,dd870288,0) at ifioctl+0x26f
soo_ioctl(dd384ea8,80206979,dde4ac1c,dd870288,dd384ea8) at soo_ioctl+0x13b
mapped_ioctl(3,80206979,80d9900,0,dde4ad34) at mapped_ioctl+0x3e1
sys_ioctl(dde4acf0,6,0,0,d8f84698) at sys_ioctl+0x16
syscall2(dde4ad40) at syscall2+0x265
Xint0x80_syscall() at Xint0x80_syscall+0x36
boot() called on cpu#1
Uptime: 3h38m6s

tap_fix_new.patch Magnifier (797 Bytes) alexh, 08/30/2009 01:02 PM


#1 Updated by alexh about 7 years ago

#2 Updated by rumcic about 7 years ago

With that patch I get a panic immediately when I do "ifconfig tap create" and
when I had cloned_interfaced="tap0 tap1" in rc.conf I got a panic during
booting as well.
Both cores located at leaf:~rumko/crash/tap/

Alex Hornung (via DragonFly issue tracker) wrote:
> Alex Hornung <> added the comment:
> Can you please try the fix at:
> http://leaf.dragonflybsd.org/~alexh/tap_fix.patch
> ----------
> assignedto: -> alexh
> nosy: +alexh
> status: unread -> chatting
> _____________________________________________________
> DragonFly issue tracker <>
> <http://bugs.dragonflybsd.org/issue1453>
> _____________________________________________________

#3 Updated by alexh about 7 years ago

Ok, I've fixed the recently introduced bug and also added an assert to catch
similar bugs.
In theory this should fix the issue; I'd be thankful if you could test it with
the original vkernel setup.


#4 Updated by alexh about 7 years ago

I've commited it upstream as it resolved the issue described here for me. I
could not reproduce it with the patch.
I'll leave this bug report open until I get a confirmation that it is indeed
The commit is: 527e4a212528eb64553709ba0116c0b80968ec7e

#5 Updated by alexh about 7 years ago

confirmed that the original bug is gone.

Also available in: Atom PDF