Bug #4175
closed
kernel panic when loading run driver for RT3070
Added by William Eshagh almost 10 years ago.
Updated over 9 years ago.
Affected Architecture:
i386
Description
I get a kernel panic whenever trying to load the run wireless driver on the 2.2-RC i386 snapshots:
<118>Configuring OPT2 interface...
run0: firmware RT2870 ver. 0.33 loaded
Fatal double fault:
eip = 0xc0ad6aa2
esp = 0xebdd8f98
ebp = 0xebdd9438
cpuid = 1; apic id = 01
panic: double fault
cpuid = 1
KDB: enter: panic
panic.txt0600001412452130241 7125 ustarrootwheeldouble faultversion.txt06000025112452130241 7603 ustarrootwheelFreeBSD 10.1-RELEASE-p3 #0 8bdb2f8(releng/10.1)-dirty: Fri Jan 2 15:55:10 CST 2015
root@pfsense-22-i386-builder:/usr/obj.i386/usr/pfSensesrc/src/sys/pfSense_SMP.10
Files
- Status changed from New to Rejected
please replicate on stock FreeBSD 10.1 and report upstream
Had time to load stock FreeBSD 10.1 and the wireless interface worked. Also updated to 2.2-RELEASE and still experience the panic when trying to join a wireless network. Attaching the last dump. Thanks!
Hi. I am not sure if I am supposed to create a new issue or update this one...
I am experiencing the exact same behavior with a chipset of the same family, as explained here
Both chipsets are supported in freebsd 10.1-RELEASE by the run driver
I verified the driver loads successfully in stock freebsd 10.1-RELEASE, however pfsense goes into kernel panic as soon as the driver is loaded, no matter the interface. I have tried this with 2 different PCs.
@
Architecture: i386
Architecture Version: 1
Dump Length: 71168B (0 MB)
Blocksize: 512
Dumptime: Thu Feb 19 00:58:50 2015
Hostname: pfSense.localdomain
Magic: FreeBSD Text Dump
Version String: FreeBSD 10.1-RELEASE-p4 #0 36d7dec(releng/10.1)-dirty: Thu Jan 22 15:12:38 CST 2015
root@pfsense-22-i386-builder:/usr/obj.i386/usr/pfSensesrc/src/sys/pfSense_SMP.10
Panic String: double fault
Dump Parity: 1244061018
Bounds: 17
Dump Status: good
...
<118>pfSense (pfSense) 2.2-RELEASE i386 Thu Jan 22 14:04:25 CST 2015
<118>Bootup complete
ugen0.3: <Ralink> at usbus0
run0: <1.0> on usbus0
run0: MAC/BBP RT5392 (rev 0x0223), RF RT5372 (MIMO 2T2R), address ec:22:80:0b:41:6d
run0: firmware RT3071 ver. 0.33 loaded
Fatal double fault:
eip = 0xc0ad7162
esp = 0xc47f3e50
ebp = 0xc47f42f0
cpuid = 0; apic id = 00
panic: double fault
cpuid = 0
KDB: enter: panic
@
there has to be something different, as the run driver we ship is 100% identical to FreeBSD 10.1's. If someone wants to ship me an affected card I'll take a look. Email me (cmb at pfsense dot org) if that might be of interest.
Got the same issue today while upgrading to 2.2 on fit-pc2i. It got RT2870 card and the same double fault while loading:
run0: firmware RT2870 ver. 0.33 loaded
Fatal double fault:
eip = 0xc0d11588
esp = 0xecf77fb8
ebp = 0xecf78018
cpuid = 0; apic id = 00
panic: double fault
cpuid = 0
KDB: enter: panic
I have textdump.tar.0 if anyone interested. I did not have time to try and reproduce on stock FreeBSD 10.1.
Workaround was to physically remove card from the machine.
I'm seeing this too on an older device that worked fine in 2.1.X. I'll try to run up a FreeBSD 10.1 install and test. I'm obviously open to any tests you'd like me to run Chris.Panic attached.
- Target version deleted (
2.2)
Hello,
I also ran into that error.
The version 2.2.4 seems to be broken with RT3070 devices.
I tried with pfsense 2.1.2 where the driver loads, the device is configurable (as wireless in AP mode). I did not yet verify if the device is able to connect clients.
The device in 2.1.2 is RT3070 utilizing firmware RT2870. I bought a LogiLink WL0054 (around 15 Euro market price now).
The ticket #4722 might be linked with this issue.
Could somebody help?
Best regards,
Ingo
Update: the device is configureable in pfsense 2.2.4 as well but crashed at loading the firmware (0.33).
If you need a crash report do not hesitate to ask for.
This needs to be reproduced on FreeBSD and/or someone needs to ship us an affected card, but we can't guarantee anything as it's not hardware we sell or endorse. As it stands this bug is still in a Rejected state.
In #4722 it seems to be a combination of hardware that leads to the crash, so it's not so simple.
You'd be better served by returning the non-working device and obtaining one that is known to function properly.
Also available in: Atom
PDF