Steps to reproduce and discussion:
For the record - problem still reproduces on r297731.
Adrian - can you have a look at this?
Solved with fix in bug #208605, comment #3 ?
Should this be re-filed under FreeBSD Wireless?
I have the same issue with a vilros stick. Occasionally the light goes out and I lose connectivity (probably due to the fact that it's a crappy nano-sized unit and there's loads of interference). Pulling it out will cause a kernel panic 8/10 times.
I'm running this on a thinkpad T440p, the wireless usb info is:
ugen0.2: <product 0x8176 vendor 0x0bda> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)
(I can provide the full dump, but it looks like all the other dumps for that product id.)
I'm running (from uname -a): 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r300249
Kernel is GENERIC.
Please let me know if more details are required, I've gone ahead and attached the crash info, the (what I think is) pertinent section of dmesg is:
urtwn0: <vendor 0x0bda product 0x8176, class 0/0, rev 2.00/2.00, addr 9> on usbus0
urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R
urtwn0: enabling 11n
wlan0: Ethernet address: 00:13:ef:50:02:e4
ugen0.3: <vendor 0x0bda> at usbus0 (disconnected)
urtwn0: at uhub0, port 6, addr 9 (disconnected)
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x0
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff80b6d145
stack pointer = 0x28:0xfffffe0454a136d0
frame pointer = 0x28:0xfffffe0454a137d0
code segment = base rx0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 5463 (wpa_supplicant)
trap number = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0454a13260
vpanic() at vpanic+0x182/frame 0xfffffe0454a132e0
panic() at panic+0x43/frame 0xfffffe0454a13340
trap_fatal() at trap_fatal+0x351/frame 0xfffffe0454a133a0
trap_pfault() at trap_pfault+0x1fd/frame 0xfffffe0454a13400
trap() at trap+0x284/frame 0xfffffe0454a13610
calltrap() at calltrap+0x8/frame 0xfffffe0454a13610
--- trap 0xc, rip = 0xffffffff80b6d145, rsp = 0xfffffe0454a136e0, rbp = 0xfffffe0454a137d0 ---
ieee80211_ioctl() at ieee80211_ioctl+0x515/frame 0xfffffe0454a137d0
ifioctl() at ifioctl+0x10ea/frame 0xfffffe0454a13860
kern_ioctl() at kern_ioctl+0x246/frame 0xfffffe0454a138c0
sys_ioctl() at sys_ioctl+0x171/frame 0xfffffe0454a139a0
amd64_syscall() at amd64_syscall+0x2db/frame 0xfffffe0454a13ab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0454a13ab0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8015c29da, rsp = 0x7fffffffe928, rbp = 0x7fffffffe980 ---
Dumping 1529 out of 16040 MB:..2%..11%..21%..31%..41%..51%..61%..71%..81%..92%Copyright (c) 1992-2016 The FreeBSD Project.
Please let me know if further details are needed.
Bug 208605 is marked fixed, but it looks to be the same issue.
Created attachment 170739 [details]
Crash core file.
This is a known problem with the usb wifi drivers. I'm not sure if it's going to get fixed before 11.0-RELEASE. Sorry :(
Adrian, you said it is not going to be fixed before
11.0 release. Just to be sure - is this problem not
fixed in 11-current?
Its not fixed in -HEAD, sorry. There are still some race conditions in device shutdown that we need to address.
The workaround is to bring hte interface down and destroy it before unplugging.
Created attachment 171469 [details]
Try attached patch (should fix various driver detach races).
I tested this patch on r302024. Bug is fixed, everything works as expected. I'm looking forward to see this patch in HEAD.
Thanks a lot!
A commit references this bug:
Date: Mon Jun 20 22:39:33 UTC 2016
New revision: 302034
urtwn: fix panic on device detach.
Remove frames from active/pending Tx queues and free related node
references when vap is destroyed to prevent various use-after-free
Reported and tested by: Aleksander Alekseev <firstname.lastname@example.org>
Approved by: re (gjb)