[ath9k-devel] Problems with ath9k_htc / AR9271

[ath9k-devel] Problems with ath9k_htc / AR9271

[Daniel Glöckner]

Hi,
we are currently evaluating Netgear WNA1100 USB sticks for use in
conjunction with an ARM based embedded device. For our tests we used
the ath9k_htc driver from compat-wireless 3.2.5-1. The sticks are
connected to a USB 1.1 OHCI controller.

Our tests consist of an endless loop of ping, iperf and wget to a
PC connected to the AP (AVM FRITZ!Box 7270 v3, 6m away) via ethernet.
The WPA2 connection uses TKIP for the group cipher and CCMP for the
pairwise cipher.

While the connections are stable over weeks when there is just one
device, the sticks tend to lock up after about 1-2 days when two
devices are competing for airtime. There are a handfull of networks
around, but there is little traffic besides our tests.

I have seen two different lock ups:
1. - USB analyzer shows all packets being NAK'ed by the stick
   - OHCI controller endlessly repeats the same packet
   - Driver queues more and more URBs
   - Kernel runs out of memory, OOM killer goes on a rampage
   - System sometimes recovers a few minutes after removing the stick

2. - Connection apparently dropped due to timeout
   - TCP connects fail with "no route to host"
   - scanning for networks yields no results
   - USB analyzer shows requests still being answered.
   - tcpdump/airodump-ng show not a single packet being received
   - reloading ath9k_htc.ko does not help

Are these known problems and can I do anything to help analyze and fix
them? Shall I create logs with a specific debugging mask?

The goal is to allow the end user to not have to touch the device for
years, so a lock up every two days is a no-go.

Is the AR9271 a good choice for stable connections?
Do you know of other current chipsets with better stability?

Best regards,

  Daniel


-- 
Dipl.-Math. Daniel Gl?ckner, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11,
Bertha-von-Suttner-Stra?e 9, 37085 G?ttingen, Germany
Sitz der Gesellschaft: G?ttingen, Amtsgericht G?ttingen HR B 3160
Gesch?ftsf?hrer: Dr. Uwe Kracke, Ust-IdNr.: DE 205 198 055

emlix - your embedded linux partner

Problems with ath9k_htc / AR9271

[Daniel Glöckner]

Hi,
we are currently evaluating Netgear WNA1100 USB sticks for use in
conjunction with an ARM based embedded device. For our tests we used
the ath9k_htc driver from compat-wireless 3.2.5-1. The sticks are
connected to a USB 1.1 OHCI controller.

Our tests consist of an endless loop of ping, iperf and wget to a
PC connected to the AP (AVM FRITZ!Box 7270 v3, 6m away) via ethernet.
The WPA2 connection uses TKIP for the group cipher and CCMP for the
pairwise cipher.

While the connections are stable over weeks when there is just one
device, the sticks tend to lock up after about 1-2 days when two
devices are competing for airtime. There are a handfull of networks
around, but there is little traffic besides our tests.

I have seen two different lock ups:
1. - USB analyzer shows all packets being NAK'ed by the stick
   - OHCI controller endlessly repeats the same packet
   - Driver queues more and more URBs
   - Kernel runs out of memory, OOM killer goes on a rampage
   - System sometimes recovers a few minutes after removing the stick

2. - Connection apparently dropped due to timeout
   - TCP connects fail with "no route to host"
   - scanning for networks yields no results
   - USB analyzer shows requests still being answered.
   - tcpdump/airodump-ng show not a single packet being received
   - reloading ath9k_htc.ko does not help

Are these known problems and can I do anything to help analyze and fix
them? Shall I create logs with a specific debugging mask?

The goal is to allow the end user to not have to touch the device for
years, so a lock up every two days is a no-go.

Is the AR9271 a good choice for stable connections?
Do you know of other current chipsets with better stability?

Best regards,

  Daniel


-- 
Dipl.-Math. Daniel Glöckner, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11,
Bertha-von-Suttner-Straße 9, 37085 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführer: Dr. Uwe Kracke, Ust-IdNr.: DE 205 198 055

emlix - your embedded linux partner

[ath9k-devel] Problems with ath9k_htc / AR9271

[Peter Stuge]

Daniel Gl?ckner wrote:
>    - OHCI controller endlessly repeats the same packet

Not a high speed USB host controller? High speed USB devices
generally see quite limited testing at full speed.


> The goal is to allow the end user to not have to touch the device
> for years, so a lock up every two days is a no-go.
> 
> Is the AR9271 a good choice for stable connections?

I'd be very careful deploying anything related to ath9k without quite
thorough testing, given a reliability requirement like yours. But on
the other hand I get told a lot how stupid I am by ath9k developers.

Fact is, ath9k was anything but stable in the past, and I'm not sure
it's really there yet.

ath9k_htc may or may not be significantly different. It does support
a different type of interface, but I expect both hardware and driver
to be similar to ath9k.

If you plan large quantity orders then I guess you will attract
debugging resources from Atheros for fixing the issues you encounter.

But I would plan also for significant engineering effort after
deployment.


//Peter

[ath9k-devel] Problems with ath9k_htc / AR9271

[Adrian Chadd]

Hi,

ath9k_htc is mostly the brainchild of one of our very bright engineers
in India. So he's the only one who has been working on it.

I'm sure he'd like to hear of bugs. The trouble though is figuring out
how to fix it.

We have the hardware to do some inspection of these issues. The
trouble is time. If you're a potential customer who would like to
drive some ath9k_htc fixes (or the FreeBSD variety, once I finally
finish my 11n stuff and port over the USB 11n support) then yes,
please speak up and we'll put you in contact with the relevant people
inside QCA.

Yes, things are customer driven :-)


Adrian

[ath9k-devel] Problems with ath9k_htc / AR9271

[Sujith]

Adrian Chadd wrote:
> Hi,
> 
> ath9k_htc is mostly the brainchild of one of our very bright engineers
> in India. So he's the only one who has been working on it.
> 
> I'm sure he'd like to hear of bugs. The trouble though is figuring out
> how to fix it.
> 
> We have the hardware to do some inspection of these issues. The
> trouble is time. If you're a potential customer who would like to
> drive some ath9k_htc fixes (or the FreeBSD variety, once I finally
> finish my 11n stuff and port over the USB 11n support) then yes,
> please speak up and we'll put you in contact with the relevant people
> inside QCA.

Hm, not exactly. Luis did the initial work of the ath9k_hw/ath9k driver core
separation (which was an enormous help later on) and basic AR9271 support.
I can't find the repo online, but I have a clone of the git tree in case
anyone's interested.

Sujith

[ath9k-devel] Problems with ath9k_htc / AR9271

[Adrian Chadd]

On 11 March 2012 05:56, Sujith <m.sujith@gmail.com> wrote:
> Hm, not exactly. Luis did the initial work of the ath9k_hw/ath9k driver core
> separation (which was an enormous help later on) and basic AR9271 support.
> I can't find the repo online, but I have a clone of the git tree in case
> anyone's interested.

Ok. Then you and Luis. :-)

I'm trying to find some time to build and tinker with the ath9k_htc
firmware so I can help you with bugs, but I'm just short on time. :/



Adrian