Actions
Bug #4722
closedRalink USB driver yields a double fault panic on pfSense, works on FreeBSD with equivalent config
Status:
Needs Patch
Priority:
Very Low
Assignee:
-
Category:
Wireless
Target version:
-
Start date:
05/21/2015
Due date:
% Done:
0%
Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:
All
Description
I've got a Ralink USB wireless adapter (Buffalo WLI-UC-GNM) that works perfectly on stock FreeBSD (10.1-STABLE) but when used on pfSense, crashes/panics. Tried on 2.2.2, 2.2.3, and 2.3 snapshots.
Adapter info from dmesg (address redacted):
run0: <1.0> on usbus4 run0: MAC/BBP RT3070 (rev 0x0201), RF RT3020 (MIMO 1T1R), address cc:e1:d5:xx:xx:xx run0: firmware RT2870 ver. 0.33 loaded
From usbconfig:
ugen4.2: <802.11 n WLAN Ralink> at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (450mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x0000 <Probed by interface class> bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0040 idVendor = 0x0411 idProduct = 0x01a2 bcdDevice = 0x0101 iManufacturer = 0x0001 <Ralink> iProduct = 0x0002 <802.11 n WLAN> iSerialNumber = 0x0003 <1.0> bNumConfigurations = 0x0001
The same crash happens with either hostap mode or BSS mode. Full crash dump is attached. Here is the backtrace:
Tracing pid 0 tid 100179 td 0xc75b5310 kdb_enter(c1448f13,c1448f13,c16052cf,c207b1b4,0,...) at kdb_enter+0x3d/frame 0xc207b168 panic(c16052cf,0,0,0,ef39e418,...) at panic+0x144/frame 0xc207b1a8 dblfault_handler() at dblfault_handler+0xab/frame 0xc207b1a8 --- trap 0x17, eip = 0xc0af43c2, esp = 0xef39df78, ebp = 0xef39e418 --- run_select_chan_group(c78b3800,c783d2d4,ef39ea38,0,0,...) at run_select_chan_group+0x12/frame 0xef39e418 run_set_chan(c78b3800,c783d2d4,ef39f878,0,0,...) at 0xc0af2964/frame 0xef39ee08 run_init_locked(ef39fbd8,c12ad2eb,c75b5310,0,1,...) at 0xc0b12d8d/frame 0xef39fbb0 run_ioctl(c7889000,80206910,0) at run_ioctl+0x2d7/frame 0xef39fc14 parent_updown(c7889000,1,0,0,0,...) at parent_updown+0x22/frame 0xef39fc28 taskqueue_run_locked(c76fc880,c76fc898,0,c143554f,0,...) at taskqueue_run_locked+0xee/frame 0xef39fc6c taskqueue_thread_loop(c6d900a4,ef39fce8,0,0,0,...) at taskqueue_thread_loop+0xc7/frame 0xef39fca4 fork_exit(c0d57fc0,c6d900a4,ef39fce8) at fork_exit+0xa3/frame 0xef39fcd4 fork_trampoline() at fork_trampoline+0x8/frame 0xef39fcd4
Looks similar to a crash someone else encountered on a custom NanoBSD (non-pfSense) build vs. stock FreeBSD:
https://www.mail-archive.com/freebsd-wireless@freebsd.org/msg03525.html
Files
Actions