AR922X Wireless flaky since upgrade to Precise

[Evan Huus]

Ever since the upgrade to precise my wireless card has delivered wildly inconsistent speeds. It can fluctuate quite quickly between full normal speed and practically nothing. There is no interference that I'm aware of, and it doesn't happen in any other OSes that I'm aware of (Oneiric or Windows).

Interesting to note is that Network Manager is aware of the fluctuation: In the "Connection Information" panel the "Speed" field is 54 Mb/s normally, but fluctuates to 11 Mb/s or so in time with the actual data rate.

relevant lspci output for the card:

02:00.0 Network controller: Atheros Communications Inc. AR922X Wireless Network Adapter (rev 01)
 Subsystem: D-Link System Inc DWA-552 802.11n Xtreme N Desktop Adapter (rev A2)
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 168, Cache Line Size: 64 bytes
 Interrupt: pin A routed to IRQ 21
 Region 0: Memory at fdce0000 (32-bit, non-prefetchable) [size=64K]
 Capabilities: [44] Power Management version 2
  Flags: PMEClk- DSI- D1- D2- AuxCurrent=100mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
  Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+
 Kernel driver in use: ath9k
 Kernel modules: ath9k

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: linux-image-3.2.0-3-generic 3.2.0-3.9
ProcVersionSignature: Ubuntu 3.2.0-3.9-generic 3.2.0-rc4
Uname: Linux 3.2.0-3-generic x86_64
NonfreeKernelModules: fglrx
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
ApportVersion: 1.90-0ubuntu1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC2: eapache 1723 F.... pulseaudio
 /dev/snd/controlC0: eapache 1723 F.... pulseaudio
 /dev/snd/controlC1: eapache 1723 F.... pulseaudio
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xfdff4000 irq 42'
   Mixer name : 'Realtek ALC888'
   Components : 'HDA:10ec0888,1028020d,00100001'
   Controls : 40
   Simple ctrls : 22
Card1.Amixer.info:
 Card hw:1 'U0x46d0x9a2'/'USB Device 0x46d:0x9a2 at usb-0000:00:1a.7-6, high speed'
   Mixer name : 'USB Mixer'
   Components : 'USB046d:09a2'
   Controls : 2
   Simple ctrls : 1
Card1.Amixer.values:
 Simple mixer control 'Mic',0
   Capabilities: cvolume cvolume-joined cswitch cswitch-joined penum
   Capture channels: Mono
   Limits: Capture 0 - 3072
   Mono: Capture 1536 [50%] [24.00dB] [on]
Card2.Amixer.info:
 Card hw:2 'HDMI'/'HDA ATI HDMI at 0xfddfc000 irq 43'
   Mixer name : 'ATI R6xx HDMI'
   Components : 'HDA:1002aa01,00aa0100,00100000'
   Controls : 5
   Simple ctrls : 1
Card2.Amixer.values:
 Simple mixer control 'IEC958',0
   Capabilities: pswitch pswitch-joined penum
   Playback channels: Mono
   Mono: Playback [on]
CheckboxSubmission: e049aa43e015d38fc2b288a8a60db142
CheckboxSystem: 2a6f54df59af338184485e85cbcf0d32
Date: Fri Dec 9 22:09:55 2011
HibernationDevice: RESUME=UUID=7a19d99e-7113-4cca-ab69-0e3d7de02716
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Beta amd64 (20110921.2)
MachineType: Dell Inc. Inspiron 530
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-3-generic root=UUID=60269649-642d-4672-83bb-7bfadaae6e31 ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.2.0-3-generic N/A
 linux-backports-modules-3.2.0-3-generic N/A
 linux-firmware 1.62
RfKill:
 0: phy0: Wireless LAN
  Soft blocked: no
  Hard blocked: no
SourcePackage: linux
UpgradeStatus: Upgraded to precise on 2011-11-26 (13 days ago)
dmi.bios.date: 06/20/2008
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.0.15
dmi.board.name: 0FM586
dmi.board.vendor: Dell Inc.
dmi.board.version: ���
dmi.chassis.type: 3
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: OEM
dmi.modalias: dmi:bvnDellInc.:bvr1.0.15:bd06/20/2008:svnDellInc.:pnInspiron530:pvr:rvnDellInc.:rn0FM586:rvr:cvnDellInc.:ct3:cvrOEM:
dmi.product.name: Inspiron 530
dmi.sys.vendor: Dell Inc.

[Brad Figg (brad-figg)]

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

[Evan Huus (eapache)]

It seems to happen significantly less often with the 3.2.0.4 kernel, but it does still happen about once every twenty seconds or so. This is significantly more usable than it was, since TCP streams have time to pick a decent window size, but it's still technically a regression from Oneiric. Given this, I'm leaving the bug open.

[Brad Figg (brad-figg)]

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

[Evan Huus (eapache)]

I'm going to assume that the bot re-nagged on the same kernel version because I accidentally removed the kernel-request tag...

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . If possible, please test the latest v3.2-rcN kernel (Not a kernel in the daily directory). Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag(Only that one tag, please leave the other tags). This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed by the mainline kernel, please add the following tag 'kernel-fixed-upstream-KERNEL-VERSION'. For example, if kernel version 3.2-rc1 fixed and issue, the tag would be: 'kernel-fixed-upstream-v3.2-rc1'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'. If you believe this bug does not require upstream testing, please add the tag: 'kernel-upstream-testing-not-needed'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[Evan Huus (eapache)]

Testing on 3.2.0-rc5 after some hiccups with fglrx. Same behaviour. Added the exists-upstream tag as requested, although I couldn't find the needs-upstream-testing tag to remove.

[Evan Huus (eapache)]

I've done a bit more investigating. Hopefully some of this will be useful.

I started a large file copy (~350MB) to another computer on the LAN (via SMB). On other OSes (Oneiric, Windows), the transfer occurs at a steady 2 Mbps or thereabouts. On precise the transfer rate will hit that level occasionally but frequently fluctuates lower and sometimes stops completely for several seconds at a time. Every now and then it will stop for so long that the transfer times out and fails.

---

I took a Wireshark capture of the transfer, and managed to snip out a decently small section that included both a successful block, a failed block, and a complete 2-second pause.

Frames 1 - 72: A successful block. Not necessarily quite at full speed because of TCP window sizing, but that's what *all* the blocks look like on Oneiric and Windows.

Frames 73 - 129: A bad block. The far end sends acks for packets we don't appear to have sent, however we must have sent them because they are necessary to reconstruct the "Write AndX Request" which the far end then replies to.

Frames 130 - 241: A few more bad blocks similar to the previous one.

Frames 242 - 266: The connection stutters for a few seconds, which was visible in the file transfer progress bar. I have no idea what's going on here protocol-wise, but something's not right.

The remainder of the file is a partial block that didn't get fully captured.

---

The far end has behaved sanely in every other test I've run, and this wireless card has behaved sanely in all tests I've run on other OSes. Based on the bad block in frames 73-129, it looks like some packets are getting successfully put on the air, but not registered as sent properly with the stack. When the far end acks or replies to those packets, the local machine gets confused.

Hopefully some of this is helpful in tracking down the bug.

[Evan Huus (eapache)]

Possibly a dupe of bug #925602 ?

I will report back once I've updated to the latest kernel.