[karmic] [Atheros AR5211] ath5k driver connection and performance issues

Bug #276508 reported by Max Bowsher
42
This bug affects 7 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Triaged
Medium
Unassigned
Nominated for Intrepid by damagedspline
Nominated for Karmic by Christiansen
network-manager (Ubuntu)
Invalid
Undecided
Unassigned
Nominated for Intrepid by damagedspline
Nominated for Karmic by Christiansen

Bug Description

Binary package hint: network-manager

Hardware: Thinkpad T40p, Atheros AR5211
Distro: Intrepid Ibex, fully up to date as of beta release

The wireless connection worked fine in Hardy. On upgrading to Intrepid, it no longer works. wpasupplicant never seems to completely establish a connection. In the GUI, the only visible feedback is that of the two-dot nm-applet icon, only one ever goes green, and the prompt for WPA passphrase re-appears every minute or so.

I did the following: reconfigured the dbus-launched wpasupplicant to debug level 5, "modprobe -r ath5k", start tailing /var/log/syslog and /var/log/wpa_supplicant.log, "modprobe ath5k", click on network name in nm-applet. I am attaching the resultant logfile. Please let me know if I can capture anything more useful.

As a datapoint: switching over to the restricted ath_pci driver by doing "modprobe -r ath5k && modprobe ath_pci" allows the connection to work.

Revision history for this message
Max Bowsher (maxb) wrote :
Revision history for this message
XaRz (perecastanyer) wrote :

Same here with iwl3945 driver.

The synthoms are the same, goig well on hardy, unusable in intrepid. I tested kernel 2.6.24 and driver works.

Can you try if your driver work with the hardy kernel?

besides, its strange. with 2.6.27 intrepid kernel some network work, and some not. In my house is not working (WPA2) and in my work is working fine.

Any ideas?

thanks.

Revision history for this message
Max Bowsher (maxb) wrote :

XaRz: The symptoms may be the similar, but I think you should find/file a separate bug for a completely different driver/hardware type.

Revision history for this message
CPKS (c-1) wrote :

I originally had madwifi-hal running with Hardy; when I installed Intrepid Alpha 6 as an upgrade, it continued to work fine until my next restart, when ath5k was substituted. Much time spent trying to remove ath5 with modprobe -r, but this would not work and I had to blacklist it. I don't think that the two drivers could have been simultaneously loaded, but if not, then I hold ath5k responsible for seriously confusing my hardware (AR242X on Acer 5620Z). With ath5k the device was configured as wmaster0 and was inaccessible to iwconfig et al. With madwifi-hal-0.10.5.6-r3861-20080903 (logical device ath0), at first it responded to iwconfig etc. but would not transmit or receive. I tried booting into Vista (spit!); again the network interface seemed functional but would neither transmit nor recive. Eventually I tried powering right down and restarting. That got it going. (Other sufferers with a dead AR242X would do well to follow the instructions at madwifi.org and to blacklist ath5k for the time being.)

Revision history for this message
Fabrice Coutadeur (fabricesp) wrote :

Can you try to disable Atheros proprietary drivers, as indicated in bug #278422?
For me, it worked.

Changed in network-manager:
status: New → Confirmed
Revision history for this message
CPKS (c-1) wrote :

I edited /etc/modprobe.d/blacklist to blacklist the madwifi proprietary drivers ath_pci and ath_hal, and removed the blacklist on ath5k. Then I rebooted.

Yes! It works! lspci confirms ath5k is now acting as the driver and iwconfig confirms that I have a wlan0 virtual device. Perhaps the problem resulted from a conflict with the previously-installed madwifi drivers. Now to test whether the connexion survives a standby...!

Revision history for this message
CPKS (c-1) wrote :

Yes, the connexion is re-established after standby. Looking good!

Revision history for this message
Max Bowsher (maxb) wrote :

Unfortunately, my observed behaviour is not so positive.

Even with ath_hal and ath_pci blacklisted, and then a clean reboot, the ath5k driver is still failing in exactly the same way, for me.

Revision history for this message
Rich (rincebrain) wrote :

Same here - ath_pci and ath_hal blacklisted, reboot, cannot connect using network mangler.

I can do it using wpa_supplicant, but network_mangler fails.

Revision history for this message
Alexander Sack (asac) wrote :

but you can still use ath_pci?

Revision history for this message
Max Bowsher (maxb) wrote :

ath_pci works - but only if I first blacklist ath5k.

Revision history for this message
Alexander Sack (asac) wrote :

seems like we need to blacklist some ath5k models (if not all). Actually, I think Tim is already working on this. so this might be a duplicate.

Changed in linux:
assignee: nobody → timg-tpi
status: New → Confirmed
Revision history for this message
Alexander Sack (asac) wrote :

please post your lspci -vv output if you are affected and blacklisting ath5k helps. Thanks

Changed in linux:
status: Confirmed → Triaged
Revision history for this message
Alexander Sack (asac) wrote :

Nothing I can see what NM can do. If there are specific issues NM could do better for ath5k, please reopen.

Changed in network-manager:
status: Confirmed → Invalid
Revision history for this message
d.love (david-homeunix) wrote :

Blacklisting ath5k works a bit better. I can connect to about 1 in 20 WPA (Enterprise) access points: plain WEP or open works every time.

Revision history for this message
d.love (david-homeunix) wrote :
Revision history for this message
Max Bowsher (maxb) wrote :

I am affected and blacklisting ath5k helps:
02:02.0 Ethernet controller: Atheros Communications Inc. AR5211 802.11ab NIC (rev 01)
 Subsystem: Phillips Components Device 8310
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 168 (2500ns min, 7000ns max), Cache Line Size: 32 bytes
 Interrupt: pin A routed to IRQ 11
 Region 0: Memory at c0210000 (32-bit, non-prefetchable) [size=64K]
 Capabilities: <access denied>
 Kernel driver in use: ath_pci
 Kernel modules: ath_pci, ath5k

Revision history for this message
Fabrice Coutadeur (fabricesp) wrote :

I'm also affected, and blacklisting ath5k allows me to connect with atheros proprietary driver:
03:01.0 Ethernet controller: Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter (rev 01)
 Subsystem: Atheros Communications Inc. Device 1051
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 168 (2500ns min, 7000ns max), Cache Line Size: 32 bytes
 Interrupt: pin A routed to IRQ 22
 Region 0: Memory at febf0000 (32-bit, non-prefetchable) [size=64K]
 Capabilities: <access denied>
 Kernel driver in use: ath_pci
 Kernel modules: ath5k, ath_pci

Revision history for this message
CPKS (c-1) wrote :

Now, after a recent upgrade to the 2.6.27-7-generic #1 SMP Fri Oct 24 06:40:41 UTC 2008 x86_64 kernel, I find I have no ath5k driver any more, and hence no wireless connexion whatsoever. Where can I get ath5k from??

Revision history for this message
Walter_Wittel (wittelw) wrote :

I hit exactly the same thing this evening after upgrading ( 2.6.27-7-generic #1 SMP Fri Oct 24 06:42:44 UTC 2008 i686 in my case). The driver was there and had been working up until tonight.

I tried a reinstall from Synaptic but that didn't help.

I am able to hit esc during boot and switch back to 2.6.27.7-generic which still has the driver (notice ath9k for both kernels):
walter@waltwld6:/lib/modules$ find . -iname 'ath5k*'
./2.6.27-6-generic/kernel/drivers/net/wireless/ath5k
./2.6.27-6-generic/kernel/drivers/net/wireless/ath5k/ath5k.ko
walter@waltwld6:/lib/modules$ find . -iname 'ath9k*'
./2.6.27-6-generic/kernel/drivers/net/wireless/ath9k
./2.6.27-6-generic/kernel/drivers/net/wireless/ath9k/ath9k.ko
./2.6.27-7-generic/kernel/drivers/net/wireless/ath9k
./2.6.27-7-generic/kernel/drivers/net/wireless/ath9k/ath9k.ko

Revision history for this message
Fabrice Coutadeur (fabricesp) wrote :

As stated in Bug #288148, you should install linux-backport-modules.
I installed linux-backports-modules-2.6.27-7-generic, and it's working (new driver Support for 5xxx series of Atheros)

Revision history for this message
Steve Beattie (sbeattie) wrote :

This bug was reported in the Intrepid development cycle; removing regression-potential and marking as regression-release.

Revision history for this message
Max Bowsher (maxb) wrote :

ath5k still broken in current Jaunty on this hardware.
madwifi still working in current Jaunty on this hardware.

Revision history for this message
Christiansen (happylinux) wrote :

I can confirm that this still is an issue with ath5k in Jaunty (kernel 2.6.28-15-generic) as well as in Karmic alpha 5 (kernel 2.6.31-9-generic).
In Jaunty the madwifi driver is the only usable solution, but still have the issue that Tx-Power defaults to 8 dBm, making it unreliable on longer distances from the AP (it can be forced to 20 dBm her in EU, but is falls back 8 dBm after a short while idling/low bandwidth usage).

I've bin investigating the issue since the Jaunty alphas, as the open ath5k has been reported working with a lot of hardware lately. Besides some ThinkPads with the ThinkPad 11a/b/g Wireless LAN Mini Express Adapter, I have access to a Netgear WG511T and a Cisco AIR-CB21AG-E-K9 both PCMCIA adapters both with Atheros 521x chipsets. For the tests I've been using a Cisco box with a Atheros 521x based B/G radio as AP, configured with either WPA-TKIP or RSN-CCMP (not at the same time though) and not broadcasting (hidden network SSID).

A ThinkPad was installed with the released Kubuntu Jaunty, and the internal ThinkPad 11a/b/g Wireless LAN Mini Express Adapter was used. I rear cases it was posible to connect, but speed and reliability was unusable. Without reinstalling, the internal adapter was disabled in BIOS and the computer was booted with the Netgear adapter inserted. This time connection was established right away and automatically on every subsequent reboot, and the connection was reliable and bandwidth as high as expected (and seen with madwifi). Changed the card to the Cisco PCMCIA adapter, and the excact same pattern as experience with the internal Thinkpad adapter was repeated - unreliable and low or no bandwidth.

The tests above was alle repeated with the Karmic Alpha 5 i386 LiveCD, an the pattern was excactly the same here two - the ThinkPad 11a/b/g Wireless LAN Mini Express Adapter and the Cisco AIR-CB21AG-E-K9 PCMCIA adapters was not usable.
BTW Karmic have too been installed on this Thinkpad as dual-boot since Alpha 3 - and between Alpha 3 and Alpha 5 the internal adapter has been nearly usable for a short while while kernel 2.6.31-6 or 2.6.31-7 and network-manager 7.1 was used - unfurtunaly I can't recreate this configuration again.

Attached textfile with excact harware id's and dmesg info for all 3 adapters.

Revision history for this message
Christiansen (happylinux) wrote :

Testes hardware id's for above.

Tim Gardner (timg-tpi)
Changed in linux (Ubuntu):
assignee: Tim Gardner (timg-tpi) → nobody
Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hi Christiansen,

Thanks for all the testing and the feedback, especially against Karmic. I'd be curious if you'd be willing to try installing linux-backports-modules-karmic to see it if helps at all? The reason I ask is that linux-backports-modules-karmic contains a much newer compat-wireless stack which may included some ath5k/9k related fixes. Please let us know your results if you test. Thanks!

Changed in linux (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Andreas Jonsson (sonofjon) wrote :

I can confirm this bug. I seem to have the same situation as Christiansen on my Thinkpad T61. madwifi (ath_pci) worked for me over the past several Ubuntu cycles but ath5k never did (this has been the case at least since Hardy). I just upgraded to Karmic, which has no madwifi. ath5k behaves as in previous releases. I can specify an essid and scan for available networks, but dhclient fails to retrieve an IP for my network (see iwconfig example below). I have also tried connecting to my router with Network manager and WiCd, but had similar disapointing experiences with those when using ath5k (can see available networks but cannot connect). Wired connections work fine however. Thanks for all the hard work you developers are putting into making Ubuntu better!

$ sudo lspci | grep Atheros
03:00.0 Ethernet controller: Atheros Communications Inc. AR5212 802.11abg NIC (rev 01)
$ uname -a
Linux brain2 2.6.31-11-generic #36-Ubuntu SMP Fri Sep 25 06:37:51 UTC 2009 i686 GNU/Linux

$ sudo iwconfig ath0 essid xxxxx
$ sudo iwconfig ath0
ath0 IEEE 802.11abg ESSID:"xxxxx"
          Mode:Managed Frequency:2.437 GHz Access Point: XX:XX:XX:XX:XX:XX
          Tx-Power=20 dBm
          Retry long limit:7 RTS thr:off Fragment thr:off
          Encryption key:off
          Power Management:off
user@computer:~$ sudo iwlist ath0 scan
.
. ... produces a list of available networks ....
.
$ sudo dhclient ath0
Internet Systems Consortium DHCP Client V3.1.2
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/ath0/00:1e:4c:30:9c:7b
Sending on LPF/ath0/00:1e:4c:30:9c:7b
Sending on Socket/fallback
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 18
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 12
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 8
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

Revision history for this message
Andreas Jonsson (sonofjon) wrote :

Leann: I can add that i have tried linux-backports-modules-karmic, but it I am still experiencing the same problem

Revision history for this message
Christiansen (happylinux) wrote :

Hi Leann (@ #26),

Certainly, and now I final got hold of the Karmic Beta ISO.

Unfortunately, as stated by Andreas Jonsson above, it doesn't seem to make any difference using LBM in nither Karmic Beta nor Jaunty (newest kernel 2.6.28-15.20). In fact in Karmic Beta I'm often able get connected with the ath5k module from the kernel image, but only got connected one time with the ath5k module from LBM. Fore both modules, when able to connect, the connection is unreliable and has extreme low throughput - mostly 10-20 Kbit/sec contrary the madwifi modules 16-18 Mbit/sec. So the LBM do not change anything in either Karmic Beta og Jaunty, and seems to make things slightly worse in Karmic.

I've too found that the LBM according to the attached dmesg log, seem not to adjust the "World regulatory domain", a thereby not making the channel 12 and 13 (legal in the EU) usable.

Unfortunatly I now too can add an other Atheros based ThinkPad adaptor to the list of not usable with the ath5k module, as a friend had an older Thinkpad which we tested with Karmic Beta. The throughput was with this adapter a little better though, but still only in Kbit/sec. Finally a Madwifi module compiled from source made it as usable as it did with the Express adapter.

The list of tested and NOT usable with ath5k modules now contains the following PCI ID's:

[168c:1014] sub [1014:058a] : ThinkPad 11a/b/g Wireless LAN Mini Express Adapter (mini-PCIe version).
[168c:1014] sub [1014:057e] : IBM 11a/b/g Wireless LAN Mini PCI Adapter (Older mini-PCI version).
[168c:0013] sub [14b9:cb21] : Cisco Aironet 802.11a/b/g Wireless CardBus Adapter (External PCMCIA non-ThinkPad).

Attaching files showing which modules (and byte size) that was loaded under during the tests.

BTW Is it possible for somone to change the headline of this bug, removing the [Intrepid] stuff ?, as this bug now covers Intrepid, Jaunty and Karmic Beta.

Revision history for this message
Christiansen (happylinux) wrote :

The karmic modules loaded during the tests above.

Revision history for this message
Christiansen (happylinux) wrote :

The jaunty modules loaded during the tests above.

Revision history for this message
Julius Thor (joolli) wrote :

Hi,

I've always had this problem with the ath5k driver. However I tried the ath5k driver again about 2 months ago and had the exact same problem, so I tried changing the channel on my AP to something that wasn't being used by my neighbors and since then my connection has stayed relatively stable.

It is relatively stable, however I do lose connection every 2-4 minutes without losing association with the AP. I don't really notice it unless I'm using streaming media. It's only like once or twice every 24 hours that I lose association with the AP but it connects again in about 30 seconds. Before I changed the channel I would get association for a few seconds before losing it again and most of the time it wouldn't associate at all.

This only applies to my home connections which is encrypted with WPA-PSK. Usually I can't connect at all while in my University. Sometimes I get a connection but lose it after a few seconds. The University WiFi network is unencrypted.

The ath_pci driver would stay connected without me changing the channel at home and could also stay connected in the University. However it caused kernel panics so I prefer ath5k when I'm able to use it. I would say that it's a regression that there isn't an option to use ath_pci karmic. I would use the ath5k at home and ath_pci when I was in Uni.

Revision history for this message
Julius Thor (joolli) wrote :

After an update the other day I tried connecting to the wireless in my University and now I get association and it remains associated. However I do get very slow connection. My top speed was about 40KB/s for a few seconds. I would say average speed was around 0-20KB/s. Very choppy connection but it's definitely a small improvement. :)

Revision history for this message
Lorenco Trichardt (trichalo) wrote :

Any chance of getting higher priority on this issue ?As this could be a bit of a show stopper for people to move to Ubuntu.
I believe that this is becoming a bigger issue that affects a large enough community (running IBM Thinkpads) that we need to get to the bottom of this.

I have seen various up and down performance on my Thinkpad T60 for the last 3 release cycles and was hopeing to get it more stable by the release of Karmic GA, but sadly it seems that there are no progress?

I am also finding more and more related bugs with various desctriptions etc all relating to Athereos wireless.
Root cause could boil down to the same thing ?? ? Not sure.

BTW, my wireless connection has deteriorated so much that it is almost unasable (Wanted 2 days to upgrade yesterday via Wireless connection on a 4GB ADSL line ?)
Hmmmm.

Getting up to 30% packet loss.... and very poor performance while I am a mere 10 m away from my AP.

Any comments welcome....

summary: - [intrepid] [Atheros AR5211] ath5k driver inoperative, wpa_supplicant
- never completes connection
+ [karmic] [Atheros AR5211] ath5k driver connection and performance issues
Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hi All,

In order to get a focused and detailed view of the issue we are going to open a new bug to track this issue in it's current state (ie Karmic).

https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/461419

I'm going to take the liberty to mark this bug as a duplicate to this new bug so that everyone will continue to be notified of any progress. I've added some detailed information to the description of bug 461419 to help us track the issue better. Please follow up at bug 461419 if you are able to.

Also please note that the proprietary madwifi drivers are no longer being used/shipped in the latest releases of Ubuntu and have been obsoleted in favor of using the free ath5k/ath9k drivers. We will only look at this issue for those using the ath5k driver. I'll also be sending out a call for testing to some mailing lists to try to gather any additional debug information.

Thanks in advance for all your cooperation and help.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.