Bug #4722
closed
Ralink USB driver yields a double fault panic on pfSense, works on FreeBSD with equivalent config
0%
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
Updated by Chris Buechler over 9 years ago
- Status changed from New to Confirmed
- Affected Version changed from 2.2.3 to 2.2.x
guessing this is probably all 2.2.x versions.
Does the workaround in #4740 also work around this?
Updated by Jim Pingle over 9 years ago
Apparently so. Moving the sleep down below the other line allows it to function. Occasionally drops an error on the console but I have a client behind it connected and working.
run0: firmware RT2870 ver. 0.33 loaded run0_wlan0: ieee80211_new_state_locked: pending RUN -> SCAN transition lost
Doesn't seem to have a negative impact otherwise. Seems like a safe change also.
Updated by Jim Pingle over 9 years ago
Spoke too soon, I went back and tried it on the original hardware that was used to replicate the problem and it still crashes there with the sleep before or after.
Moving the USB dongle to an APU I can't make it crash there at all even with a stock 2.2.3. May just have to chalk this up to some other hardware combination issue.
Updated by Chris Buechler about 9 years ago
- Status changed from Confirmed to Needs Patch
- Target version deleted (
2.3) - Affected Version deleted (
2.2.x)
seems specific to certain combinations of hardware, and doesn't appear to be in anything we're doing.