Description of problem: Wireless Card: Atheros AR5007EG Listed in linux as AR242x: 07:00.0 Ethernet controller: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01) Subsystem: Hewlett-Packard Company Unknown device 137a Flags: bus master, fast devsel, latency 0, IRQ 169 Memory at c2000000 (64-bit, non-prefetchable) [size=64K] Capabilities: [40] Power Management version 2 Capabilities: [50] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- Capabilities: [60] Express Legacy Endpoint IRQ 0 Capabilities: [90] MSI-X: Enable- Mask- TabSize=1 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel I have tried a few patch kernels included in bug #499999 to try to get this card working. The ath5k module in RH 5.3 (up to and including kernel-2.6.18-128.1.10.el5) fail to create a devices for this card and the kmod-ath5k kernel's in epel-testing would create the wlan0 device but were only able to produce these errors in the logs: May 21 23:33:17 mobile-tek kernel: ath5k phy0: gain calibration timeout (2412MHz) May 21 23:33:17 mobile-tek kernel: ath5k phy0: unable to reset hardware: -11 The newest kmod-ath5k (kmod-ath5k-0.5.1-1.el5.elrepo) fixes the gain calibration issue and is usable. However it is at a cost of performance. Version-Release number of selected component (if applicable): kernel-2.6.18-128.1.10.el5 How reproducible: Every time I boot (cold or reboot) Steps to Reproduce: 1. Start laptop 2. Try to connect to wireless laptop Actual results: NetworkManager does not see any networks and dmesg reports: May 21 23:33:17 mobile-tek kernel: ath5k phy0: gain calibration timeout (2412MHz) May 21 23:33:17 mobile-tek kernel: ath5k phy0: unable to reset hardware: -11 Expected results: No errors in dmesg and Wireless card works and can scan/connect to wireless networks. Additional info: This is all the info I have noticed as well, not sure if any is relevant but here it is. I was using the madwifi-hal driver (latest snapshot) before I got this kmod-ath5k driver working and it was quite fast (19.37 Mb/s down as reported by speedtest.net) consistantly. http://www.speedtest.net/result/479669071.png Now, with the new kmod-ath5k I am getting between 1 and 5 Mb/s and inconsistantly. http://www.speedtest.net/result/481499740.png I can switch back to the madwifi and get the higher speed results again every time. I can also see a visible degradation in speed as even a simple ping will show higher numbers on my local network with the kmod-ath5k Also, the wifi led light on button stays orange, and I have to press the button every time I boot to get the card to scan even with working madwifi and working kmod-ath5k. In Windows this button is blue when "on" and it remembers it's state (on/off) even after reboot or shutdown. I would not have to press it again if it was "on" when I shutdown the laptop. It would just connect at boot to known networks if found. Even after the card is up and connected to a wireless network the wifi led on button stays orange. With the madwifi driver I could issue the following commands to make the light blink blue/orange with activity but NOT stay blue as expected when "on". sudo /sbin/sysctl -w dev.wifi0.ledpin=3 sudo /sbin/sysctl -w dev.wifi0.softled=1 This does not work with ath5k or kmod-ath5k as these drivers do not seem to expose that kernel option.
Created attachment 345449 [details] Re-working of Bob Copeland's patch for RHEL 5.4 This patch is a reworking of Bob Copeland's patch (from December 2008) that has been manually applied to the ath5k/ directory (present in the sources of kernel-2.6.18-150.el5) and then re-created so that it will automagically apply to RHEL 5.4 kernels.
Created attachment 345553 [details] Latest results for speed tests I did some comparative speed tests changing drivers (madwifi-hal/kmod-ath5k) and rebooting. These results shows that I can consistently reproduce speed loss with the kmod-ath5k driver. The upload seems to be the same or close on all tests but I believe that is due to the upload cap Brighthouse places on all connections. If the upload was uncapped I believe we would see similar drops in speed on upload as well.
Patch from comment 1 is included in the test kernels here: http://people.redhat.com/linville/kernels/rhel5/ Please give them a try ASAP and post the results here...thanks!
OK here are the results... Kernel: 2.6.18-152.el5.jwltest.88 (uname -r) First Boot: Kernel panic removed the "pci=nomsi" and "nomce" from boot line to solve for next boot. Interesting as for all other kernels I have to have BOTH of these to boot. Second Boot (without pci=nomsi or nomce): ifconfig: eth0 Link encap:Ethernet HWaddr 00:1F:16:69:E6:60 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:50 Base address:0xe000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2542 errors:0 dropped:0 overruns:0 frame:0 TX packets:2542 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2672684 (2.5 MiB) TX bytes:2672684 (2.5 MiB) No wlan0 device was created. dmesg output (trimmed for brevity): Jun 9 22:40:19 mobile-tek kernel: ath5k phy0: gain calibration timeout (2412MHz) Jun 9 22:40:19 mobile-tek kernel: ath5k phy0: unable to reset hardware: -11 Jun 9 22:40:24 mobile-tek kernel: ath5k phy0: gain calibration timeout (2412MHz) Jun 9 22:40:24 mobile-tek kernel: ath5k phy0: unable to reset hardware: -11 Third boot (this boot): ifconfig (trimmed for brevity): wlan0 Link encap:Ethernet HWaddr 00:24:2B:A2:FE:E0 inet addr:192.168.0.26 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::224:2bff:fea2:fee0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) wmaster0 Link encap:UNSPEC HWaddr 00-24-2B-A2-FE-E0-88-07-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Also, speed test again shows huge loss in speed, I can barely get 5Mb down and < 1Mb up, and in some cases worse. Previous tests (tested again before trying this kernel) show 15-19 Mb down and 1 - 1.5 Mb up which I can consistently reproduce with the madwifi driver as seen in my earlier attachment. To conclude, the gain calibration error is still present and is only fixed by a complete power off and start (reboot does not work). Also, speed is also greatly reduced by this kernel/driver.
Hmmm...Alan, where did you get that patch? I thought I recognized it, but it doesn't seem to have actually been a committed patch upstream...
(In reply to comment #5) > Hmmm...Alan, where did you get that patch? I thought I recognized it, but it > doesn't seem to have actually been a committed patch upstream... John, Checking in my records, I see http://bugzilla.kernel.org/show_bug.cgi?id=12080
Also, I have another question. This may be unrelated to this topic, but it is not unrelated to this driver so I thought maybe it was worth asking here. This laptop (Compaq CQ60-206US) has a wifi button right next to the power button. In windows the button is orange when wifi (the Atheros 5007 card) is turned off, and blue when it is on. Also, in windows this button "remembers" it's last state (on|off). So when I cold boot, or warm boot if the device was "on" when the laptopo was last on, it will start in the "on" mode this time. In Linux using the ath5k driver or the madwifi, the light is ALWAYS orange and I usually have to press the wifi button (twice) before it will turn the device on and I can connect on every boot no matter what it's last state was. One exception to the led light, the madwifi driver allows you to set these kernel options on the command line: sysctl -w dev.wifi0.ledpin=3 sysctl -w dev.wifi0.softled=1 which will make the led blink blue|orange with activity but not stay blue when the device is on. Can't the ath5k use a similar technique to make this available as an option? Maybe give the user the choice to set as activity status (blink as madwifi does) or use the inteded purpose (stay blue when the device is on). This is the only indication the user has to notify them that the driver is loaded and the device is "on" other than having them do a "iwlist wlan0 scan". That is just annoying to have to do at every boot to test if you card is working or not.
LEDs and rfkill are both topics that are very laptop-specific -- apparently wiring those is a creative outlet for system designers... Anyway, the ath5k driver in RHEL is a bit dated (mostly from the 2.6.27 era). You might want to try a recent Fedora or upstream kernel on the hardware in question. In any case, please pursue that issue in a separate bug -- hijacked bugs can be very confusing!
Yes, I thought that might be the case (new bug report for LEDs and rfkill) but I was not sure where to ask that. Laying that aside, is there or will there be another patch to test regarding this gain calibration error? Any news on why this driver cripples the speed on this card? I am still using kernel '2.6.18-152.el5.jwltest.88' from http://people.redhat.com/linville/kernels/rhel5/ and have only seen the gain calibration error once but do continue to suffer speed loss of more than 50% in some cases (see speed tests above). It is my understanding that the gain calibration error only rears it's head once in a while anyway so this probably explains why I have seen it only once with this kernel.
Redhat EL 5.4 kernel and drivers resolves this issue.
I'm closing bug, since is fixed in 5.4 .