[ath9k-devel] Card AR928X very slow with new kernels

[ath9k-devel] Card AR928X very slow with new kernels

[Pierre Willaime]

Hello,

I have some troubles with my atheros wireless card. With new kernels, the connection is very slow and unreliable. It was not the same on debian stable with an old kernel.

It seems that the problem is somehow linked with the ath9k driver and linux 3.2xxx.

I tried to disable ipv6 and to start ath9k with the option "nohwcrypt" but I didn't see any huge improvement. Here are the commands I entered:

# Disable ipv6
  	echo "#disable ipv6" | tee -a /etc/sysctl.conf 	       
	echo "net.ipv6.conf.all.disable_ipv6 = 1" | tee -a /etc/sysctl.conf 
	echo "net.ipv6.conf.default.disable_ipv6 = 1" | tee -a /etc/sysctl.conf 
	echo "net.ipv6.conf.lo.disable_ipv6 = 1" | tee -a /etc/sysctl.conf

# ath9k option
  	echo "options ath9k nohwcrypt=1" > /etc/modprobe.d/ath9k.conf
	

Here is a way to fix this? If no, could I wait for an upgrade of linux which could fix this or is there no hope?

Thanks

pw

P-S : I am not member of the ath9k-devel list, so if you can put me in CC...

------------------------------
Here is some information on my system (debian sid); I use network-manager:

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

# iwconfig
wlan0     IEEE 802.11abgn  ESSID:"xxxxxxxxx"  
          Mode:Managed  Frequency:2.437 GHz  Access Point: 00:23:F8:95:B2:11   
          Bit Rate=1 Mb/s   Tx-Power=16 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:on
          Link Quality=26/70  Signal level=-84 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:293  Invalid misc:11321   Missed beacon:0

# uname -a
Linux nil 3.2.0-2-amd64 #1 SMP Sun Apr 15 16:47:38 UTC 2012 x86_64 GNU/Linux


# modinfo ath9k
filename:       /lib/modules/3.2.0-2-amd64/kernel/drivers/net/wireless/ath/ath9k/ath9k.ko
license:        Dual BSD/GPL
description:    Support for Atheros 802.11n wireless LAN cards.
author:         Atheros Communications
alias:          pci:v0000168Cd00000034sv*sd*bc*sc*i*
alias:          pci:v0000168Cd00000033sv*sd*bc*sc*i*
alias:          pci:v0000168Cd00000032sv*sd*bc*sc*i*
alias:          pci:v0000168Cd00000030sv*sd*bc*sc*i*
alias:          pci:v0000168Cd0000002Esv*sd*bc*sc*i*
alias:          pci:v0000168Cd0000002Dsv*sd*bc*sc*i*
alias:          pci:v0000168Cd0000002Csv*sd*bc*sc*i*
alias:          pci:v0000168Cd0000002Bsv*sd*bc*sc*i*
alias:          pci:v0000168Cd0000002Asv*sd*bc*sc*i*
alias:          pci:v0000168Cd00000029sv*sd*bc*sc*i*
alias:          pci:v0000168Cd00000027sv*sd*bc*sc*i*
alias:          pci:v0000168Cd00000024sv*sd*bc*sc*i*
alias:          pci:v0000168Cd00000023sv*sd*bc*sc*i*
depends:        ath9k_hw,ath9k_common,mac80211,ath,cfg80211
intree:         Y
vermagic:       3.2.0-2-amd64 SMP mod_unload modversions 
parm:           debug:Debugging mask (uint)
parm:           nohwcrypt:Disable hardware encryption (int)
parm:           blink:Enable LED blink on activity (int)
parm:           btcoex_enable:Enable wifi-BT coexistence (int)

$ lsmod | grep -i ath
ath9k                  73540  0 
ath9k_common           12728  1 ath9k
ath9k_hw              322017  2 ath9k_common,ath9k
ath                    21370  3 ath9k_hw,ath9k_common,ath9k
mac80211              192768  2 ath9k,iwlwifi
cfg80211              137140  4 mac80211,ath,ath9k,iwlwifi

[ath9k-devel] Card AR928X very slow with new kernels

[Mitch Davis]

On Sun, Apr 22, 2012 at 10:54 AM, Pierre Willaime
<pierre.willaime@gmail.com> wrote:
> Hello,
>
> I have some troubles with my atheros wireless card. With new kernels, the connection is very slow and unreliable. It was not the same on debian stable with an old kernel.

Me too, although I don't have any datapoints about older versions.

I am running Linux 3.3.2 under Fedora 16.  According to lspci, my computer has:

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

> I tried to disable ipv6 and to start ath9k with the option "nohwcrypt" but I didn't see any huge improvement.

I didn't see any improvement either.

A good way to trigger the problem for me is to run transmission, the
bittorrent program.  As well as it Not Working Very Well, plus
Frequent Disconnects, the ping time from a 2nd computer to the AP goes
from 2ms to 8000ms.  So perhaps the driver is spamming the airwaves.

I'd love to investigate what's happening but I have no idea where to
start.  Is this page what I'm after:

  http://linuxwireless.org/en/users/Drivers/ath9k/debug

That page tells me about all the cool things for debugging, but
doesn't give me an idea of how to methodically go about finding the
right info.  Any suggestions for values of debug?  Any suggestions for
the right place to look in /sys/kernel/debug/ath9k?

Thank you,

Mitch.

[ath9k-devel] Card AR928X very slow with new kernels

[Peter Stuge]

Mitch Davis wrote:
> I'd love to investigate what's happening but I have no idea where
> to start.  Is this page what I'm after:
> 
>   http://linuxwireless.org/en/users/Drivers/ath9k/debug
> 
> That page tells me about all the cool things for debugging, but
> doesn't give me an idea of how to methodically go about finding the
> right info.  Any suggestions for values of debug?  Any suggestions
> for the right place to look in /sys/kernel/debug/ath9k?

I was in your situation some years ago. Unfortunately what you hope
for is nowhere to be found. :\

If you want someone knowledgeable about ath9k hardware to talk in
deep technical detail with you then you must basically first prove
yourself by studying the driver enough that you can actually fix the
problem on your own. You will unfortunately find little to no help
with loading the driver into your head, not even some simple overview
like "it's like NIC with x tx descriptors and y rx descriptors". :\
The data sheet for the hardware is not generally available. It has
leaked of course, but you are discouraged to use it unless you have
received your own copy off-list thanks to your outstanding efforts.

Atheros try to take problem reports seriously and will try to
reproduce problems in their lab. If they succeed they typically
develop fixes. I have yet to see Atheros guide any user on the list,
competent as she may be, to do remote debugging to find the key
information about the error in the local environment where the error
is reliably reproducible. I have ranted violently about this on the
list and many people hate me for that.

Obviously your problem is often not reproducible in the lab, because
it depends on factors in your RF environment, which I assume that
everyone understands. I'm not completely sure about the reasons for
this sad state of affairs, but that's the way it goes here. :\


//Peter

[ath9k-devel] Card AR928X very slow with new kernels

[Mitch Davis]

On Mon, Apr 23, 2012 at 11:39 AM, Peter Stuge <peter@stuge.se> wrote:
> Mitch Davis wrote:
>> I'd love to investigate what's happening but I have no idea where
>> to start. ?Is this page what I'm after:
>>
>> ? http://linuxwireless.org/en/users/Drivers/ath9k/debug
>>
>> That page tells me about all the cool things for debugging, but
>> doesn't give me an idea of how to methodically go about finding the
>> right info. ?Any suggestions for values of debug? ?Any suggestions
>> for the right place to look in /sys/kernel/debug/ath9k?
>
> I was in your situation some years ago. Unfortunately what you hope
> for is nowhere to be found. :\

Sigh.  I'm confronted with a wall of possibilities, and no idea of
where to start.

> then you must basically first prove yourself

This situation is akin to having to take a fire-fighter's course in
order to have the fire brigade put out the fire in your house. :-(

> I have ranted violently about this on the list and many people hate me for that.

My turn to rant.

Does a project which rails so loudly against the truth deserve your
time?  Other projects say "hmm, sorry to hear that, turn on these
debugging options, send us the log, and we'll see what we can do".
It's certainly what I've done with the other open source projects I've
been involved with.  A bug report is a GIFT!

I don't have the time to become an ath9k expert, I have enough irons
in enough other fires.  I am willing to do the right thing for open
source by doing quality debugging work, but I'm not going to become an
ath9k expert for a $20 wifi card

If one can't get help from the project, it would be a better use of my
time and money to throw away the AR9287 card and buy a different
brand.  And I can help other Linux users save their time by blogging
about my experience, and Google watching AR9287 and AR928X, so that
when someone says "I have a problem", I can save them time by telling
them honestly and candidly of my experience in getting help.

Or, someone can tell me a debugging option to try, so I can get a log.

Sigh.

[ath9k-devel] Card AR928X very slow with new kernels

[Ben Greear]

On 04/22/2012 07:35 PM, Mitch Davis wrote:
> On Mon, Apr 23, 2012 at 11:39 AM, Peter Stuge<peter@stuge.se>  wrote:
>> Mitch Davis wrote:
>>> I'd love to investigate what's happening but I have no idea where
>>> to start.  Is this page what I'm after:
>>>
>>>    http://linuxwireless.org/en/users/Drivers/ath9k/debug
>>>
>>> That page tells me about all the cool things for debugging, but
>>> doesn't give me an idea of how to methodically go about finding the
>>> right info.  Any suggestions for values of debug?  Any suggestions
>>> for the right place to look in /sys/kernel/debug/ath9k?
>>
>> I was in your situation some years ago. Unfortunately what you hope
>> for is nowhere to be found. :\
>
> Sigh.  I'm confronted with a wall of possibilities, and no idea of
> where to start.

If you have a kernel that works, and one that doesn't, you can try to
bisect and figure out what commit caused it to go bad.

I must have deleted your first email..but can you be more specific
about what kernel(s) work for you and which ones fail?

Try looking at the xmit, interrupt, and recv ath9k debugfs files.

With the very latest wireless-testing tree, there are some extended
interrupt errors in the interrupt debugfs file that might shed
some light.

Let us know what AP you are using, if you know.

Feel free to post a set of these to the list (ie, with some specific
amount of time between them so we can see the rate of change).


Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

[ath9k-devel] Card AR928X very slow with new kernels

[Peter Stuge]

Mitch Davis wrote:
> Does a project which rails so loudly against the truth deserve your time?

I was certainly discouraged from the response I got when I tried to
debug my problems long ago.


> Other projects say "hmm, sorry to hear that, turn on these
> debugging options, send us the log, and we'll see what we can do".
> It's certainly what I've done with the other open source projects
> I've been involved with.  A bug report is a GIFT!

I agree. Suggestions about enabling debug options do happen on the
list, but they're a little bit down the list of common response.
There is incredibly strong focus on lab reproduction, which is of
course particularly useless for anything involving RF on remote site.


> I don't have the time to become an ath9k expert, I have enough irons
> in enough other fires.  I am willing to do the right thing for open
> source by doing quality debugging work, but I'm not going to become
> an ath9k expert for a $20 wifi card

This is exactly what I said. It was very effective in getting me
absolutely no help at all.


> If one can't get help from the project, it would be a better use of
> my time and money to throw away the AR9287 card and buy a different
> brand.  And I can help other Linux users save their time by blogging
> about my experience, and Google watching AR9287 and AR928X, so that
> when someone says "I have a problem", I can save them time by telling
> them honestly and candidly of my experience in getting help.

Give it a couple of days and see what happens, but yes I completely
agree. I have never been able to use ath9k successfully while trying
three different generations of hardware. For the last few years I've
been using an Intel card which isn't perfect either but at least
doesn't have the severe issues I had with ath9k hardware.

Another thing I note is that anything older than the newest hardware,
which usually is not available on the market yet, receives less to no
attention from the more experienced Atheros developers, because they
are all working on the next hardware.

The Atheros hardware is really really nice in comparison with
basically all competitors, so I do want to be able to use it. I'll
get a new ath9k card at some point but it's not very high priority.
I will choose very carefully what I buy based on what few bits of
information come through the list regarding chipsets, in order to
maximize my chances of being able to get qualified and motivated
support. I was looking at AR9380 but I think it is getting too old by
now.


> Or, someone can tell me a debugging option to try, so I can get a log.

Someone might still! I don't expect it will lead to efficient
exchange between developers and users, but hopefully it will
lead to something somewhere.

I've been around for a while but like you I do not have time to
become an ath9k expert besides the many other things I work on,
including hardware and other driver development, so I can't really
help you either, or I would have already. But I stay on the list to
follow ath9k land to know what hardware is relevant (there is
certainly no other way to find out, and even here only very few bits)
and to inform newcomers as yourself somehow what can be expected,
because I know I would have appreciated it *so* much myself.

Of course I'm not making myself any more popular among Atheros
developers but I'm just telling it like it is. I also understand that
many of them may not agree at all with the situation, but I guess
this hardware segment does not really have any margins whatsoever, so
we get what Windows users are willing to pay for.


//Peter

[ath9k-devel] Card AR928X very slow with new kernels

[Mitch Davis]

On Mon, Apr 23, 2012 at 1:07 PM, Ben Greear <greearb@candelatech.com> wrote:
>
> If you have a kernel that works, and one that doesn't, you can try to
> bisect and figure out what commit caused it to go bad.
>
> I must have deleted your first email..but can you be more specific
> about what kernel(s) work for you and which ones fail?

That was Pierre, who started this thread.

For me, I have two AR9287 cards in two almost identical laptops.  For
one of them (wife's), the wireless has never worked well.  The other
(mine) has been pretty good.  Recently I swapped the wireless cards.
Mine started giving all sorts of trouble, but the wife's was no
better.  When I upgraded from kernel 3.3.1 to 3.3.2, mine got a whole
lot better, whereas the wife's didn't.  I suspect there are two problems,
one of which got fixed in 3.3.2.

> Try looking at the xmit, interrupt, and recv ath9k debugfs files.

Thanks I will.

In the case the card becomes unassociated, is there a way of finding
out the reason why?

Mitch.

[ath9k-devel] Card AR928X very slow with new kernels

[Peter Stuge]

Mitch Davis wrote:
> In the case the card becomes unassociated, is there a way of
> finding out the reason why?

For me this happened when some beacon frames weren't received.
No suggestions for finding out *why* they weren't received.


//Peter

[ath9k-devel] Card AR928X very slow with new kernels

[Mitch Davis]

On Mon, Apr 23, 2012 at 10:47 PM, Peter Stuge <peter@stuge.se> wrote:
> Mitch Davis wrote:
>> In the case the card becomes unassociated, is there a way of
>> finding out the reason why?
>
> For me this happened when some beacon frames weren't received.
> No suggestions for finding out *why* they weren't received.

Even that's useful, thanks.

Mitch.

[ath9k-devel] Card AR928X very slow with new kernels

[Ben Greear]

On 04/22/2012 11:58 PM, Mitch Davis wrote:
> On Mon, Apr 23, 2012 at 1:07 PM, Ben Greear<greearb@candelatech.com>  wrote:
>>
>> If you have a kernel that works, and one that doesn't, you can try to
>> bisect and figure out what commit caused it to go bad.
>>
>> I must have deleted your first email..but can you be more specific
>> about what kernel(s) work for you and which ones fail?
>
> That was Pierre, who started this thread.
>
> For me, I have two AR9287 cards in two almost identical laptops.  For
> one of them (wife's), the wireless has never worked well.  The other
> (mine) has been pretty good.  Recently I swapped the wireless cards.
> Mine started giving all sorts of trouble, but the wife's was no
> better.  When I upgraded from kernel 3.3.1 to 3.3.2, mine got a whole
> lot better, whereas the wife's didn't.  I suspect there are two problems,
> one of which got fixed in 3.3.2.
>
>> Try looking at the xmit, interrupt, and recv ath9k debugfs files.
>
> Thanks I will.
>
> In the case the card becomes unassociated, is there a way of finding
> out the reason why?

dmesg output (and/or /var/log/messages) may give clues, as should the
wpa_supplicant logs.

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

[ath9k-devel] Card AR928X very slow with new kernels

[Ben Greear]

On 04/23/2012 06:46 AM, Ben Greear wrote:
> On 04/22/2012 11:58 PM, Mitch Davis wrote:
>> On Mon, Apr 23, 2012 at 1:07 PM, Ben Greear<greearb@candelatech.com>   wrote:
>>>
>>> If you have a kernel that works, and one that doesn't, you can try to
>>> bisect and figure out what commit caused it to go bad.
>>>
>>> I must have deleted your first email..but can you be more specific
>>> about what kernel(s) work for you and which ones fail?
>>
>> That was Pierre, who started this thread.
>>
>> For me, I have two AR9287 cards in two almost identical laptops.  For
>> one of them (wife's), the wireless has never worked well.  The other
>> (mine) has been pretty good.  Recently I swapped the wireless cards.
>> Mine started giving all sorts of trouble, but the wife's was no
>> better.  When I upgraded from kernel 3.3.1 to 3.3.2, mine got a whole
>> lot better, whereas the wife's didn't.  I suspect there are two problems,
>> one of which got fixed in 3.3.2.

Also, 3.3.1 had a bad ath9k regression, that was fixed in 3.3.2....

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com