Christophe Prévotaux | 11 Dec 17:14 2014

Chip glitch for RSSI value ?

Sometimes it seems the ath9k series chips (at least some of them ) do not report RSSI for some frames, is this a
known chip glitch ?


Christophe Prévotaux
Email: c.prevotaux <at>

ath9k-devel mailing list
ath9k-devel <at>
Christophe Prévotaux | 11 Dec 14:47 2014

High Resolution RTT timestamp timer in ath9k

I would like to know if there is a way to access the ath9k High Resolution Timestamp timers

The current RTT resolution is quite low and not so useful for my purpose.


Christophe Prévotaux
Email: c.prevotaux <at>

ath9k-devel mailing list
ath9k-devel <at>
Till Wollenberg | 8 Dec 12:46 2014

Max. 7 stations per AP with ath9k?


I just came across the ath9k website and read that ath9k in AP mode supports 
only "up to 7 stations due to a firmware limitation" (see "Modes of operation" 
at ).

Does this really apply to ath9k (i.e. PCIe devices) or just to USB devices 

I think the note on the website is related to the discussion of Andrew Connell, 
Adrian Chadd, and Gergely Kiss from April 2013 and April 2014:

Best regards
Federico Tramarin | 5 Dec 07:31 2014

help to keep a fixed rate with broadcast packets

Hello everyone,

first of all thank you very much for the support this mailimg list 
provides to the users/developers of ath9k drivers.

I am a PostDoc researcher, and I am working on a project related to an 
experimental IEEE 802.11n performance analysis. For purposes of 
research, in my experimental session I need to be able to purposely set 
the tx rate (MCS) of packets sent in broadcast, and keep it fixed (no rc).

More in detail, I need to sent packets between two nodes (say, a client 
server UDP application), and to this aim I am using 'scapy' for 
transmission at level 2, or even at level 3 of the stack.
I need the packet have a broadcast L2 dest address, since this way the 
retransmission/backoff algorithm will be avoided.
The problem is that broadcast L2 packets are sent always at a very low 
tx rate (typically 1 MBit/s, strange!) with respect to unicast packets, 
even if I indicate the frame is of type data. It seems that being a 
broadcast packet it is treated af a typical management/no-ack/control 
frame, hence resorting to the using of a rate picked from a basic rate set.

The possible solutions I tried are:

- use of iw -> I (with much difficulties) can control the tx rate 
(actually I need to specificy the MCS), but have not control of the rate 
used for broadacst packets. Also, I have no way to change the rate in 
the basic rates set.

- use of (old) iwconfig -> I have control of the tx rate, honestly more 
reliably that with iw. However, iwconfig does not allow to specify the 
(Continue reading)

Thomas Hühn | 30 Nov 22:57 2014

Re: queue priority mapping

Hi Sergey,

You are right, the wrong mapping was caused by the call order.
Felix has already sent 3 patches to fix that bug. So lets test.

Greetings from Berlin

> Am 30.11.2014 um 19:18 schrieb Sergey Ryazanov <ryazanov.s.a <at>>:
> Hi Thomas,
> 2014-11-30 14:30 GMT+03:00 Thomas Hühn <thomas <at>>:
>> From my point of view the call-path of the functions look like this:
>> ath9k_init_queues(struct ath_softc *sc)
>>       -> ath_txq_setup(sc, ATH9K_TX_QUEUE_DATA, i) with subtype-remapping
>> via
>> qi.tqi_subtype = subtype_txq_to_hwq[subtype];
>> -> ath9k_hw_setuptxqueue(ah, qtype, &qi);
>> And the subtyperemapping reflects the correct AC class mapping to ath9k hw
>> queues.
> tqi_subtype field doesn't define hw queue. Quick grep show only 6
> lines in the whole driver, where this field is accessed. Actual hw
> queue number stored in axq_qnum field of ath_txq as documented in
(Continue reading)

Kamran Nishat | 25 Nov 07:25 2014

Change in Channel width


I want to ask how channel width is changed in the driver ath9k.
Function ath_set_channel in channel.c is called on the change in
channel width in openwrt. It "says first cleanup all pending DMAs".
Does this means all packets in the HW buffer will be send before

In the specification of AR9380 it is mentioned "the  channel switching
time between 2.4 GHz and 5 GHz is reduced  from 10 ms to as little as
1 ms." . Is change in channel width equivalent in change in channel?

How the information of channel width is communicated to the clients?
Is it sent in beacons or in association packets?

Hubert Feurstein | 20 Nov 19:00 2014

queue priority mapping


in ath9k_init_queues are the AC levels mapped to the hardware-queues by this loop below. But doesn't this map the priorities in the wrong direction? The hardware queue 0 has the lowest priority, but is mapped to IEEE80211_AC_VO. And the hardware queue 3 (with higher priority) is mapped to IEEE80211_AC_BK. Shouldn't that be the other way around (as changed below) ?

<at> <at> -323,11 +323,12 <at> <at> static int ath9k_init_queues(struct ath_softc *sc)
  sc->beacon.cabq = ath_txq_setup(sc, ATH9K_TX_QUEUE_CAB, 0);
  sc->tx.uapsdq = ath_txq_setup(sc, ATH9K_TX_QUEUE_UAPSD, 0);
- for (i = 0; i < IEEE80211_NUM_ACS; i++) {
+ for (i = IEEE80211_NUM_ACS - 1; i >= 0; i--) {
  sc->tx.txq_map[i] = ath_txq_setup(sc, ATH9K_TX_QUEUE_DATA, i);
  sc->tx.txq_map[i]->mac80211_qnum = i;
  sc->tx.txq_max_pending[i] = ATH_MAX_QDEPTH;
  return 0;

Best regards
ath9k-devel mailing list
ath9k-devel <at>
Pieter Robyns | 18 Nov 19:35 2014

ath9k_htc hardware A-MPDU handling


I'm trying to measure the number of A-MPDU delimiter CRC errors for a 
receiving ath9k_htc device under heavy load. To do this, I counted the 
CRC errors in ar5416hw.c at each AR_PreDelimCRCErr and 
AR_PostDelimCRCErr. Then I wanted to test how the hardware handles a 
delimiter CRC error versus a normal CRC error, so I created a test 
scenario as follows: in the first run my ar9271 bursts data frames 
filled with "\x00" bytes. In the second test it bursts frames filled 
with the A-MPDU delimiter "\x4e".

I expected the latter test to have a higher delimiter CRC error rate, 
because more delimiters are being sent, and a failure of the first 
delimiter CRC would 'cascade' to multiple delimiter CRC errors. However, 
my results show a similar amount of CRC errors for each test.

Unfortunately, implementation details regarding how the hardware handles 
these errors are unavailable to the best of my knowledge (Atheros 
confidential maybe?), so it is hard to figure out whether the test is 
wrong or whether the hardware does something I didn't expect. Does the 
hardware report each delimiter error or does it just scan forward after 
one report? Would it be possible to retrieve all delimiter CRC error 
occurrences in some way?

Kind regards,
Pieter Robyns
Alex Williamson | 13 Nov 21:30 2014

Qualcomm Atheros AR93xx reset behavior


This is a question not about the wireless properties of the Atheros
AR93xx, but about the PCIe bus reset behavior.  We have a user reporting
errors with a TP-LINK TL-WDN4800 and I've acquired the same card and
have been able to reproduce the error on two systems.  The problem is
that if we attempt to do a secondary bus reset or link down from the
parent bridge of these devices, the card will throw errors like Surprise
Down and never seems to return to a working state, sometimes throwing
machine checks if we attempt to access config space again.

The reason for attempting bus resets is that we want to use PCI device
assignment to attach the device to a virtual machine.  Performing a bus
reset puts the device in a known state for the VM and clears any guest
state from the device when returning it to the host.  For most devices
this works quite well, especially when the device does not support FLR.
In this case we need to figure out if we need a blacklist mechanism to
avoid bus resets for this device or whether there's a procedure we can
use to create a device specific reset in place of a standard bus reset.

The specific device is:

xx:xx.x Network controller [0280]: Qualcomm Atheros AR93xx Wireless Network Adapter [168c:0030] (rev 01)
        Subsystem: Qualcomm Atheros Device [168c:3112]

Is there anyone with access to hardware specs for this device that can
help?  Perhaps there's an errata on the PCIe interface that might
explain it or some specific steps we can take to make the device behave
for reset.  Thanks!

Giuseppe Torelli | 7 Nov 23:41 2014

Bluetooth unable to scan devices


I have an ACER E1-570 whose bluetooth is not working:

gt <at> Aspire-E1-570 ~ $ lsmod | grep ath
dm_multipath           22873  0 
scsi_dh                14882  1 dm_multipath
ath9k                 164164  0 
ath9k_common           13551  1 ath9k
ath9k_hw              453856  2 ath9k_common,ath9k
ath                    28698  3 ath9k_common,ath9k,ath9k_hw
mac80211              630653  1 ath9k
cfg80211              484040  3 ath,ath9k,mac80211

gt <at> Aspire-E1-570 ~ $ rfkill list
0: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
2: acer-wireless: Wireless LAN
Soft blocked: no
Hard blocked: no
3: acer-bluetooth: Bluetooth
Soft blocked: no
Hard blocked: no
gt <at> Aspire-E1-570

t <at> Aspire-E1-570 ~ $ hcitool dev
hci0 48:D2:24:D6:C7:34
gt <at> Aspire-E1-570 ~ 

t <at> Aspire-E1-570 ~ $ uname -a
Linux Aspire-E1-570 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

t <at> Aspire-E1-570 ~ $ sudo bluetoothd -nd
bluetoothd[5585]: Bluetooth daemon 4.101
bluetoothd[5585]: src/main.c:parse_config() parsing main.conf
bluetoothd[5585]: src/main.c:parse_config() discovto=0
bluetoothd[5585]: src/main.c:parse_config() pairto=0
bluetoothd[5585]: src/main.c:parse_config() pageto=8192
bluetoothd[5585]: src/main.c:parse_config() auto_to=60
bluetoothd[5585]: src/main.c:parse_config() name=%h-%d
bluetoothd[5585]: src/main.c:parse_config() class=0x000100
bluetoothd[5585]: src/main.c:parse_config() Key file does not have key 'DeviceID'
D-Bus setup failed: Name already in use
bluetoothd[5585]: Unable to get on D-Bus

I see many people have got this weird problem on the internet but with no luck. Can you please help me? I hope the above info are sufficient, otherwise please ask me.

ath9k-devel mailing list
ath9k-devel <at>
小伦子 | 6 Nov 05:47 2014

Looking for help while using Ath9k to make multi virtual station

Dear ALL:
        I am tring to use ath9k driver with AR9380 chips to make multi virtual station to connect to an ap.Here is the problem i have meet.
        I am using linux kernel 3.14.8 #14 SMP PREEMPT
        As the ( web suggest i create vif and using wpa_supplicant to connect to the ap. Then i got some very strange problem :
        1. the AR9380 is support ht_40 and the ap i got is support ht_40 too, but i can't connect with in 300Mbps, all i can connect is 150Mbps. i have google the same problem that find out in kernel 3.8 seems have the problem in intel card(,
        2. system is getting very slow and the kernel memory kmalloc-4096 object was increase very fast , the system's memory was running out very quick. so i dig the kernel code and find out that every one phy receive pkt will copy to each vif in /net/mac80211/rx.c:3211 so i change it to skb_clone, it seems the system went well and the kmalloc-4096 object is not increase that fast, memory looks ok.But i don't known is that i am right to make that change? and it seems that it bring another problem to me (problems 3)
<at> <at> -3208,7 +3208,11 <at> <at>
3208 3208 return false;
3209 3209  
3210 3210 if (!consume) {
3211   - skb = skb_copy(skb, GFP_ATOMIC);
  3211 + //skb = skb_copy(skb, GFP_ATOMIC);
  3212 + // here get a bug if skb_copy over memory use
  3213 + // if kernel never change this pkt is ok for clone
  3214 + // woolen
  3215 + skb = skb_clone(skb, GFP_ATOMIC);
3212 3216 if (!skb) {
3213 3217 if (net_ratelimit())
3214 3218 wiphy_debug(local->hw.wiphy,
         3. when i use the change i make in problem 2, i use 7 AR9380 card connect to 24 aps each one ap connects 60 vif stations.Each card phy make 240 sta, while the wpa_supplicant start to connect to the ap ,the driver get some error message :
tx hung, queue: %i axq-depth: %i, ampdu-depth: %i resetting the chip.
i found the message in kernel/drivers/net/wireless/ath/ath9k/link.c : 46. it seems like while tx process the hardware didn't push the pkt out to the ap.This problem almost make me crazy. I have try many way to fix( ignore the hung and continue, reinvoke the tx pkt tasklet to tx the pkt and then reset chips) but faile.So i am ask for help~!

        the attach is some env info.

       Thank you all
 王沃伦  Mail:Just_woolen <at>
Attachment (status_report.txt): application/octet-stream, 6870 bytes
ath9k-devel mailing list
ath9k-devel <at>