168c:0032 Wifi connection unstable -- Atheros AR9485 ath9k

[Guillaume Michaud]

Using Ubuntu 12.04 beta 2, wifi connection is really unstable on my Asus UX31.
At the same place, with Windows 7, the connection is stable.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: network-manager 0.9.4.0-0ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-21.34-generic 3.2.13
Uname: Linux 3.2.0-21-generic x86_64
ApportVersion: 2.0-0ubuntu2
Architecture: amd64
Date: Mon Apr 2 20:58:59 2012
IfupdownConfig:
 auto lo
 iface lo inet loopback
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Beta amd64 (20120328)
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
 WimaxEnabled=true
ProcEnviron:
 TERM=xterm
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
SourcePackage: network-manager
UpgradeStatus: No upgrade log present (probably fresh install)
nmcli-con: Error: command ['nmcli', '-f', 'all', 'con'] failed with exit code 1: Error: Can't obtain connections: settings service is not running.
---
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
ApportVersion: 2.0.1-0ubuntu2
Architecture: amd64
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: PCH [HDA Intel PCH], device 0: ALC269VB Analog [ALC269VB Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: gfmichaud 1727 F.... pulseaudio
Card0.Amixer.info:
 Card hw:0 'PCH'/'HDA Intel PCH at 0xdfe00000 irq 53'
   Mixer name : 'Intel CougarPoint HDMI'
   Components : 'HDA:10ec0269,10431427,00100100 HDA:80862805,80860101,00100000'
   Controls : 18
   Simple ctrls : 8
DistroRelease: Ubuntu 12.04
HibernationDevice: RESUME=UUID=384ec156-d35e-4d52-9404-4180b3520ddb
IfupdownConfig:
 auto lo
 iface lo inet loopback
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Beta amd64 (20120328)
IpRoute:
 default via 192.168.0.254 dev eth1 proto static
 169.254.0.0/16 dev eth1 scope link metric 1000
 192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.30 metric 2
MachineType: ASUSTeK Computer Inc. UX31E
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
 WimaxEnabled=true
Package: network-manager 0.9.4.0-0ubuntu2
PackageArchitecture: amd64
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-23-generic root=UUID=3698f1d7-5c60-473c-b752-c98e427883f7 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.2.0-23.36-generic 3.2.14
RelatedPackageVersions:
 linux-restricted-modules-3.2.0-23-generic N/A
 linux-backports-modules-3.2.0-23-generic N/A
 linux-firmware 1.78
StagingDrivers: rts5139 mei
Tags: precise staging precise
Uname: Linux 3.2.0-23-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin netdev plugdev sambashare sudo
dmi.bios.date: 01/20/2012
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: UX31E.211
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: UX31E
dmi.board.vendor: ASUSTeK Computer Inc.
dmi.board.version: 1.0
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK Computer Inc.
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrUX31E.211:bd01/20/2012:svnASUSTeKComputerInc.:pnUX31E:pvr1.0:rvnASUSTeKComputerInc.:rnUX31E:rvr1.0:cvnASUSTeKComputerInc.:ct10:cvr1.0:
dmi.product.name: UX31E
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK Computer Inc.
nmcli-con:
 NAME UUID TYPE TIMESTAMP TIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH
 AndroidGM 52f72e54-c826-4a4a-9619-3fef08de5496 802-11-wireless 1333888153 dim. 08 avril 2012 14:29:13 CEST yes no /org/freedesktop/NetworkManager/Settings/1
 CNGM_WEP 712368a2-4545-4f12-b2cc-f5ecc2394ef9 802-11-wireless 1334253900 jeu. 12 avril 2012 20:05:00 CEST yes no /org/freedesktop/NetworkManager/Settings/0
nmcli-dev:
 DEVICE TYPE STATE DBUS-PATH
 eth1 802-11-wireless connected /org/freedesktop/NetworkManager/Devices/0
nmcli-nm:
 RUNNING VERSION STATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN
 running 0.9.4.0 connected enabled enabled enabled enabled disabled

[Guillaume Michaud (gfmichaud)]

Ethernet connection via the provided USB adaptater is stable too, so this is a Wifi-specific issue.

[Mathieu Trudel-Lapierre (cyphermox)]

The connection here is failing for two reason: group timeouts, and inactivity. This is what is blocking the association from properly completing, possibly because the driver isn't able to drive the card properly, or possibly due to low signal. I'll mark the network-manager task as Incomplete until there can be evidence that NM is really at fault.

There has been an error in the attached log about the acer_wmi driver which handles rfkill switches, perhaps this is related, so I'm also opening a linux task.

[Guillaume Michaud (gfmichaud)]

Can I do something to help ?

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 971809

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Guillaume Michaud (gfmichaud)]

apport information

[Julien-Charles Lévesque (jclevesque)]

I also have poor wifi performance in Linux, currently using 12.04 and I must manually reconnect to my AP every 15 minutes or so because the connection just stops working.

[tuxkillbill (tuxkillbill-free)]

Is it a network-manager problem or a ath9 driver problem ?

[Julien-Charles Lévesque (jclevesque)]

Could be either, any cues as to the proper way to diagnose this?

I've had trouble on many different kernels. I tried 3.3.0, 3.4-rc4 and the stock kernel of precise (I think 3.2.0.24? can't check atm).

[tuxkillbill (tuxkillbill-free)]

I'm trying with WICD for see differences.

[Joseph Salisbury (jsalisbury)]

This issue also appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report at bugzilla.kernel.org [1]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug.

If you are comfortable with opening a bug upstream, It would be great if you can report back the upstream bug number in this bug report. That will allow us to link this bug to the upstream report.

[1] https://wiki.ubuntu.com/Bugs/Upstream/kernel

[Mathieu Laurent (mla)]

I have the same problem.

"options ath9k nohwcrypt=1" improves my wifi connection

[tuxkillbill (tuxkillbill-free)]

Mathieu,
Could you explain how (or where...) can I use this option ? ("options ath9k nohwcrypt=1")
Is it a kernel parameter ?

[tuxkillbill (tuxkillbill-free)]

OK, I found how can I use it, but not effect. My wifi connection isn't better !

[Patrik Kullman (nomego)]

I disabled hwcrypt by putting "options ath9k nohwcrypt=1" in /etc/modprobe.d/ath9k.conf

I'm not sure about transfer speeds, I don't transfer that much data with this computer, but I do care about stability in the wifi, which did not improve. The connection drops and re-associates in different intervals, with this in dmesg:

[ 7874.188947] cfg80211: All devices are disconnected, going to restore regulatory settings
[ 7874.188958] cfg80211: Restoring regulatory settings
[ 7874.188985] cfg80211: Calling CRDA to update world regulatory domain
[ 7874.196938] cfg80211: Ignoring regulatory request Set by core since the driver uses its own custom regulatory domain
[ 7874.200337] cfg80211: World regulatory domain updated:
[ 7874.200341] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 7874.200347] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 7874.200351] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 7874.200355] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 7874.200359] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 7874.200363] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 7875.285146] wlan0: authenticate with 58:6d:8f:4a:b6:72
[ 7875.293525] wlan0: send auth to 58:6d:8f:4a:b6:72 (try 1/3)
[ 7875.295524] wlan0: authenticated
[ 7875.304257] wlan0: associate with 58:6d:8f:4a:b6:72 (try 1/3)
[ 7875.308054] wlan0: RX AssocResp from 58:6d:8f:4a:b6:72 (capab=0x411 status=0 aid=4)
[ 7875.308065] wlan0: associated

[Thomas Hood (jdthood)]

Still incomplete for n-m, based on the reasoning in comment #3. Or has someone provided evidence that this is a problem in NM and not just in the driver?

[Julien-Charles Lévesque (jclevesque)]

I still get bad network performance under 12.10 Beta 1. It is much worse when there are multiple network sources with same SSID.

[Guillaume Michaud (gfmichaud)]

The problem is still here with "3.2.0-32-generic #51-Ubuntu SMP Wed Sep 26 21:33:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux".

[Guillaume Michaud (gfmichaud)]

As confirmed on http://ubuntuforums.org/showpost.php?p=12296138&postcount=1766 the problem is still there in kernel 3.6.

What can I do to help ?
I have now been waiting for 8 months, hoping 12.10 will solve this, but it has not. So I am willing to do what is required to help with solving this issue. My laptop is almost unusable without Wifi.

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Wifi connection with an Atheros AR9485 card is very unstable (bad quality, and very bad range).
At the beginning connection quality stays where it reasonably should be, but after few seconds it drops to poor values :

:~$ sudo iwconfig
lo no wireless extensions.

wlan0 IEEE 802.11bgn ESSID:"Pluff"
          Mode:Managed Frequency:2.412 GHz Access Point: 94:0C:6D:C5:8B:B4
          Bit Rate=54 Mb/s Tx-Power=15 dBm
          Retry long limit:7 RTS thr:off Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=46/70 Signal level=-64 dBm
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:4 Missed beacon:0
......
:~$ sudo iwconfig
lo no wireless extensions.

wlan0 IEEE 802.11bgn ESSID:"Pluff"
          Mode:Managed Frequency:2.412 GHz Access Point: 94:0C:6D:C5:8B:B4
          Retry long limit:7 RTS thr:off Fragment thr:off
          Encryption key:off
          Power Management:off
          Bit Rate=54 Mb/s Tx-Power=15 dBm
          Link Quality=28/70 Signal level=-82 dBm
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:4 Missed beacon:0

--- --- --- --- --- --- --- --- ---

This was tested on (cat /proc/version) :
- Linux version 3.5.0-17-generic (buildd@allspice) (gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1) ) #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012
which is the standard Ubuntu 12.10 kernel and
- Linux version 3.7.0-999-generic (apw@gomeisa) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201210210405 SMP Sun Oct 21 08:05:46 UTC 2012
which is the latest upstream kernel

The exact name of the network card is (lspci) :
02:00.0 Network controller: Atheros Communications Inc. AR9485 Wireless Network Adapter (rev 01)

--- --- --- --- --- --- --- --- ---

This bug is related to Ubuntu Launchpad bug n°971809.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/971809

[Marius B. Kotsbak (mariusko)]

If y. don't want/can look into the driver code, I think the best would be to have some patience since the upstream bug report ia just registered. Or look into similar bug reports to see if there are duplicates.

A workaround is buying a USB wifi dongle...

[emailadhoc (emailadhoc-linux-kernel-bugs)]

I have an Atheros Communications Inc. AR9485 (revision 1) and I'm experiencing the same problems under kernel 3.6.7 (fedora 18).

The speed is very low when I walk some meters away from the access point, any network around me appears to have a very low signal level. Sometimes, even if the bit rate is set at 1mbps, the connection just drops and I can't re-associate since the network appears to be out-of-range. I usually have to restart the adapter. I initially thought that someone was jamming me, since I use a 14dbi directional antenna (and my ap is set at 23-26 dBm)

[gfmichaud (gfmichaud-linux-kernel-bugs)]

The problem is still here in 3.7 final.

[sujith (sujith-linux-kernel-bugs)]

A few patches updating AR9485 support have been posted. Once compat-drivers is updated to the latest linux-next snapshot, they can be used.

Regarding the signal issue, I can reproduce it. It drops as soon as ANI kicks in, right after this message:

ath: phy5: Starting IQ Cal and Correction for Chain 0
ath: phy5: Original: Chn 0 iq_corr_meas = 0x002ba228
ath: phy5: Chn 0 pwr_meas_i = 0x07e86ffe
ath: phy5: Chn 0 pwr_meas_q = 0x079f1692
ath: phy5: iqCorrNeg is 0x00000000
ath: phy5: Chn 0 iCoff = 0x00000005
ath: phy5: Chn 0 qCoff = 0x00000002
ath: phy5: Chn 0 : iCoff = 0x7b qCoff = 0x2
ath: phy5: Register offset (0x98dc) before update = 0x20000000
ath: phy5: Register offset (0x98dc) QI COFF (bitfields 0x00003f80) after update = 0x20003d82
ath: phy5: Register offset (0x98dc) QQ COFF (bitfields 0x0000007f) after update = 0x20003d82
ath: phy5: IQ Cal and Correction done for Chain 0
ath: phy5: IQ Cal and Correction (offset 0x98dc) enabled (bit position 0x00004000). New Value 0x20007d82

I'll take a look at this issue.

[gfmichaud (gfmichaud-linux-kernel-bugs)]

@Sujith

I don't know what ANI is, but I saw there
https://wiki.archlinux.org/index.php/ASUS_Zenbook_UX31E
that
- fixing the wireless connection's BSSID
- disabling the ath9k driver ani feature with "echo 1 > /sys/kernel/debug/ieee80211/phy0/ath9k/disable_ani"
could help, but it did not really solved the problem for me.

Maybe it helps ?

[Timo Jyrinki (timo-jyrinki)]

Unduplicating. This is related to bug #945379, but it's not specifically about this AR9485 problem, and the upstream bugzilla tracker also has two separate bugs for AR9485 and other Atheros devices.

[Roy Meissner (roymeissn)]

The problem still occurs on Kernel 3.8.5 from upstream

[Pau Iranzo (paugnu)]

This might help someone: https://wiki.archlinux.org/index.php/ASUS_Zenbook_UX31E#Unstable_Wireless_when_using_Network_Manager

[tomwys (tomwys-linux-kernel-bugs)]

Related:
https://bugzilla.kernel.org/show_bug.cgi?id=55901
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1160188

I have same issue on Asus S500CA.

02:00.0 Network controller: Atheros Communications Inc. AR9485 Wireless Network Adapter (rev 01)

Linux tomwys-laptop 3.8.0-19-generic #29-Ubuntu SMP Wed Apr 17 18:16:28 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

[Chris (chrisjlee)]

Problem exists for me as well on asus vivobook ca500.

The connection will drop and connection is interittent often. Using raring ringtail 13.04.

[Guillaume Michaud (gfmichaud)]

I invite you all to provide details to the upstream kernel bug :
http://bugzilla.kernel.org/show_bug.cgi?id=49201

[Joseph Salisbury (jsalisbury)]

The v3.10-rc2 kernel is now available. Can folks affected by this issue test that kernel to see if it exhibits the bug?
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-rc2-saucy/

[Guillaume Michaud (gfmichaud)]

Testing it, I will provide my feedback in a few hours.

[Guillaume Michaud (gfmichaud)]

Same as always.
If I move away (~5m) from the hotspot, the connection works perfectly fine for a while ; then it suddenly & inexplicably drops down, and never comes back.

If I move again closer to the hotspot, /var/log shows what is written in CLOSER.txt.

If I move again farther, after a random amount of time I am disconnected and /var/log shows what is written in FARTHER.txt.

I insist on saying that until this sudden disconnection, the connection works perfectly fine (good bandwith & no lag).
This is a Linux-related problem since in the same location everything works perfectly fine with Windows 7.

[Diego Carrera Gallego (diegocarrera2000)]

the bug is still on kernel 3.10.0-031000rc2-generic

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Still here in 3.10.0-031000rc2-generic.

[gfmichaud (gfmichaud-linux-kernel-bugs)]

(In reply to comment #6)
> Still here in 3.10.0-031000rc2-generic.

If I move away (~5m) from the hotspot, the connection works perfectly fine for a while ; then it suddenly & inexplicably drops down, and never comes back.

If I move again closer to the hotspot, /var/log shows what is written in CLOSER.txt.

If I move again farther, after a random amount of time I am disconnected and /var/log shows what is written in FARTHER.txt.

I insist on saying that until this sudden disconnection, the connection works perfectly fine (good bandwith & no lag).
This is a Linux-related problem since in the same location everything works perfectly fine with Windows 7.

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Created attachment 103071
/var/log/syslog when I move closer to the wifi access point

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Created attachment 103081
/var/log/syslog when I move away from the wifi access point

[sujith (sujith-linux-kernel-bugs)]

Can you disable PowerSave and see if things improve ?
("iw dev wlan0 set power_save off).

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Since last week I've tested a few things that do seem to improve connection quality and range :
- switching to WPA2 (TKIP) instead of WPA
- switching to a channel with a greater number (from 4 to 11)
- disabling ANI
- disabling power management

I've added in /etc/pm/power.d/wireless :
echo 1 > /sys/kernel/debug/ieee80211/phy0/ath9k/disable_ani
/sbin/iwconfig wlan0 power off

So yes it helps.
However it is not perfect : 50% of the time network is not detected at boot, or the connection drops down after a moment. But 50% of the time it works just fine (particularly on mornings, I don't know why...? Guess it has something to do with the neighbours ?).

[Helmut (helmut-lammel)]

Ubuntu was not able to solve this Problem since one Year.
My Asus UX31 ist not to be used.
So i went back to Windows.
Sorry

[Guillaume Michaud (gfmichaud)]

Since last week I've tested a few things that do seem to improve connection quality and range :
- switching to WPA2 (TKIP) instead of WPA
- switching to a channel with a greater number (from 4 to 11)
- disabling ANI
- disabling power management

I've added in /etc/pm/power.d/wireless :
echo 1 > /sys/kernel/debug/ieee80211/phy0/ath9k/disable_ani
/sbin/iwconfig wlan0 power off

It helps a lot, yet it is not perfect.
I've submitted it all upstream.

> https://bugzilla.kernel.org/show_bug.cgi?id=49201

[hatsch (hatsch-linux-kernel-bugs)]

i am on ubuntu and as mentioned in this post:
http://ubuntuforums.org/showthread.php?t=1865577&page=191&p=12634850#post12634850

the wifi with ath9k is stable using kernel 3.6.11,
only later kernels have the problem.

i am using it now for some hours, and i had no disconnect yet.

[gfmichaud (gfmichaud-linux-kernel-bugs)]

That's curious because I had the problem with both 3.5.0 (current Ubuntu kernel when I filed the bug) and 3.7.0 (latest upstream kernel when I filed the bug).

But it used to work better between december 2012 and april 2013 (when I upgraded to Ubuntu 13.04 and kernel 3.8).
So maybe a few 3.6.* versions are free from this problem.

[sujith (sujith-linux-kernel-bugs)]

> the wifi with ath9k is stable using kernel 3.6.11,
> only later kernels have the problem.
>
> i am using it now for some hours, and i had no disconnect yet.

Which kernel are you using right now ? Also, please report if the connection is stable with powersave disabled.

[hatsch (hatsch-linux-kernel-bugs)]

i am on kernel 3.6.11 (amd64) from the ubuntu mainline ppa
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6.11-raring/

i am on battery for the last hour and powermanagement is on.

no disconnects yet! sitting in a cafe the access point is ~5 meters away and i have 5 other laptop users around me. with kernel 3.8.x on the same place with no other users around i had reglular disconnects after a couple of minutes.

[hatsch (hatsch-linux-kernel-bugs)]

also i have not set nohwcrypt=1 and didn't limit the connection to b/g
as i have tried as a workaround with other kernel versions (with limited success).

[gfmichaud (gfmichaud-linux-kernel-bugs)]

I have set nowhcrypt=1 as well, last week.
It has improved significantly my connection.

[sujith (sujith-linux-kernel-bugs)]

Ok, we are losing track of things a bit. :)

Can you guys please test the latest backports release, with powersave disabled ? Or maybe the wireless-testing tree maintained by John Linville, which contains the latest version of the driver. (Please leave all the other options like ANI, HWCRYPTO to their default values).

[gfmichaud (gfmichaud-linux-kernel-bugs)]

2 weeks ago I tested the latest upstream kernel built for Ubuntu :
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-rc2-saucy/
I had everything set to default (fresh Ubuntu install) and can confirm the bug was there.

I've been testing the latestet build today :
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-rc4-saucy/

I have disabled all the workarounds I had previously set
- re-enabling ANI
- re-enabling power management
- re-enabling hwcrypt
- BSSID not set manually in Network Manager

I can confirm that the bug exists (tested this morning)
- in the standard Ubuntu kernel (3.8.0-23-generic)
- in the latest upstream kernel (3.10.0-031000rc4-generic #201306020443 SMP Sun Jun 2 08:43:56 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux)

With 3.10, when disabling power management (without touching to hwcrypt, BSSID or ANI) enables me to get the connectiion working at boot, but I get disconnected afterwards.

Disabling both power management and ANI helps me get the connection working at boot and keep it alive afterwards.

I've not disabled hwcrypt again as it seems to work, or added back a fixed BSSID in Network Manager, but I can do further testing if need be.

AP information
- from iwconfig
wlan0 IEEE 802.11bgn ESSID:"XXXX"
          Mode:Managed Frequency:2.462 GHz Access Point: XX:XX:XX:XX:XX:XX
          Bit Rate=19.5 Mb/s Tx-Power=15 dBm
          Retry long limit:7 RTS thr:off Fragment thr:off
          Power Management:off
          Link Quality=33/70 Signal level=-77 dBm
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:21 Invalid misc:98 Missed beacon:0

- from iwlist
wlan0 Scan completed :
          Cell 01 - Address: XX:XX:XX:XX:XX:XX
                    Channel:11
                    Frequency:2.462 GHz (Channel 11)
                    Quality=56/70 Signal level=-54 dBm
                    Encryption key:on
                    ESSID:"XXXX"
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
                              9 Mb/s; 12 Mb/s; 18 Mb/s
                    Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s
                    Mode:Master
                    Extra:tsf=00000045352652cc
                    Extra: Last beacon: 160ms ago
                    IE: Unknown: 0004434E474D
                    IE: Unknown: 010882848B960C121824
                    IE: Unknown: 03010B
                    IE: Unknown: 2A0104
                    IE: Unknown: 32043048606C
                    IE: IEEE 802.11i/WPA2 Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (2) : CCMP TKIP
                        Authentication Suites (1) : PSK
                    IE: Unknown: 2D1A6C0003FFFFFF0001000000000000000100000000000000000000
                    IE: Unknown: 3D160B000700000000000000000000000000000000000000
                    IE: Unknown: DD180050F2020101000003A4000027A4000042435E0062322F00

[gfmichaud (gfmichaud-linux-kernel-bugs)]

One last bit about 3.10 : disabling ANI without disabling power management doesn't help.

[sujith (sujith-linux-kernel-bugs)]

> I can confirm that the bug exists (tested this morning)
> - in the standard Ubuntu kernel (3.8.0-23-generic)
> - in the latest upstream kernel (3.10.0-031000rc4-generic #201306020443 SMP
>
> With 3.10, when disabling power management (without touching to hwcrypt,
> BSSID
> or ANI) enables me to get the connectiion working at boot, but I get
> disconnected afterwards.
>
> Disabling both power management and ANI helps me get the connection working
> at
> boot and keep it alive afterwards.

Thanks.

Using the latest upstream kernel, can you please load the driver with debug=0x8f49 and post the kernel log when the disconnect happens ?

(With PowerSave disabled but ANI enabled).

[sujith (sujith-linux-kernel-bugs)]

Also, iwconfig and friends have been deprecated for years, so please use "iw" instead.

[gfmichaud (gfmichaud-linux-kernel-bugs)]

By "kernel log" do you mean /var/log/syslog or some other file ?

To load the driver with debug=0x8f49, is the right method to put
options ath9k debug=0x8f49
in /etc/modprobe.d/ath9k.conf ?

[sujith (sujith-linux-kernel-bugs)]

(In reply to comment #23)
> By "kernel log" do you mean /var/log/syslog or some other file ?

"dmesg" or /var/log/kernel.log - but this depends on the distribution.

> To load the driver with debug=0x8f49, is the right method to put
> options ath9k debug=0x8f49
> in /etc/modprobe.d/ath9k.conf ?

That seems correct.

[sujith (sujith-linux-kernel-bugs)]

I have posted various patches for ANI, they are under review.

https://patchwork.kernel.org/patch/2658201/
https://patchwork.kernel.org/patch/2658211/
https://patchwork.kernel.org/patch/2658221/
https://patchwork.kernel.org/patch/2658231/
https://patchwork.kernel.org/patch/2658241/
https://patchwork.kernel.org/patch/2658251/

[gfmichaud (gfmichaud-linux-kernel-bugs)]

I will test with 3.10 and debug=0x8f49 in a few hours when I'm back home.

I'll be glad to test your patches too when they are available for testing.

[gfmichaud (gfmichaud-linux-kernel-bugs)]

So here are the logs :
- kernel 3.10
- debug=0x8f49
- ANI on & power_save off

Booting away (place A) from the access point, no network
> DMESG_1.txt
Getting closer (place B) from the access point, connection is established
> DMESG_2.txt
Getting away (back to place A) from the access point, network drops down
> DMESG_3.txt
Getting closer (place B) from the access point, connection is re-established
> DMESG_4.txt

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Created attachment 103351
DMESG_1.txt

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Created attachment 103361
DMESG_2.txt

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Created attachment 103371
DMESG_3.txt

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Created attachment 103381
DMESG_4.txt

[sujith (sujith-linux-kernel-bugs)]

The debug information aren't present in the logs. Check if these options are present in the kernel config:

CONFIG_ATH_DEBUG=y
CONFIG_ATH9K_DEBUGFS=y

Also, in your distribution, /var/log/syslog appears to contain both kernel and NM messages. That would be useful to have.

ath9k messages would look like this: http://pastebin.com/gzcdX8mV

[gfmichaud (gfmichaud-linux-kernel-bugs)]

I don't know, for kernel configuration. I didn't build it myself. :-(

Here is the syslog for the period covered by the DMESG : syslog.txt

[gfmichaud (gfmichaud-linux-kernel-bugs)]

So I've built my own custom kernel with the source from kernel.org and enabled debugging... :-)

gfmichaud@dragonfly:~$ uname -a
Linux dragonfly 3.10.0-rc4 #1 SMP Tue Jun 4 19:25:23 CEST 2013 x86_64 x86_64 x86_64 GNU/Linux

Booting close (place B) to the access point : network up
> DMESG_CUSTOM_1.txt
Getting away (place A) from the access point : network down
> DMESG_CUSTOM_2.txt
Getting close (back to place B) to the access point : network up again
> DMESG_CUSTOM_3.txt

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Created attachment 103391
DMESG_CUSTOM_1.txt

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Created attachment 103401
DMESG_CUSTOM_2.txt

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Created attachment 103411
DMESG_CUSTOM_3.txt

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Created attachment 103421
Syslog at the same time as DMESG_CUSTOM_3.txt

[sujith (sujith-linux-kernel-bugs)]

Thanks for the logs. There was one suspicious line from the syslog:

Jun 4 20:11:33 dragonfly wpa_supplicant[1023]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:24:d4:69:f4:14 reason=4

Reason 4 is "WLAN_REASON_DISASSOC_DUE_TO_INACTIVITY" - the AP kicked out the associated station.

But, right before the disconnect, we see this:

Jun 4 20:11:25 dragonfly kernel: [ 224.978454] ath: phy0: tx hung, resetting the chip

Another weird line:

Jun 4 20:07:46 dragonfly kernel: [ 4.423684] ath: phy0: UNDEFINED -> AWAKE
Jun 4 20:07:46 dragonfly kernel: [ 4.423754] ath: phy0: serialize_regmode is 0
Jun 4 20:07:46 dragonfly kernel: [ 4.425939] ath: phy0: timeout (1000 us) on reg 0x15f18: 0x00000000 & 0x00000007 != 0x00000004

Since you mentioned that things work with ANI disabled, I'll prepare some test patches for ANI against mainline.

[sujith (sujith-linux-kernel-bugs)]

Can you try these patches ? http://msujith.org/patches/test/Jun-05-2013/
They apply on top of Linus' tree.

(leave ANI enabled, but PS disabled).

[gfmichaud (gfmichaud-linux-kernel-bugs)]

It works *better* but not *perfectly*, with all the workarounds I said :
- ANI disabled
- power management disabled
- hwcrypt disabled
- BSSID set manually in Network Manager
I still get random disconnection, but *less*. I will try to provide logs.

For the patches, I'll try the (just have to learn how to patch the kernel first !).

[gfmichaud (gfmichaud-linux-kernel-bugs)]

So I have enabled
- full debugging in /etc/modprobe.d/ath9k.conf whith options ath9k debug=0xffff
- and kept all my workarounds (ANI, PM, hwcrypt disabled, BSSID set manually)

1) Booted and got network up
> DMESG_ALL_1.txt

2) Took the computer away from the AP and left for some time ; when I came back network was down
> DMESG_ALL_2.txt

3) Took the computer back closer to the AP and got network up again
> DMESG_ALL_3.txt

(As far as I am concerned, it used to work better with 3.8 and those workarounds than this custom 3.10 with the same workarounds.)

I hope the logfiles help understand what's happening.

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Created attachment 103491
DMESG_ALL_1.txt

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Created attachment 103501
DMESG_ALL_2.txt

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Created attachment 103511
DMESG_ALL_3.txt

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Created attachment 103521
Syslog at the same time as DMESG_ALL_3.txt

[gfmichaud (gfmichaud-linux-kernel-bugs)]

I tried to apply your 6 patches on the kernel but there were problems with 2 of them. Details in PATCHING_PROBLEM.txt

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Created attachment 103541
PATCHING_PROBLEM.txt

[sujith (sujith-linux-kernel-bugs)]

Hm, please apply only the patches here: http://msujith.org/patches/test/Jun-05-2013/. The ones in patchwork are for wireless-testing and not for Linus' tree.

Also, do not enable any workarounds - that makes it impossible to diagnose the issue. The only thing that needs to be done is to disable powersave. The syslog appears to contain everything, so dmesg contents are not needed.

[gfmichaud (gfmichaud-linux-kernel-bugs)]

OK I'll try in a few hours and post the results here : kernel patched, no workaround (but power management disabled), syslog with full debug.

[sujith (sujith-linux-kernel-bugs)]

Can you post the output of lsusb ? I'd like to see if Bluetooth is Atheros-based.

[gfmichaud (gfmichaud-linux-kernel-bugs)]

I usually have bluetooth disabled in the BIOS.
I will re-enabled it for the test.
Kernel is compiling right now, patches are OK, so I'll post all the results within the hour.

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Si here are the results :
- I booted as usual, close to the AP (syslog1.txt)
- Then I took the computer away, and after a while network disconnected (syslog2.txt)
- When I took back the computer close to the AP, Network Manager tried to re-establish the connection twice and failed twice (syslog3.txt)
- Then it failed a third time (syslog4.txt)
- But when I rebooted, without moving, the connection got up juste fine (syslog5.txt)

Logs (and lsusb) can be found here (too big to fit in here) :
http://ubuntuone.com/34brDrhFa0eCabk94wCVva

However, it seems better with the patch than without.
To do the test, I close the door of my office, which does not prevent the connection to work on Windows but does on Linux. Without my previous "workarounds", I experienced disconnections even with the door open with standard unpatched kernels. I don't, with this custom patched kernel.

[sujith (sujith-linux-kernel-bugs)]

Thanks.

AR9485 is a 1x1 chip, which requires that proper RX diversity support is required in the driver. Incorrect/incomplete antenna diversity logic in the driver will adversely affect RX sensitivity. I'll take a look.

[gfmichaud (gfmichaud-linux-kernel-bugs)]

OK.
Tell me if there is further testing to be done.
I'll use the patched kernel for a few days and provide in-depth feedback too.

[sujith (sujith-linux-kernel-bugs)]

As a quick test, can you check if using minstrel makes a difference ? Just disable the CONFIG_ATH9K_RATE_CONTROL option in the kernel config and syslog would show:

ieee80211 phy28: Selected rate control algorithm 'minstrel_ht'

The switch has been made recently:
http://marc.info/?l=linux-wireless&m=137048839031184&w=2

[gfmichaud (gfmichaud-linux-kernel-bugs)]

I set CONFIG_ATH9K_RATE_CONTROL=n in .config before building but there's no "minstrel" mentioned in syslog when I boot afterwards.

[gfmichaud (gfmichaud-linux-kernel-bugs)]

I did the same tests as usual (near/far/near) and had the same results.
Logs can be found here : http://ubuntuone.com/1NS4KrlDHNtoXrGSvqXwis
But I don't know why "minstrel" doesn't show up in the logs.

gfmichaud@dragonfly:~/Documents/linux-3.10-rc4$ grep 'ATH' .config
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_BT_ATH3K=m
CONFIG_UEVENT_HELPER_PATH=""
# CONFIG_MD_MULTIPATH is not set
# CONFIG_DM_MULTIPATH is not set
CONFIG_NET_VENDOR_ATHEROS=y
CONFIG_ATH_COMMON=m
CONFIG_ATH_CARDS=m
CONFIG_ATH_DEBUG=y
# CONFIG_ATH5K is not set
CONFIG_ATH5K_PCI=y
CONFIG_ATH9K_HW=m
CONFIG_ATH9K_COMMON=m
CONFIG_ATH9K_BTCOEX_SUPPORT=y
CONFIG_ATH9K=m
CONFIG_ATH9K_PCI=y
CONFIG_ATH9K_AHB=y
CONFIG_ATH9K_DEBUGFS=y
# CONFIG_ATH9K_MAC_DEBUG is not set
CONFIG_ATH9K_RATE_CONTROL=n
# CONFIG_ATH9K_HTC is not set
# CONFIG_ATH6KL is not set
CONFIG_SECURITY_PATH=y

[sujith (sujith-linux-kernel-bugs)]

Try using this: ./scripts/config --file .config -d ATH9K_RATE_CONTROL

[jkp (jkp-linux-kernel-bugs)]

Don't know if this is of any help, but my experience with kernel 3.10-rc4 & the patches from power management off and patches from http://msujith.org/patches/test/Jun-05-2013/ is that the signal strength & data rate go down very much after ca. 30 seconds. Both with and without disable_ani. Distance between computer and AP ca. 30 cm.

When I connect to the wlan AP from nm-applet, data rate 72,2Mbps

          Link Quality=58/70 Signal level=-52 dBm
          Link Quality=60/70 Signal level=-50 dBm

Then after ca. 30 seconds, data rate drops to 1Mbps:

          Link Quality=49/70 Signal level=-61 dBm
          Link Quality=47/70 Signal level=-63 dBm
          Link Quality=48/70 Signal level=-62 dBm
          Link Quality=54/70 Signal level=-56 dBm
          Link Quality=46/70 Signal level=-64 dBm
          Link Quality=40/70 Signal level=-70 dBm

The values fluctuate somewhat, but the drop of ca. 10 dBm after ca. 30 seconds appears to be quite systematic.

Not sure what to look for in the logs or which parts to post.

Hardware: asus transformer book tx300 (4005)

lspci -v:

01:00.0 Network controller: Atheros Communications Inc. AR9485 Wireless Network Adapter (rev 01)
 Subsystem: AzureWave Device 2126
 Flags: bus master, fast devsel, latency 0, IRQ 16
 Memory at f7c00000 (64-bit, non-prefetchable) [size=512K]
 Expansion ROM at f7c80000 [disabled] [size=64K]
 Capabilities: [40] Power Management version 2
 Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
 Capabilities: [70] Express Endpoint, MSI 00
 Capabilities: [100] Advanced Error Reporting
 Capabilities: [140] Virtual Channel
 Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
 Kernel driver in use: ath9k

Wlan AP: Sierra 4G/wlan router

[jkp (jkp-linux-kernel-bugs)]

Sorry for garbled text, meant to say that patches from http://msujith.org/patches/test/Jun-05-2013/ , then power management off, and with and without disable_ani, no other workarounds.

[jkp (jkp-linux-kernel-bugs)]

Created attachment 103651
kernel messages from two AP connections

Log with patches http://msujith.org/patches/test/Jun-05-2013/ , first connect with ca. -60 dBm signal, then -50dBm switching to -60dBm in ca. 30 secs.

[jkp (jkp-linux-kernel-bugs)]

Two more observations:

1) With this distance & AP, the connection drops to 1 Mbps soon only when power management is off. When power management is on, the connections stays at 72,2 Mbps.

2) At start after connect, the iwconfig "Invalid misc" field grows to ca. 30, stops growing after a while.

Both reardless of ANI being on or off.

[gfmichaud (gfmichaud-linux-kernel-bugs)]

@Sujith :

I tried ./scripts/config --file .config -d ATH9K_RATE_CONTROL :

Now :
root@dragonfly:~/Documents/linux-3.10-rc4# grep 'ATH' .config
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_BT_ATH3K=m
CONFIG_UEVENT_HELPER_PATH=""
# CONFIG_MD_MULTIPATH is not set
# CONFIG_DM_MULTIPATH is not set
CONFIG_NET_VENDOR_ATHEROS=y
CONFIG_ATH_COMMON=m
CONFIG_ATH_CARDS=m
CONFIG_ATH_DEBUG=y
# CONFIG_ATH5K is not set
CONFIG_ATH5K_PCI=y
CONFIG_ATH9K_HW=m
CONFIG_ATH9K_COMMON=m
CONFIG_ATH9K_BTCOEX_SUPPORT=y
CONFIG_ATH9K=m
CONFIG_ATH9K_PCI=y
CONFIG_ATH9K_AHB=y
CONFIG_ATH9K_DEBUGFS=y
# CONFIG_ATH9K_MAC_DEBUG is not set
# CONFIG_ATH9K_RATE_CONTROL is not set
# CONFIG_ATH9K_HTC is not set
# CONFIG_ATH6KL is not set
CONFIG_SECURITY_PATH=y

But I dont find any mention of minstrel in my syslog :
root@dragonfly:~/Documents/linux-3.10-rc4# grep -i 'minstrel' /var/log/syslog
root@dragonfly:~/Documents/linux-3.10-rc4# dmesg | grep -i 'minstrel'

[gfmichaud (gfmichaud-linux-kernel-bugs)]

gfmichaud@dragonfly:~/Documents/linux-3.10-rc4$ grep -i 'minstrel' .config
CONFIG_MAC80211_RC_MINSTREL=y
CONFIG_MAC80211_RC_MINSTREL_HT=y
CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT="minstrel_ht"

[gfmichaud (gfmichaud-linux-kernel-bugs)]

However I thing minstrel is activated.
I have activated mac80211 debug in the kernel before compiling and now there is :

root@dragonfly:/sys/kernel/debug/ieee80211/phy0/netdev:wlan0/stations/00:24:d4:69:f4:14# ls
agg_status current_tx_rate ht_capa last_rx_rate node_stat rx_bytes rx_fragments tx_filtered tx_retry_count wep_weak_iv_count
beacon_loss_count dev inactive_ms last_seq_ctrl num_ps_buf_frames rx_dropped rx_packets tx_fragments tx_retry_failed
connected_time flags last_ack_signal last_signal rc_stats rx_duplicates tx_bytes tx_packets vht_capa

looks like what's in http://wireless.kernel.org/en/developers/Documentation/mac80211/RateControl/minstrel

But I can't remember if it was like that before enabling mac80211 debug in the kernel.

[gfmichaud (gfmichaud-linux-kernel-bugs)]

I have tried this configuration both on the patched and unpatched kernel (with power management off).
I think minstrel is activated because /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0/stations/00\:24\:d4\:69\:f4\:14/rc_stats don't look at all with my standard 3.8 kernel and this custom 3.10 :

gfmichaud@dragonfly:~$ cat rc_stats_3.10
type rate throughput ewma prob this prob retry this succ/attempt success attempts
CCK/LP 1.0M 0.4 50.4 100.0 0 0( 0) 5 22
CCK/LP 2.0M 0.0 0.0 0.0 0 0( 0) 0 0
CCK/LP 5.5M 0.0 0.0 0.0 0 0( 0) 0 0
CCK/LP 11.0M 0.0 0.0 0.0 0 0( 0) 0 0
HT20/LGI t MCS0 4.8 79.8 50.0 3 0( 0) 318 495
HT20/LGI MCS1 3.3 28.7 7.6 4 0( 0) 439 879
HT20/LGI T P MCS2 14.6 88.5 100.0 5 3( 3) 757 1825
HT20/LGI MCS3 0.0 0.0 0.0 0 0( 0) 0 4
HT20/LGI MCS4 0.0 0.0 0.0 0 0( 0) 0 4
HT20/LGI MCS5 0.0 0.0 0.0 0 0( 0) 0 5
HT20/LGI MCS6 0.0 0.0 0.0 0 0( 0) 0 4
HT20/LGI MCS7 0.0 0.0 0.0 0 0( 0) 0 4
HT20/SGI MCS0 4.7 68.2 100.0 3 0( 0) 22 38
HT20/SGI MCS1 3.6 29.2 0.0 4 0( 0) 2 12
HT20/SGI MCS2 5.9 33.1 25.0 5 0( 0) 38 110
HT20/SGI MCS3 0.0 0.0 0.0 0 0( 0) 0 4
HT20/SGI MCS4 0.0 0.0 0.0 0 0( 0) 0 4
HT20/SGI MCS5 0.0 0.0 0.0 0 0( 0) 0 5
HT20/SGI MCS6 0.0 0.0 0.0 0 0( 0) 0 4
HT20/SGI MCS7 0.0 0.0 0.0 0 0( 0) 0 3

Total packet count:: ideal 1505 lookaround 77
Average A-MPDU length: 1.0

gfmichaud@dragonfly:~$ cat rc_stats_3.8
    HT MCS Rate Success Retries XRetries PER
                1.0: 2 0 0 0
                2.0: 0 0 0 0
                5.5: 0 0 0 0
               11.0: 0 0 0 0
  HT20 1 13.0: 0 0 0 0
  HT20 2 19.5: 0 0 0 0
  HT20 3 26.0: 0 0 0 0
  HT20 ...

[sujith (sujith-linux-kernel-bugs)]

Yes, that is minstrel. I've dropped the ANI patches since they don't seem to improve things.

[sujith (sujith-linux-kernel-bugs)]

Can you apply this patch http://msujith.org/patches/ar9485/div-ctrl.patch and post the output of /sys/kernel/debug/ieee80211/phy#/ath9k/base_eeprom ?

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Applied the patch on a 3.10-RC4 kernel without any other modification (except enabling ATH9K debuggung).
Here comes the log : base_eeprom_1.txt

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Created attachment 103721
base_eeprom_1.txt

[sujith (sujith-linux-kernel-bugs)]

Hm, I think you forgot to load the new module. ;)
With that patch, this would be displayed:

ANT Div. Control : 6

[gfmichaud (gfmichaud-linux-kernel-bugs)]

You mean with CONFIG_ATH9K_RATE_CONTROL disabled ?

[sujith (sujith-linux-kernel-bugs)]

No, this is not related to rate control. That 1-line patch dumps the "ANT Div. Control" field in the base_eeprom debugfs file. I think you just have to reload the newly compiled module.

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Yep there's :
    ANT Div. Control : 201

> base_eeprom_new.txt

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Created attachment 103731
base_eeprom_new.txt

[sujith (sujith-linux-kernel-bugs)]

Thanks.

It looks like RX antenna diversity is enabled on the chip in your card. This will most likely not work, but can you try this patch, see if any change is seen in connectivity and post the syslog (with the usual debug=0x8f49) ?

http://msujith.org/patches/ar9485/disable-comb.patch

I don't have such a chip with me, unfortunately.

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Created attachment 103741
make_errors.txt

[gfmichaud (gfmichaud-linux-kernel-bugs)]

I have applied both of your patches (div-ctrl.patch & disable-comb.patch) but now the kernel & modules won't compile.
I put the errors I see in make_errors.txt

[sujith (sujith-linux-kernel-bugs)]

Hm, not sure. But, you can just comment out the line that enables diversity combining, that is sufficient. I've attached a patch.

[sujith (sujith-linux-kernel-bugs)]

Created attachment 103751
disable comb patch

[jkp (jkp-linux-kernel-bugs)]

Appeared to be a missing } in the disable-comb.patch

[jkp (jkp-linux-kernel-bugs)]

Also here:

    ANT Div. Control : 201

However the code snippet in the disable-comb patch appears to not be in execution path, this message does not show up in the log:

"Diversity combining enabled in EEPROM\n"

[gfmichaud (gfmichaud-linux-kernel-bugs)]

The new version of the patch works but /sys/kernel/debug/ieee80211/phy0/ath9k/base_eeprom still shows :
      EEPROM Version : 2
          RegDomain1 : 96
          RegDomain2 : 31
             TX Mask : 1
             RX Mask : 1
          Allow 5GHz : 0
          Allow 2GHz : 1
   Disable 2GHz HT20 : 0
   Disable 2GHz HT40 : 0
   Disable 5Ghz HT20 : 0
   Disable 5Ghz HT40 : 0
          Big Endian : 0
           RF Silent : 29
           BT option : 0
          Device Cap : 0
         Device Type : 5
  Power Table Offset : 0
        Tuning Caps1 : 0
        Tuning Caps2 : 0
 Enable Tx Temp Comp : 1
 Enable Tx Volt Comp : 0
   Enable fast clock : 1
     Enable doubling : 1
  Internal regulator : 1
        Enable Paprd : 1
     Driver Strength : 0
          Quick Drop : 0
   Chain mask Reduce : 0
   Write enable Gpio : 3
   WLAN Disable Gpio : 0
       WLAN LED Gpio : 8
 Rx Band Select Gpio : 255
             Tx Gain : 6
             Rx Gain : 0
              SW Reg : 0
    ANT Div. Control : 201
          MacAddress : 00:08:ca:87:8f:fc

[sujith (sujith-linux-kernel-bugs)]

The eeprom contents will not be modified, they are read-only. But, with diversity combining commented out, is there any difference in link stability ?

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Can't tell right now, I'm not home and won't have wifi connection (except tethering) until tonight. :-(

[sujith (sujith-linux-kernel-bugs)]

(In reply to comment #83)
> Also here:
>
> ANT Div. Control : 201
>
> However the code snippet in the disable-comb patch appears to not be in
> execution path, this message does not show up in the log:
>
> "Diversity combining enabled in EEPROM\n"

Have you loaded the driver with debug=0x8f49 ? Also, can you post the full output of the base_eeprom file ?

[jkp (jkp-linux-kernel-bugs)]

base_eeprom without mac address (only difference to ghmuchaud's file is WLAN LED Gpio)

      EEPROM Version : 2
          RegDomain1 : 96
          RegDomain2 : 31
             TX Mask : 1
             RX Mask : 1
          Allow 5GHz : 0
          Allow 2GHz : 1
   Disable 2GHz HT20 : 0
   Disable 2GHz HT40 : 0
   Disable 5Ghz HT20 : 0
   Disable 5Ghz HT40 : 0
          Big Endian : 0
           RF Silent : 29
           BT option : 0
          Device Cap : 0
         Device Type : 5
  Power Table Offset : 0
        Tuning Caps1 : 0
        Tuning Caps2 : 0
 Enable Tx Temp Comp : 1
 Enable Tx Volt Comp : 0
   Enable fast clock : 1
     Enable doubling : 1
  Internal regulator : 1
        Enable Paprd : 1
     Driver Strength : 0
          Quick Drop : 0
   Chain mask Reduce : 0
   Write enable Gpio : 3
   WLAN Disable Gpio : 0
       WLAN LED Gpio : 6
 Rx Band Select Gpio : 255
             Tx Gain : 6
             Rx Gain : 0
              SW Reg : 0
    ANT Div. Control : 201

[jkp (jkp-linux-kernel-bugs)]

Well, I had echo 0xffffffffffffffff > /sys/kernel/debug/ieee80211/*/ath9k/debug after loading. But now loading ath9k.ko with debug=0x8f49 I still get no message from hw.c about diversity. Also, /sys/kernel/debug/ieee80211/*/ath9k/diversity
 has "0".

[jkp (jkp-linux-kernel-bugs)]

Sorry, I take the last one back, my bad - I had locally modified the debug condition, now I get the debug log as I should:

Jun 7 23:01:44 assu kernel: [38948.170558] ath: phy22: Diversity combining enabled in EEPROM
Jun 7 23:01:44 assu kernel: [38948.170560] ath: phy22: Not enabling COMB in the driver

[jkp (jkp-linux-kernel-bugs)]

With the patches and power management on, I still can't connect to my normal wlan AP from the place where kernel 3.6.11 and win8 do connect to the AP, so reception is definitely worse that with those environments.

One thing - with kernel 3.10rc and the patches the antennas are listed as follows:

iw phy phy22 info

 Available Antennas: TX 0x1 RX 0x1
 Configured Antennas: TX 0x1 RX 0x1

My recollection is that earlier with some earlier kernel versions I've seen 0x3 listed as the RX antenna.

[jkp (jkp-linux-kernel-bugs)]

Without the disable-comp patch:

 Available Antennas: TX 0x1 RX 0x3
 Configured Antennas: TX 0x1 RX 0x3

[jkp (jkp-linux-kernel-bugs)]

But with power management on, I can connect to the 4G Sierra AP from ca. 7-8 meters and connection is 72 Mbps.

[gfmichaud (gfmichaud-linux-kernel-bugs)]

I've tested the kernel with both patches.
Connectivity is not better.
Close to the AP (syslog1.txt), it works. Then, farther, Network Manager still shows the connection working but everything I try times out (syslog2.txt). Then it disconnects (syslog3.txt). And connects again when I come back closer (syslog4.txt).

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Created attachment 104091
Syslog - 2013-06-10 7h19

[gfmichaud (gfmichaud-linux-kernel-bugs)]

I've just run a second test session and the result was much much better !
No disconnection at all, good link quality (3 out 4 for some time) and good bitrate (from 19 to 22 MB/s).
I give you the syslog too.
I may be able to do a longer test session (a few hours) tonight.

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Created attachment 104101
Syslog - 2013-06-10 7h39

[sujith (sujith-linux-kernel-bugs)]

Thanks for testing. So the antenna diversity code in ath9k is probably buggy. It was written for the earlier AR9002 chips and has not been touched in years even though the driver gained "support" for AR9003 (including AR9485). I'll look at it.

[gfmichaud (gfmichaud-linux-kernel-bugs)]

OK ! If you need me test anything, feel free to ask.

[jkp (jkp-linux-kernel-bugs)]

It appears there's some changes in kernel version 3.10-rc5 ath9k code (at kernel.org) - I'm compiling it and will be testing.

Also trying some tests with the sensitivity (not seeing not-so-close networks) - appears that with 3.6.11 and 3.7.1 I can see & connect to my regular network while with 3.8.0 and 3.10-rc4 I can't see it. Testing next with 3.7.4. Hopefully with this I can find out which change(s) made the sensitivity worse.

[sujith (sujith-linux-kernel-bugs)]

(In reply to comment #100)
> It appears there's some changes in kernel version 3.10-rc5 ath9k code (at
> kernel.org) - I'm compiling it and will be testing.
>
> Also trying some tests with the sensitivity (not seeing not-so-close
> networks)
> - appears that with 3.6.11 and 3.7.1 I can see & connect to my regular
> network
> while with 3.8.0 and 3.10-rc4 I can't see it. Testing next with 3.7.4.
> Hopefully with this I can find out which change(s) made the sensitivity
> worse.

Between 3.7 and 3.8 there were two commits for AR9485 (the rest are for PAPRD, which is disabled for all chips).

a796a1d ath9k_hw: Fix RX gain initvals for AR9485
413c030 ath9k_hw: Update AR9485 initvals

Can you try this patch ?

https://patchwork.kernel.org/patch/2696121/

[jkp (jkp-linux-kernel-bugs)]

I'll test - against which version, 3.10-rc5?

[sujith (sujith-linux-kernel-bugs)]

The patch was posted for the wireless-testing tree, but it should apply on top of mainline (3.10-rc5).

[sujith (sujith-linux-kernel-bugs)]

Also, can you please test this patch ?
http://msujith.org/patches/ar9485/ar9485-test.patch

[jkp (jkp-linux-kernel-bugs)]

Wow, the first patch makes a big difference! Tested on 3.10-rc4 as the 3.10-rc5 compile didn't finish yet. Strength meter now shows better readings than on 3.6.11 and 3.7.1, and seems to be on par with what Win8 shows. Thanks. Writing this on the wireless link with power management on, will test with long-term wireless use and report if there are problems.

Quality=54/70 Signal level=-56 dBm
Link Quality=48/70 Signal level=-62 dBm

[jkp (jkp-linux-kernel-bugs)]

Works also with second patch, maybe a bit lower signal values but maybe not, not sure:

          Link Quality=45/70 Signal level=-65 dBm
          Link Quality=45/70 Signal level=-65 dBm
          Link Quality=37/70 Signal level=-73 dBm
          Link Quality=49/70 Signal level=-61 dBm
          Link Quality=40/70 Signal level=-70 dBm
          Link Quality=51/70 Signal level=-59 dBm

[jkp (jkp-linux-kernel-bugs)]

With power management off, speed as reported by iwconfig drops to 1Mbps as before, but rises more often back to 65 Mbps, does seem problematic. . Kernel 3.10-rc4. With power management on, seems to stay at 65 Mbps.

[sujith (sujith-linux-kernel-bugs)]

The second patch is applicable for a specific model of AR9485. Can you please attach the output of "dmidecode" to this bug ? Also, the contents of "modal_eeprom" in the ath9k debugfs directory.

The power management issue appears to be different, so we can analyze it in a new bug report.

[sujith (sujith-linux-kernel-bugs)]

(In reply to comment #99)
> OK ! If you need me test anything, feel free to ask.

Please test this patch: https://patchwork.kernel.org/patch/2696121/

[jkp (jkp-linux-kernel-bugs)]

Here's the info from kernel version 3.8.0 (suppose that doesn't matter but just saying in case), (that's because for some reason the internal display of this computer doesn't work with the 3.10rc4 kernel and I'm on the move without a display cable).

modal_eeprom:

   2GHz modal Header :
 Chain0 Ant. Control : 16
 Chain1 Ant. Control : 16
 Chain2 Ant. Control : 16
 Ant. Common Control : 1088
Ant. Common Control2 : 559240
           Ant. Gain : 0
       Switch Settle : 44
    Chain0 xatten1DB : 30
    Chain1 xatten1DB : 0
    Chain2 xatten1DB : 0
Chain0 xatten1Margin : 5
Chain1 xatten1Margin : 0
Chain2 xatten1Margin : 0
          Temp Slope : 38
          Volt Slope : 0
      spur Channels0 : 180
      spur Channels1 : 140
      spur Channels2 : 164
      spur Channels3 : 100
      spur Channels4 : 0
 Chain0 NF Threshold : -1
 Chain1 NF Threshold : 0
 Chain2 NF Threshold : 0
          Quick Drop : 0
       txEndToXpaOff : 0
      xPA Bias Level : 0
  txFrameToDataStart : 14
       txFrameToPaOn : 14
      txFrameToXpaOn : 14
              txClip : 3
    ADC Desired size : -30
   5GHz modal Header :
 Chain0 Ant. Control : 0
 Chain1 Ant. Control : 0
 Chain2 Ant. Control : 0
 Ant. Common Control : 272
Ant. Common Control2 : 139810
           Ant. Gain : 0
       Switch Settle : 45
    Chain0 xatten1DB : 0
    Chain1 xatten1DB : 0
    Chain2 xatten1DB : 0
Chain0 xatten1Margin : 0
Chain1 xatten1Margin : 0
Chain2 xatten1Margin : 0
          Temp Slope : 68
          Volt Slope : 0
      spur Channels0 : 0
      spur Channels1 : 0
      spur Channels2 : 0
      spur Channels3 : 0
      spur Channels4 : 0
 Chain0 NF Threshold : -1
 Chain1 NF Threshold : 0
 Chain2 NF Threshold : 0
          Quick Drop : 0
       txEndToXpaOff : 0
      xPA Bias Level : 0
  txFrameToDataStart : 14
       txFrameToPaOn : 14
      txFrameToXpaOn : 14
              txClip : 3
    ADC Desired size : -30

dmidecode with some id info removed:

# dmidecode 2.11
# SMBIOS entry point at 0xda152198
SMBIOS 2.7 present.
23 structures occupying 1673 bytes.
Table at 0xDA130018.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
 Vendor: American Megatrends Inc.
 Version: TX300CA.207
 Release Date: 01/03/2013
 Address: 0xF0000
 Runtime Size: 64 kB
 ROM Size: 6144 kB
 Characteristics:
  PCI is supported
  BIOS is upgradeable
  BIOS shadowing is allowed
  Boot from CD is supported
  Selectable boot is supported
  BIOS ROM is socketed
  EDD is supported
  5.25"/1.2 MB floppy services are supported (int 13h)
  3.5"/720 kB floppy services are supported (int 13h)
  3.5"/2.88 MB floppy services are supported (int 13h)
  Print screen service is supported (int 5h)
  8042 keyboard serv...

[sujith (sujith-linux-kernel-bugs)]

(In reply to comment #110)
> Here's the info from kernel version 3.8.0 (suppose that doesn't matter but
> just
> saying in case), (that's because for some reason the internal display of this
> computer doesn't work with the 3.10rc4 kernel and I'm on the move without a
> display cable).

Thanks.

Here is a patch adding support for this card:
http://msujith.org/patches/wl/Jun-13-2013/0001-ath9k-Add-custom-parameters-for-CUS198.patch

Can you test this ? This will apply on top of the earlier patch ("Assign default xlna config for AR9485").

Also, after you explicitly unload/reload ath9k (modprobe -r ath9k; modprobe ath9k), the line "Set parameters for CUS198" should be seen in dmesg.

[jkp (jkp-linux-kernel-bugs)]

Applied first https://patchwork.kernel.org/patch/2696121/ then http://msujith.org/patches/wl/Jun-13-2013/0001-ath9k-Add-custom-parameters-for-CUS198.patch on top of Ubuntu kernel 3.8.0-26 which I have running now.

Patch(1) applied it with some fuzz and I had to manually apply the patch to pci.c.

Seems to work fine with a short test: decent bandwidth, keeps up, shows 65 Mbps as rate, link quality between 40 and 50, and I get the kernel message:

ath: phy1: Set parameters for CUS198

I can test later with some other kernel versions if needed.

[gfmichaud (gfmichaud-linux-kernel-bugs)]

(In reply to comment #109)
> (In reply to comment #99)
> > OK ! If you need me test anything, feel free to ask.
>
> Please test this patch: https://patchwork.kernel.org/patch/2696121/

I need a few precisions :
- do I have to apply this patch only ?
- on top of the 3.10-rc5 kernel ?
- with powersave mode off ?
- what do I have to post (logs...) after testing ?

[sujith (sujith-linux-kernel-bugs)]

On top of Linus Torvalds' tree, apply these patches:

https://patchwork.kernel.org/patch/2696121/
http://msujith.org/patches/wl/Jun-13-2013/0001-ath9k-Add-custom-parameters-for-CUS198.patch

PS has been disabled by default in mainline now.

Reload ath9k and in dmesg, the message "Set parameters for CUS198" should be seen.

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Sorry I'm a kernel newbie...
How can I download Linus' tree ?
Previously, I downloaded the sources from kernel.org

[sujith (sujith-linux-kernel-bugs)]

Hm, in that case, you can just apply the patches on top of the 3.10-rc5 tarball.

[jkp (jkp-linux-kernel-bugs)]

Tested also with mainline 3.9.5, applied first https://patchwork.kernel.org/patch/2696121/ then http://msujith.org/patches/wl/Jun-13-2013/0001-ath9k-Add-custom-parameters-for-CUS198.patch. Applied with some fuzz, no manual intervention required, results look the same as with 3.8.0.

[jkp (jkp-linux-kernel-bugs)]

Same good results with mainline 3.10-rc5, applied first
https://patchwork.kernel.org/patch/2696121/ then
http://msujith.org/patches/wl/Jun-13-2013/0001-ath9k-Add-custom-parameters-for-CUS198.patch.
Applied with some fuzz, no manual intervention required, results look the same
as with 3.8.0 and 3.9.5.

[jkp (jkp-linux-kernel-bugs)]

Out of topic probably, but as I see that bluetooth is in the same device: seems like there is a problem with bluetooth also, but could be something else than the driver. Device is found, hciconfig shows bytes sent and received, but hcitool scan doesn't show devices.

[sujith (sujith-linux-kernel-bugs)]

What does lsusb -v show ?

[jkp (jkp-linux-kernel-bugs)]

Bus 001 Device 003: ID 13d3:3402 IMC Networks
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 1.10
  bDeviceClass 224 Wireless
  bDeviceSubClass 1 Radio Frequency
  bDeviceProtocol 1 Bluetooth
  bMaxPacketSize0 64
  idVendor 0x13d3 IMC Networks
  idProduct 0x3402
  bcdDevice 0.01
  iManufacturer 1
  iProduct 2
  iSerial 3
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 177
    bNumInterfaces 2
    bConfigurationValue 1
    iConfiguration 4
    bmAttributes 0xe0
      Self Powered
      Remote Wakeup
    MaxPower 100mA
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 0
      bAlternateSetting 0
      bNumEndpoints 3
      bInterfaceClass 224 Wireless
      bInterfaceSubClass 1 Radio Frequency
      bInterfaceProtocol 1 Bluetooth
      iInterface 0
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x81 EP 1 IN
        bmAttributes 3
          Transfer Type Interrupt
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0010 1x 16 bytes
        bInterval 1
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x82 EP 2 IN
        bmAttributes 2
          Transfer Type Bulk
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0040 1x 64 bytes
        bInterval 1
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x02 EP 2 OUT
        bmAttributes 2
          Transfer Type Bulk
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0040 1x 64 bytes
        bInterval 1
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 1
      bAlternateSetting 0
      bNumEndpoints 2
      bInterfaceClass 224 Wireless
      bInterfaceSubClass 1 Radio Frequency
      bInterfaceProtocol 1 Bluetooth
      iInterface 0
      Endpoint Descriptor:
       bLength 7
        bDescriptorType 5
        bEndpointAddress 0x83 EP 3 IN
        bmAttributes 1
          Transfer Type Isochronous
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0000 1x 0 bytes
        bInterval 1
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x03 EP 3 OUT
        bmAttributes 1
    ...

[sujith (sujith-linux-kernel-bugs)]

Hm, that's weird. What does 'ls -l /sys/bus/usb/drivers' show ? Does it have ath3k ?

[jkp (jkp-linux-kernel-bugs)]

No - there's "btusb" with contents:

lrwxrwxrwx 1 root root 0 kesä 13 19:30 1-1.1:1.0 -> ../../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0
lrwxrwxrwx 1 root root 0 kesä 13 19:30 1-1.1:1.1 -> ../../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.1
--w------- 1 root root 4096 kesä 13 19:30 bind
lrwxrwxrwx 1 root root 0 kesä 13 19:30 module -> ../../../../module/btusb
-rw-r--r-- 1 root root 4096 kesä 13 19:30 new_id
-rw-r--r-- 1 root root 4096 kesä 13 19:30 remove_id
--w------- 1 root root 4096 kesä 13 19:02 uevent
--w------- 1 root root 4096 kesä 13 19:30 unbind

[gfmichaud (gfmichaud-linux-kernel-bugs)]

One last question before testing : do I have to disable ATH9K_RATE_CONTROL or not ?

[jkp (jkp-linux-kernel-bugs)]

Hmm, probably ran lsusb -v without root access, here's with root, has some more info:

Bus 001 Device 003: ID 13d3:3402 IMC Networks
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 1.10
  bDeviceClass 224 Wireless
  bDeviceSubClass 1 Radio Frequency
  bDeviceProtocol 1 Bluetooth
  bMaxPacketSize0 64
  idVendor 0x13d3 IMC Networks
  idProduct 0x3402
  bcdDevice 0.01
  iManufacturer 1 Atheros Communications
  iProduct 2 Bluetooth USB Host Controller
  iSerial 3 Alaska Day 2006
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 177
    bNumInterfaces 2
    bConfigurationValue 1
    iConfiguration 4 BT HCI
    bmAttributes 0xe0
      Self Powered
      Remote Wakeup
    MaxPower 100mA
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 0
      bAlternateSetting 0
      bNumEndpoints 3
      bInterfaceClass 224 Wireless
      bInterfaceSubClass 1 Radio Frequency
      bInterfaceProtocol 1 Bluetooth
      iInterface 0
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x81 EP 1 IN
        bmAttributes 3
          Transfer Type Interrupt
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0010 1x 16 bytes
        bInterval 1
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x82 EP 2 IN
        bmAttributes 2
          Transfer Type Bulk
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0040 1x 64 bytes
        bInterval 1
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x02 EP 2 OUT
        bmAttributes 2
          Transfer Type Bulk
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0040 1x 64 bytes
        bInterval 1
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 1
      bAlternateSetting 0
      bNumEndpoints 2
      bInterfaceClass 224 Wireless
      bInterfaceSubClass 1 Radio Frequency
      bInterfaceProtocol 1 Bluetooth
      iInterface 0
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x83 EP 3 IN
        bmAttributes 1
          Transfer Type Isochronous
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0000 1x 0 bytes
        bInterval 1
      Endpoint De...

[sujith (sujith-linux-kernel-bugs)]

(In reply to comment #124)
> One last question before testing : do I have to disable ATH9K_RATE_CONTROL or
> not ?

Yes, ATH9K_RATE_CONTROL has to be disabled.

[sujith (sujith-linux-kernel-bugs)]

(In reply to comment #125)
> Hmm, probably ran lsusb -v without root access, here's with root, has some
> more
> info:
>
> Bus 001 Device 003: ID 13d3:3402 IMC Networks
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 1.10
> bDeviceClass 224 Wireless
> bDeviceSubClass 1 Radio Frequency
> bDeviceProtocol 1 Bluetooth
> bMaxPacketSize0 64
> idVendor 0x13d3 IMC Networks
> idProduct 0x3402
> bcdDevice 0.01
> iManufacturer 1 Atheros Communications
> iProduct 2 Bluetooth USB Host Controller
> iSerial 3 Alaska Day 2006

Ok, I am not familiar with bluetooth - I'll try to get more information.

[jkp (jkp-linux-kernel-bugs)]

Ah, I wondered I might have forgotten something with my 3.8.0 test - now I remember, it was ATH9K_RATE_CONTROL:

# grep RATE_CONTROL .config
CONFIG_ATH9K_RATE_CONTROL=y

Seems to work quite well even with this.

For 3.9.5 and 3.10 I had it disabled:

# grep RATE_CONTROL .config
# CONFIG_ATH9K_RATE_CONTROL is not set

[gfmichaud (gfmichaud-linux-kernel-bugs)]

So I've applied both patches on top of the 3.10-rc5 kernel.

Everything looks OK :
gfmichaud@dragonfly:~$ sudo rmmod ath9k
[sudo] password for gfmichaud:
gfmichaud@dragonfly:~$ sudo modprobe ath9k
gfmichaud@dragonfly:~$ dmesg | grep -i parameters
[ 289.311397] ath: phy0: ANI parameters: SI=3, ofdmWS=on FS=7 MRCcck=on listenTime=25 ofdmErrs=64 cckErrs=892
[ 297.359862] ath: phy1: Set parameters for CUS198

However, it looks like powersave is on by default (I've removed the item in /etc/pm/power.d that disabled it) :
gfmichaud@dragonfly:~$ iw dev wlan0 get power_save
Power save: on

Link quality seems to have improved a lot :
- in 3.8 without patches, "iw dev wlan0 link" shows me "signal" between -74 and -86 dBm
- in 3.10-rc5 with the patches, it shows me "signal" between -55 and -62 dBm

I'll do futher testing and report here.

[sujith (sujith-linux-kernel-bugs)]

(In reply to comment #129)
> However, it looks like powersave is on by default (I've removed the item in
> /etc/pm/power.d that disabled it) :
> gfmichaud@dragonfly:~$ iw dev wlan0 get power_save
> Power save: on

The PS/rate-control patches will be in -rc6.

[gfmichaud (gfmichaud-linux-kernel-bugs)]

I've been using it with all doors closed at home and experienced no disconnection and no lag.
Looks really great !!! :-)

[jkp (jkp-linux-kernel-bugs)]

No problems here either, seems to work fine in longer term (well, a few hours) use too. Power management has been on for me though so far, will try with power management off.

[jkp (jkp-linux-kernel-bugs)]

With power management off, when I look at the iwconfig bit rate every five seconds, it's mostly 65 Mbps but about every once in 25 .. once in 50 it's 1 Mbps.

[jkp (jkp-linux-kernel-bugs)]

With power management off, occasionally there are longer periods of low speed (1..30 Mbps) and this affects also practical usability quite a lot.

[sujith (sujith-linux-kernel-bugs)]

Can you open separate bugs for the PS and bluetooth issues ? Thanks.

John, I think this bug can be closed now, patch has been sent:
https://patchwork.kernel.org/patch/2718041/

[jkp (jkp-linux-kernel-bugs)]

OK, I will - and big thanks for making the wireless much more usable!

[gfmichaud (gfmichaud-linux-kernel-bugs)]

Yes, thank you very very much ! :-)

[jkp (jkp-linux-kernel-bugs)]

Bugs 59691 & 59701 are the power management and bluetooth bugs:

https://bugzilla.kernel.org/show_bug.cgi?id=59691

https://bugzilla.kernel.org/show_bug.cgi?id=59701

[Timo Jyrinki (timo-jyrinki)]

Upstream bug (https://bugzilla.kernel.org/show_bug.cgi?id=49201) was marked as Fix Released. I checked that the related fixes are in Ubuntu 13.10 (make sure you're running the latest 3.10 kernel). It should be useful to test it to find out whether things finally have improved. My initial take is that it seems to work better, but no wonders expected. But is it now as good as it gets with the hardware/antenna limitations?

It might be best to file a new bug to track newer upstream bug reports. Alternatively, this bug could be updated with another upstream bug report, but the current one is indeed set as fixed.

[Guillaume Michaud (gfmichaud)]

Are you sure the patches have been included in the latest 3.10 ? Because their state is still "new" on patchwork.kernel.org.
https://patchwork.kernel.org/patch/2696121/
https://patchwork.kernel.org/patch/2718041/

As far as I'm concerned, they have worked really well and improved dramatically wifi performance and range.

[Timo Jyrinki (timo-jyrinki)]

Ah, thanks Guillaume for correction! I was staring at the disabling of power management, enabling of minstrel algorithm etc but there was still more then. So staying tuned as well.

[gfmichaud (gfmichaud-linux-kernel-bugs)]

How do we know in which kernel the patches will be committed ?
Will the be in 3.10 or later ?

[linville (linville-linux-kernel-bugs)]

Presumably in 3.11...

[Timo Jyrinki (timo-jyrinki)]

Yep, linux-next is a real, great improvement. I took the latest snapshot from https://www.kernel.org/pub/linux/kernel/projects/backports/2013/06/18/ + ran make defconfig-ath9k && make && sudo make install. Hopefully the patches will get in soon enough, so that I don't need to rerun the module building every time kernel updates.

[Guillaume Michaud (gfmichaud)]

Timo, do you mean there's an "official" (or semi-official) way to get a kernel which includes the update ?
If so, what is it ?
I use a kernel I've compiled myself for now, but now and then I've got issues with missing modules and so on.

[Timo Jyrinki (timo-jyrinki)]

Guillaume: Official/easy enough way to get the kernel modules on top of your existing (eg. Ubuntu provided) kernel. First, I noticed the patches talked about were already in the 'linux-next' at http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/drivers/net/wireless/ath/ath9k?id=HEAD - added around two weeks ago.

Secondly the Driver Backports (formerly compat-wireless) project has been providing development drivers from linux-next for users of older kernels, so it's possible to do just what I did: get the tarball, compile and install a specific driver and reboot. You keep on using the default Ubuntu kernel but get up-to-date drivers. If you update the kernel from eg. distro archives, you need to recompile the updated drivers.

See https://backports.wiki.kernel.org/index.php/Main_Page for more info, although I find it a bit non-structured compared to the old 'compat-wireless' site that used to reside under http://wireless.kernel.org/.

[Guillaume Michaud (gfmichaud)]

I've done it yesterday ; it works great. :-)

I don't know who can do it but it would be a great idea to update
https://help.ubuntu.com/community/AsusZenbook
and indicate this workaround.

[Guillaume Michaud (gfmichaud)]

The bug has been solved in the kernel ; it was not a network-manager bug.

[Timo Jyrinki (timo-jyrinki)]

Guillaume: added to the wiki page. Meanwhile, the patches have been merged to Torvalds' Linux tree, meaning 3.11 kernel will have the patches: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/net/wireless/ath/ath9k?id=HEAD

[Guillaume Michaud (gfmichaud)]

Does not concern Network Manager after all

[Guillaume Michaud (gfmichaud)]

Timo : great ! thanks ! :-)

[Pascal d'Hermilly (pascal-tipisoft)]

Will the fix be backported to 13.04?

[artur.szymczak (artur.szymczak-linux-kernel-bugs)]

Was it merged in 3.11-rc3?

[Timo Jyrinki (timo-jyrinki)]

I think it would be useful to backport to 13.04, but one would need to know which patches exactly are needed. If someone knows, please share. The "Assign default xlna config" was now backported to upstream 3.10 series and is already in 13.10 as well, but I wonder if that patch alone (http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/net/wireless/ath/ath9k?id=e9c25a407d5c75646eb258de1363dccc1fd3ab47) would be enough to patch 13.04's 3.8 kernel with? Or would http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath9k?id=9b60b64bfe98b9cc01b21e6126819b11a0f0a971 or maybe more be needed as well?

[Guillaume Michaud (gfmichaud)]

Those are the two (and only) patches needed :

[v2] ath9k: Add custom parameters for CUS198
https://patchwork.kernel.org/patch/2718041/

[1/3] ath9k_hw: Assign default xlna config for AR9485
https://patchwork.kernel.org/patch/2696121/

[Timo Jyrinki (timo-jyrinki)]

It seems the default xlna config is actually already scheduled for the next Raring kernel update! See bug #1204666.

As for the other one, it needed slight rebasing but I'm attaching the patch that applies with git am to git://kernel.ubuntu.com/ubuntu/ubuntu-raring.git here.

[Timo Jyrinki (timo-jyrinki)]

Another update, since I continue to be interested in this one even though it's fixed for me :)

Ubuntu 12.10 and 13.04 users received a kernel update last night that includes the other patch. That means also users of Ubuntu 12.04.2 and 12.04.3 LTS:s (to be released on Thursday), which use the kernel from 12.10/13.04 respectively, or people with original 12.04 installation who have opted in to use the quantal/raring stacks.

I think I briefly used a similar setup when 3.10 kernel was still in Ubuntu 13.10 and it also used to have only this "Assign default xlna config for AR9485". If I recall correctly it improved some things but the connection still broke up constantly in non-optimal reception?

So I believe the second patch, which I've provided a patch for, would be still required.

[harroxelas (harroxelas-linux-kernel-bugs)]

Were the patches merged on 3.11-rc6?

[j (jaceclayton)]

Hello -- I'm a complex Linux newbie & just installed Ubuntu 12.04.3 LTS on my Asus UX31 -- It's running the updated kernel (as far as I know) and the wi-fi connectivity is very flaky.

    I would like to try out the patch Timo provides but have no idea where to begin. Can someone direct me to some basic info on patching in Ubuntu, and what I would need to know to patch this particular file?

 thanks,

 j

[sujith (sujith-linux-kernel-bugs)]

The fixes are in the 3.11 release.

[Timo Jyrinki (timo-jyrinki)]

j: Unfortunately I don't know where would be up-to-date and correct instructions for easily building own patched kernel, cleanly and as a .deb packge. https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel looks relatively simple compared to other pages, but not really sure if it's completely accurate.

For compiling the kernel on your own, the idea would be to apply the patch to the kernel with:

patch -p1 < v2-ath9k-Add-custom-parameters-for-CUS198.patch

inside the kernel sources directory. Then compile and install the kernel and test WLAN after rebooting into the new kernel.

If not wanting to test the patch alone and just wanting to have the problem fixed, I posted instructions on updating only the driver at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1160188/comments/58

[Kevin Follstad (kfollstad)]

I am still having problems after applying the backported patched driver.

I went from my wifi dropping out ~ every 20 minutes (reason 2) with a reboot being the only way to reestablish a connection to this:

Sep 22 14:23:09 K55A NetworkManager[1138]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Sep 22 14:28:06 K55A NetworkManager[1138]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Sep 22 14:30:06 K55A NetworkManager[1138]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Sep 22 14:32:06 K55A NetworkManager[1138]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Sep 22 14:40:06 K55A NetworkManager[1138]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Sep 22 14:48:06 K55A NetworkManager[1138]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Sep 22 14:56:06 K55A NetworkManager[1138]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Sep 22 14:58:37 K55A NetworkManager[1138]: <info> (wlan0): supplicant interface state: completed -> disconnected
Sep 22 14:58:37 K55A NetworkManager[1138]: <info> (wlan0): supplicant interface state: disconnected -> scanning
Sep 22 14:58:38 K55A NetworkManager[1138]: <info> (wlan0): supplicant interface state: scanning -> authenticating
Sep 22 14:58:38 K55A NetworkManager[1138]: <info> (wlan0): supplicant interface state: authenticating -> associating
Sep 22 14:58:38 K55A NetworkManager[1138]: <info> (wlan0): supplicant interface state: associating -> associated
Sep 22 14:58:38 K55A NetworkManager[1138]: <info> (wlan0): supplicant interface state: associated -> completed
Sep 22 15:00:06 K55A NetworkManager[1138]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Sep 22 15:04:06 K55A NetworkManager[1138]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Sep 22 15:06:06 K55A NetworkManager[1138]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Sep 22 15:08:06 K55A NetworkManager[1138]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Sep 22 15:14:06 K55A NetworkManager[1138]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Sep 22 15:18:06 K55A NetworkManager[1138]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted

I suppose it is an improvement in that the need to reboot is gone. But the end result is that every few minutes there will be a period where the connection cuts out completely or latency goes WAY UP as network manager tries to reestablish the connection.

[linville (linville-linux-kernel-bugs)]

*** Bug 55171 has been marked as a duplicate of this bug. ***

[linville (linville-linux-kernel-bugs)]

*** Bug 55901 has been marked as a duplicate of this bug. ***

[Timo Jyrinki (timo-jyrinki)]

I'm marking this as fixed as it's fixed in a released Ubuntu (13.10), and the remaining thing would be to port needed patches to older Ubuntus.

According to Kevin's test it may be that more patches would need to be backported than the one specified. I'd recommend 13.04 users to upgrade to 13.10. 13.04 only has 9 months of security support so that must be done in 2-3 months anyhow.

The Ubuntu 13.10 kernel will also be available to 12.04 LTS users by January (via opt-in or installing from 12.04.4 installation media). That can be followed at bug #1244356.

[tafazzi87 (tafazzi-87)]

sorry but i see that with ubuntu 13.10 this bug is fixed, but i've still that. can i fix this in some way???

[wim glenn (wim-glenn-w)]

Agree this is NOT fixed on 13.10. I had the problem on my zenbook ux31 on 13.04, and resolved it with the advices mentioned in this thread. But after installing 13.10 a couple of days ago, the problem is back just as before :(

Linux wim-zenbook 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

[Timo Jyrinki (timo-jyrinki)]

Hmm. This bug is associated with the upstream bug https://bugzilla.kernel.org/show_bug.cgi?id=49201 which was fixed. I can also confirm than on my Zenbook UX31E starting from the 3.10 kernel and also with the 3.11 kernel in Ubuntu 13.10, WLAN is working well in many places where it was completely unusable before.

It's probable there are different kind of problems in different networks (like WPA2 Enterprise), but at least the one identified upstream which broke connections, gave poor connectivity for many was fixed.

I'd suggest filing a new bug for the issue you're seeing, since otherwise this bug would become quite confusing to handle with multiple different upstream bugs. If you check https://bugzilla.kernel.org/buglist.cgi?quicksearch=ar9485 , there is for example the bug 62381 to which the new Launchpad bug could be associated if it has a fitting description.

I think this bug should remain marked Fix Released unless Guillaume (the bug reporter) finds that the bug he tracked with upstream has really regressed in the 3.11 at some point.

It is anyway an interesting data point that you had the bug fixed by using the wireless tree snapshots, but somehow are seeing still a problem with 3.11 where all those fixes should be included.

[Guillaume Michaud (gfmichaud)]

As far as I'm concerned, everything works fine with 3.11 in Saucy.
I agree with Timo : I think it's another bug, that should be declared and investigated separately.

[tafazzi87 (tafazzi-87)]

yes i understand but i've same bug it's useless open a new bug, because it's not fixed for me and for another...if i have to open a new bug for my issue i've to copy and paste this

[eugene.shatokhin (eugene.shatokhin-linux-kernel-bugs)]

(In reply to Sujith from comment #143)
> The fixes are in the 3.11 release.

Thanks! Could you queue them for the stable kernel trees as well?

[Kemel Zaidan aka Legendario (kemelzaidan)]

Well, I've just bought a new laptop with the same wifi chipset and it doesn't work properly. The connection isn't unstable, but it's even worse: the system only recognize the wifi interface after suspending the machine and waking up again. That's so weird but it's the only workaround I've found so far: http://ubuntuforums.org/showthread.php?t=2172434

This driver certainly needs to be worked out.

[jesuinovieira_ (jesuinovieira-linux-kernel-bugs)]

Hi, can anyone help me?

How do I apply a patch? I got the same problem.