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> lists.ath9k.org
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> lists.ath9k.org
小伦子 | 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 (http://www.candelatech.com/vsta.php) 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(https://bugzilla.kernel.org/show_bug.cgi?id=54851#c17,https://bbs.archlinux.org/viewtopic.php?id=161056).
        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> qq.com
Attachment (status_report.txt): application/octet-stream, 6870 bytes
ath9k-devel mailing list
ath9k-devel <at> lists.ath9k.org
Joris Guisson | 3 Nov 21:08 2014

Support for killer n1525


I recently purchased an MSI GT 72 gaming laptop with a killer n1525 wifi card in it. The wifi didn't work, so I took a look at the latest kernel release (3.18-rc3), and it seems there is no support in it for the card. I didn't find the PCI device id (0x003e) listed in any of the atheros drivers, the only killer related entries where in ath9k:

        /* Killer Wireless (3x3) */
          .driver_data = ATH9K_PCI_KILLER },
          .driver_data = ATH9K_PCI_KILLER },

        { PCI_VDEVICE(ATHEROS, 0x0030) }, /* PCI-E  AR9300 */

This is the lspci -vvv output:

04:00.0 Network controller: Qualcomm Atheros Device 003e (rev 20)
        Subsystem: Bigfoot Networks, Inc. Device 1525
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Interrupt: pin A routed to IRQ 255
        Region 0: Memory at f7200000 (64-bit, non-prefetchable) [disabled] [size=2M]
        Capabilities: [40] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [50] MSI: Enable- Count=1/8 Maskable+ 64bit-
                Address: 00000000  Data: 0000
                Masking: 00000000  Pending: 00000000
        Capabilities: [70] Express (v2) Endpoint, MSI 00
                DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 <64us
                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us
                        ClockPM+ Surprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR+, OBFF Via message
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, OBFF Disabled
                LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
                         EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
        Capabilities: [100 v2] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
                AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
        Capabilities: [148 v1] Virtual Channel
                Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
                Arb:    Fixed- WRR32- WRR64- WRR128-
                Ctrl:   ArbSelect=Fixed
                Status: InProgress-
                VC0:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
                        Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
                        Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=01
                        Status: NegoPending- InProgress-
        Capabilities: [168 v1] Device Serial Number 00-00-00-00-00-00-00-00
        Capabilities: [178 v1] Latency Tolerance Reporting
                Max snoop latency: 71680ns
                Max no snoop latency: 71680ns
        Capabilities: [180 v1] L1 PM Substates
                L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
                          PortCommonModeRestoreTime=50us PortTPowerOnTime=10us

So is anybody actually working on support for this NIC ? 

It may just be a matter of adding a new device ID entry in the table above, if the NIC more or less works like previous killer NIC's.

ath9k-devel mailing list
ath9k-devel <at> lists.ath9k.org
Jeremy whocares | 3 Nov 13:32 2014

Support for 13d3:3408 in ath3k

A windows inf file shows 13d3:3408 as VID_13D3&PID_3408 = "Qualcomm Atheros Bluetooth 4.0 + HS

The wifi combo card is QCWB335

hciconfig --all
hci0: Type: BR/EDR Bus: USB
BD Address: 54:27:1E:58:4A:36 ACL MTU: 1022:8 SCO MTU: 183:5
RX bytes:741 acl:0 sco:0 events:61 errors:0
TX bytes:1079 acl:0 sco:0 commands:56 errors:0
Features: 0xff 0xfe 0x0d 0xfe 0xd8 0x7f 0x7b 0x8f
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
Link mode: SLAVE ACCEPT 
Name: 'mint-0'
Class: 0x6c0100
Service Classes: Rendering, Capturing, Audio, Telephony
Device Class: Computer, Uncategorized
HCI Version: (0x7) Revision: 0x3101
LMP Version: (0x7) Subversion: 0x1
Manufacturer: Atheros Communications, Inc. (69)
ath9k-devel mailing list
ath9k-devel <at> lists.ath9k.org
Ruiz Gaistardo, Esau E | 3 Nov 03:40 2014

difference between AR9271 and AR9271L?

Hi Development Team:

Can you please provide information regarding power consumption for AR9271, in the 3 most significant
states:  IDLE, TX and RX?, 

Thanks for your support

E Ruiz
Graf Monika | 31 Oct 17:33 2014

Time-of-flight positioning - Atheros

Hello Everyone

I am currently at a project where I am using Atheros Chipsets AR9590 with the ath9k driver on Debian.
I am wondering how the time-of-flight information can be retrieved per packet in most recent Atheros chipsets.
Could you tell me how that I get that out of the driver? Or which register do I have to access in order to get the
hardware timestamp (in nanosec)?

Thank you for your help!

Dan Carpenter | 29 Oct 16:48 2014

[patch] ath9k: fix some debugfs output

The right shift operation has higher precedence than the mask so we
left shift by "(i * 3)" and then immediately right shift by "(i * 3)"
then we mask.  It should be left shift, mask, and then right shift.

Signed-off-by: Dan Carpenter <dan.carpenter <at> oracle.com>

diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index 2a2a17d..c9afc15 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
 <at>  <at>  -455,7 +455,7  <at>  <at>  static ssize_t read_file_dma(struct file *file, char __user *user_buf,
 			 "%2d          %2x      %1x     %2x           %2x\n",
 			 i, (*qcuBase & (0x7 << qcuOffset)) >> qcuOffset,
 			 (*qcuBase & (0x8 << qcuOffset)) >> (qcuOffset + 3),
-			 val[2] & (0x7 << (i * 3)) >> (i * 3),
+			 (val[2] & (0x7 << (i * 3))) >> (i * 3),
 			 (*dcuBase & (0x1f << dcuOffset)) >> dcuOffset);