168c:002a ath9k disassociates/reassociates a lot

[Matt Behrens]

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.

WORKAROUND: ndiswrapper.

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 directory
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xf7eb8000 irq 16'
   Mixer name : 'Realtek ALC269'
   Components : 'HDA:10ec0269,1043834a,00100004'
   Controls : 12
   Simple ctrls : 7
Date: Sun Aug 16 17:15:46 2009
DistroRelease: Ubuntu 9.10
MachineType: ASUSTeK Computer INC. 1000HE
Package: linux-image-2.6.31-5-generic 2.6.31-5.24
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-5-generic root=UUID=564b6024-8d7a-4d50-8410-563167a8756a ro quiet splash
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-5.24-generic
RelatedPackageVersions:
 linux-backports-modules-2.6.31-5-generic N/A
 linux-firmware 1.15
SourcePackage: linux
Tags: ubuntu-unr
Uname: Linux 2.6.31-5-generic i686
dmi.bios.date: 07/23/2009
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1002
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: 1000HE
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: x.xx
dmi.chassis.asset.tag: 0x00000000
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTek Computer INC.
dmi.chassis.version: x.x
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1002:bd07/23/2009:svnASUSTeKComputerINC.:pn1000HE:pvrx.x:rvnASUSTeKComputerINC.:rn1000HE:rvrx.xx:cvnASUSTekComputerINC.:ct10:cvrx.x:
dmi.product.name: 1000HE
dmi.product.version: x.x
dmi.sys.vendor: ASUSTeK Computer INC.

[Tuomas Aavikko (taavikko)]

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.

[Matt Behrens (zigg)]

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

[Richard Ayotte (rich-ayotte)]

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

[Matt Behrens (zigg)]

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.

[Matt Behrens (zigg)]

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.

[Matt Behrens (zigg)]

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.

[CyberCr33p (chris-cretaforce)]

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

[CyberCr33p (chris-cretaforce)]

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.

[Jason 'vanRijn' Kasper (vr-movingparts)]

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

[Nuvie (morganfgrant)]

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.

[Jean-Marc Chaton (chatondebian)]

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

[Howard Chu (hyc)]

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.

[jeroenl (jeroenl)]

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

[jeroenl (jeroenl)]

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

[Kunal Gangakhedkar (kunal-gangakhedkar)]

+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.

[Jason 'vanRijn' Kasper (vr-movingparts)]

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?

[Matt Behrens (zigg)]

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.

[Jaromir Obr (jaromir-obr)]

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.

[kervel (frank-dekervel)]

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

[Jason 'vanRijn' Kasper (vr-movingparts)]

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?

[Matt Behrens (zigg)]

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

[Jason 'vanRijn' Kasper (vr-movingparts)]

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! =:)

[Matt Behrens (zigg)]

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.

[CyberCr33p (chris-cretaforce)]

@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

[Matt Behrens (zigg)]

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.

[Tyrael (marco-crociani)]

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: [phone]
Fax: [phone]

[Matt Behrens (zigg)]

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.

[Jose Bernardo (bernardo-bandos)]

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.

[Matt Behrens (zigg)]

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. :)

[cardonator (bcardon)]

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.

[Tuomas Aavikko (taavikko)]

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...

[vaib (vaibhav12)]

@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

[Tyrael (marco-crociani)]

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: [phone]
Fax: [phone]

[vaib (vaibhav12)]

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.

[kervel (frank-dekervel)]

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.

[vaib (vaibhav12)]

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.

[Howard Chu (hyc)]

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.

[kervel (frank-dekervel)]

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

[kervel (frank-dekervel)]

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.

[Dan Trevino (dantrevino)]

Installed linux-backports-modules-karmic last night, and this morning I woke find I cant associate with an open ap.

I get:

ath9k: Two wiphys trying to scan at the same time
ath9k: Two wiphys trying to scan at the same time
ath9k: Two wiphys trying to scan at the same time
ath9k: Two wiphys trying to scan at the same time

messages.

Only have the single wireless though.

[Howard Chu (hyc)]

Even with current wireless-testing the same problems remain, they just occur less frequently now.

Sep 30 22:39:52 violino kernel: [327694.163945] wlan0: authenticate with AP 00:12:17:26:56:10
Sep 30 22:39:53 violino kernel: [327694.360741] wlan0: authenticate with AP 00:12:17:26:56:10
Sep 30 22:39:53 violino kernel: [327694.362835] wlan0: authenticated
Sep 30 22:39:53 violino kernel: [327694.362856] wlan0: associate with AP 00:12:17:26:56:10
Sep 30 22:39:53 violino kernel: [327694.367017] wlan0: RX ReassocResp from 00:12:17:26:56:10 (capab=0x431 status=0 aid=2)
Sep 30 22:39:53 violino kernel: [327694.367040] wlan0: associated
Sep 30 23:09:06 violino kernel: [329447.700548] wlan0: no probe response from AP 00:12:17:26:56:10 - disassociating
Sep 30 23:09:12 violino kernel: [329453.390434] wlan0: authenticate with AP 00:12:17:26:56:10
Sep 30 23:09:12 violino kernel: [329453.587227] wlan0: authenticate with AP 00:12:17:26:56:10
Sep 30 23:09:12 violino kernel: [329453.596536] wlan0: authenticated
Sep 30 23:09:12 violino kernel: [329453.596557] wlan0: associate with AP 00:12:17:26:56:10
Sep 30 23:09:12 violino kernel: [329453.626150] wlan0: RX ReassocResp from 00:12:17:26:56:10 (capab=0x431 status=0 aid=2)
Sep 30 23:09:12 violino kernel: [329453.626175] wlan0: associated
Sep 30 23:15:11 violino kernel: [329813.143845] wlan0: no probe response from AP 00:12:17:26:56:10 - disassociating
Sep 30 23:15:17 violino kernel: [329818.803730] wlan0: authenticate with AP 00:12:17:26:56:10
Sep 30 23:15:17 violino kernel: [329818.806118] wlan0: authenticated
Sep 30 23:15:17 violino kernel: [329818.806145] wlan0: associate with AP 00:12:17:26:56:10
Sep 30 23:15:17 violino kernel: [329818.810114] wlan0: RX ReassocResp from 00:12:17:26:56:10 (capab=0x431 status=0 aid=2)
Sep 30 23:15:17 violino kernel: [329818.810250] wlan0: associated
Oct 1 02:17:26 violino kernel: [340747.876038] wlan0: no probe response from AP 00:12:17:26:56:10 - disassociating
Oct 1 02:17:32 violino kernel: [340753.543467] ath9k: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x40000020
Oct 1 02:17:32 violino kernel: [340753.552914] wlan0: authenticate with AP 00:12:17:26:56:10
Oct 1 02:17:32 violino kernel: [340753.553687] wlan0: authenticated
Oct 1 02:17:32 violino kernel: [340753.553712] wlan0: associate with AP 00:12:17:26:56:10
Oct 1 02:17:32 violino kernel: [340753.556806] wlan0: RX ReassocResp from 00:12:17:26:56:10 (capab=0x431 status=0 aid=2)
Oct 1 02:17:32 violino kernel: [340753.556806] wlan0: associated
Oct 1 02:53:36 violino kernel: [342917.805911] wlan0: no probe response from AP 00:12:17:26:56:10 - disassociating
Oct 1 02:53:42 violino kernel: [342923.475754] wlan0: authenticate with AP 00:12:17:26:56:10
Oct 1 02:53:42 violino kernel: [342923.476639] wlan0: authenticated
Oct 1 02:53:42 violino kernel: [342923.476639] wlan0: associate with AP 00:12:17:26:56:10
Oct 1 02:53:42 violino kernel: [342923.479881] wlan0: RX ReassocResp from 00:12:17:26:56:10 (capab=0x431 status=0 aid=2)
Oct 1 02:53:42 violino kernel: [342923.479881] wlan0: associated
Oct 1 03:00:21 violino kernel: [343322.409166] wlan0: no probe response from AP 00:12:17:26:56:10 - disassociating
O...

[Alexander Sack (asac)]

also see bug 439723

[Kunal Gangakhedkar (kunal-gangakhedkar)]

I did try frank's patches on top of ubuntu-karmic git tree - indeed, they did reduce the no. of disconnects.
But, the main problem of pathetic performance during heavy network load still persists. :(
Note that I'm using the default NetworkManager setup - maybe, that's the culprit?

Need to check manual setup of wlan iface instead of relying on NetworkManager.

@vaibhav,
In comment #37, you claim that you're getting sustained 2.8MBps - is it with manual configuration of the wlan?
If yes, could you post your wpa_supplicant.conf and /etc/network/interfaces file?

I can probably use that.

As mentioned by Howard in comment #42, I did try to follow it up with the Atheros guys on both ath9k-devel and linux-wireless mailing lists, but got nowhere - finally, even I gave up on it :(

[Kunal Gangakhedkar (kunal-gangakhedkar)]

For people following ubuntu-karmic.git, attaching frank's patches applied to the git tree.
This is as of commit f296e92811aec89c51b9377263e4229196cf266f.

[Kunal Gangakhedkar (kunal-gangakhedkar)]

Second patch - for disabling rfkill in ath9k/main.c.

[CyberCr33p (chris-cretaforce)]

Does these 2 patches solve the problem 100% ?

[Kunal Gangakhedkar (kunal-gangakhedkar)]

@ CyberCr33p,
No they don't.
They merely make the disconnects less frequent - making it a bit more usable than earlier where the disconnects were rather frequent.

However, as I mentioned earlier in comment #44, the problem of bad performance on loaded network still exists.
May be, that could also be because of NetworkManager doing frequent scans in my setup - I still need to try out the manual iface config to rule out that possibility too.

[Howard Chu (hyc)]

I've been running without NetworkManager and just with manually configured wpa_supplicant; the disconnects and performance issue still remain. But NetworkManager aggravates the situation, which is why I now disable it. (I described the other issue with NetworkManager in bug 439723)

[vientito (billyleung336)]

What I have observed with this package linux-backports-modules-2.6.28-15-generic is as follows:

system (am64) driver used: rt73usb
front-end: wicd-client (wicd 1.6.2.2-1)
encryption: WPA-TKIP

disconnection comes almost predictably at 18mins, 38min, 58 mins of every hour. Disconnection usually lasts for 5-10 secs and then it will reconnect again. Wicd-client still indicates connection during the absence of signal. Name resolution totally fails rendering everything associated with internet silent.

What I have found is that when I disable NTP daemon in the background it will rid of this problem to a large extent. Except for temporarily disconnection at 18 min at every hour, it seems much better than before. The 18 min disconnection has to do with cron.hourly setting which tells the system to run cron scripts at 17min though I have found no proof so far (there are no existing scripts in cron.daily to execute at 17 min).

I say "almost predictably" because 4 out of 5 times it will disrupt any realtime online video I am watching. Sometimes the video will come back after the 5-10 sec disruption but almost everytime the video will freeze and lose with broadcast server completely.

All symptoms disappear if I resort to wired connection via eth0 instead of wireless modules.

[vaib (vaibhav12)]

Really sad that disabling rfkill and powersave not working out for you guys.
In my case after patch i haven't have had single disconnect whatsoever. Before patch
I was getting disconnects every minute sort off (i didn't manage to note exact duration, but as soon as heavy load after 4-5 mb data it would get disconnect).
Problem had existed with 2.6.31 2.6.31.1 (both compiled my own).

I am not using network manager. OS-debian/unstable. Device told by lspci:
05:00.0 Ethernet controller: Attansic Technology Corp. Atheros AR8121/AR8113/AR8114 PCI-E Ethernet Controller (rev b0)

@Kunal my interface file is below and i don't have any config for wpa of my own :

auto lo
iface lo inet loopback

# The primary network interface
#allow-hotplug eth0
#iface eth0 inet dhcp

auto wlan0
iface wlan0 inet static
wpa-ssid <your ssid>
wpa-psk <your password>
address 192.168.1.5
netmask 255.255.255.0
gateway 192.168.1.1

[Tyrael (marco-crociani)]

With the last version of linux-backports-modules-karmic or the 20090928 compact-wireless it was pretty usable but after the generic update of many packages in the last 2/3 days it is again really bad.

[CyberCr33p (chris-cretaforce)]

There was a new kernel yesterday (2.6.31-12.39). Did someone tried it?

[Howard Chu (hyc)]

Where's the changelog, was there even any related change in that kernel update?

I've switched to 2.6.32-rc3 built directly from kernel.org source. The ath9k driver appears to work a lot better there, but the kernel crashes on me. I'm guessing the crashes are related to the ATI r600 KMS support though. It may be worth trying the current compat-wireless again on 2.6.31.

[CyberCr33p (chris-cretaforce)]

You can see changes here:

https://lists.ubuntu.com/archives/karmic-changes/2009-October/010290.html

There are some fixes for ath5k but not ath9k

[Andy Whitcroft (apw)]

Could those affected please retest both with the latest Karmic kernel 2.6.31-12.39 or later and report back here. If that is bad could you also install the latest matching linux-backports-modules which brings compat-wireless and report on that. In all cases report versions and succuess/failure here. Thanks!

[Tyrael (marco-crociani)]

2.6.31-12-generic
SMP 64BIT
- probably poor performance
- after some time the connection stops working (NM says that it is connected). Some time after it start working again. Then it stops... etc... Then it stops definitely so modprobe -r ath9k, stop network-manager, modprobe ...

[ 667.052577] wlan0: no probe response from AP 00:22:6b:62:72:0a - disassociating
[ 668.459827] wlan0: authenticate with AP 00:22:6b:62:72:0a
[ 668.466031] wlan0: authenticated
[ 668.466044] wlan0: associate with AP 00:22:6b:62:72:0a
[ 668.470363] wlan0: RX ReassocResp from 00:22:6b:62:72:0a (capab=0x411 status=0 aid=1)
[ 668.470374] wlan0: associated
[ 737.062590] wlan0: no probe response from AP 00:22:6b:62:72:0a - disassociating
[ 738.453556] wlan0: authenticate with AP 00:22:6b:62:72:0a
[ 738.456118] wlan0: authenticated
[ 738.456131] wlan0: associate with AP 00:22:6b:62:72:0a
[ 738.462835] wlan0: RX ReassocResp from 00:22:6b:62:72:0a (capab=0x411 status=0 aid=1)
[ 738.462849] wlan0: associated
[ 802.082579] wlan0: no probe response from AP 00:22:6b:62:72:0a - disassociating
[ 803.512311] wlan0: authenticate with AP 00:22:6b:62:72:0a
[ 803.514611] wlan0: authenticated
[ 803.514621] wlan0: associate with AP 00:22:6b:62:72:0a
[ 803.518879] wlan0: RX ReassocResp from 00:22:6b:62:72:0a (capab=0x411 status=0 aid=1)
[ 803.518889] wlan0: associated
[ 847.081291] wlan0: no probe response from AP 00:22:6b:62:72:0a - disassociating
[ 848.518891] wlan0: authenticate with AP 00:22:6b:62:72:0a
[ 848.521692] wlan0: authenticated
[ 848.521706] wlan0: associate with AP 00:22:6b:62:72:0a
[ 848.526244] wlan0: RX ReassocResp from 00:22:6b:62:72:0a (capab=0x411 status=0 aid=1)
[ 848.526261] wlan0: associated
[ 882.540062] wlan0: no probe response from AP 00:22:6b:62:72:0a - disassociating
[ 883.956855] wlan0: authenticate with AP 00:22:6b:62:72:0a
[ 883.959201] wlan0: authenticated
[ 883.959214] wlan0: associate with AP 00:22:6b:62:72:0a
[ 883.963529] wlan0: RX ReassocResp from 00:22:6b:62:72:0a (capab=0x411 status=0 aid=1)
[ 883.963542] wlan0: associated
[ 922.041301] wlan0: no probe response from AP 00:22:6b:62:72:0a - disassociating
[ 923.442411] wlan0: authenticate with AP 00:22:6b:62:72:0a
[ 923.444829] wlan0: authenticated
[ 923.444843] wlan0: associate with AP 00:22:6b:62:72:0a
[ 923.449218] wlan0: RX ReassocResp from 00:22:6b:62:72:0a (capab=0x411 status=0 aid=1)
[ 923.449232] wlan0: associated
[ 957.071295] wlan0: no probe response from AP 00:22:6b:62:72:0a - disassociating
[ 958.493218] wlan0: authenticate with AP 00:22:6b:62:72:0a
[ 958.495906] wlan0: authenticated
[ 958.495916] wlan0: associate with AP 00:22:6b:62:72:0a
[ 958.501612] wlan0: RX ReassocResp from 00:22:6b:62:72:0a (capab=0x411 status=0 aid=1)
[ 958.501625] wlan0: associated
[ 982.092558] wlan0: no probe response from AP 00:22:6b:62:72:0a - disassociating
[ 983.486737] wlan0: authenticate with AP 00:22:6b:62:72:0a
[ 983.489132] wlan0: authenticated
[ 983.489145] wlan0: associate with AP 00:22:6b:62:72:0a
[ 983.493446] wlan0: RX ReassocResp from 00:22:6b:62:72:0a (capab=0x411 status=0 aid=1)
[ 983.493459] wlan0: associated
[ 992.110047] wlan0: no probe respons...

[CyberCr33p (chris-cretaforce)]

Hello Andy,

With the karmic kernel 2.6.31-12.39 I see 40% packet loss when I transfer files on my lan.

With the backports I see no more than 3% packet loss while I was transfering 7,5GB of data with the speed of 21mbps.

When the 3% packet loss happens I see on my syslog this message:

wpa_supplicant[1297]: CTRL-EVEN-SCAN-RESULTS

[Tyrael (marco-crociani)]

There is no linux-backports-modules-2.6.31-12-generic in the repo.

[CyberCr33p (chris-cretaforce)]

I speak too soon. I upgrade to the latest karmic packages and I see a lot of packet loss again.

[Howard Chu (hyc)]

>With the backports I see no more than 3% packet loss while I was transfering 7,5GB of data with the speed of 21mbps.

>When the 3% packet loss happens I see on my syslog this message:

>wpa_supplicant[1297]: CTRL-EVEN-SCAN-RESULTS

That's caused by NetworkManager's background scanning. If you run without NM this won't occur; or you can patch NM to turn off its background scanning attempts.

[Richard Ayotte (rich-ayotte)]

The latest kernel is much much better.

uname -a

Linux panthera 2.6.31-12-generic #40-Ubuntu SMP Wed Oct 7 04:13:44 UTC 2009 x86_64 GNU/Linux

How do verify packet loss?

[Lorenco Trichardt (trichalo)]

ping your router / wireless device :)

PS I see the same problem..... seems stable for a while then starts it's nonsense.....
[ 3454.044441] wlan0: associate with AP 00:0c:42:0c:5d:30
[ 3454.047938] wlan0: RX ReassocResp from 00:0c:42:0c:5d:30 (capab=0x421 status=0 aid=3)
[ 3454.047943] wlan0: associated
[ 3461.104428] wlan0: deauthenticated (Reason: 6)
[ 3462.109075] wlan0: direct probe to AP 00:0c:42:0c:5d:30 try 1
[ 3462.113316] wlan0 direct probe responded
[ 3462.113320] wlan0: authenticate with AP 00:0c:42:0c:5d:30
[ 3462.114688] wlan0: authenticated
[ 3462.114691] wlan0: associate with AP 00:0c:42:0c:5d:30
[ 3462.120628] wlan0: RX ReassocResp from 00:0c:42:0c:5d:30 (capab=0x421 status=0 aid=3)

 lsmod | grep ath
ath5k 124260 0
mac80211 181236 1 ath5k
led_class 4096 2 ath5k,thinkpad_acpi
ath 8060 1 ath5k
cfg80211 93052 3 ath5k,mac80211,ath

Thinkpad T60....
Jaunty - Beta .... (Was up to date 12 hours ago) Takes a while to update with this problem....

[David Huggins-Daines (dhuggins)]

hi, i'm running 2.6.31-12.41 on an eeepc 1005ha. with network-manager I get a lot of the bogus roaming from bug #291760. If I switch to wicd, which doesn't roam automatically, I get the disassociation/association problem:

Oct 8 13:40:03 bluesy kernel: [ 543.544154] wlan0: no probe response from AP 00:1a:1e:1e:d2:40 - disassociating
Oct 8 13:40:03 bluesy kernel: [ 543.565826] ath9k: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x00000020

What I've just seen is:

 1) Load the module and connect
 2) Under heavy traffic (branching a large bzr tree over ssh) I get 2-3 disassociations over a minute or two
 3) After this the disassociations stop, but the network performance is lousy (about 10% packet loss)

This is on an academic network with hundreds or thousands of different APs, but I've been in the same room for the last few hours.

[Joey Stanford (joey)]

Bug #378156 might be a dup of this one.

[CyberCr33p (chris-cretaforce)]

There is a new version of backports released today. Can someone test it ?

[CyberCr33p (chris-cretaforce)]

With the latest compat-wireless 2009-10-09, so far I see 0% - 4% packet loss which I believe is related to the Network-Manager CTRL-EVEN-SCAN-RESULTS.

[notoriousdbp (david-baird-parker)]

Just to say I'm running Karmic Beta 64 bit and the performance of ath9k with network manager is dreadful. It suddenly drops for no reason and refuses to re-connect until I reboot. My wireless network uses WPA2 if that helps.

[David Huggins-Daines (dhuggins)]

One additional data point here - with 2.6.31-12, I had the disassociation problem on campus at CMU (hundreds of access points, usually 5-10 of them visible at once, unsecured network), but not at home (one access point, WEP). Will report on 2.6.31-13 later.

[Christopher Peplin (chris.peplin)]

In response to dhd, I had the disassociation problem on the same multi-AP, unencrypted campus (go Tartans?) and also at home (one access point, WPA2).

[Kunal Gangakhedkar (kunal-gangakhedkar)]

I just upped my kernel + linux-backports-modules from git...
And, it's a lot more usable now. For the first time, I could transfer an ISO from the desktop to laptop over wlan - it was still slow; but much much better than previous cases.

Also, the rfkill-disable patch is no longer needed since that code is removed from wireless-testing git tree itself (from where compat-wireless comes).

[notoriousdbp (david-baird-parker)]

That's all very well but we're just over a fortnight away from full release and for many people with the ath9k chipset wireless is going to be pretty much unusable. I'm thinking about it from the "can my wife and daughter use it" angle.

[koadman (koadman)]

I just updated with 2.6.31-13 and after adding the module backports, I went from being completely unable to do large file transfers to fast and smooth operation. Link quality is being reported much higher too. I've got an AR9285 in a laptop, in case it helps.

[Jim Braux-Zin (j-brauxzin)]

Yes, the module backports seems to solve the problem for me. I hope they will be installed automatically, otherwise this might cause some trouble to new users. Anyway, everything works fine now!

[CyberCr33p (chris-cretaforce)]

Test if for few hours and let us know if it's stable for you.

For me it's usable (0-4% packet loss) but after some hours it disconnect
and doesn't connect again.

[Kunal Gangakhedkar (kunal-gangakhedkar)]

@notoriousdbp,
Well, I don't think ubuntu guys can do anything for the issues here. I've tried to take up the matter with the atheros guys on ath9k-devel list and they haven't been all that helpful which doesn't go well with the whole open source nature. They just stopped responding - even for the casual status-of-the-development queries. :(
UNLESS the ubuntu kernel team decides to push it with the atheros guys, but I doubt it will work..

The way I see it is - for the 'wife and daughter' cases, the driver is pretty much usable - considering the typical usage pattern of casual web-surfing and chit-chatting here and there. I doubt those are right candidates for heavy wlan traffic which is the problem now. The disconnects are pretty rare these days with the current compat-wireless.

The only time the driver still craps out is when NM does a background scan while there is a transfer going on - unfortunately, the AR9285 chip seems to be one of the 'cheap' ones which requires a full reset even for a background scan and that's the main cause of the stalling transfers. And of course, the power-management implementation sucks too..

@all,
Note that the driver is still *not* fully stable - it still does crap out from time to time for some weird unknown (to me, at least) reasons. But, it is improving - slowly but steadily - so, there is hope :)

Wish I had some know-how of the 802.11-land to see where the driver needs the fixes. Unfortunately, I'm a storage guy with absolutely no understanding of 802.11.. :(

[Kunal Gangakhedkar (kunal-gangakhedkar)]

@chris(CyberCr33p),
yeah, it's the same here - it seems to be stable for some time; but after a while, it disconnects and refuses to connect again - even after rmmod + modprobe'ing the driver.
This indicates that it must be messing up the internal state of the h/w somewhere during one of the resets (possibly, the last one) for scan. I could be wrong though.

This is why I said that the driver borks for some unknown reason in my previous comment.

[Jose Bernardo (bernardo-bandos)]

I'd love to try the backports, but for now they are broken for LPIA:
"linux-backports-modules-karmic-lpia: Depende: linux-backports-modules-2.6.31-13-lpia o qual é um pacote virtual." - translating, it looks like it depends of a virtual package.

As for being usable for "wife and daughter" - only if you're not using 802.11n. With a 802.11n connection, I see network hangs that last over 1 minute. If your wife or daughter can live with connections that work for one minute, followed by another minute off (closing any skype calls, etc.), then you're a lucky man - mine would skin me alive if I gave them a laptop (not) working like that... ;)

[Rcommander (rcomander)]

@Jose-- Haha so true. Its a universal fact about family members!. I wanted to add a me 3 to this post. I have a Studio xps 13 by Dell and wireless N router, the connection is superslow with the latest kernels and drivers. the problems only affects when streaming, regular browsing seems okay.

[notoriousdbp (david-baird-parker)]

It just strikes me that this is a major regression from Jaunty which could give a lot of potential new users a bad experience of Ubuntu which would be disappointing to say the least.

[Mark (mnd999)]

I don't think this is a regression. This driver was poor in jaunty as well for me:

01:00.0 Network controller: Atheros Communications Inc. AR5008 Wireless Network Adapter (rev 01)
        Subsystem: D-Link System Inc Device 3a70
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 28
        Region 0: Memory at f8ff0000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: <access denied>
        Kernel driver in use: ath9k
        Kernel modules: ath9k

The current kernel is definitely an improvement over jaunty either stock or with backports. I no longer see the disassociations and with wpa_supplicant the card sticks solidly to the access point. However it does still just stop working several times a day and requires an ifdown / ifup to get it going again. This is a PCI-Express card btw, not sure if that makes any difference.

[Dan Trevino (dantrevino)]

Just piling on.

Still getting a lot of disassociations with 2.6.31-11 in karmic beta. Even an apt-get update causes a lot of issues.

  linux-backports-modules-karmic seems to behave much nicer.

[Brian Ealdwine (eode)]

I have a gateway lt3103u (yay!)
and
AR9285 Wireless Network Adapter (PCI-Express)

running karmic 64-bit

The default kernel still gives me major issues.
With linux-backports-modules-karmic installed, things are better, but not fixed by any means. It often takes around a minute for Ubuntu.com to load, although this doesn't always happen all the time, it happens most of the time. It seems to work in fits and starts, but checking out dmesg, it doesn't seem to be disassociating/reassociating.

--- google.com ping statistics ---
101 packets transmitted, 64 received, 36% packet loss, time 100104ms
rtt min/avg/max/mdev = 36.756/49.755/797.336/94.189 ms

[David Huggins-Daines (dhuggins)]

The default kernel (as of 2.6.31-14.47) also disassociates repeatedly for me, using wicd, on the CMU network (it doesn't do it at home though). With linux-backports-modules-karmic it seems to work pretty smoothly - I was unable to completely run "apt-get update" before, now it works...

Likewise, pinging and downloading a CD image seem to be working okay with backports-modules (version number is 2.6.31-14.16).

This is on an eeepc 1005HA.

[Tyrael (marco-crociani)]

The same of dhd but with a minipciexpress card integrated on Zotac ION Motherboard.
Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01)

[Chris Yoder (cyoder)]

If you "service stop network-manager" with this chipset, the connection will
last longer. It still fades eventually, but less often.

On Thu, Oct 15, 2009 at 4:PM, Tyrael <email address hidden> wrote:

> The same of dhd but with a minipciexpress card integrated on Zotac ION
> Motherboard.
> Network controller: Atheros Communications Inc. AR928X Wireless Network
> Adapter (PCI-Express) (rev 01)
>
> --
> 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.
>
>

[CyberCr33p (chris-cretaforce)]

Does someone else test it with linux-backports-modules-2.6.31 (2.6.31-14.16) ?

[Matt Behrens (zigg)]

I did for about an hour last night—first time off ndiswrapper since my last report—had no trouble. I didn't think it was worthy of report yet, though, since the sample was so short.

[Mark (mnd999)]

Tested with backports with two torrents for an hour was all fine, then complete system lockup. Had to reset. This also happened with backports on the previous kernel.

[koadman (koadman)]

I've been using it with 2.6.31-13 + backports for about a week and have noticed that after resume from suspend I sometimes (not always!) need to unload and reload the ath related modules and restart network manager to get the wifi working again. Just restarting network-manager was not sufficient. Next time it happens I'll look through the system log for something relevant. Apart from the resume issue the connectivity has been great. It was not usable without backports, not for skype, barely for e-mail, so I would definitely call this a showstopper for anyone with an ath card and without the skill or patience to install module backports themselves (jo mamma!).

[simon tretter (s-tretter)]

running with linux-backports-modules-2.6.31-14,
lspci: 03:00.0 Network controller: Atheros Communications Inc. AR5008 Wireless Network Adapter (rev 01)
my dmesg: [ 1884.754889] wlan0: associated
[ 2006.525753] ath9k: DMA failed to stop in 10 ms AR_CR=0xdeadbeef AR_DIAG_SW=0xdeadbeef
[ 2164.504061] No probe response from AP 00:1c:4a:07:27:e6 after 500ms, disconnecting.
[ 2168.744544] wlan0: direct probe to AP 00:1c:4a:07:27:e6 (try 1)
[ 2168.747932] wlan0: direct probe responded
[ 2168.747939] wlan0: authenticate with AP 00:1c:4a:07:27:e6 (try 1)
[ 2168.752323] wlan0: authenticated
[ 2168.752358] wlan0: associate with AP 00:1c:4a:07:27:e6 (try 1)
[ 2168.767902] wlan0: RX ReassocResp from 00:1c:4a:07:27:e6 (capab=0x411 status=0 aid=3)
[ 2168.767909] wlan0: associated

if I ping my router I've following statistic: 58 packets transmitted, 51 received, 12% packet loss, time 57158ms
this problem is very annoying...

[simon tretter (s-tretter)]

I found a workarround:
"sudo iwconfig wlan0 power off"
solved the "No Probe response" problem... Sometimes the ping is over 200ms,.. but the network is very stable now..

ping statistic to my router: "60 packets transmitted, 60 received, 0% packet loss, time 59086ms"

So the problem is still related to the powermanagment of the driver!?

[CyberCr33p (chris-cretaforce)]

With "power off" I see 0% - 1% packet loss. Is any way to turn power off permanently instead of typing this command every time I boot my netbook?

[Partha (partha1b-deactivatedaccount)]

Have you tried updating Karmic with this driver? In my case, I pretty
much have to rmmod/modprobe at least 2-3 times to finish the
download/update process. If the download is more than 20M, then it is
even worse. I get frozen connection whenever the connection speed is
over 1MBps (10Mbps).

On Sat, Oct 24, 2009 at 8:45 AM, simon tretter <email address hidden> wrote:
> I found a workarround:
> "sudo iwconfig wlan0 power off"
> solved the "No Probe response" problem...  Sometimes the ping is over 200ms,.. but the network is very stable now..
>
> ping statistic to my router: "60 packets transmitted, 60 received, 0%
> packet loss, time 59086ms"
>
> So the problem is still related to the powermanagment of the driver!?
>
> --
> 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: Confirmed
> Status in “linux” package in Ubuntu: Triaged
>
> 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
>   ...

[NicolasO (nicolas-oury-gmail)]

Using 2.6.31-14 and backport modules and backport modules wireless, I am having two problems:

- slow connection, that stalls for long time. Switching off power management solve that.
- no wifi after sleep. modprobe -r ath9k ; modprobe ath9k solve that.

Do you know if I could add that to a script at each wake-up?
As it solves a lot of problem for ath9k, maybe it could be sane to do this moves by default until power management works properly?

I have an Asus 1005HA.
It seems to be a regression because I didn't have the same problems with 13. (Only slow connection after a wakeup)

[Kunal Gangakhedkar (kunal-gangakhedkar)]

On Wednesday 28 Oct 2009 5:33:42 pm NicolasO wrote:
> Using 2.6.31-14 and backport modules and backport modules wireless, I am
> having two problems:
>
> - slow connection, that stalls for long time. Switching off power
> management solve that. - no wifi after sleep. modprobe -r ath9k ; modprobe
> ath9k solve that.
>
> Do you know if I could add that to a script at each wake-up?
> As it solves a lot of problem for ath9k, maybe it could be sane to do this
> moves by default until power management works properly?
>
> I have an Asus 1005HA.
> It seems to be a regression because I didn't have the same problems with
> 13. (Only slow connection after a wakeup)

Yeah, it definitely seems to be a regression.
I'm also running -14 with same problems.
Have been quite busy with work, so couldn't post the details. :(

Kunal

[John Peacock (zenoparadoxus)]

Running with 9.10 and linux-backports-modules-karmic-generic, I am no longer seeing the crashes (which made the wifi connection unusable). I was even able to return from hibernation and immediately reconnect. I am still seeing occasional stalls, but nowhere near as bad as 9.4 was; I am testing with the "power off" option as well.

IMNSHO, there is absolutely no way that 9.10 should ship with the existing kernel.

John

[Jason Toffaletti (jason)]

Still seeing this with:
ii linux-image-2.6.31-14-generic 2.6.31-14.48
ii linux-backports-modules-karmic 2.6.31.14.27

It is less frequent, but I'm still getting disconnects and not able to reconnect until I rmmod ath9k. Sometimes it takes a full reboot.

[Partha (partha1b-deactivatedaccount)]

I can confirm this. I turned off power management and the disconnects
are less frequent, though have not downloaded anything massive
recently. Now you have to unload and reload ath9k to get your
connection back.

As I have said before, I used a get a great connection with the
version of ath9k driver from April/May 2009 time frame.

On Wed, Oct 28, 2009 at 11:36 PM, Jason Toffaletti
<email address hidden> wrote:
> Still seeing this with:
> ii  linux-image-2.6.31-14-generic             2.6.31-14.48
> ii  linux-backports-modules-karmic            2.6.31.14.27
>
> It is less frequent, but I'm still getting disconnects and not able to
> reconnect until I rmmod ath9k. Sometimes it takes a full reboot.
>
> --
> 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: Confirmed
> Status in “linux” package in Ubuntu: Triaged
>
> 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: s...

[Pitcher (m-waechter)]

same here with Karmic 64bit.

[Emily Cartier (elacartier)]

I have a fresh install of 9.10 UNR on an Asus EEE pc 1000HE with an ath9k wireless driver. I've been using 9.04 xubuntu via a wubi install to get comfortable and dodge the OpenGL battery eating bug (looks like 9.10 fixed!). Under 9.04, my wireless connection was typically under 50% signal strength, but it was stable and worked fine for irc, forum posting and watching YouTube vids. The machine would suspend and resume, and it would take 3 or more to get the network to an unstable state. Since that's pretty comparable to this machine's Windows uptimes, I was happy.

Under 9.10 as released, I get no suspends. After a single suspend, the wireless connection will work for perhaps 30s, and then it fails. I'm not even able to get into my router. If I disconnect and reconnect, I will get another 30s or so of connection. Then no more router. If it helps, the router is a WRT160N, and I'm usually connected via 802.11n using WPA2 Personal with passphrase authentication. I have an identical 1000HE available that only runs Windows, so it's easy to do simultaneous comparisons (not looks identical, I've confirmed that all internals really are the same hardware).

It looks to me like what I'm experiencing is this bug making it into the live release. What logfiles or data would help confirm this? I don't want to start applying fixes at random without confirming that I have an actual bug, not a case of the software is configured wrong.

[Rachel Greenham (rachel-strangenoises)]

Emily, I had exactly those symptoms earlier during the Karmic Alpha/Beta
period for a long while on my Asus 1008HA (with Apple Airport Extreme
base station). I even reported it in bug
https://bugs.launchpad.net/bugs/442644 but it did actually seem to
resolve itself before release. (Reminds me; after submitting this I
should go there and say so, not that any devs were showing much interest...)

I continued to have other issues (poor signal strength, the excessive
disassociates/reassociates of this bug report, occasional loss of
connection even though network manager thought it was OK) up until and
including the release, but earlier comments on this bug report suggested
installing the backports module (linux-backports-modules-karmic) and
since I did so the performance has, for me at least, been basically
perfect. Suggest trying that for your issue too. :-)

[Kunal Gangakhedkar (kunal-gangakhedkar)]

On Sat, Oct 31, 2009 at 9:19 PM, Rachel Greenham
<email address hidden> wrote:
> I continued to have other issues (poor signal strength, the excessive
> disassociates/reassociates of this bug report, occasional loss of
> connection even though network manager thought it was OK) up until and
> including the release, but earlier comments on this bug report suggested
> installing the backports module (linux-backports-modules-karmic) and
> since I did so the performance has, for me at least, been basically
> perfect. Suggest trying that for your issue too. :-)

The reason for occasional "perceived" loss of connectivity is because
of the background scanning initiated by NM.
Basically, when the device starts a scan for available networks, it
has to be reset to switch frequencies.
This is true for (almost?) all the wireless devices and is not
particular to ath9k based devices.

As soon as the scan finishes, NM just does a single hand-shake with
the previously associated AP and continues on with the connection.

Kunal

[Christopher Peplin (chris.peplin)]

Kunal, do you know of a bug report for the NM issue? The only one I can find is https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/373680 The network connection dropouts are more than a "perceived" loss for me - all web pages hang for 20-30 seconds and Skype calls drop.

[Howard Chu (hyc)]

There are a number of bug reports for NM already. You can start with this

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

and the subsequent Gnome bug report

https://bugzilla.gnome.org/show_bug.cgi?id=580185

I provided a patch to remove the offending background scanning behavior in NM (the patch is attached to both of those bug reports) but the NM guys still believe that background scanning is a Good Thing (never mind the problems it causes, and never mind that other tools like wicd that don't do background scanning work perfectly).

The Gnome NetworkManager bug list also has several bug reports related to this scanning behavior, some people complaining that it doesn't scan fast enough,

https://bugzilla.gnome.org/show_bug.cgi?id=403245

some complaining that it scans too much.

https://bugzilla.gnome.org/show_bug.cgi?id=600246

Personally I think this feature is an exercise in futility, and they really need to dump it and just go with manually invoked scanning.

https://bugzilla.gnome.org/show_bug.cgi?id=587796

But at this point, having sent numerous emails and samples of perfectly good code to them and being ignored,

https://bugzilla.gnome.org/show_bug.cgi?id=551747

I don't have much hope that they're ever going to see the light. Look at their bug list

https://bugzilla.gnome.org/buglist.cgi?quicksearch=product%3A"NetworkManager"+

it's got over 300 open bugs stretching back more than 3 years and they just ignore them.

[Christopher Peplin (chris.peplin)]

If the scanning has been an issue in NM for so long, though, why does my other laptop (with an Intel 802.11g wireless card) not have any problems in Jaunty or Karmic? Is there something about the ath9k driver that just doesn't take being interrupted for scanning well?

[Howard Chu (hyc)]

That was explained in one of the previous discussions. The ath9k is an a/b/g/n interface and has a lot more channels to scan, and it's the extra time required to scan these additional channels that causes the association to time out. Or that's the theory anyway; the ath9k driver seems to still have plenty of problems of its own without NM adding to them.

[Rachel Greenham (rachel-strangenoises)]

Howard Chu wrote:
> That was explained in one of the previous discussions. The ath9k is an
> a/b/g/n interface and has a lot more channels to scan, and it's the
> extra time required to scan these additional channels that causes the
> association to time out. Or that's the theory anyway; the ath9k driver
> seems to still have plenty of problems of its own without NM adding to
> them.
>
>
Well, it's still the case that installing the backports, and otherwise
changing *nothing*, so I'm still using network-manager, i get better
signal strength and no loss of connection and good transfer rates.

So I reckon while the NM issues *may* be real issues to some people,
they're not the big story here.

[Kunal Gangakhedkar (kunal-gangakhedkar)]

On Sun, Nov 1, 2009 at 3:34 AM, Rachel Greenham
<email address hidden> wrote:
> Howard Chu wrote:
>> That was explained in one of the previous discussions. The ath9k is an
>> a/b/g/n interface and has a lot more channels to scan, and it's the
>> extra time required to scan these additional channels that causes the
>> association to time out. Or that's the theory anyway; the ath9k driver
>> seems to still have plenty of problems of its own without NM adding to
>> them.
>>
>>
> Well, it's still the case that installing the backports, and otherwise
> changing *nothing*, so I'm still using network-manager, i get better
> signal strength and no loss of connection and good transfer rates.
>
> So I reckon while the NM issues *may* be real issues to some people,
> they're not the big story here.
>

LBM (linux-backports-modules) is based on the cutting-edge of
wireless-testing kernel tree via compat-wireless.
http://wireless.kernel.org/en/users/Download#Getting_compat-wireless_on_Ubuntu

If you follow it here:
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=summary

you'd see that there are quite a few changes that have gone recently into ath9k.
Maybe, that's fixed some of the older issues that we've been
discussing here - I'm yet to install karmic.

Point being that the shipped kernel drivers and lbm drivers may be worlds apart.

@Christopher,
the problem of background scanning is compounded by the fact that
ath9k takes a lot of time to complete the scan.
It's improving at a snail's pace - to add to that, the atheros guys
haven't been all that helpful either.
I'm subscribed to both wireless-devel and ath9k-devel lists.

The meaning of 'perceived' loss is wrt NM - it thinks the connection
is alive while the scan is progressing.
I agree that in reality, the tcp connections (so do udp - dns lookups
almost never work during a scan) drop like crazy during scans - even I
have to switch to wired whenever using skype or anything that requires
sustained connectivity.

@Howard,
The scanning process is a required process - otherwise, you can never
come to know about what networks are available in your vicinity.
However, the way it's implemented seems to be problematic.

Unfortunately, for me, wicd has never worked :(
And I'm not all that hopeful about NM either.

Kunal

[Howard Chu (hyc)]

@Kunal,
Yes, scanning is required to find a network to connect to, when you initially have no connection at all. My point is that once you're successfully associated to a network, automatic/background scanning should stop. You don't need scanning to happen any more unless the environment changes - either the AP is deactivated, or you're using a mobile computer and you move to a different location. In most cases, people using wifi are stationary for the majority of the time they're connected.

Those other bug reports I referenced already indicate that NM is lousy at choosing an appropriate background scan interval. In some cases it occurs too frequently and causes the session to ping-pong when there are multiple APs nearby of approximately equal strength. In some cases it occurs too slowly, long after the network environment has changed. Basically it's impossible for NM to know exactly when it should scan again. So, unless it actually loses the connection (in which case scanning would resume automatically anyway) it should just stop and only scan when a user manually requests a scan.

[findepi (piotr-findeisen)]

On Sun, Nov 1, 2009 at 07:58, Howard Chu <email address hidden> wrote:

> @Kunal,
> Yes, scanning is required to find a network to connect to, when you
> initially have no connection at all. My point is that once you're
> successfully associated to a network, automatic/background scanning should
> stop. You don't need scanning to happen any more unless the environment
> changes - either the AP is deactivated, or you're using a mobile computer
> and you move to a different location. In most cases, people using wifi are
> stationary for the majority of the time they're connected.
>

Howard, you're right: in "most cases" but not always.
Often in one place there is more than one WiFI network you can join
(example: university campus). You may be forced to join your
less-preferred-one in absence of the more-preferred, but you still you will
want background scans to know when the more-preferred becomes accessible.

Of course, once you're connected scans are much, much less important. But if
NM would totally stop scanning, I would consider it a bug :)

best regards,
Piotr

[Pitcher (m-waechter)]

Same here, weaksignal and sometimes connection lost.

Karmic 64 bit.

[NicolasO (nicolas-oury-gmail)]

Hello all,

I have made a clean install of UNR 9.10 on my asus 1005 ha.

The wifi card is useless without backported modules. (Connection lost and have to stop/restart the module all the time).

With backported modules, it works fine at home. (Fast, stable connection on my WEP router).
At work, it keeps having te associate/dissociate problem that seems due to GNM.
 (Maybe it is trigger by multiple
open access points, on the same network, and GNM trying to find the same one.)

Howard, I totally agree with you. Even if my netbook is small, I am never running while browsing the web and would be happy not to have any scan happening once I am connected.
Maybe for some people, it is really cool to list all the available networks at all the time, but it is necessary at least to have a configuration option to "stop scanning when connected, for faster network connection".

Ubuntu (and sadly GNU/Linux probably at the same time) will lose a great deal of users with that one.
Especially if they realise it is a known problem coming from a "feature" ( scanning of network).

I think i had less/no problem with Kubuntu (at least on the release candidate).

[NicolasO (nicolas-oury-gmail)]

Hi,
I replaced GNM by wicd (don't forget to set up wlan0 as your wireless connection, it didn't detect it) and there is no drop anymore.
(At least after half an hour test. But that's long compared to what it used to be with GNM.)

So it seems that once you have 9.10 + backported modules, it is only a strange interaction between the slow scan of all ath9K frequencies and a "feature" of GNM.

Wicd has a Refresh button to rescan...

[Howard Chu (hyc)]

I got sick of NetworkManager taking away control here, so I wrote this patch

http://hostap.epitest.fi/bugz/show_bug.cgi?id=335

It restores access to the wpa_supplicant using the normal control interface, even with the DBUS interface active. This allows tools like wpa_cli and python wpa_ctrl to keep working, and it allows you to manually issue scan requests.

[Partha (partha1b-deactivatedaccount)]

I got sick of the loss of connection and not being able to even update
the system without multiple connection restarts. I went ahead and
installed ndiswrapper and all is fine with the world of my wireless
card now.

Partha

On Mon, Nov 2, 2009 at 6:19 AM, Howard Chu <email address hidden> wrote:
> I got sick of NetworkManager taking away control here, so I wrote this
> patch
>
> http://hostap.epitest.fi/bugz/show_bug.cgi?id=335
>
> It restores access to the wpa_supplicant using the normal control
> interface, even with the DBUS interface active. This allows tools like
> wpa_cli and python wpa_ctrl to keep working, and it allows you to
> manually issue scan requests.
>
>
> ** Bug watch added: Hostap bugzilla #335
>   http://hostap.epitest.fi/bugz/show_bug.cgi?id=335
>
> --
> 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: Confirmed
> Status in “linux” package in Ubuntu: Triaged
>
> 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...

[Pitcher (m-waechter)]

fixed with installation of the backports :-))

[Partha (partha1b-deactivatedaccount)]

more (wireless) power to ya. :)

On Mon, Nov 2, 2009 at 2:33 PM, Pitcher <email address hidden> wrote:
> fixed with installation of the backports :-))
>
> --
> 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: Confirmed
> Status in “linux” package in Ubuntu: Triaged
>
> 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 directory
> Card0.Amixer.info:
>  Card hw:0 'Intel'/'HDA Intel at 0xf7eb8000 irq 16'
>   Mixer name   : 'Realtek ALC269'
>   Components   : 'HDA:10ec0269,1043834a,00100004'
>   Control...

[Doc (cufalo)]

It's not fixed with backports!!!!
Install them means making impossible to turn off the wifi, in the sense that you get a complete freeze of the system!
I tried twice and twice I had to forcibly shut down the PC: the ext4 file system did the rest! :-(((

[Doc (cufalo)]

I forgot: fresh installation of karmic koala!

[Kunal Gangakhedkar (kunal-gangakhedkar)]

On Tuesday 03 Nov 2009 8:49:25 pm Doc wrote:
> It's not fixed with backports!!!!
> Install them means making impossible to turn off the wifi, in the sense that you get a complete freeze of the system!
> I tried twice and twice I had to forcibly shut down the PC: the ext4 file system did the rest! :-(((
>
>

Yup, it's not yet fixed - PM problems are still cropping up which is really sad :(
It invariably locks up the system while resuming from suspend.

This is also on a fresh karmic install with stock lbm installed.

Kunal

[Pitcher (m-waechter)]

with the backports my connection is absolute stable and the signal strenghts is higher.
so for me it's fixed.

[István Kondor (kondor)]

+1 (Karmic_64)
Just wanted to mention that I had the same problem and the LBM-wireless package solved it. Everything is fine for the last 24 hours. Strength is also doubled.

[Tyrael (marco-crociani)]

Not fixed.
I have to remove the module continuously and I have to "sudo iwconfig wlan0 power off" to avoid system freeze.
I tried linux-backports-modules and compat-wireless-2009-11-03.

[f0ma (f0ma)]

I confirm that this bug not detected after install:
linux-backports-modules - fix disconnects from AP.
wicd (replace gnome-network-manager) - fix ping problem.

[Tony Wieczorek (tonyjw)]

I can confirm that installing the backports significantly increases the speed and reliability of the wireless card on my eeepc 1005ha, with Karmic 9.10 Netbook Remix (UNR).

sudo apt-get install linux-backports-modules-wireless-karmic-generic

I installed the above package, restarted the netbook and saw an increase from 35% signal strength to 65%. The wireless connection survives multiple sleep/wake-up cycles.

[Mark (mnd999)]

Yes, but as stated previously by a number of people, backports makes the whole system prone to locking up.

[Andrew Ziem (ahziem1)]

Tony,

Yes, linux-backports-modules-wireless-karmic-generic is much better here too on Ubuntu 9.10 (2.6.31-14-generic, 64-bit) on an HP dv7 notebook. I was surprised to see it work after opening the lid (suspend/resume from RAM)

[notoriousdbp (david-baird-parker)]

+1 here for using linux-backports-modules-wireless-karmic-generic. Did also try just using linux-backports-modules but that caused other features not to work as well. So I guess the question is how we move from backports to general release, if we can?

[f0ma (f0ma)]

For me latest nightly build compat-wireless fix this bug completely:
http://wireless.kernel.org/download/compat-wireless-2.6/

[Canale Grande (canalegrande)]

Using atheros AR9285 on Eeepc 1005AH karmic 2.6.31-14 originally had only 52% next to my AP.
With the beforementioned link / driver (ath9k) it went up to 85%. For me this bug has been fixed.
Thank you all

[acadavid (acadavid-gmail)]

Installing compat-wireless seems to have fixed the problem for me here. I just have a fresh Ubuntu Notebook Remix 9.10 install on an Asus 1000HE. Just download that file, uncompress it, move to that dir, and read the README file to install, and finally reboot, and it should work like a charm.

[Partha (partha1b-deactivatedaccount)]

Have you tried any large downloads say for instances like 600-700megs?

On Wed, Nov 11, 2009 at 12:26 PM, acadavid <email address hidden> wrote:
> Installing compat-wireless seems to have fixed the problem for me here.
> I just have a fresh Ubuntu Notebook Remix 9.10 install on an Asus
> 1000HE. Just download that file, uncompress it, move to that dir, and
> read the README file to install, and finally reboot, and it should work
> like a charm.
>
> --
> 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: Confirmed
> Status in “linux” package in Ubuntu: Triaged
>
> 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 A...

[findepi (piotr-findeisen)]

I installed Ubuntu's linux-backports-modules package and configured ath9k module to be offloaded for suspend (see SUSPEND_MODULES config var of 'pm', `man pm-suspend`).
It didn't fix the problem completely — afterwards i had some disconnects — but significantly improved the situation.

[findepi (piotr-findeisen)]

Forgot to add — "situation improved" means I was able to transfer serveal GBs of my photos over WiFi with good speed as for my setup.

[Paulo Albuquerque (paulo.albuquerque)]

I have an Eee S101. I had the same issues described here, and I installed linux-backports-modules-wireless-karmic-generic. The situation improved a bit, but I still can't manage to get sustained data transfers.

[diogovieira (diogovieira)]

Noticed that my wireless card is disabled after suspend requiring a reboot. Using linux-backport-modules-karmic-generic. And my signal is still a bit unstable with very high speed at a time and none the next minute (but not disconnecting itself).

[PenquinCoder (penquincoder)]

Wanted to add a 'me too' to this bug.

Linux laptop 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linux
Ubuntu 9.10 x64
Atheros AR928x Wireless
HP DV73060

I have tried installing backports, using Wicd, using network manager, using ndiswrapper, and now using compat-wireless-2.6.32-rc7 and network-manager. With this setup, it actually allows me to use the wlan0 interface, and connect. However, I must manually start the interface on every boot using : sudo ifconfig wlan0 up. Also, the card constantly disassociates and re-associates. This causes tremendous amount of packet loss (~40%) doing anything, and will sometimes completely drop the signal.

Suspend/hibernate do not work on this laptop, when trying to use it the screen will come back with bright green/red/blue streaks along the top, and I have to hard reboot to get back into Gnome/desktop.

[Iskan Der (makut)]

I've got Ubuntu 9.10 on ASUS eeePC 1005HA (it has Atheros AR9285).
Wi-Fi connection is very unstable under heavy load. E.g., when I copy a big file from an SMB share the connection drops after ~200-300 Mb transferred. Sometimes system is even unable to reconnect to the network after that. The same problem occurs on resume after suspend/hibernation. To bring connection back I have to reload ath9k:
sudo modprobe -r ath9k
sudo modprobe ath9k
I've tried installing linux-backport-modules-karmic-generic and wicd, but that does not seem to solve the problem.

[Partha (partha1b-deactivatedaccount)]

This has been my experience (see above somewhere)as well. I have the
same card. When I used Fedora 10, I usually installed a
compat-wireless release from April 2009. However, under Ubuntu I was
having the same problems as you with the built in driver. I finally
gave up and use ndiswrapper. Rock solid connection and in fact
stronger signal. I routinely get 1.5/1.6 MB/sec. The only problem on
my computer is suspend/resume which I will tackle one of these days.
But it not a priority for me.

On Wed, Nov 18, 2009 at 2:08 AM, Iskan Der <email address hidden> wrote:
> I've got Ubuntu 9.10 on ASUS eeePC 1005HA (it has Atheros AR9285).
> Wi-Fi connection is very unstable under heavy load. E.g., when I copy a big file from an SMB share the connection drops after ~200-300 Mb transferred. Sometimes system is even unable to reconnect to the network after that. The same problem occurs on resume after suspend/hibernation. To bring connection back I have to reload ath9k:
> sudo modprobe -r ath9k
> sudo modprobe ath9k
> I've tried installing linux-backport-modules-karmic-generic and wicd, but that does not seem to solve the problem.
>
> --
> 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: Confirmed
> Status in “linux” package in Ubuntu: Triaged
>
> 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 ...

[Olivier Sirven (slaanesh)]

Just wanted to add a "me too" here.

And BTW I tried to use ndiswrapper instead but I can't make it works:
# ndiswrapper -l
netathr : driver installed
 device (168C:002B) present (alternate driver: ath9k)
# modprobe ndiswrapper
# tail -n 50 /var/log/syslog
Nov 18 14:19:29 corwin kernel: [1996874.684541] ndiswrapper (import:242): unknown symbol: ntoskrnl.exe:'RtlIsServicePackVersionInstalled'
Nov 18 14:19:29 corwin kernel: [1996874.684566] ndiswrapper (import:242): unknown symbol: ntoskrnl.exe:'KeInitializeGuardedMutex'
Nov 18 14:19:29 corwin kernel: [1996874.684577] ndiswrapper (import:242): unknown symbol: ntoskrnl.exe:'KeReleaseGuardedMutex'
Nov 18 14:19:29 corwin kernel: [1996874.684588] ndiswrapper (import:242): unknown symbol: ntoskrnl.exe:'KeAcquireGuardedMutex'
Nov 18 14:19:29 corwin kernel: [1996874.684692] ndiswrapper (import:242): unknown symbol: NDIS.SYS:'NdisMSetBusData'
Nov 18 14:19:29 corwin kernel: [1996874.684712] ndiswrapper (import:242): unknown symbol: NDIS.SYS:'NdisAllocateMdl'
Nov 18 14:19:29 corwin kernel: [1996874.684724] ndiswrapper (import:242): unknown symbol: NDIS.SYS:'NdisRetreatNetBufferDataStart'
Nov 18 14:19:29 corwin kernel: [1996874.684738] ndiswrapper (import:242): unknown symbol: NDIS.SYS:'NdisAdvanceNetBufferDataStart'
Nov 18 14:19:29 corwin kernel: [1996874.684751] ndiswrapper (import:242): unknown symbol: NDIS.SYS:'NdisFreeMdl'
Nov 18 14:19:29 corwin kernel: [1996874.684764] ndiswrapper (import:242): unknown symbol: NDIS.SYS:'NdisMGetBusData'
Nov 18 14:19:29 corwin kernel: [1996874.684783] ndiswrapper (import:242): unknown symbol: NDIS.SYS:'NdisOpenConfigurationEx'
Nov 18 14:19:29 corwin kernel: [1996874.684805] ndiswrapper (import:242): unknown symbol: NDIS.SYS:'NdisAllocateNetBufferAndNetBufferList'
Nov 18 14:19:29 corwin kernel: [1996874.684819] ndiswrapper (import:242): unknown symbol: NDIS.SYS:'NdisMAllocateNetBufferSGList'
Nov 18 14:19:29 corwin kernel: [1996874.684832] ndiswrapper (import:242): unknown symbol: NDIS.SYS:'NdisMFreeNetBufferSGList'
Nov 18 14:19:29 corwin kernel: [1996874.684869] ndiswrapper (import:242): unknown symbol: NDIS.SYS:'NdisMSendNetBufferListsComplete'
Nov 18 14:19:29 corwin kernel: [1996874.684901] ndiswrapper (import:242): unknown symbol: NDIS.SYS:'NdisAllocateMemoryWithTagPriority'
Nov 18 14:19:29 corwin kernel: [1996874.684924] ndiswrapper (import:242): unknown symbol: NDIS.SYS:'NdisMSynchronizeWithInterruptEx'
Nov 18 14:19:29 corwin kernel: [1996874.684937] ndiswrapper (import:242): unknown symbol: NDIS.SYS:'NdisFreeIoWorkItem'
Nov 18 14:19:29 corwin kernel: [1996874.684951] ndiswrapper (import:242): unknown symbol: NDIS.SYS:'NdisAllocateIoWorkItem'
Nov 18 14:19:29 corwin kernel: [1996874.684975] ndiswrapper (import:242): unknown symbol: NDIS.SYS:'NdisMRegisterInterruptEx'
Nov 18 14:19:29 corwin kernel: [1996874.684988] ndiswrapper (import:242): unknown symbol: NDIS.SYS:'NdisMResetComplete'
Nov 18 14:19:29 corwin kernel: [1996874.685033] ndiswrapper (import:242): unknown symbol: NDIS.SYS:'NdisMRegisterMiniportDriver'
Nov 18 14:19:29 corwin kernel: [1996874.685047] ndiswrapper (import:242): unknown symbol: NDIS.SYS:'NdisMDeregisterMiniportDriver'
Nov 18 14:19:29 corwin k...

[mlaverdiere (mlaverdiere)]

I'm sorry if I'm crossposting with Bug #333730, but in case it might be useful to others, here's my experience with ath9k module/Atheros AR928X card, including a some workarounds I've found along the road:

1. Like other reporters have mentioned, the ath9k drivers provided out of the box by Jaunty and Karmic give really unstable and weak connections. In my case, installing the linux-backports-wireless-modules-karmic (jaunty) improves things dramatically (it gives me a quite stable and strong connection), while there are still some deassociate/reassociate issues reported here (see point 2 for the workaround for these issues).

2. I think I have managed to somewhat circumvent these issues (especially for streaming audio to a Soundbridge M1001 with Firefly Media Server), by opting for one or the other following solutions:

a) like others have reported, using wicd instead of network-manager seems to solve the problem, at least in my case for the purpose of audio streaming.

b) keeping network-manager, but using ndiswrapper (instead of ath9k module) with a Windows XP driver for the AR928X card is my preferred choice. See these sites to find the right XP drivers:

http://forums.laptopvideo2go.com/topic/15297-latest-atheros-modded-driver-for-windws-7-vista-and-winxp/ (These ones work perfectly for me; look for v.7.7.0.259 or the atheros_v7.7.0.259_v1.26.exe file)

http://www.atheros.cz/ (these ones work well, but without the blue led functionality...)

Hope this helps.

[Olivier Sirven (slaanesh)]

Using the given driver I was able to run ndiswrapper and it seems to
work just fine now.

mlaverdiere <email address hidden> writes:

> I'm sorry if I'm crossposting with Bug #333730, but in case it might be
> useful to others, here's my experience with ath9k module/Atheros AR928X
> card, including a some workarounds I've found along the road:
>
> 1. Like other reporters have mentioned, the ath9k drivers provided out
> of the box by Jaunty and Karmic give really unstable and weak
> connections. In my case, installing the linux-backports-wireless-
> modules-karmic (jaunty) improves things dramatically (it gives me a
> quite stable and strong connection), while there are still some
> deassociate/reassociate issues reported here (see point 2 for the
> workaround for these issues).
>
> 2. I think I have managed to somewhat circumvent these issues
> (especially for streaming audio to a Soundbridge M1001 with Firefly
> Media Server), by opting for one or the other following solutions:
>
> a) like others have reported, using wicd instead of network-manager
> seems to solve the problem, at least in my case for the purpose of audio
> streaming.
>
> b) keeping network-manager, but using ndiswrapper (instead of ath9k
> module) with a Windows XP driver for the AR928X card is my preferred
> choice. See these sites to find the right XP drivers:
>
> http://forums.laptopvideo2go.com/topic/15297-latest-atheros-modded-
> driver-for-windws-7-vista-and-winxp/ (These ones work perfectly for me;
> look for v.7.7.0.259 or the atheros_v7.7.0.259_v1.26.exe file)
>
> http://www.atheros.cz/ (these ones work well, but without the blue led
> functionality...)
>
> Hope this helps.

[Iskan Der (makut)]

Yesterday I've removed backport modules and installed the most recent compat-wireless (2009-11-18). This one seems to work fine (previous version, 2009-11-13, was unable to load). At least, I was finally able to copy a 700Mb image from a Samba share via Wi-Fi.

[Didier Roche-Tolomelli (didrocks)]

Can anyone can try this workaround attached to the patch?
It just unload and reload the driver for 1005HA. Put it in /etc/pm/sleep.d/.

[Jesse Michael (jesse.michael)]

I tried out the 75_ath9k-1005ha-reload file and have had 17 disassociate/reassociate cycles in the last hour and 15 minutes since I suspended and resumed with that file in /etc/pm/sleep.d/.

My wap is about 10 feet away from me through a single lath-and-plaster interior wall and currently is reporting between 50% and 60% signal strength.

[squiggleslash (squiggleslash)]

Yeah, I'll add my name to those saying sudo apt-get install linux-backports-modules-wireless-karmic-generic fixes the problem, or at least tries to. Before I installed that and rebooted, Hulu.com was virtually unusable, and tail -f /var/log/syslog Nov 21 20:23:20 darkstar wpa_supplicant[1157]: CTRL-EVENT-SCAN-RESULTS
Nov 21 20:23:41 darkstar wpa_supplicant[1157]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
Nov 21 20:23:41 darkstar NetworkManager: <info> (wlan1): supplicant connection state: completed -> disconnected
Nov 21 20:23:41 darkstar kernel: [ 5871.484062] wlan1: no probe response from AP 00:01:02:03:04:05 - disassociating
Nov 21 20:23:41 darkstar NetworkManager: <info> (wlan1): supplicant connection state: disconnected -> scanning
Nov 21 20:23:42 darkstar wpa_supplicant[1157]: CTRL-EVENT-SCAN-RESULTS
Nov 21 20:23:42 darkstar wpa_supplicant[1157]: WPS-AP-AVAILABLE
Nov 21 20:23:48 darkstar wpa_supplicant[1157]: CTRL-EVENT-SCAN-RESULTS
Nov 21 20:23:48 darkstar wpa_supplicant[1157]: WPS-AP-AVAILABLE
Nov 21 20:23:48 darkstar kernel: [ 5878.701142] wlan1: authenticate with AP 00:01:02:03:04:05
Nov 21 20:23:48 darkstar kernel: [ 5878.704549] wlan1: authenticated
Nov 21 20:23:48 darkstar kernel: [ 5878.704556] wlan1: associate with AP 00:01:02:03:04:05
Nov 21 20:23:48 darkstar wpa_supplicant[1157]: Trying to associate with 00:01:02:03:04:05 (SSID='myapsid' freq=2412 MHz)
Nov 21 20:23:48 darkstar wpa_supplicant[1157]: Association request to the driver failed
Nov 21 20:23:48 darkstar NetworkManager: <info> (wlan1): supplicant connection state: scanning -> associating
Nov 21 20:23:48 darkstar wpa_supplicant[1157]: Associated with 00:01:02:03:04:05
Nov 21 20:23:48 darkstar wpa_supplicant[1157]: CTRL-EVENT-CONNECTED - Connection to 00:01:02:03:04:05 completed (reauth) [id
=0 id_str=]
Nov 21 20:23:48 darkstar NetworkManager: <info> (wlan1): supplicant connection state: associating -> associated
Nov 21 20:23:48 darkstar kernel: [ 5878.707771] wlan1: RX ReassocResp from 00:01:02:03:04:05 (capab=0x11 status=0 aid=5)
Nov 21 20:23:48 darkstar kernel: [ 5878.707776] wlan1: associated
Nov 21 20:23:48 darkstar NetworkManager: <info> (wlan1): supplicant connection state: associated -> completed

Since the reboot, I've watched the whole of Family Guy via Hulu.com without incident. So whatever's in those backports appears to have fixed this specific issue.

[Matt Behrens (zigg)]

Hi there, original reporter here :)

I've finally got around to testing backports-modules-wireless. Tonight I've been getting fairly good results, but I get occasional pauses of a few seconds a few times every hour on my ssh session. Doesn't drop, though.

[Jesse Michael (jesse.michael)]

linux-backports-modules-wireless-karmic-generic has been a lot more stable for me as well.

I've had a few of these messages show up in my dmesg since I suspended and resumed 7 hours or so ago, but haven't had any drop/reassociate cycles at all in that time--

[61982.000897] ath9k: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x00000020

I also noticed that my signal strength is significantly higher with the backports driver as well. With my laptop sitting at the exact same location I was only getting 50-60% two days ago with the default driver, I'm now getting 94%.

[Leann Ogasawara (leannogasawara)]

Based on feedback posted here, most notably from Matt Behrens (the original bug reporter):

https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/414560/comments/148

It seems this issue is resolved after installing linux-backports-modules. For now I'm going to close this against the linux-backports-modules package. If anyone is still experiencing issues even after trying linux-backports-modules, please open a new bug. This bug already has a lengthy amount of comments so any remaining issues might be better addressed with a new but report. Thanks!

[Paulo Albuquerque (paulo.albuquerque)]

The patch that was incorporated into linux-backports-modules is not a solution, only a workaround. And it doesn't solve the issues described as stated by me and many others in the comments.

Please have a look at this kernel bug where a solution is being proposed http://bugzilla.kernel.org/show_bug.cgi?id=14267 (Disassociating atheros wlan). Quoting from the proposed bug fix: "I did a bisect yesterday on this, and the results seemed to have worked over here by reverting: 75e6c3b72b3ab01c47629f3fbd0fed4e6550bf3a cfg80211: lower dynamic PS timeout to 100ms". Hopefully this should provide a real solution.

[rusart (ruslan-levitskiy)]

I have the same problem with RaLink (04:00.0 Network controller: RaLink RT2860) on Kubuntu Karmic (WPA-PSK). Sometimes connection lost with this lines in syslog:

2009-11-24 19:41:31 rusart-laptop NetworkManager <info> (ra0): device state change: 8 -> 3 (reason 11)
2009-11-24 19:41:31 rusart-laptop NetworkManager <info> (ra0): deactivating device (reason: 11).
2009-11-24 19:41:31 rusart-laptop NetworkManager <info> (ra0): canceled DHCP transaction, dhcp client pid 25869
2009-11-24 19:41:31 rusart-laptop NetworkManager <WARN> check_one_route(): (ra0) error -34 returned from rtnl_route_del(): Sucess#012
2009-11-24 19:41:31 rusart-laptop NetworkManager <info> (ra0): removing resolv.conf from /sbin/resolvconf
2009-11-24 19:41:31 rusart-laptop avahi-daemon[816] Withdrawing address record for 192.168.0.100 on ra0.
2009-11-24 19:41:31 rusart-laptop avahi-daemon[816] Leaving mDNS multicast group on interface ra0.IPv4 with address 192.168.0.100.
2009-11-24 19:41:31 rusart-laptop avahi-daemon[816] Interface ra0.IPv4 no longer relevant for mDNS.
2009-11-24 19:41:31 rusart-laptop avahi-daemon[816] querier.c: querier_remove() called but no querier to remove.
2009-11-24 19:41:31 rusart-laptop avahi-daemon[816] last message repeated 9 times
2009-11-24 19:41:31 rusart-laptop NetworkManager <info> Activation (ra0) starting connection 'exogenesis'

Only one way to reconnect is deactivate wireless and activate it again. Else there is requests for WPA keyphrase with no results.

P.S. Sorry for my english...

[Matt Behrens (zigg)]

rusart: this bug is for Atheros wireless (specifically ath9k), not RaLink.

[Tyrael (marco-crociani)]

I still have problem with backports.
04:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01)

[ 425.750135] cfg80211: Calling CRDA to update world regulatory domain
[ 425.829054] cfg80211: World regulatory domain updated:
[ 425.829064] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 425.829072] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 425.829079] (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 425.829085] (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 425.829092] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 425.829098] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 425.854324] ACPI: PCI Interrupt Link [LN3A] enabled at IRQ 19
[ 425.854337] alloc irq_desc for 19 on node 0
[ 425.854342] alloc kstat_irqs on node 0
[ 425.854360] ath9k 0000:04:00.0: PCI INT A -> Link[LN3A] -> GSI 19 (level, low) -> IRQ 19
[ 425.854379] ath9k 0000:04:00.0: setting latency timer to 64
[ 426.281351] ath: EEPROM regdomain: 0x60
[ 426.281359] ath: EEPROM indicates we should expect a direct regpair map
[ 426.281367] ath: Country alpha2 being used: 00
[ 426.281372] ath: Regpair used: 0x60
[ 426.308647] phy0: Selected rate control algorithm 'ath9k_rate_control'
[ 426.310561] Registered led device: ath9k-phy0::radio
[ 426.310619] Registered led device: ath9k-phy0::assoc
[ 426.310663] Registered led device: ath9k-phy0::tx
[ 426.310707] Registered led device: ath9k-phy0::rx
[ 426.310754] phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0: mem=0xffffc90003180000, irq=19
[ 426.403348] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 433.831105] wlan0: deauthenticating from 00:22:6b:62:72:0a by local choice (reason=3)
[ 433.831271] wlan0: direct probe to AP 00:22:6b:62:72:0a (try 1)
[ 433.838957] wlan0: direct probe responded
[ 433.838971] wlan0: authenticate with AP 00:22:6b:62:72:0a (try 1)
[ 433.841197] wlan0: authenticated
[ 433.841246] wlan0: associate with AP 00:22:6b:62:72:0a (try 1)
[ 433.845758] wlan0: RX AssocResp from 00:22:6b:62:72:0a (capab=0x411 status=0 aid=4)
[ 433.845766] wlan0: associated
[ 433.856893] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[21989.542769] No probe response from AP 00:22:6b:62:72:0a after 500ms, disconnecting.
[21991.027345] wlan0: direct probe to AP 00:22:6b:62:72:0a (try 1)
[21991.032625] wlan0: direct probe responded
[21991.032640] wlan0: authenticate with AP 00:22:6b:62:72:0a (try 1)
[21991.035500] wlan0: authenticated
[21991.035586] wlan0: associate with AP 00:22:6b:62:72:0a (try 1)
[21991.041377] wlan0: RX ReassocResp from 00:22:6b:62:72:0a (capab=0x411 status=0 aid=3)
[21991.041389] wlan0: associated
[34338.441416] wlan0: deauthenticating from 00:22:6b:62:72:0a by local choice (reason=3)
[34338.442541] wlan0: direct probe to AP 00:22:6b:62:72:0a (try 1)
[34338.447802] wlan0: direct probe responded
[34338.447813] wlan0: authenticate with AP 00:22:6b:62:72:0a (try 1)
[34338.450039] wlan0: authenticated
[34338.478052] wlan0: deauthenticating from 00:22:6b:62:72:0a by local choice (reason=3)
[34338.704670] wlan0: deauthenticating...

[Aisthesis (aisthesis)]

Can confirm backport has improved signal strength and fluctuates much less from 35-45% to 67-70% from where my laptop sits at home. I work from home and this is my work machine and use it daily 8-12 hours a day. However, still seeing the random drop off when network is at full load but only lasts for 1 second which is a huge improvement over 20sec to 1min REAL disconnects, not just a drop off.

I am no longer seeing disconnects in dmesg at full load now for 43 minutes.

Also, hoping that system does not lock as others reported, will report back if it locks.

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

ii linux-backports-modules-2.6.31-16-generic 2.6.31-16.18
ii linux-backports-modules-wireless-karmic-generic 2.6.31.16.29

[Tyrael (marco-crociani)]

My system locks. :(
Back to ndiswrapper...

[Partha (partha1b-deactivatedaccount)]

My system with ndiswrapper has been rock solid for weeks even without reboot.

On Thu, Dec 10, 2009 at 6:02 PM, Tyrael <email address hidden> wrote:
> My system locks. :(
> Back to ndiswrapper...
>
> --
> 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: Confirmed
> Status in “linux-backports-modules-2.6.31” package in Ubuntu: Fix Released
>
> 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 directory
> Card0.Amixer.info:
>  Card hw:0 'Intel'/'HDA Intel at 0xf7eb8000 irq 16'
>   Mixer name   : '...

[Eduard Drenth (eduarddrenth)]

I too started using ndiswrapper, but still faced problems after
suspend/resume. In my case the solution was changing from wap security
to wep security. Also my connection is much faster now.

Bye,

Eduard
Op woensdag 18-11-2009 om 10:46 uur [tijdzone +0000], schreef Partha:

> This has been my experience (see above somewhere)as well. I have the
> same card. When I used Fedora 10, I usually installed a
> compat-wireless release from April 2009. However, under Ubuntu I was
> having the same problems as you with the built in driver. I finally
> gave up and use ndiswrapper. Rock solid connection and in fact
> stronger signal. I routinely get 1.5/1.6 MB/sec. The only problem on
> my computer is suspend/resume which I will tackle one of these days.
> But it not a priority for me.
>
>
> On Wed, Nov 18, 2009 at 2:08 AM, Iskan Der <email address hidden> wrote:
> > I've got Ubuntu 9.10 on ASUS eeePC 1005HA (it has Atheros AR9285).
> > Wi-Fi connection is very unstable under heavy load. E.g., when I copy a big file from an SMB share the connection drops after ~200-300 Mb transferred. Sometimes system is even unable to reconnect to the network after that. The same problem occurs on resume after suspend/hibernation. To bring connection back I have to reload ath9k:
> > sudo modprobe -r ath9k
> > sudo modprobe ath9k
> > I've tried installing linux-backport-modules-karmic-generic and wicd, but that does not seem to solve the problem.
> >
> > --
> > 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: Confirmed
> > Status in “linux” package in Ubuntu: Triaged
> >
> > 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...

[Aisthesis (aisthesis)]

System locks with backport consistently.

[wouterla (wouter-lagerweij)]

A tip from the kernel bugzilla comments:

iwconfig wlan0 power off

This switches off power management for the driver, and for me solved the issue.

Anyone know how to make sure this is always set? I've now put the command in a script in /etc/network/if-up.d/, but have the feeling this could be done in a nicer fashion...

(Sorry, I see this was mentioned above already, by simon tretter and others. So see this as confirmation that it works for mee too:-)

[bitinerant (bitinerant)]

Thanks for the tip, but the command `iwconfig wlan1 power off` does not help on my system.

I figured out how to visualize the network pauses by printing dots to the terminal in a background process while connecting to a remote system via ssh and asking it to count. See attachment for details. If you remove blank lines and turn off word wrap, it shows a very clear pattern of two pauses about 7 seconds part, repeating every 119.5 seconds. The pauses vary from about 2 to15 seconds each. (The 'local' system is using Atheros AR5418 wireless (ath9k) connected to a Linsys AP via 802.11g using WPA/WPA2. The 'remote' system and the AP are connected via CAT5.)

[Roy Lee (yoryor)]

Have just installed linux-backport-modules-karmic-generic and linux-backport-modules-wireless-karmic-generic, on kernel 2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 04:02:15 UTC 2009 x86_64 GNU/Linux.
Machine's a DV5Z-1000 with Atheros AR928X adapter.
Will leave the machine on with Transmission running and report if I encounter any lockups during regular usage.

[Ryan Davis (ryan-mokeys)]

Also experiencing this problem on a fresh karmic install and asus EEEPC 1101HA
Installed linux-backports-modules-wireless-karmic-generic, getting much better speeds and haven't had a noticeable disconnect for about 15minutes (was getting them every 2min or so before)

Still using the stock Network Manager and my wlan0 power management is on.

[Roy Lee (yoryor)]

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.

[lopee (lopee)]

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!

[Mark (mnd999)]

Not fixed in backports due to the random lockups which occur

[Roy Lee (yoryor)]

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.

[notoriousdbp (david-baird-parker)]

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.

[_oOMOo_ (hermann-blaxhall)]

@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.

[Paulo Albuquerque (paulo.albuquerque)]

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

[Roy Lee (yoryor)]

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.

[notoriousdbp (david-baird-parker)]

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

[Jaromir Obr (jaromir-obr)]

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.

[Roy Lee (yoryor)]

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.

[Matt Behrens (zigg)]

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.

[Michael B. Trausch (mtrausch)]

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.)

[Kunal Gangakhedkar (kunal-gangakhedkar)]

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

[Michael B. Trausch (mtrausch)]

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

[Tyrael (marco-crociani)]

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.
>

[Michael B. Trausch (mtrausch)]

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...

[Paulo Albuquerque (paulo.albuquerque)]

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!

[Kunal Gangakhedkar (kunal-gangakhedkar)]

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

[gajm (gajm-deactivatedaccount)]

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.

[Jorge García (bardok-gmail)]

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...

[Håvard Berland (berland)]

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.

[Håvard Berland (berland)]

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.

[Tyrael (marco-crociani)]

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

[seakayone (seakayone)]

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)

[Kristoffer Lundén (kristoffer-lunden)]

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.

[notoriousdbp (david-baird-parker)]

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

[[e-mail] (walden-joshua)]

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 ...

[Jorge García (bardok-gmail)]

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.

[[e-mail] (walden-joshua)]

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...

[Jorge García (bardok-gmail)]

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.

[Howard Chu (hyc)]

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.

[Petr Olexa (olexa)]

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.

[Howard Chu (hyc)]

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

[Vsevolod Velichko (torkvemada)]

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!

[[e-mail] (walden-joshua)]

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...

[Han He (upwell)]

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.

[Jaromir Obr (jaromir-obr)]

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

[Tomi Hukkalainen (tpievila)]

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 ...

[penalvch (penalvch)]

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.