What    |Removed                     |Added
                 CC|                            |

--- Comment #4 from ---
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
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 0x0, 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 ---
Uptime: 1d8h37m35s
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.


You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to