Skip to contentSkip to conversation

Pending ath9k bugs

ath9k-devel Luis R. Rodriguez 3 participants 5 messages Jun 1, 2009 – Jun 2, 2009

lore
Share & tools
lore
#0 lore raw

Here is a list of pending ath9k bugs, if I've missed anything please reply to this e-mail and let us know. If you have any insights into specific AP issues (one with Airport Express N, another with DAP-1353) please let us know.

kernel.org:

1) "Very low signal strenghts with ath9k in 2.6.29"
http://bugzilla.kernel.org/show_bug.cgi?id=12930
Patch available but user still reports issues with both Windows and Linux with an AR5416 PCI-E card. Patch has not yet been pushed upstream.
2) "AR5008/DWA-552 - Very slow" on 2.6.30-rc2

	http://bugzilla.kernel.org/show_bug.cgi?id=13141
	Card is an AR5416 card (PCI-E), AP is "Airport Express N" in 11 mode
	with WPA. Claims under windows performance is better. User is testing
	with kerenl 2.6.30-rc2.

ath9k-devel:

1) Cannot associate with AP DAP-1353 in 11n mode, no encryption.

	First message:
	https://lists.ath9k.org/pipermail/ath9k-devel/2009-May/001566.html
	Thread:
	https://lists.ath9k.org/pipermail/ath9k-devel/2009-May/thread.html#1566

Red Hat Bugzilla:

1) " [ath9k] not able to use WLAN on channel 13 with AR5008 [168c:0024] [NEEDINFO]"

	https://bugzilla.redhat.com/show_bug.cgi?id=503285
2) "ath9k - bit rate is always reported as 1 Mb/s   [NEEDINFO]"
	https://bugzilla.redhat.com/show_bug.cgi?id=481259
3) " ath9k can not connect to hidden networks   [NEEDINFO]"
	https://bugzilla.redhat.com/show_bug.cgi?id=496505
	This is against a "linksys wpa54g" with WPA2
4) "NetworkManager requires ath9k reload to work. [NEEDINFO]"
	https://bugzilla.redhat.com/show_bug.cgi?id=489216

OpenSuse:

1) "wi-fi card Atheros AR928X returns "no scan results""

	https://bugzilla.novell.com/show_bug.cgi?id=462673
	Not sure what to make of this. Jiri might know better.

I reviewed most ath9k Ubuntu bug reports but unfortunately all are on old stable kernel releases or old kernels, most need more info, and I was unable to find any useful bug report which reflects the current ath9k as is upstream or any critical fix for older stable kernel releases. If I missed anything please do let us know.

Luis

#2 lore raw
In reply to Luis R. Rodriguez
Quoted 1 line · Luis R. Rodriguez

Red Hat Bugzilla:

...

Quoted 8 lines

4) "NetworkManager requires ath9k reload to work. [NEEDINFO]"

	https://bugzilla.redhat.com/show_bug.cgi?id=489216

OpenSuse:

1) "wi-fi card Atheros AR928X returns "no scan results""

	https://bugzilla.novell.com/show_bug.cgi?id=462673
	Not sure what to make of this. Jiri might know better.

As far as I can tell, it's unrelated to the kernel. It's NM or a user setting what is to blame here. And maybe it's related to the RH entry above?

#3 lore raw
In reply to Luis R. Rodriguez
Quoted 1 line · Luis R. Rodriguez

ath9k-devel:

I just remembered of another issue:

BUG_ON in rc.c when using 11n. This could be caused by an incorrect assumption in ath9k that the rc priv is correctly for the target rate. The issue may be seen when trying to associate and changing between legacy and HT rates on SMP systems when mac80211 passes frames on different queues due to multiqueue support. If that is indeed the reason for the issue we will probably need locking on the rc priv or simply to revamp it. I'll send a patch for now to downgrade the BUG_ON but we do need a proper fix for this, it just needs more careful review.

While on the topic I should mention a welcomed change would be to actually revamp ath9k RC to fix it to correctly report MCS rates to mac80211. Then add MCS support for minstrel, and finally allow ath9k to make use of minstrel as an optional rate control algo. If anyone is up for the task please say so :)

Luis

#4 lore raw
Quoted 10 lines

BUG_ON in rc.c when using 11n. This could be caused by an incorrect assumption in ath9k that the rc priv is correctly for the target rate. The issue may be seen when trying to associate and changing between legacy and HT rates on SMP systems when mac80211 passes frames on different queues due to multiqueue support. If that is indeed the reason for the issue we will probably need locking on the rc priv or simply to revamp it. I'll send a patch for now to downgrade the BUG_ON but we do need a proper fix for this, it just needs more careful review.

I agree that rc priv needs proper locking, but I dont think this particular issue is related to some race in rc priv. As I already mentioned in one of the mails related to this problem, the root cause can be a failure in channel set, have we confirmed that?. I tried to reproduce this on my setup but no luck.

Quoted 4 lines

While on the topic I should mention a welcomed change would be to actually revamp ath9k RC to fix it to correctly report MCS rates to mac80211.

This needs complete rewrite of ath9k rate control alg.

Vasanth