168c:002a ath9k disassociates/reassociates a lot

I have to manually set rate every few minutes,

taavikko@hp-dv5:~$ iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wmaster0 no wireless extensions.

wlan0 IEEE 802.11abgn ESSID:"devil_is_wireless"
          Mode:Managed Frequency:2.457 GHz Access Point: 00:1E:AB:00:8C:5B
          Bit Rate=0 kb/s Tx-Power=20 dBm
          Retry long limit:7 RTS thr:off Fragment thr:off
          Power Management:on
          Link Quality=62/70 Signal level=-48 dBm
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

pan0 no wireless extensions.

taavikko@hp-dv5:~$ sudo iwconfig wlan0 rate 54M
[sudo] password for taavikko:
taavikko@hp-dv5:~$ iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wmaster0 no wireless extensions.

wlan0 IEEE 802.11abgn ESSID:"devil_is_wireless"
          Mode:Managed Frequency:2.457 GHz Access Point: 00:1E:AB:00:8C:5B
          Bit Rate=54 Mb/s Tx-Power=20 dBm
          Retry long limit:7 RTS thr:off Fragment thr:off
          Power Management:on
          Link Quality=68/70 Signal level=-42 dBm
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

pan0 no wireless extensions.

Is that in response to performance issues? Does it clear it up somehow?
What does your dmesg look like?

I've got the same problem on Jaunty with the 2.6.31r6 mainline kernel.

rich@panthera:~$ uname -a
Linux panthera 2.6.31-020631rc6-generic #020631rc6 SMP Fri Aug 14 09:04:48 UTC 2009 x86_64 GNU/Linux

[ 118.757172] wlan0: direct probe to AP 00:1c:f0:f7:88:31 try 1
[ 118.762099] wlan0 direct probe responded
[ 118.762106] wlan0: authenticate with AP 00:1c:f0:f7:88:31
[ 118.763999] wlan0: authenticated
[ 118.764020] wlan0: associate with AP 00:1c:f0:f7:88:31
[ 118.771017] wlan0: RX AssocResp from 00:1c:f0:f7:88:31 (capab=0x431 status=0 aid=2)
[ 118.771023] wlan0: associated
[ 118.780611] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 129.092094] wlan0: no IPv6 routers present
[ 344.752127] wlan0: no probe response from AP 00:1c:f0:f7:88:31 - disassociating
[ 350.345025] wlan0: authenticate with AP 00:1c:f0:f7:88:31
[ 350.346940] wlan0: authenticated
[ 350.346945] wlan0: associate with AP 00:1c:f0:f7:88:31
[ 350.350345] wlan0: RX ReassocResp from 00:1c:f0:f7:88:31 (capab=0x431 status=0 aid=2)
[ 350.350351] wlan0: associated
[ 469.828591] wlan0: no probe response from AP 00:1c:f0:f7:88:31 - disassociating
[ 475.425763] wlan0: authenticate with AP 00:1c:f0:f7:88:31
[ 475.427807] wlan0: authenticated
[ 475.427812] wlan0: associate with AP 00:1c:f0:f7:88:31
[ 475.431272] wlan0: RX ReassocResp from 00:1c:f0:f7:88:31 (capab=0x431 status=0 aid=2)
[ 475.431279] wlan0: associated
[ 483.916416] wlan0: no probe response from AP 00:1c:f0:f7:88:31 - disassociating
[ 489.505238] wlan0: authenticate with AP 00:1c:f0:f7:88:31
[ 489.507236] wlan0: authenticated
[ 489.507242] wlan0: associate with AP 00:1c:f0:f7:88:31
[ 489.511416] wlan0: RX ReassocResp from 00:1c:f0:f7:88:31 (capab=0x431 status=0 aid=2)
[ 489.511427] wlan0: associated
[ 498.824375] wlan0: no probe response from AP 00:1c:f0:f7:88:31 - disassociating
[ 504.412812] wlan0: authenticate with AP 00:1c:f0:f7:88:31
[ 504.608589] wlan0: authenticate with AP 00:1c:f0:f7:88:31
[ 504.610581] wlan0: authenticated
[ 504.610586] wlan0: associate with AP 00:1c:f0:f7:88:31
[ 504.614052] wlan0: RX ReassocResp from 00:1c:f0:f7:88:31 (capab=0x431 status=0 aid=2)
[ 504.614058] wlan0: associated

Confirming, seems to be a 2.6.31 problem?

Still have this problem in 2.6.31-6-generic. It *seems* like a suspend/resume cycle makes it likely I'll have this problem, though I have seen it on a completely cold boot with no suspend/resume as well.

I found this bug in Linux:

http://bugzilla.kernel.org/show_bug.cgi?id=13807

I believe this is the same issue we're running into here. I can't speak to signal strength--never really looked, to be honest--but the other symptoms are identical.

I am currently running the latest drivers out of compat-wireless <http://linuxwireless.org/en/users/Download> (direct install, not from backports) and I'm not seeing disassociations yet in early tests but I am seeing pretty poor performance similar to what I'd seen before.

I have the same problem with the netbook Asus Eee PC 1008HA and Ubuntu Karmic Alpha 5.

Linux netbook 2.6.31-9-generic #29-Ubuntu SMP Sun Aug 30 17:39:23 UTC 2009 i686 GNU/Linux

It looks like the problem starts after a suspend/resume as Matt Behrens said in comment #5.

If after a suspend/resume, I press Fn + F2 (disables the wifi) on my netbook and press again Fn+F2 (enables the wifi) the problem disappears.

Just wanted to add a "me too" in Ubuntu 9.04 on my Eee PC 1005HA with backported kernel modules.

02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
        Kernel driver in use: ath9k
        Kernel modules: ath9k

2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009 i686 GNU/Linux

Also adding a "me too" in Debian Testing ("Squeeze") w/D-Link 802.11n Atheros AR5008.

Linux Hydrogen 2.6.30-1-686 #1 SMP Sat Aug 15 19:11:58 UTC 2009 i686 GNU/Linux
configuration: broadcast=yes driver=ath9k latency=0 multicast=yes wireless=IEEE 802.11bgn

My install of ath9k is *not* re-associating, and as this is a headless server, I have had to run dhclient under crontab until this is fixed. Sorry, no dmesg because I cannot access the box when it is not associated.

Me too
I've got the same config than Jason 'vanRijn' Kasper (#10)

Another "me too" on Jaunty but with 2.6.31-rc9. Switching to current wireless-testing driver is even worse. Stability on ath9k has gone done continuously since 2.6.31. I don't have any 2.6.30 builds but the last kernel that worked half-decently for me with this wifi driver was 2.6.29.

I can also confirm this (up to date Karmic). The signal is weak, but it also disconnects after a while. Right now I can't even connect at all, but that's maybe related to the fact taht the network is not starting on boot after the last updates: see http://ubuntuforums.org/showthread.php?t=1267044&highlight=karmic+network

Oeps... forgot to mention that I have an Asus Eee 1101HA.

+1 me too - but on an HP dv6 series laptop with an AR9285.

lspci -v output:
08:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network
Adapter (PCI-Express) (rev 01)
        Subsystem: Hewlett-Packard Company Device 3040
        Flags: bus master, fast devsel, latency 0, IRQ 17
        Memory at d1200000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] Message Signalled Interrupts: Mask- 64bit- Queue=0/0Enable-
        Capabilities: [60] Express Legacy Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting <?>
        Capabilities: [140] Virtual Channel <?>
        Capabilities: [160] Device Serial Number 12-14-24-ff-ff-17-15-00
        Capabilities: [170] Power Budgeting <?>
        Kernel driver in use: ath9k
        Kernel modules: ath9k

Kernel I'm running is:
kunal@plutonium:~$ uname -a
Linux plutonium 2.6.31-10-generic #30 SMP Thu Sep 10 13:55:01 IST 2009 x86_64 GNU/Linux

built from http://kernel.ubuntu.com/git/ubuntu/ubuntu-karmic.git on Jaunty.

I've also posted the issues on ath9k-devel mailing list, but not gotten any helpful replies from there.. :(

Maybe, I'll give wireless-testing a try.

So, I'm trying compat-wireless-2009-09-14 on my Eee 1005HA (Atheros AR9285), and it looks like while ath9k isn't completely dropping my connection as often, I'm still seeing that it gets a beacon loss and then it goes through a connection retry step. The end result seems to be that while NetworkManager doesn't disconnect me and force me to disable/enable wireless to get connected again, my network connection seems extremely flaky. Running an ssh session between my 1005HA and another Linux box in my house (inside my LAN), keyboard input is very interrupted... like I'll type "ls -la /tmp/foo/bar/baz" and after about every 3rd or 4th letter is typed, my ssh connection freezes and then resumes again. Really weird. More annoying than having a completely dropped connection every 10 minutes or so.

Is there a better place to be carrying on this discussion? I REALLY want to get this problem fixed so I can not absolutely hate my Netbook and this bug doesn't seem to be getting any official recognition/help/feedback?

If you need a workaround, and you got Windows drivers with your system, ndiswrapper. That's what I've been using and I've been waiting for good news before going back to try. It works solidly.

I don't know how to get anyone's attention. LKML? There is a Linux bug that I linked to this one.

For me, workaround is using older kernel 2.6.28-13.
I was using it in Ubuntu 9.04 and it also works well after upgrade to Ubuntu 9.10.

hi,

as described in bug ... i worked around this problem by disabling two new features in ATH9K (power management and rfkill polling) that were described as possibly buggy in ath9k-devel.

i have put a rebuilt version of linux-backports-modules on this PPA:
https://launchpad.net/~frank-dekervel/+archive/ppa

for me it brings back jaunty-like performance.
i don't know much about ppa's and when i have to re-upload the package (on every new linux-image ? or only when the version number increases?), but it seems to work on my computer.

i used the package linux-backports-modules-2.6.31-10-generic (version 2.6.31-10.12kervel2)
see also my comments in bug https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/378156 and http://bugzilla.kernel.org/show_bug.cgi?id=13807

sorry for the crossposting but i believe that all these bugreports are related.

greetings,
frank

Matt, I'd totally settle for using ndiswrapper, but my attempts thus far have failed miserably. Here's what I see in kern.log when I try:

Sep 16 23:54:30 darth-mini kernel: [45897.921928] ndiswrapper version 1.53 loaded (smp=yes, preempt=no)
Sep 16 23:54:30 darth-mini kernel: [45897.981715] ndiswrapper (link_pe_images:603): DLL initialize failed for athw.sys
Sep 16 23:54:30 darth-mini kernel: [45897.981827] ndiswrapper: driver netathw (,03/13/2009,7.7.0.259) loaded
Sep 16 23:54:30 darth-mini kernel: [45897.982497] ndiswrapper 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
Sep 16 23:54:30 darth-mini kernel: [45897.982515] ndiswrapper (mp_init:210): assuming WDM (non-NDIS) driver
Sep 16 23:54:30 darth-mini kernel: [45897.982662] usbcore: registered new interface driver ndiswrapper

And this is after using it with the WLAN_NE785.zip drivers that I downloaded from Asustek's support website. What Atheros WLAN drivers are you successfully using with ndiswrapper?

Jason 'vanRijn' Kasper wrote:
> Matt, I'd totally settle for using ndiswrapper, but my attempts thus far
> have failed miserably.
For this card:

01:00.0 Network controller: Atheros Communications Inc. AR928X Wireless
Network Adapter (PCI-Express) (rev 01)
Subsystem: Device 1a3b:1067

I'm using the drivers that came on my system's CD. I can't find it at
the moment ;) but NE785 sounds familiar. As I recall both sets of
wireless drivers were identical save some extra setup files.

Here are the sha1sums:

matt@sampo:/etc/ndiswrapper/netathw$ sha1sum *athw*
98df1930314739287321fcbeca5d06db23d9871b athw.sys
6ba785ea6446bc6f452381423d76dc24dbd56217 netathw.inf

I just wanted to update with what I've found lately... I tried kervel's patch from comment #20 and I'm _VERY_ pleased with the results. I've been running a custom-compiled compat-wireless-2009-09-14 with power management and rfkill polling turned off, per his comment, and I have not had any network disconnects or drops whatsoever, and the network connection has been really, really good. Like, sustained 1.9M/s file transfers over the wireless connection, which I've never gotten before even on my Thinkpad. Hope this helps someone else and/or helps the kernel devs to a good solution that can be made a permanent part of the ath9k kernel modules. The only thing I don't like is that I had to uninstall linux-backports-modules-2.6.28-15-generic to be able to use compat-wireless and since then, eeepc-tray isn't as functional as it should be and I have to manually hit FN+F1 to suspend instead of just being able to close the lid to suspend (closing the lid just unloads the ath9k module but doesn't go any further).

Anyway, thank you kervel! =:)

Jason et al,

I was talking about this driver over at eeeuser's forums a bit and decided to swap it back in a couple nights ago. I feel like I haven't had a lot of testing, but it hasn't failed me yet, and it's completely unpatched... I'm not even using backports.

Version: 2.6.31-10.34

I wonder if it might work for you now? I'll keep on it, of course, myself, and report back if it decides to fail on me.

About the only non-standard thing I've got going on is nomodeset in my kernel line to get around bug #431812.

@Matt Behrens

Do you mean that the 2.6.31-10.34 kernel ( https://lists.ubuntu.com/archives/karmic-changes/2009-September/008819.html ) fix the problem for you?

Thanks

Seems to, based on a few hours of use each night for two or three nights now. And I just updated to 10.35 this morning which still seems okay.

That's why I'm curious how everyone else is doing.

Again, no patches, replacement of NetworkManager, backports, etc. are in play.

With the US Robotics Router (b,g) my desktop with ath9k seems to like to
disassociate/reassociate, now with the Linksys WRT610N (b,g,n) it doesn't
disassociate but I have to disassociate and reassociate manually because the
connection stop working sometimes (very often).

I have also this problem:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/429748

With 10.35. No disassociates/reassociates, but I

On Wed, Sep 23, 2009 at 12:11 PM, Matt Behrens <email address hidden> wrote:

> Seems to, based on a few hours of use each night for two or three nights
> now. And I just updated to 10.35 this morning which still seems okay.
>
> That's why I'm curious how everyone else is doing.
>
> Again, no patches, replacement of NetworkManager, backports, etc. are in
> play.
>
> --
> ath9k disassociates/reassociates a lot
> https://bugs.launchpad.net/bugs/414560
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Marco Lorenzo Crociani,
<email address hidden>
Telefono: +39 02320622509
Fax: +39 02700540121

By way of update, I am seeing a few dis/reassociations in the dmesg:

[ 2256.008126] wlan0: no probe response from AP 00:15:e9:13:47:60 - disassociating
[ 2257.391225] wlan0: authenticate with AP 00:15:e9:13:47:60
[ 2257.394249] wlan0: authenticated
[ 2257.394262] wlan0: associate with AP 00:15:e9:13:47:60
[ 2257.398239] wlan0: RX ReassocResp from 00:15:e9:13:47:60 (capab=0x431 status=0 aid=1)
[ 2257.398252] wlan0: associated
[ 4476.009115] wlan0: no probe response from AP 00:15:e9:13:47:60 - disassociating
[ 4477.387976] wlan0: authenticate with AP 00:15:e9:13:47:60
[ 4477.390436] wlan0: authenticated
[ 4477.390458] wlan0: associate with AP 00:15:e9:13:47:60
[ 4477.393063] wlan0: RX ReassocResp from 00:15:e9:13:47:60 (capab=0x431 status=0 aid=1)
[ 4477.393075] wlan0: associated
[ 6971.024115] wlan0: no probe response from AP 00:15:e9:13:47:60 - disassociating
[ 6972.403064] wlan0: authenticate with AP 00:15:e9:13:47:60
[ 6972.405772] wlan0: authenticated
[ 6972.405793] wlan0: associate with AP 00:15:e9:13:47:60
[ 6972.408426] wlan0: RX ReassocResp from 00:15:e9:13:47:60 (capab=0x431 status=0 aid=1)
[ 6972.408446] wlan0: associated

but these are around 30-40 min. apart and aren't causing any performance problems that I can tell. They may, in fact, be completely normal?

I've tried my system all over my house in the past few days. I haven't noticed any of the problems that have otherwise plagued me since I moved from jaunty to karmic alpha4.

I've been using wicd instead of plasma-widget-networkmanagement, and I still see some (much minor) disconnects with the last kernel version. Also, on resume I have to remove and modprobe the ath9k module again, or I'll have to wait a few minutes until it no longer shows as busy when I try to do a "iwlist scan",

I tried installing network-manager and plasma-widget-networkmanagement again to check if I still had the frequent disconnects problem, but there seems to be some incompatibility between them right now.

Looks like I spoke too soon. Left it asleep all night and on resume it was back to its old tricks.

Sorry if I got anyone excited. :)

I just got a new work laptop a couple of weeks ago and have been having nothing but trouble with the wireless card.

02:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01)

using the ath9k driver.

Depending on the access point I am using, I get a wide variety of results and stability.

At home I have a Buffalo WHR-HP-G54 with the Tomato firmware. It is "reasonably" stable, it disconnects every hour or so without cause which is far better than anywhere else I've used this.

At work I have had two different routers that I am unsure of models on, one was a NetGear and the other is a D-Link. With both I lose connection constantly and have to reassociate. This happens at least once every half hour.

At another location I have a Linksys WRT54GL. It is almost completely and utterly unusable. The wireless never disassociates, it just stops working completely. I have to manually re-associate with the access point for the connection to start working again.

On the Linksys it is really strange because some services continue working while others just die, and eventually they all die. And this happens multiple times every half hour. Often I don't even have a connection the instant I connect to the access point.

This is REALLY bad. Atheros cards have been available with an open source driver for a long time and there are tons of open bugs in Launchpad about this same kind of issue with the ath9k driver.

It's pretty obvious that trying to use wireless is a PITA, and this should
be treated as accordingly.

Linux dv5 2.6.31-11-generic #36-Ubuntu SMP Fri Sep 25 06:37:23 UTC 2009
x86_64 GNU/Linux

[ 1158.012067] wlan0: no probe response from AP 00:1e:ab:00:8c:5b -
disassociating
[ 1158.380507] ath9k: DMA failed to stop in 10 ms AR_CR=0x00000024
AR_DIAG_SW=0x40000020
[ 1164.012015] wlan0: authenticate with AP 00:1e:ab:00:8c:5b
[ 1164.015940] wlan0: authenticated
[ 1164.015952] wlan0: associate with AP 00:1e:ab:00:8c:5b
[ 1164.027187] wlan0: RX ReassocResp from 00:1e:ab:00:8c:5b (capab=0x411
status=0 aid=1)
[ 1164.027195] wlan0: associated
[ 2046.012578] wlan0: no probe response from AP 00:1e:ab:00:8c:5b -
disassociating
[ 2052.028859] wlan0: authenticate with AP 00:1e:ab:00:8c:5b
[ 2052.031227] wlan0: authenticated
[ 2052.031247] wlan0: associate with AP 00:1e:ab:00:8c:5b
[ 2052.044058] wlan0: RX ReassocResp from 00:1e:ab:00:8c:5b (capab=0x411
status=0 aid=1)
[ 2052.044074] wlan0: associated
[ 2055.522180] wlan0: disassociated (Reason: 15)
[ 2056.520082] wlan0: associate with AP 00:1e:ab:00:8c:5b
[ 2056.720085] wlan0: associate with AP 00:1e:ab:00:8c:5b
[ 2056.920072] wlan0: associate with AP 00:1e:ab:00:8c:5b
[ 2057.120067] wlan0: association with AP 00:1e:ab:00:8c:5b timed out
[ 2063.689519] wlan0: authenticate with AP 00:1e:ab:00:8c:5b
[ 2063.690747] wlan0: authenticated
[ 2063.690758] wlan0: associate with AP 00:1e:ab:00:8c:5b
[ 2063.703636] wlan0: RX ReassocResp from 00:1e:ab:00:8c:5b (capab=0x411
status=0 aid=1)
[ 2063.703650] wlan0: associated
[ 2524.084119] wlan0: no probe response from AP 00:1e:ab:00:8c:5b -
disassociating
[ 2530.068508] wlan0: authenticate with AP 00:1e:ab:00:8c:5b
[ 2530.072083] wlan0: authenticated
[ 2530.072083] wlan0: associate with AP 00:1e:ab:00:8c:5b
[ 2530.084345] wlan0: RX ReassocResp from 00:1e:ab:00:8c:5b (capab=0x411
status=0 aid=1)
[ 2530.084353] wlan0: associated
[ 2534.188513] wlan0: disassociated (Reason: 15)
[ 2535.184574] wlan0: associate with AP 00:1e:ab:00:8c:5b
[ 2535.384697] wlan0: associate with AP 00:1e:ab:00:8c:5b
[ 2535.584722] wlan0: associate with AP 00:1e:ab:00:8c:5b
[ 2535.784593] wlan0: association with AP 00:1e:ab:00:8c:5b timed out
[ 2541.692508] wlan0: authenticate with AP 00:1e:ab:00:8c:5b
[ 2541.693922] wlan0: authenticated
[ 2541.693930] wlan0: associate with AP 00:1e:ab:00:8c:5b
[ 2541.706806] wlan0: RX ReassocResp from 00:1e:ab:00:8c:5b (capab=0x411
status=0 aid=1)
[ 2541.706814] wlan0: associated
[ 2952.427742] wlan0: disassociating by local choice (reason=3)
[ 2952.504506] ath9k: DMA failed to stop in 10 ms AR_CR=0x00000024
AR_DIAG_SW=0x40000020
[ 2953.516505] ath9k: DMA failed to stop in 10 ms AR_CR=0x00000024
AR_DIAG_SW=0x40000020
[ 2953.736507] ath9k: DMA failed to stop in 10 ms AR_CR=0x00000024
AR_DIAG_SW=0x40000020
[ 2953.952509] ath9k: DMA failed to stop in 10 ms AR_CR=0x00000024
AR_DIAG_SW=0x40000020
[ 2954.168508] ath9k: DMA failed to stop in 10 ms AR_CR=0x00000024
AR_DIAG_SW=0x40000020
[ 2954.384508] ath9k: DMA failed to stop in 10 ms AR_CR=0x00000024
AR_DIAG_SW=0x40000020
[ 2954.600508] ath9k: DMA failed to stop in 10 ms AR_CR=0x00000024
AR_DIAG_SW=0x40000020
[ 2954.8205...

@Tuomas: Try applying frank's patch. Patch worked wonders for me. Before that I had same issues as you.

https://bugs.edge.launchpad.net/linux/+bug/414560/comments/20
http://bugzilla.kernel.org/show_bug.cgi?id=13807

Is that package ok also if it is for 2.6.31-10.12 and now kernel version is
2.6.31.11.22?

On Mon, Sep 28, 2009 at 12:07 PM, vaib <email address hidden> wrote:

> @Tuomas: Try applying frank's patch. Patch worked wonders for me. Before
> that I had same issues as you.
>
> https://bugs.edge.launchpad.net/linux/+bug/414560/comments/20
> http://bugzilla.kernel.org/show_bug.cgi?id=13807
>
> --
> ath9k disassociates/reassociates a lot
> https://bugs.launchpad.net/bugs/414560
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Marco Lorenzo Crociani,
<email address hidden>
Telefono: +39 02320622509
Fax: +39 02700540121

I am using vanilla kernel (2.6.31.1), not from ubuntu. I was searching net when I came across this thread.
Nevertheless you can download kernel source from ubuntu and check manually whether they have used it or not. This patch basically disables power save and rfkill feature in ath9k. It will comment powersave options in config file and comment one function in ath9k. You can manually look at patch and use it.

hi,
i'll try to rebuild my PPA packages tomorrow (or at least check if it is still uptodate with latest kernel version)

btw vaib: i'll try to rebuild my packages with only the disable rfkill polling part as you suggest that the other part is irrelevant.

i also still have (with patched kernel) very occasional connection drops: my internet stops working, networkmanager doesn't see that the connection dropped and i have to re-click the icon of my WLAN in networkmanager to get connection again (no module reloading needed). I think it happens once a day on average.

Also as in comment 23 user reported ath9k was working with powersave+rfkill disabled. In my case I am having absolute 0 drops and sustained 2.8 MBps transfer speed after patch. My signal strength reported by iwconfig = 37/70.

Running a current wireless-testing, it appears that commit c93f7c14 fixes a lot of the random disconnects for me. But I still get hangs under sustained transfers, with the "DMA failed to stop" message in the kernel log.

hi,

i've updated my PPA ( https://launchpad.net/~frank-dekervel/+archive/ppa/ ) to latest kernel version. The commit above (c93f7c14) also seems to remove the same rfkill polling, so i have removed that part of my patch. My PPA is still built with disabled DEFAULT_PS, i guess the official ubuntu linux-backports-modules will soon be "good"..

greetings,
Frank

before you try the PPA above, also try the official linux-backports-modules-karmic. it seems that the official one now has a fairly recent wireless-testing.

What I've noticed after about a day's usage was that there were no more messages in dmesg, but there would still be periods of zero activity over wireless (about 10-15 seconds every few minutes).

So I wouldn't say a "real" fix has been released.

Edit: I just found that it correlates with "wpa_supplicant[1213]: CTRL-EVENT-SCAN-RESULTS" entries in the syslog.

I remember reading something about the driver/interface not being able to "multitask" and scan while being active at the same time - so a scan causes the activity to be paused/broken.

This is not fixed, its better with the backports and updates connection no longer drops but like Roy Lee said, connection speed goes to zero every few minutes.

Its a real annoyance on networks like bittorrent because it takes a bit of time for peers to reestablish full connection speed and so it lowers the average speed a lot.

Thank you!

Not fixed in backports due to the random lockups which occur

I've since switched to WICD which has been flawless for the last 18 hours.
To be fair, the problems might be due to NetworkManager or wpa_supplicant.
NM keeps wpa_supplicant constantly scanning, while WICD stops scanning once a connection has been established.
If NM has an option to stop scanning once a connection has been established, that would be better. It wouldn't make sense to have a connection established and still keep scanning for new networks. Not many would want to have their current connection broken just to switch to another connection with a X% stronger signal.
I've really want to go back to NM though, as it has 3G Modem support which is great.

Is it me or has there been a general regression in wireless performance with the 2.6.31 kernel. I have noticed worse performance with the zd1211rw driver on my desktop machine too and wondered if it was just a coincidence that I have been unlucky in using two wireless drivers that happen to have problems or whether there are wider issues with wireless performance generally. This may not be the correct place to discuss it but just thought I'd add my observation.

@Roy Lee - I share your sentiments, NetworkManager adds 3 seconds to pings (and other packets I assume) every couple of minutes; WICD doesn't exhibit this behaviour. It is very noticeable when browsing etc., and happens on the ath5k chip I use on another laptop too. Why not let the user decide when to scan?

On another note, the backports modules does seem to have fixed the poor wireless performance for me.

Apparently the issue has finally been solved for kernel 2.6.32 and in the latest ath9k drivers from compat-wireless. Truly solved, it's not a trick like disabling power saving. https://bugzilla.redhat.com/show_bug.cgi?id=538792

Urgh, a new kernel can sometimes take very long to get into the official Ubuntu repositories.
Although I wonder if the problem with AR928X adapters not being able to conduct regular wireless activity and scanning for new networks concurrently is a driver issue or the adapter's inherent fault. I'll switch into Vista in a moment to download something and then do a refresh of the wireless network listing to see if it exhibits the same behaviour.

We won't see 2.6.32 until Lucid Lynx at the earliest

A week ago I upgraded Ubuntu 9.10 to 10.04 (Lucid Lynx) and since then I haven't had any problem with AR928X when using kernel 2.6.32. Currently I'm testing kernel 2.6.33-rc2 and it works well too.
In Ubuntu 9.10 with kernel 2.6.31 I had to use kernel backport.

It's good news for common users that at least LTS distribution will have fixed it.

Happy 2010 everyone! Frustrations arising from this bug shouldn't deter/dampen the mood. :)

I guess it's only another 4 months to wait before Lucid LTS, so I'm ok to wait while using WICD.

Just to share, I've experienced the system hang twice so far while using the two linux-backports-modules-* packages, both times happening while:
- wireless not being connected to an AP
- using a USB 3G modem
- performing general OpenOffice editing / light surfing of the internet.
No significant entry found in syslog.

There have also been two incidents when the system failed to boot properly, right after grub. I'm not sure if it that was due to the two backports modules though - I did not check up on syslog during the subsequent boots.

I've since removed the two backports modules, and will post again should I experience any further failed bootups or lockups of the system.

Meanwhile, fingers crossed the new kernel will make its way into the backports soon.

Just wanted to toss it out there for the many subscribers to this bug (I stopped subscribing some time ago since I wasn't actually losing my connection anymore) that lucid with 2.6.32 does indeed seem to be good in this regard.

I have 2.6.32.3 installed on Karmic, and my problems with this issue have gone away. Would it be of any use to try to bisect the kernel to provide a patch here for Karmic, or is someone already working on such a thing? (I ask because it is pretty important that I get back to the Karmic kernel, because VirtualBox in Karmic does not work with 2.6.32.3, and I use it a good amount.)

On Monday 11 Jan 2010 9:56:47 pm Michael B. Trausch wrote:
> I have 2.6.32.3 installed on Karmic, and my problems with this issue
> have gone away. Would it be of any use to try to bisect the kernel to
> provide a patch here for Karmic, or is someone already working on such a
> thing? (I ask because it is pretty important that I get back to the
> Karmic kernel, because VirtualBox in Karmic does not work with 2.6.32.3,
> and I use it a good amount.)
>
>

Slightly off-topic, but you could simply do "sudo service vboxdrv setup"
or "sudo invoke-rc.d vboxdrv setup" to recompile the VBox drivers
after updating the kernel.
This works unless the kernel API is changed drastically.

I use it all the time.

Kunal

On Tue, Jan 12, 2010 at 6:20 AM, Kunal Gangakhedkar
<email address hidden> wrote:
> On Monday 11 Jan 2010 9:56:47 pm Michael B. Trausch wrote:
>> I have 2.6.32.3 installed on Karmic, and my problems with this issue
>> have gone away.  Would it be of any use to try to bisect the kernel to
>> provide a patch here for Karmic, or is someone already working on such a
>> thing?  (I ask because it is pretty important that I get back to the
>> Karmic kernel, because VirtualBox in Karmic does not work with 2.6.32.3,
>> and I use it a good amount.)
>>
>
> Slightly off-topic, but you could simply do "sudo service vboxdrv setup"
> or "sudo invoke-rc.d vboxdrv setup" to recompile the VBox drivers
> after updating the kernel.
> This works unless the kernel API is changed drastically.
>
> I use it all the time.

Right, I am aware of how to do that. DKMS is in Ubuntu to make this
simpler (thanks, Dell!), since DKMS manages the module builds. The
problem is similar to the NVIDIA module problem back with 2.6.28,
where the kernel API changed in some way that was never guaranteed to
be stable in the first place.

I wound up simply updating VBox, but still the core issue here is this:

If I bisect the kernel to attempt to isolate a patch that fixes ath9k
in Karmic's kernel, will an Ubuntu Kernel Team member take that patch
and get it into Ubuntu? If that's not a guaranteed "Yes", I am not
going to try, because I have my system working pretty well for me and
I am kind of tired of submitting debdiffs and them getting ignored
half the time. I don't figure that this will be an easy task, but I
am willing to do it *if* I know for sure that it will be of benefit to
others.

   --- Mike

With 2.6.32.3 the situation is better but with problems.
After some hours (8? 10?) I come back to the PC and the connection was lost.
The ping command that pings every 3 seconds my router was giving:

ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available

Restarting network-manager and umounting/mounting the module doesn't
fix the connection.

Marco

On Tue, Jan 12, 2010 at 5:21 PM, Michael B. Trausch <email address hidden> wrote:
> On Tue, Jan 12, 2010 at 6:20 AM, Kunal Gangakhedkar
> <email address hidden> wrote:
>> On Monday 11 Jan 2010 9:56:47 pm Michael B. Trausch wrote:
>>> I have 2.6.32.3 installed on Karmic, and my problems with this issue
>>> have gone away.  Would it be of any use to try to bisect the kernel to
>>> provide a patch here for Karmic, or is someone already working on such a
>>> thing?  (I ask because it is pretty important that I get back to the
>>> Karmic kernel, because VirtualBox in Karmic does not work with 2.6.32.3,
>>> and I use it a good amount.)
>>>
>>
>> Slightly off-topic, but you could simply do "sudo service vboxdrv setup"
>> or "sudo invoke-rc.d vboxdrv setup" to recompile the VBox drivers
>> after updating the kernel.
>> This works unless the kernel API is changed drastically.
>>
>> I use it all the time.
>
> Right, I am aware of how to do that. DKMS is in Ubuntu to make this
> simpler (thanks, Dell!), since DKMS manages the module builds.  The
> problem is similar to the NVIDIA module problem back with 2.6.28,
> where the kernel API changed in some way that was never guaranteed to
> be stable in the first place.
>
> I wound up simply updating VBox, but still the core issue here is this:
>
> If I bisect the kernel to attempt to isolate a patch that fixes ath9k
> in Karmic's kernel, will an Ubuntu Kernel Team member take that patch
> and get it into Ubuntu?  If that's not a guaranteed "Yes", I am not
> going to try, because I have my system working pretty well for me and
> I am kind of tired of submitting debdiffs and them getting ignored
> half the time.  I don't figure that this will be an easy task, but I
> am willing to do it *if* I know for sure that it will be of benefit to
> others.
>
>   --- Mike
>
> --
> ath9k disassociates/reassociates a lot
> https://bugs.launchpad.net/bugs/414560
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Hrm. I haven't run into any such issue yet, and I'm going on two days
of uptime. That said, I did wind up having a nonrelated issue with
the wireless access point here, it apparently does not like running
traffic at full capacity on the WLAN and overheated and I had to fall
back to using wired while it was unplugged. But once it cooled down
and was plugged back in, I was able to get back on again and all was
well…

Anything in your dmesg or /var/log/kern.log or /var/log/daemon.log
that shows any issues with your WLAN under 2.6.32.3?

   --- Mike

On Wed, Jan 13, 2010 at 8:05 AM, Tyrael <email address hidden> wrote:
> With 2.6.32.3 the situation is better but with problems.
> After some hours (8? 10?) I come back to the PC and the connection was lost.
> The ping command that pings every 3 seconds my router was giving:
>
> ping: sendmsg: No buffer space available
> ping: sendmsg: No buffer space available
> ping: sendmsg: No buffer space available
>
> Restarting network-manager and umounting/mounting the module doesn't
> fix the connection.
>
> Marco
>
> On Tue, Jan 12, 2010 at 5:21 PM, Michael B. Trausch <email address hidden> wrote:
>> On Tue, Jan 12, 2010 at 6:20 AM, Kunal Gangakhedkar
>> <email address hidden> wrote:
>>> On Monday 11 Jan 2010 9:56:47 pm Michael B. Trausch wrote:
>>>> I have 2.6.32.3 installed on Karmic, and my problems with this issue
>>>> have gone away.  Would it be of any use to try to bisect the kernel to
>>>> provide a patch here for Karmic, or is someone already working on such a
>>>> thing?  (I ask because it is pretty important that I get back to the
>>>> Karmic kernel, because VirtualBox in Karmic does not work with 2.6.32.3,
>>>> and I use it a good amount.)
>>>>
>>>
>>> Slightly off-topic, but you could simply do "sudo service vboxdrv setup"
>>> or "sudo invoke-rc.d vboxdrv setup" to recompile the VBox drivers
>>> after updating the kernel.
>>> This works unless the kernel API is changed drastically.
>>>
>>> I use it all the time.
>>
>> Right, I am aware of how to do that. DKMS is in Ubuntu to make this
>> simpler (thanks, Dell!), since DKMS manages the module builds.  The
>> problem is similar to the NVIDIA module problem back with 2.6.28,
>> where the kernel API changed in some way that was never guaranteed to
>> be stable in the first place.
>>
>> I wound up simply updating VBox, but still the core issue here is this:
>>
>> If I bisect the kernel to attempt to isolate a patch that fixes ath9k
>> in Karmic's kernel, will an Ubuntu Kernel Team member take that patch
>> and get it into Ubuntu?  If that's not a guaranteed "Yes", I am not
>> going to try, because I have my system working pretty well for me and
>> I am kind of tired of submitting debdiffs and them getting ignored
>> half the time.  I don't figure that this will be an easy task, but I
>> am willing to do it *if* I know for sure that it will be of benefit to
>> others.
>>
>>   --- Mike
>>
>> --
>> ath9k disassociates/reassociates a lot
>> https://bugs.launchpad.net/bugs/414560
>> You received this bug notification because you are a direct subscriber
>> of the bug.
>>
>
> --
> ath9k disassociates/reassociates a lot
> https://bugs.launchpad.ne...

Loaded up a Lucid live CD today, I was able to get sustained 1.1 Mb/sec data transfers. Something I hadn't seen since Jaunty, Hurray!

Just compiled a custom kernel from Linus' git tree (2.6.33-rc4)
and ath9k works without much ado.
Have an uptime of ~16 hrs now without a problem.

Even suspend-resume works nicely :)

Thought I'd share it with you all.

Thanks,
Kunal

Just to confirm, the backported Lucid kernel has solved the problem on my machine, EeePC 1000HE with AR928X.
Lucid backported 2.6.32-11.15 (based on 2.6.32.4)
https://launchpad.net/~guido-iodice/+archive/best-intel
Everything seems to work fine, no disconnections reported by dmesg, excellent link quality and a constant 3.0 MB/sec transfer rate.

Just to confirm once again, I updated yesterday to Lucid Lynx, and
with the 2.6.32 kernel the problem went away (though now I've got all
the problems derived from being using an Alpha version :P).

Regards,

Bdk

2010/1/25 gajm <email address hidden>:
> Just to confirm, the backported Lucid kernel has solved the problem on my machine, EeePC 1000HE with AR928X.
> Lucid backported 2.6.32-11.15 (based on 2.6.32.4)
> https://launchpad.net/~guido-iodice/+archive/best-intel
> Everything seems to work fine, no disconnections reported by dmesg, excellent link quality and a constant 3.0 MB/sec transfer rate.
>
> --
> ath9k disassociates/reassociates a lot
> https://bugs.launchpad.net/bugs/414560
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Linux Kernel: Fix Released
> Status in “linux-backports-modules-2.6.31” package in Ubuntu: Confirmed
>
> Bug description:
> I cannot find any rhyme or reason to this, but my
>
> 01:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01)
>
> seems to like to disassociate/reassociate a lot since I started testing karmic as of alpha 4.
>
> A typical dmesg excerpt:
>
> [ 1881.988111] wlan0: no probe response from AP 00:15:e9:13:47:60 - disassociating
> [ 1883.367859] wlan0: authenticate with AP 00:15:e9:13:47:60
> [ 1883.370161] wlan0: authenticated
> [ 1883.370181] wlan0: associate with AP 00:15:e9:13:47:60
> [ 1883.372802] wlan0: RX ReassocResp from 00:15:e9:13:47:60 (capab=0x431 status=0 aid=1)
> [ 1883.372822] wlan0: associated
> [ 1892.008117] wlan0: no probe response from AP 00:15:e9:13:47:60 - disassociating
> [ 1893.385338] wlan0: authenticate with AP 00:15:e9:13:47:60
> [ 1893.385521] wlan0: authenticate with AP 00:15:e9:13:47:60
> [ 1893.388175] wlan0: authenticated
> [ 1893.388196] wlan0: associate with AP 00:15:e9:13:47:60
> [ 1893.391563] wlan0: RX ReassocResp from 00:15:e9:13:47:60 (capab=0x431 status=0 aid=1)
> [ 1893.391585] wlan0: associated
> [ 1926.988135] wlan0: no probe response from AP 00:15:e9:13:47:60 - disassociating
> [ 1928.365306] wlan0: authenticate with AP 00:15:e9:13:47:60
> [ 1928.367426] wlan0: authenticated
> [ 1928.367442] wlan0: associate with AP 00:15:e9:13:47:60
> [ 1928.370948] wlan0: RX ReassocResp from 00:15:e9:13:47:60 (capab=0x431 status=0 aid=1)
> [ 1928.370969] wlan0: associated
> [ 1966.988114] wlan0: no probe response from AP 00:15:e9:13:47:60 - disassociating
> [ 1968.366568] wlan0: authenticate with AP 00:15:e9:13:47:60
> [ 1968.368624] wlan0: authenticated
> [ 1968.368643] wlan0: associate with AP 00:15:e9:13:47:60
> [ 1968.371872] wlan0: RX ReassocResp from 00:15:e9:13:47:60 (capab=0x431 status=0 aid=1)
> [ 1968.371893] wlan0: associated
>
> Performance drops significantly when this starts going on.  At times it becomes impossible to look up hosts, etc.  Other times, it will run fine for hours on end.
>
> ProblemType: Bug
> AplayDevices:
>  **** List of PLAYBACK Hardware Devices ****
>  card 0: Intel [HDA Intel], device 0: ALC269 Analog [ALC269 Analog]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> Architecture: i386
> ArecordDevices:
>  **** List of CAPTU...

I upgraded to Lucid Lynx to see if it helped as it has for others here. It did not, it made things worse. I tried switching over to wicd (it helped on 9.10), but even that is hopeless now. I have 10 seconds of connectivity before I loose the connection for a minute or two.

Asus EEE PC 1000HE, 32-bit, 802.11n router, WPA in use.

Please disregard my previous post. I was bit by
https://bugs.launchpad.net/ubuntu/+source/grub/+bug/470490
and were unknowingly running a karmic kernel in my lucid installation. Looks much better now with 2.6.32.

With 2.6.32-02063208-generic #02063208 SMP Wed Feb 10 10:10:27 UTC 2010 x86_64 GNU/Linux (http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32.8/)
I still have problems. The connection works only for some time (10 minutes? 15?) than also if ping to router works html navigation doesn't work.

dmesg
[ 80.170140] cfg80211: Calling CRDA to update world regulatory domain
[ 80.248137] cfg80211: World regulatory domain updated:
[ 80.248145] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 80.248153] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 80.248160] (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 80.248167] (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 80.248174] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 80.248180] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 80.284909] ACPI: PCI Interrupt Link [LN3A] enabled at IRQ 19
[ 80.284923] alloc irq_desc for 19 on node -1
[ 80.284930] alloc kstat_irqs on node -1
[ 80.284947] ath9k 0000:04:00.0: PCI INT A -> Link[LN3A] -> GSI 19 (level, low) -> IRQ 19
[ 80.284964] ath9k 0000:04:00.0: setting latency timer to 64
[ 80.712120] ath: EEPROM regdomain: 0x60
[ 80.712128] ath: EEPROM indicates we should expect a direct regpair map
[ 80.712137] ath: Country alpha2 being used: 00
[ 80.712141] ath: Regpair used: 0x60
[ 80.768021] phy0: Selected rate control algorithm 'ath9k_rate_control'
[ 80.770603] Registered led device: ath9k-phy0::radio
[ 80.770816] Registered led device: ath9k-phy0::assoc
[ 80.771612] Registered led device: ath9k-phy0::tx
[ 80.771871] Registered led device: ath9k-phy0::rx
[ 80.771933] phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0: mem=0xffffc90003200000, irq=19
[ 80.831098] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 88.219743] wlan0: deauthenticating from 00:22:6b:62:72:0a by local choice (reason=3)
[ 88.228706] wlan0: direct probe to AP 00:22:6b:62:72:0a (try 1)
[ 88.423788] wlan0: direct probe to AP 00:22:6b:62:72:0a (try 2)
[ 88.623779] wlan0: direct probe to AP 00:22:6b:62:72:0a (try 3)
[ 88.823782] wlan0: direct probe to AP 00:22:6b:62:72:0a timed out
[ 89.788421] ath9k: Failed to stop TX DMA in 100 msec after killing last frame
[ 89.788443] ath9k: Unable to stop TxDMA. Reset HAL!
[ 99.408412] wlan0: direct probe to AP 00:22:6b:62:72:0a (try 1)
[ 99.415011] wlan0: direct probe responded
[ 99.415022] wlan0: authenticate with AP 00:22:6b:62:72:0a (try 1)
[ 99.417212] wlan0: authenticated
[ 99.417252] wlan0: associate with AP 00:22:6b:62:72:0a (try 1)
[ 99.421767] wlan0: RX AssocResp from 00:22:6b:62:72:0a (capab=0x411 status=0 aid=1)
[ 99.421775] wlan0: associated
[ 99.433445] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

Unfortunately linux-backports-modules-2.6.31 (running kernel 2.6.31-19-generic) does only solve some of the issues on the hardware of my flatmate, e.g. radio level seems to be shown alright now. But the wifi connection is still not very stable using both networkmanager and wicd. wicd seems to be more stable though.

What I have experienced while using wicd is that whenever the wifi list is refreshed the bandwith of ongoing downloads will drop to zero but the connection will remain. As far as I know, network-manager is running such scans automatically in background and at that times the connection may break then resulting in a less stable experience on the machine we have here.

$ lspci|grep Wire
03:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01)

This still happens in completely updated as of this second Lucid. Also, the linked upstream kernel bug is marked as closed, but the comments seems to indicate that there are still issues.

Mine's running really well in Lucid and in Karmic with the backported driver.

mine runs but performance is just slow. painfully slow at times.
trying to download anything over 2MB or so is near impossible.

On Thu, Apr 8, 2010 at 2:02 PM, notoriousdbp
<email address hidden> wrote:
> Mine's running really well in Lucid and in Karmic with the backported
> driver.
>
> --
> ath9k disassociates/reassociates a lot
> https://bugs.launchpad.net/bugs/414560
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in The Linux Kernel: Fix Released
> Status in “linux-backports-modules-2.6.31” package in Ubuntu: Confirmed
>
> Bug description:
> I cannot find any rhyme or reason to this, but my
>
> 01:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01)
>
> seems to like to disassociate/reassociate a lot since I started testing karmic as of alpha 4.
>
> A typical dmesg excerpt:
>
> [ 1881.988111] wlan0: no probe response from AP 00:15:e9:13:47:60 - disassociating
> [ 1883.367859] wlan0: authenticate with AP 00:15:e9:13:47:60
> [ 1883.370161] wlan0: authenticated
> [ 1883.370181] wlan0: associate with AP 00:15:e9:13:47:60
> [ 1883.372802] wlan0: RX ReassocResp from 00:15:e9:13:47:60 (capab=0x431 status=0 aid=1)
> [ 1883.372822] wlan0: associated
> [ 1892.008117] wlan0: no probe response from AP 00:15:e9:13:47:60 - disassociating
> [ 1893.385338] wlan0: authenticate with AP 00:15:e9:13:47:60
> [ 1893.385521] wlan0: authenticate with AP 00:15:e9:13:47:60
> [ 1893.388175] wlan0: authenticated
> [ 1893.388196] wlan0: associate with AP 00:15:e9:13:47:60
> [ 1893.391563] wlan0: RX ReassocResp from 00:15:e9:13:47:60 (capab=0x431 status=0 aid=1)
> [ 1893.391585] wlan0: associated
> [ 1926.988135] wlan0: no probe response from AP 00:15:e9:13:47:60 - disassociating
> [ 1928.365306] wlan0: authenticate with AP 00:15:e9:13:47:60
> [ 1928.367426] wlan0: authenticated
> [ 1928.367442] wlan0: associate with AP 00:15:e9:13:47:60
> [ 1928.370948] wlan0: RX ReassocResp from 00:15:e9:13:47:60 (capab=0x431 status=0 aid=1)
> [ 1928.370969] wlan0: associated
> [ 1966.988114] wlan0: no probe response from AP 00:15:e9:13:47:60 - disassociating
> [ 1968.366568] wlan0: authenticate with AP 00:15:e9:13:47:60
> [ 1968.368624] wlan0: authenticated
> [ 1968.368643] wlan0: associate with AP 00:15:e9:13:47:60
> [ 1968.371872] wlan0: RX ReassocResp from 00:15:e9:13:47:60 (capab=0x431 status=0 aid=1)
> [ 1968.371893] wlan0: associated
>
> Performance drops significantly when this starts going on.  At times it becomes impossible to look up hosts, etc.  Other times, it will run fine for hours on end.
>
> ProblemType: Bug
> AplayDevices:
>  **** List of PLAYBACK Hardware Devices ****
>  card 0: Intel [HDA Intel], device 0: ALC269 Analog [ALC269 Analog]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> Architecture: i386
> ArecordDevices:
>  **** List of CAPTURE Hardware Devices ****
>  card 0: Intel [HDA Intel], device 0: ALC269 Analog [ALC269 Analog]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> AudioDevicesInUse:
>  USER        PID ACCESS COMMAND
>  /dev/snd/controlC0:  matt       3290 F.... pulseaudio
> CRDA: Error: [Errno 2] No such file or ...

I am now running Ubuntu Lucid Lynx (2.6.32-19-generic #28-Ubuntu SMP Thu Apr 1 10:39:41 UTC 2010 x86_64 GNU/Linux) with the latest updates, and have no problems with my WIFI connection (BT is now running w/o problems). I updated to Lucid just because of this problem, and now it is running quite stable.

your adapter is a "AR9285" ????

2010/4/8 Jorge García <email address hidden>:
> I am now running Ubuntu Lucid Lynx (2.6.32-19-generic #28-Ubuntu SMP Thu
> Apr 1 10:39:41 UTC 2010 x86_64 GNU/Linux) with the latest updates, and
> have no problems with my WIFI connection (BT is now running w/o
> problems). I updated to Lucid just because of this problem, and now it
> is running quite stable.
>
> --
> ath9k disassociates/reassociates a lot
> https://bugs.launchpad.net/bugs/414560
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in The Linux Kernel: Fix Released
> Status in “linux-backports-modules-2.6.31” package in Ubuntu: Confirmed
>
> Bug description:
> I cannot find any rhyme or reason to this, but my
>
> 01:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01)
>
> seems to like to disassociate/reassociate a lot since I started testing karmic as of alpha 4.
>
> A typical dmesg excerpt:
>
> [ 1881.988111] wlan0: no probe response from AP 00:15:e9:13:47:60 - disassociating
> [ 1883.367859] wlan0: authenticate with AP 00:15:e9:13:47:60
> [ 1883.370161] wlan0: authenticated
> [ 1883.370181] wlan0: associate with AP 00:15:e9:13:47:60
> [ 1883.372802] wlan0: RX ReassocResp from 00:15:e9:13:47:60 (capab=0x431 status=0 aid=1)
> [ 1883.372822] wlan0: associated
> [ 1892.008117] wlan0: no probe response from AP 00:15:e9:13:47:60 - disassociating
> [ 1893.385338] wlan0: authenticate with AP 00:15:e9:13:47:60
> [ 1893.385521] wlan0: authenticate with AP 00:15:e9:13:47:60
> [ 1893.388175] wlan0: authenticated
> [ 1893.388196] wlan0: associate with AP 00:15:e9:13:47:60
> [ 1893.391563] wlan0: RX ReassocResp from 00:15:e9:13:47:60 (capab=0x431 status=0 aid=1)
> [ 1893.391585] wlan0: associated
> [ 1926.988135] wlan0: no probe response from AP 00:15:e9:13:47:60 - disassociating
> [ 1928.365306] wlan0: authenticate with AP 00:15:e9:13:47:60
> [ 1928.367426] wlan0: authenticated
> [ 1928.367442] wlan0: associate with AP 00:15:e9:13:47:60
> [ 1928.370948] wlan0: RX ReassocResp from 00:15:e9:13:47:60 (capab=0x431 status=0 aid=1)
> [ 1928.370969] wlan0: associated
> [ 1966.988114] wlan0: no probe response from AP 00:15:e9:13:47:60 - disassociating
> [ 1968.366568] wlan0: authenticate with AP 00:15:e9:13:47:60
> [ 1968.368624] wlan0: authenticated
> [ 1968.368643] wlan0: associate with AP 00:15:e9:13:47:60
> [ 1968.371872] wlan0: RX ReassocResp from 00:15:e9:13:47:60 (capab=0x431 status=0 aid=1)
> [ 1968.371893] wlan0: associated
>
> Performance drops significantly when this starts going on.  At times it becomes impossible to look up hosts, etc.  Other times, it will run fine for hours on end.
>
> ProblemType: Bug
> AplayDevices:
>  **** List of PLAYBACK Hardware Devices ****
>  card 0: Intel [HDA Intel], device 0: ALC269 Analog [ALC269 Analog]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> Architecture: i386
> ArecordDevices:
>  **** List of CAPTURE Hardware Devices ****
>  card 0: Intel [HDA Intel], device 0: ALC269 Analog [ALC269 Analog]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> AudioDevicesInUse:
>  USER        PID ACCESS COMMAND
>  /dev...

Hi,

lspci output:

06:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01)

and lsmod (only the lines regarding ath9k):

ath9k 329077 0
mac80211 237604 1 ath9k
ath 9723 1 ath9k
cfg80211 148386 3 ath9k,mac80211,ath
led_class 3732 2 ath9k,sdhci

Regards.

On a slightly related note - I have a number of status update daemons on my network that send status updates using UDP broadcast. They generally only broadcast each update packet once. (UPS monitoring, a few other misc things.) With NetworkManager doing its periodic scans, these UDP broadcast packets are lost / not received on my laptop if they're sent while NM is scanning. This is extremely annoying, because that means I lose important information about the health of my network. The only way to get this data reliably is by turning off background scanning when the device is already connected.

Recently I was found that problem is only with certain APs. With the same settings on other AP everything working fine.
So I tried switch back to problematic AP and search for problem.
Finally I found that problem is solved for me when I switch encryption from TKIP to AES.
Maybe it can be indice when looking for problem in NM code.

Petr: it was a nice thought, but I've only ever used AES and the problem still occurred.

Unfortunately, I can confirm the problem on kernel 2.6.38-6 (natty) with Atheros AR9287.
Tried on APs with WEP and with WPA2.
It continuously disconnects from AP. In syslog I can find lines like:
Mar 13 22:20:30 inquisitia-nout kernel: [52750.828766] ath: Failed to stop TX DMA in 100 msec after killing last frame
Mar 13 22:20:30 inquisitia-nout kernel: [52750.828816] ath: Failed to stop TX DMA!

Unfortunately i have completely abandoned Ubuntu and moved back to Debian
unstable/testing. as of debian's kernel "Linux MorphixDesktop 2.6.37-2-amd64
#1 SMP Sun Feb 27 10:12:22 UTC 2011 x86_64 GNU/Linux" this bug appears to be
fixed. I'm not sure why Ubuntu has yet to see the fix yet but it looks like
Debian has taken care of this.

On Mon, Mar 14, 2011 at 3:07 AM, Vsevolod Velichko <
<email address hidden>> wrote:

> Unfortunately, I can confirm the problem on kernel 2.6.38-6 (natty) with
> Atheros AR9287.
> Tried on APs with WEP and with WPA2.
> It continuously disconnects from AP. In syslog I can find lines like:
> Mar 13 22:20:30 inquisitia-nout kernel: [52750.828766] ath: Failed to stop
> TX DMA in 100 msec after killing last frame
> Mar 13 22:20:30 inquisitia-nout kernel: [52750.828816] ath: Failed to stop
> TX DMA!
>
> --
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (519158).
> https://bugs.launchpad.net/bugs/414560
>
> Title:
> ath9k disassociates/reassociates a lot
>
> Status in The Linux Kernel:
> Fix Released
> Status in “linux-backports-modules-2.6.31” package in Ubuntu:
> Confirmed
>
> Bug description:
> I cannot find any rhyme or reason to this, but my
>
> 01:00.0 Network controller: Atheros Communications Inc. AR928X
> Wireless Network Adapter (PCI-Express) (rev 01)
>
> seems to like to disassociate/reassociate a lot since I started
> testing karmic as of alpha 4.
>
> A typical dmesg excerpt:
>
> [ 1881.988111] wlan0: no probe response from AP 00:15:e9:13:47:60 -
> disassociating
> [ 1883.367859] wlan0: authenticate with AP 00:15:e9:13:47:60
> [ 1883.370161] wlan0: authenticated
> [ 1883.370181] wlan0: associate with AP 00:15:e9:13:47:60
> [ 1883.372802] wlan0: RX ReassocResp from 00:15:e9:13:47:60 (capab=0x431
> status=0 aid=1)
> [ 1883.372822] wlan0: associated
> [ 1892.008117] wlan0: no probe response from AP 00:15:e9:13:47:60 -
> disassociating
> [ 1893.385338] wlan0: authenticate with AP 00:15:e9:13:47:60
> [ 1893.385521] wlan0: authenticate with AP 00:15:e9:13:47:60
> [ 1893.388175] wlan0: authenticated
> [ 1893.388196] wlan0: associate with AP 00:15:e9:13:47:60
> [ 1893.391563] wlan0: RX ReassocResp from 00:15:e9:13:47:60 (capab=0x431
> status=0 aid=1)
> [ 1893.391585] wlan0: associated
> [ 1926.988135] wlan0: no probe response from AP 00:15:e9:13:47:60 -
> disassociating
> [ 1928.365306] wlan0: authenticate with AP 00:15:e9:13:47:60
> [ 1928.367426] wlan0: authenticated
> [ 1928.367442] wlan0: associate with AP 00:15:e9:13:47:60
> [ 1928.370948] wlan0: RX ReassocResp from 00:15:e9:13:47:60 (capab=0x431
> status=0 aid=1)
> [ 1928.370969] wlan0: associated
> [ 1966.988114] wlan0: no probe response from AP 00:15:e9:13:47:60 -
> disassociating
> [ 1968.366568] wlan0: authenticate with AP 00:15:e9:13:47:60
> [ 1968.368624] wlan0: authenticated
> [ 1968.368643] wlan0: associate with AP 00:15:e9:13:47:60
> [ 1968.371872] wlan0: RX ReassocResp from 00:15:e9:13:47:60 (capab=0x431
> status=0 aid=1)
> [ 1968.371893] wlan0: associated
>
> Performance drops significantly when this starts going on. At times
> it becomes impossible to look up hos...

I have the similar problem on my laptop, ubuntu 11.04 and kernel 2.6.38-9-generic x86_64.

The ping to router failed again and again after several minutes running.
It's easy to reproduce in my env. Once I use bittorrent client to download something, after a while, the problem occurs.
I need to reconnect to my AP to get everything back.

#lspci
05:00.0 Network controller: Atheros Communications Inc. AR9287 Wireless Network Adapter (PCI-Express) (rev 01)

If I use a USB wireless card instead, everything is fine.

Hope someone can fix this issue.

Han He,
it might be an issue in the recent kernel. See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/761176
There is a workaround which helped me: Add "options ath9k nohwcrypt=1" to ath9k.conf in /etc/modprobe.d

Tried the workaround, but connection was unstable when moving lots of data. Also started getting these kinds of messages in dmesg:

[937173.268949] kworker/0:1: page allocation failure. order:1, mode:0x4020
[937173.268956] Pid: 2064, comm: kworker/0:1 Not tainted 2.6.38-8-generic #42-Ubuntu
[937173.268958] Call Trace:
[937173.268961] <IRQ> [<ffffffff811147c4>] ? __alloc_pages_nodemask+0x604/0x840
[937173.268976] [<ffffffff81149f45>] ? alloc_pages_current+0xa5/0x110
[937173.268981] [<ffffffff81153722>] ? new_slab+0x282/0x290
[937173.268984] [<ffffffff811551e2>] ? __slab_alloc+0x262/0x390
[937173.268996] [<ffffffffa0217099>] ? ath_rxbuf_alloc+0x39/0xc0 [ath]
[937173.269000] [<ffffffff811584eb>] ? __kmalloc_node_track_caller+0x9b/0x1a0
[937173.269005] [<ffffffffa0217099>] ? ath_rxbuf_alloc+0x39/0xc0 [ath]
[937173.269011] [<ffffffff814c5473>] ? __alloc_skb+0x83/0x170
[937173.269015] [<ffffffffa0217099>] ? ath_rxbuf_alloc+0x39/0xc0 [ath]
[937173.269023] [<ffffffffa0304a82>] ? ath_rx_tasklet+0x462/0x850 [ath9k]
[937173.269029] [<ffffffff81012c40>] ? nommu_map_page+0x0/0x90
[937173.269034] [<ffffffffa02fde15>] ? ath9k_ioread32+0x35/0x90 [ath9k]
[937173.269039] [<ffffffffa0301406>] ? ath9k_tasklet+0x96/0x190 [ath9k]
[937173.269044] [<ffffffff8106cc43>] ? tasklet_action+0x73/0x120
[937173.269047] [<ffffffff8106d538>] ? __do_softirq+0xa8/0x1c0
[937173.269052] [<ffffffff81030518>] ? ack_apic_level+0x78/0x1a0
[937173.269057] [<ffffffff8110e725>] ? mempool_alloc_slab+0x15/0x20
[937173.269061] [<ffffffff8100cf1c>] ? call_softirq+0x1c/0x30
[937173.269064] [<ffffffff8100ea45>] ? do_softirq+0x65/0xa0
[937173.269067] [<ffffffff8106d755>] ? irq_exit+0x85/0x90
[937173.269073] [<ffffffff815caec6>] ? do_IRQ+0x66/0xe0
[937173.269077] [<ffffffff815c3213>] ? ret_from_intr+0x0/0x15
[937173.269079] <EOI> [<ffffffff81155a65>] ? kmem_cache_alloc+0x75/0x120
[937173.269086] [<ffffffff8110e725>] ? mempool_alloc_slab+0x15/0x20
[937173.269089] [<ffffffff8110ea69>] ? mempool_alloc+0x59/0x140
[937173.269094] [<ffffffff812c1148>] ? generic_make_request+0x2d8/0x5c0
[937173.269099] [<ffffffff811976de>] ? bio_alloc_bioset+0x3e/0xf0
[937173.269104] [<ffffffffa0371d74>] ? crypt_alloc_buffer+0x44/0x170 [dm_crypt]
[937173.269109] [<ffffffffa03723e0>] ? kcryptd_crypt+0x0/0x40 [dm_crypt]
[937173.269113] [<ffffffffa0372241>] ? kcryptd_crypt_write_convert+0xd1/0x270 [dm_crypt]
[937173.269117] [<ffffffffa03723e0>] ? kcryptd_crypt+0x0/0x40 [dm_crypt]
[937173.269121] [<ffffffffa03723ff>] ? kcryptd_crypt+0x1f/0x40 [dm_crypt]
[937173.269126] [<ffffffff8108269d>] ? process_one_work+0x11d/0x420
[937173.269130] [<ffffffff81083298>] ? worker_thread+0x168/0x360
[937173.269133] [<ffffffff81083130>] ? worker_thread+0x0/0x360
[937173.269137] [<ffffffff810877e6>] ? kthread+0x96/0xa0
[937173.269140] [<ffffffff8100ce24>] ? kernel_thread_helper+0x4/0x10
[937173.269144] [<ffffffff81087750>] ? kthread+0x0/0xa0
[937173.269147] [<ffffffff8100ce20>] ? kernel_thread_helper+0x0/0x10
[937173.269149] Mem-Info:
[937173.269151] Node 0 DMA per-cpu:
[937173.269154] CPU 0: hi: 0, btch: 1 usd: 0
[937173.269157] CPU 1: hi: 0, btch: 1 usd: 0
[937173.269159] Node ...

Matt Behrens, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the kernel in the mainline kernels archive directory daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.8-rc5

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags:
kernel-unable-to-test-upstream
kernel-unable-to-test-upstream-VERSION-NUMBER

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.