gmane.linux.drivers.ath5k.devel

Re: Bug 16436 - ath5k (AR5001) does not work after resume and fails with "ath5k phy0: gain calibration timeout"

Adrian Chadd — 2012-05-15T15:02:16

Hi,

Would you be able to boot a FreeBSD live image on that machine and see
if FreeBSD has the same issue with wifi?

I've been doing a whole bunch of testing with AR5210/AR5211 hardware
recently to ensure I haven't broken anything.

If FreeBSD works better then the ath5k guys have a bit more of a
chance of figuring out what's going on with this (really) legacy
hardware.

Thanks,


Adrian

Bug 16436 - ath5k (AR5001) does not work after resume and fails with "ath5k phy0: gain calibration timeout"

2012-05-14T23:06:46

  Hi All,

I'm having constant troubles with ath5k driver with sympthoms described here: 

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

This is very old bug as it is reported in 2.6 bugzila but there are lot's of comments (including mine)
about this happening in 3.3 Is someone working on this and can I help with something to get
this issue resoved quickly?

Best regards
   Stoian Ivanov

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

Хостинг компания ICN.BG дарява 5% от Вашата поръчка
в подкрепа на фондация "За Нашите Деца"!
 http://www.icn.bg/default.icn?show=home_______________________________________________
ath5k-devel mailing list
ath5k-devel-xDcbHBWguxEUs3QNXV6qNA< at >public.gmane.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel

Re: Country settings no honored

Denis Periša — 2012-05-14T16:08:15

IMHO:
This CRDA stuff just dont work with multiple cards.
I've had this problem for ages now.. especially with different cards...
It's always changed, intersected .. whatever.. it's never like it should be.
My advice is to modify regd.c from kernel and recompile regulatory.bin
. there is script online.

On Mon, May 14, 2012 at 6:02 PM, Beat Meier
<mbe_ml-Rr1ePhOm/97Wpu6QEFMNjE7EXpO/VAb1< at >public.gmane.org> wrote:

Re: How can I rename wlanX to athX ?

Beat Meier — 2012-05-14T16:04:14

Thanks with your info I have found that
   ip link set wlan0 name ath0

To auto generate ath0 you can do something like the following in 
/etc/network/interfaces

auto wlan0
iface wlan0 inet static
         address 10.99.99.1 ### not realy used but must be here for 
config reasons
         netmask 255.255.255.0
         pre-up ip link set wlan0 name ath0

auto ath0
iface ath0 inet static
         address 10.24.5.1
         netmask 255.255.255.0
         hostapd /etc/hostapd/hostapd.ath0.conf

Thanks and greetings

Beat

Country settings no honored

Beat Meier — 2012-05-14T16:02:04

Hello

I try to enable channel 12 and 13 for reg domain AR which are allowed 
here for ath5k and WLM54AGP23 (168c:001b) card.
I have enabled this in the regdomain binary and installed it with my 
public key in /lib/crda.
I have also tried orig regdomain...
Kernel is 3.0.0, distribution debian-6.0
Country is set with hostapd, because iw reg set does not work...

Output is the following
[    7.453516] cfg80211:     (start_freq - end_freq < at > bandwidth), 
(max_antenna_gain, max_eirp)
[    7.453616] cfg80211:     (2402000 KHz - 2472000 KHz < at > 40000 KHz), 
(300 mBi, 2000 mBm)
[    7.474621] cfg80211:     (2457000 KHz - 2482000 KHz < at > 20000 KHz), 
(300 mBi, 2000 mBm)
[    7.498654] cfg80211:     (2474000 KHz - 2494000 KHz < at > 20000 KHz), 
(300 mBi, 2000 mBm)
[    7.525638] cfg80211:     (5170000 KHz - 5250000 KHz < at > 40000 KHz), 
(300 mBi, 2000 mBm)
[    7.554621] cfg80211:     (5735000 KHz - 5835000 KHz < at > 40000 KHz), 
(300 mBi, 2000 mBm)
[    8.295351] cfg80211: Calling CRDA for country: US
[    8.297104] ath5k phy0: Atheros AR5414 chip found (MAC: 0xa5, PHY: 0x61)
[    8.298572] ath5k 0000:00:0e.0: registered as 'phy1'
[    8.370951] cfg80211: Regulatory domain changed to country: US
[    8.371495] cfg80211:     (start_freq - end_freq < at > bandwidth), 
(max_antenna_gain, max_eirp)
[    8.372565] cfg80211:     (2402000 KHz - 2472000 KHz < at > 40000 KHz), 
(300 mBi, 2700 mBm)
[    8.377458] cfg80211:     (5170000 KHz - 5250000 KHz < at > 40000 KHz), 
(300 mBi, 1700 mBm)
[    8.379754] cfg80211:     (5250000 KHz - 5330000 KHz < at > 40000 KHz), 
(300 mBi, 2000 mBm)
[    8.380534] cfg80211:     (5490000 KHz - 5600000 KHz < at > 40000 KHz), 
(300 mBi, 2000 mBm)
[    8.388459] cfg80211:     (5650000 KHz - 5710000 KHz < at > 40000 KHz), 
(300 mBi, 2000 mBm)
[    8.390220] cfg80211:     (5735000 KHz - 5835000 KHz < at > 40000 KHz), 
(300 mBi, 3000 mBm)
[    9.147424] ath5k phy1: Atheros AR5414 chip found (MAC: 0xa5, PHY: 0x61)
....
[   14.488129] cfg80211: Calling CRDA for country: AR
[   14.608818] cfg80211: Regulatory domain changed to country: AR
[   14.618512] cfg80211:     (start_freq - end_freq < at > bandwidth), 
(max_antenna_gain, max_eirp)
[   14.619584] cfg80211:     (2402000 KHz - 2494000 KHz < at > 40000 KHz), 
(N/A, 3000 mBm)

But the channels and power seems to be still from country US which was 
set at startup because
iw phy0 info gives the following output:

Wiphy phy0
         Band 1:
                 Frequencies:
                         * 2412 MHz [1] (27.0 dBm)
                         * 2417 MHz [2] (27.0 dBm)
                         * 2422 MHz [3] (27.0 dBm)
                         * 2427 MHz [4] (27.0 dBm)
                         * 2432 MHz [5] (27.0 dBm)
                         * 2437 MHz [6] (27.0 dBm)
                         * 2442 MHz [7] (27.0 dBm)
                         * 2447 MHz [8] (27.0 dBm)
                         * 2452 MHz [9] (27.0 dBm)
                         * 2457 MHz [10] (27.0 dBm)
                         * 2462 MHz [11] (27.0 dBm)
                         * 2467 MHz [12] (disabled)
                         * 2472 MHz [13] (disabled)
                         * 2484 MHz [14] (disabled)
                 Bitrates (non-HT):
                         * 1.0 Mbps
                         * 2.0 Mbps (short preamble supported)
                         * 5.5 Mbps (short preamble supported)
                         * 11.0 Mbps (short preamble supported)
                         * 6.0 Mbps
                         * 9.0 Mbps
                         * 12.0 Mbps
                         * 18.0 Mbps
                         * 24.0 Mbps
                         * 36.0 Mbps
                         * 48.0 Mbps
                         * 54.0 Mbps

So what's wrong that channels are not set right? With madwifi driver it 
worked to set the channels at least of JP.
If you set country JP with the orig regdomain database it's the same 
stuff channel 12-14 are not enabled.
It's seems that the card or what ever stores the first set country which 
is per default US at startup...
How can I set at startup the country?
I created file
   /etc/modprobe.d/cfg80211.conf
with

then the output is as follows (first set to JP after that someone set it 
to US and mi hostapd config has too JP...)
Waiting for /dev to be fully populated...[    7.370263] cfg80211: World 
regulatory domain updated:
[    7.376450] cfg80211:     (start_freq - end_freq < at > bandwidth), 
(max_antenna_gain, max_eirp)
[    7.377540] cfg80211:     (2402000 KHz - 2472000 KHz < at > 40000 KHz), 
(300 mBi, 2000 mBm)
[    7.422579] cfg80211:     (2457000 KHz - 2482000 KHz < at > 20000 KHz), 
(300 mBi, 2000 mBm)
[    7.439165] cfg80211:     (2474000 KHz - 2494000 KHz < at > 20000 KHz), 
(300 mBi, 2000 mBm)
[    7.448689] cfg80211:     (5170000 KHz - 5250000 KHz < at > 40000 KHz), 
(300 mBi, 2000 mBm)
[    7.470357] cfg80211:     (5735000 KHz - 5835000 KHz < at > 40000 KHz), 
(300 mBi, 2000 mBm)
[    7.477181] cfg80211: Calling CRDA for country: JP
[    7.653563] cfg80211: Regulatory domain changed to country: JP
[    7.655098] cfg80211:     (start_freq - end_freq < at > bandwidth), 
(max_antenna_gain, max_eirp)
[    7.656166] cfg80211:     (2402000 KHz - 2472000 KHz < at > 40000 KHz), 
(N/A, 2000 mBm)
[    7.660379] cfg80211:     (2457000 KHz - 2482000 KHz < at > 20000 KHz), 
(N/A, 2000 mBm)
[    7.662099] cfg80211:     (2474000 KHz - 2494000 KHz < at > 20000 KHz), 
(N/A, 2000 mBm)
[    7.662824] cfg80211:     (4910000 KHz - 4930000 KHz < at > 10000 KHz), 
(N/A, 2300 mBm)
[    7.667378] cfg80211:     (4910000 KHz - 4990000 KHz < at > 40000 KHz), 
(N/A, 2300 mBm)
[    7.671834] cfg80211:     (4930000 KHz - 4950000 KHz < at > 10000 KHz), 
(N/A, 2300 mBm)
[    7.672560] cfg80211:     (5030000 KHz - 5045000 KHz < at > 10000 KHz), 
(N/A, 2300 mBm)
[    7.674333] cfg80211:     (5030000 KHz - 5090000 KHz < at > 40000 KHz), 
(N/A, 2300 mBm)
[    7.678376] cfg80211:     (5050000 KHz - 5060000 KHz < at > 10000 KHz), 
(N/A, 2300 mBm)
[    7.680111] cfg80211:     (5170000 KHz - 5250000 KHz < at > 40000 KHz), 
(N/A, 2000 mBm)
[    7.680835] cfg80211:     (5250000 KHz - 5330000 KHz < at > 40000 KHz), 
(N/A, 2000 mBm)
[    7.685375] cfg80211:     (5490000 KHz - 5710000 KHz < at > 40000 KHz), 
(N/A, 2300 mBm)
[    8.272147] cfg80211: Calling CRDA for country: US
[    8.273895] ath5k phy0: Atheros AR5414 chip found (MAC: 0xa5, PHY: 0x61)
[    8.275362] ath5k 0000:00:0e.0: registered as 'phy1'
[    8.348205] cfg80211: Current regulatory domain intersected:
[    8.349210] cfg80211:     (start_freq - end_freq < at > bandwidth), 
(max_antenna_gain, max_eirp)
[    8.350192] cfg80211:     (2402000 KHz - 2472000 KHz < at > 40000 KHz), 
(N/A, 2000 mBm)
[    8.354274] cfg80211:     (2457000 KHz - 2472000 KHz < at > 15000 KHz), 
(N/A, 2000 mBm)
[    8.355997] cfg80211:     (5170000 KHz - 5250000 KHz < at > 40000 KHz), 
(N/A, 1700 mBm)
[    8.356722] cfg80211:     (5250000 KHz - 5330000 KHz < at > 40000 KHz), 
(N/A, 2000 mBm)
[    8.361272] cfg80211:     (5490000 KHz - 5600000 KHz < at > 40000 KHz), 
(N/A, 2000 mBm)
[    8.362996] cfg80211:     (5650000 KHz - 5710000 KHz < at > 40000 KHz), 
(N/A, 2000 mBm)
[    9.120072] cfg80211: Calling CRDA for country: US
[    9.128247] ath5k phy1: Atheros AR5414 chip found (MAC: 0xa5, PHY: 0x61)
[    9.305179] cfg80211: Current regulatory domain intersected:
[    9.311299] cfg80211:     (start_freq - end_freq < at > bandwidth), 
(max_antenna_gain, max_eirp)
[    9.312393] cfg80211:     (2402000 KHz - 2472000 KHz < at > 40000 KHz), 
(N/A, 2000 mBm)
[    9.322153] cfg80211:     (2457000 KHz - 2472000 KHz < at > 15000 KHz), 
(N/A, 2000 mBm)
[    9.326159] cfg80211:     (5170000 KHz - 5250000 KHz < at > 40000 KHz), 
(N/A, 1700 mBm)
[    9.327883] cfg80211:     (5250000 KHz - 5330000 KHz < at > 40000 KHz), 
(N/A, 2000 mBm)
[    9.334162] cfg80211:     (5490000 KHz - 5600000 KHz < at > 40000 KHz), 
(N/A, 2000 mBm)
[    9.335904] cfg80211:     (5650000 KHz - 5710000 KHz < at > 40000 KHz), 
(N/A, 2000 mBm)
done.
....
[   17.687881] cfg80211: Calling CRDA to update world regulatory domain
[   17.768934] cfg80211: World regulatory domain updated:
[   17.770411] cfg80211:     (start_freq - end_freq < at > bandwidth), 
(max_antenna_gain, max_eirp)
[   17.771517] cfg80211:     (2402000 KHz - 2472000 KHz < at > 40000 KHz), 
(300 mBi, 2000 mBm)
[   17.774193] cfg80211:     (2457000 KHz - 2482000 KHz < at > 20000 KHz), 
(300 mBi, 2000 mBm)
[   17.775206] cfg80211:     (2474000 KHz - 2494000 KHz < at > 20000 KHz), 
(300 mBi, 2000 mBm)
[   17.775991] cfg80211:     (5170000 KHz - 5250000 KHz < at > 40000 KHz), 
(300 mBi, 2000 mBm)
[   17.777904] cfg80211:     (5735000 KHz - 5835000 KHz < at > 40000 KHz), 
(300 mBi, 2000 mBm)
[   17.788909] cfg80211: Calling CRDA for country: 97


Don't know why country 97 is tried. hostap has JP in config file too...

Thanks for any help

Beat

Re: How can I rename wlanX to athX ?

Holger Schurig — 2012-05-14T06:43:39

You can "rename" an interface with an UDEV rule at creation time.

I haven't checked if "ifrename" works, but I guess that'll do it, too.

A third option is this:

iw wlan0 interface add ath0 type station
iw wlan0 interface del wlan0

How can I rename wlanX to athX ?

Beat Meier — 2012-05-12T15:18:30

Hello

Is it not possible to name the interface other than wlanX?
I want to use compatibility with cacti etc. to use either madwifi or 
mac802011 and try
to use athX instead of wlanX with mac80211 drivers...

Thanks

Beat

almost no client connection to ath5k driver in long distance link setup, why?

Beat Meier — 2012-05-11T19:05:29

Hello

I'm trying to use ath5k instead of madwifi with atheros cards.
In the labor it work nice, but in long distance links it fails

Setup:
AP in master mode: voyage-0.8.0 with kernel-3.0.0, hostapd 1:0.7.3-2, 
using wpa2-psk
Clients: Ubiquity with openwrt or buffalo hw with openwrt or repeater 
with madwifi

I have one client which connects to the ap with aht5k driver but the 
other clients same hw,sw does not connect.
NS2 from ubiquity too does not connect...
Buffalo use broadcom chipset, ns2 use atheros chipset

Only difference is that the clients that does not connect have a little 
bit bader signal...
On the madwifi ap it shows me the following signals on ap:

working buffalo client: -60 distance 3.0km
not working buffalo client: -70 distance 6.9km
not working buffalo client: -64 distance 2.3km
not working ns2: -82 distance 6.8km

I have also tried to set distance with: iw phy0 set distance 25000
iw versions: iw 3.1-1, libiw30 30~pre9-5

Here the log output of clients not working

May 10 20:47:20 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
MLME: MLME-DISASSOCIATE.indication(00:15:6d:8c:cf:2c, 8)
May 10 20:47:20 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
MLME: MLME-DELETEKEYS.request(00:15:6d:8c:cf:2c)
May 10 20:47:21 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
IEEE 802.11: deauthenticated due to inactivity
May 10 20:47:21 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
MLME: MLME-DEAUTHENTICATE.indication(00:15:6d:8c:cf:2c, 2)
May 10 20:47:21 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
MLME: MLME-DELETEKEYS.request(00:15:6d:8c:cf:2c)
May 10 20:47:23 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
IEEE 802.11: authentication OK (open system)
May 10 20:47:23 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
MLME: MLME-AUTHENTICATE.indication(00:15:6d:8c:cf:2c, OPEN_SYSTEM)
May 10 20:47:23 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
MLME: MLME-DELETEKEYS.request(00:15:6d:8c:cf:2c)
May 10 20:47:23 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
IEEE 802.11: did not acknowledge authentication response
May 10 20:47:23 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
IEEE 802.11: association OK (aid 3)
May 10 20:47:23 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
IEEE 802.11: did not acknowledge association response
May 10 20:47:33 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
WPA: event 2 notification
May 10 20:47:33 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
IEEE 802.1X: unauthorizing port
May 10 20:47:33 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
IEEE 802.11: disassociated
May 10 20:47:33 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
MLME: MLME-DISASSOCIATE.indication(00:15:6d:8c:cf:2c, 8)
May 10 20:47:33 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
MLME: MLME-DELETEKEYS.request(00:15:6d:8c:cf:2c)
May 10 20:47:34 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
IEEE 802.11: deauthenticated due to inactivity
May 10 20:47:34 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
MLME: MLME-DEAUTHENTICATE.indication(00:15:6d:8c:cf:2c, 2)
May 10 20:47:34 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
MLME: MLME-DELETEKEYS.request(00:15:6d:8c:cf:2c)
May 10 20:47:35 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
IEEE 802.11: authentication OK (open system)
May 10 20:47:35 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
MLME: MLME-AUTHENTICATE.indication(00:15:6d:8c:cf:2c, OPEN_SYSTEM)
May 10 20:47:35 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
MLME: MLME-DELETEKEYS.request(00:15:6d:8c:cf:2c)
May 10 20:47:35 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
IEEE 802.11: did not acknowledge authentication response
May 10 20:47:35 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
IEEE 802.11: association OK (aid 3)
May 10 20:47:35 swb-sbe-p2p-x-new hostapd: wlan0: STA 00:15:6d:8c:cf:2c 
IEEE 802.11: did not acknowledge association response


BTW: Have the same problem with repeaters with madwifi connecting to ap 
with athk5 driver.
In the 5.8GHz frequency the repeater connects but data traffic is very 
slow (1.2Mpbs) instead of 7Mbps in one direction the other is ok with 
5.9Mbps
but an iperf running will disconnect repeater (signal of -66 on 
madwifi/distance 13km), ap use CM9 card, repeater use CM9
In the 2.4GHz the client will not connect (signal of -83 on 
madwifi/distance 21km), ap use WLM54GP23 card repeater use WLM54GP23

Anybody using aht5k in long distance setup?
What can I do more to debug the problem?

Will to in the next days tests to use ath5k as client with 
wpa_supplicant to see if it will fail too ...

Any hints, solutions???

Thanks

Beat

Re: [PATCH 1/3] drivers/net: Convert compare_ether_addr to ether_addr_equal

David Miller — 2012-05-11T03:35:34

From: Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ< at >public.gmane.org>
Date: Wed,  9 May 2012 20:17:46 -0700

 ...

Applied.

Re: [PATCH 1/3] drivers/net: Convert compare_ether_addr to ether_addr_equal

Jussi Kivilinna — 2012-05-10T20:15:25

Quoting David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q< at >public.gmane.org>:


I'm sorry. I will not do this again.

-Jussi

Re: [PATCH 1/3] drivers/net: Convert compare_ether_addr to ether_addr_equal

David Miller — 2012-05-10T16:30:24

Never, EVER, quote an entire large patch just to make a comment
on one small hunk.

I very nearly missed what you had to say because when scrolling
through it it appeared as if you made no comments at all.

Again, NEVER, EVER, do this.  It's extremely anti-social.  Edit out
the irrelevant quoted content when replying to people, always.

Re: [PATCH 1/3] drivers/net: Convert compare_ether_addr to ether_addr_equal

Jussi Kivilinna — 2012-05-10T14:32:01

Quoting Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ< at >public.gmane.org>:


While reviewing this, noticed that above original code is wrong. It  
should be !compare_ether_addr. So do I push patch fixing this through  
wireless-testing althought it will later cause conflict with this patch?

-Jussi

ath5k phy0: failed to warm reset the MAC Chip

Paul Bolle — 2012-04-19T21:06:04

0) In the logs of a laptop I use I've found error pairs like this error
pair:
    <3>[13053.997856] ath5k phy0: failed to warm reset the MAC Chip
    <3>[13053.997871] ath5k phy0: can't reset hardware (-5)

The logs show it for a v3.3 based kernel and for the v3.4-rc2 kernel. I
can't say whether or not preceding kernels also triggered it.

1) I only noticed these errors because I tend to check these logs for
errors: I cannot link these errors to drops in (the quality of) wireless
connectivity.

2) The call chain involved should be:

drivers/net/wireless/ath/ath5k/base.c:
2737 ath5k_reset(...)
     {
2765         ret = ath5k_hw_reset(...);
2766         if (ret) {
2767                 ATH5K_ERR(ah, "can't reset hardware (%d)\n", ret);
2768                 goto err;
2769         }
     }

drivers/net/wireless/ath/ath5k/base.c:
1144 ath5k_hw_reset(...)
     {
1296         ret = ath5k_hw_nic_wakeup(...);
1297         if (ret)
1298                 return ret;
     }

 667 ath5k_hw_nic_wakeup(...)
     {
 728                 ret = ath5k_hw_nic_reset(...);
 729 
 730         if (ret) {
 731                 ATH5K_ERR(ah, "failed to warm reset the MAC Chip\n");
 732                 return -EIO;
 733         }
     }

 395 ath5k_hw_nic_reset(...)
     {
 421         ret = ath5k_hw_register_timeout(...);
     }

  65 ath5k_hw_register_timeout(...)
     {
  80         return (i <= 0) ? -EAGAIN : 0;
     }

Note that the -EAGAIN returned by ath5k_hw_register_timeout() and
ath5k_hw_nic_reset() is transformed to -EIO by ath5k_hw_nic_wakeup().

3) Do these message really indicate errors? Or can they perhaps be
downgraded to (say) KERN_INFO level (ie, <6> prefix)?


Paul Bolle

Re: [PATCH] ath5k: add possible wiphy interfacecombinations

Felix Fietkau — 2012-04-16T16:07:25

It is an arbitrary number.

- Felix

Re: [PATCH] ath5k: add possible wiphy interfacecombinations

Ben Greear — 2012-04-16T16:11:00

I think the actual max for a channel (AP?) is somewhere around 2000, so maybe
make it 2048 just to make sure we are not adding artificial limitations?

Same with ath9k.

Thanks,
Ben

Re: [PATCH] ath5k: add possible wiphy interfacecombinations

Ben Greear — 2012-04-16T16:02:04

The station max is just an arbitrary number or is 256 really
the max it can handle?  At least on ath9k, more are supported,
but I haven't tested ath5k lately....

Thanks,
Ben

[PATCH] ath5k: Remove extraneous statements fromath5k_hw_proc_4word_tx_status and ath5k_hw_proc_2word_status.

Qasim Javed — 2012-04-06T01:40:15

Signed-off-by: Qasim Javed <qasimj-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>
---
 drivers/net/wireless/ath/ath5k/desc.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/ath5k/desc.c b/drivers/net/wireless/ath/ath5k/desc.c
index f8bfa3a..97b92c3 100644
--- a/drivers/net/wireless/ath/ath5k/desc.c
+++ b/drivers/net/wireless/ath/ath5k/desc.c
< at >< at > -441,10 +441,8 < at >< at > ath5k_hw_proc_2word_tx_status(struct ath5k_hw *ah,
 struct ath5k_desc *desc,
 struct ath5k_tx_status *ts)
 {
-struct ath5k_hw_2w_tx_ctl *tx_ctl;
 struct ath5k_hw_tx_status *tx_status;
 
-tx_ctl = &desc->ud.ds_tx5210.tx_ctl;
 tx_status = &desc->ud.ds_tx5210.tx_stat;
 
 /* No frame has been send or error */
< at >< at > -495,11 +493,9 < at >< at > ath5k_hw_proc_4word_tx_status(struct ath5k_hw *ah,
 struct ath5k_desc *desc,
 struct ath5k_tx_status *ts)
 {
-struct ath5k_hw_4w_tx_ctl *tx_ctl;
 struct ath5k_hw_tx_status *tx_status;
 u32 txstat0, txstat1;
 
-tx_ctl = &desc->ud.ds_tx5212.tx_ctl;
 tx_status = &desc->ud.ds_tx5212.tx_stat;
 
 txstat1 = ACCESS_ONCE(tx_status->tx_status_1);

Re: 10 MHz bandwidth with incorrect bitrate

Adrian Chadd — 2012-04-01T01:33:43

hi,

I'm -pretty- sure that the PLCP will indicate the normal 802.11 rate,
but it's just modulated on half/quarter size carriers.



adrian

10 MHz bandwidth with incorrect bitrate

Virág László — 2012-03-31T23:38:04

Hello everyone,

I'm quite new on this list. As the subject shows I have configured the
ath5k driver to operate on 10 MHz bandwidth (check by spectrum
analyzer). With this setup the desired bitrates were halved indicated
by throughput measurements (iperf, netperf, etc.). I know that
dividing the bandwidth
by two results a /2 decreasing in maximum datarate but I thought that
the driver and/or the Atheros SoC can correct the properties
(obviously not). Of course doubling the desired rate can solve the
problem but the PLCP header will indicate the doubled rate which is
not a perfect way for me.
Has anybody experienced this kind of phenomenon?
I wonder if there is a simple way to tell the SoC and/or the driver to
work on 10 MHz bandwidth with e.g. 6Mbps and the outcome will match
the desired options.
I don't know exactly how the Atheros SoC works, what kind of
properties can be defined, for example the proper options for doubled
datarate for the 10 MHz bandwidth considering the correct PLCP
information in the signal field which indicates the correct bitrate
for 10 MHz (not the doubled).

Thank you.
Laszlo

Re: Problem with XR9

Adrian Chadd — 2012-03-24T22:57:13

Hi!

There's no CPU on the NIC.

The interrupt load is going down because at some point, you're not
handling each RX interrupt before the next RX packet comes, so it
doesn't generate a new interrupt.

There was code in madwifi/freebsd/HAL that did TX interrupt mitigation
by only flipping on the TXINT bit in the TX descriptor on every N'th
descriptor, then also taking a TX error interrupt (TXURN I think?)
when the QCU ran out of frames to feed the PCU. That way it only had
to take an interrupt every 'n'th frame when under load.

Just please keep in mind that whilst the NIC is receiving, the
transmission is going to take quite a bit longer to occur. They don't
work in parallel.


Adrian

On 23 March 2012 22:14, Qasim Javed <qasimj-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Problem with XR9

Qasim Javed — 2012-03-24T05:14:17

Hi everyone,

I have a question regarding a problem I have been facing while using
an Ubiquiti XR9 Wifi card. This is basically a Wifi card which
operates in the 900MHz band and is based on the Atheros 5414 (supports
802.11b/g) chipset. There is an open source driver (mainly maintained
by Atheros and contributions from others) called ath5k.

For a research problem, I wanted to measure the amount of time elapsed
between when a packet enters the MAC layer queues (in this case
mac80211 transmit queue) and when it is actually transmitted over the
air. Measuring the entry into the MAC layer is easy as the stack runs
on the Host CPU and can be instrumented. For the exact time when the
frame is actually transmitted, the card provides support for reading
that information. More specifically, whenever a frame is transmitted,
a transmission status descriptor can be read. This transmission status
descriptor contains the exact timestamp (in TUs) at which the last
successful frame transmission attempt was made.

Interestingly enough, when I take the difference of two timestamps, I
get really large values on the order of 200,000 microseconds. This
only happens when there is a lot of data to send such as when using
iperf. On the other hand, if I just use ping and then look at the
value measured above, they are fine. I measured the values when there
was no contention from any other node (experiments were carried out
over a testbed where nodes are connected via coaxial cables). So,
basically I get large bloated values only when there are lot of
transmission attempts back to back.

I tried moving the point at which the first timestamp is taken as
close to the hardware as possible i.e. just before the frame is DMA'ed
to the card. I get the same large values which indicates that delays
are not being incurred due to queues on the host. Also, instead of
depending on the card for providing the second timestamp (the time at
which the frame is put on air), I tried to measure it myself within an
interrupt handler which is invoked whenever the host CPU is
interrupted by an interrupt generated as a result of receiving a frame
on the Wifi card. Also, in this case I get large values as before.
This indicates that the mechanism used to take the transmit timestamp
on the card is working fine.

I did some further research using the "mpstat" tool and found that the
number of interrupts per second (corresponding to the received frames)
generated by the card goes down if the offered load exceeds a certain
threshold. This seems to indicate that there is some problem in the
code running on the cards's own processor as the number of interrupts
going down as a result of more offered load is ungraceful behavior.

I was wondering if you could offer some insight into this or ways to
solve this problem?

Thanks and regards,
-Qasim