Bug 502542
Summary: | ath5k gain calibration error | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | David Dreggors <dadreggors> | ||||||
Component: | kernel | Assignee: | Stanislaw Gruszka <sgruszka> | ||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Red Hat Kernel QE team <kernel-qe> | ||||||
Severity: | high | Docs Contact: | |||||||
Priority: | low | ||||||||
Version: | 5.4 | CC: | ajb, linville, mschmidt, peterm, sgruszka | ||||||
Target Milestone: | rc | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2011-02-05 21:14:44 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
David Dreggors
2009-05-26 02:43:33 UTC
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 . |