Bug #1453
closed
Multiple instances of tap0 and panic when destroying
0%
Description
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.
Backtrace:
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
pfi_detach_ifnet_event+0xb
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
tap_clone_destroy+0x45
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
--
Regards,
Rumko
Files
Updated by alexh over 15 years ago
Can you please try the fix at:
http://leaf.dragonflybsd.org/~alexh/tap_fix.patch
Updated by rumcic about 15 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 <ahornung@gmail.com> 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 <bugs@lists.dragonflybsd.org>
<http://bugs.dragonflybsd.org/issue1453>
_____________________________________________
Updated by alexh about 15 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.
Cheers,
Alex
Updated by alexh about 15 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
solved.
The commit is: 527e4a212528eb64553709ba0116c0b80968ec7e