Problems with ath9k_htc / AR9271

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

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

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

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

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

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