Bug 502542 - ath5k gain calibration error
ath5k gain calibration error
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.4
All Linux
low Severity high
: rc
: ---
Assigned To: Stanislaw Gruszka
Red Hat Kernel QE team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-25 22:43 EDT by David Dreggors
Modified: 2011-02-05 16:14 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-02-05 16:14:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Re-working of Bob Copeland's patch for RHEL 5.4 (3.54 KB, patch)
2009-05-26 08:00 EDT, Alan Bartlett
no flags Details | Diff
Latest results for speed tests (1.04 KB, text/plain)
2009-05-26 23:50 EDT, David Dreggors
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 499999 None None None Never

  None (edit)
Description David Dreggors 2009-05-25 22:43:33 EDT
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.
Comment 1 Alan Bartlett 2009-05-26 08:00:52 EDT
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.
Comment 2 David Dreggors 2009-05-26 23:50:41 EDT
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.
Comment 3 John W. Linville 2009-06-09 13:53:13 EDT
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!
Comment 4 David Dreggors 2009-06-09 23:10:41 EDT
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.
Comment 5 John W. Linville 2009-06-11 09:57:30 EDT
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...
Comment 6 Alan Bartlett 2009-06-11 10:11:19 EDT
(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
Comment 7 David Dreggors 2009-06-11 19:07:05 EDT
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.
Comment 8 John W. Linville 2009-06-15 11:07:03 EDT
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!
Comment 11 David Dreggors 2009-06-15 22:01:28 EDT
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.
Comment 12 David Dreggors 2009-10-28 14:18:31 EDT
Redhat EL 5.4 kernel and drivers resolves this issue.
Comment 13 Stanislaw Gruszka 2011-02-05 16:14:44 EST
I'm closing bug, since is fixed in 5.4 .

Note You need to log in before you can comment on or make changes to this bug.