Unable to use more than 2 'Atheros AR9271' WiFi Dongles

[pi-resource]

More than two WiFi Dongel with the Atheros AR9271 chipsets are not identified. In this example I used a TP-LINK TL-WN722N. I can confirm there were NO power issues. See dmesg outputs below.

First device plugged in: (all normal)
[ 3626.648706] usb 1-1.2.1: new high-speed USB device number 6 using dwc_otg
[ 3626.799647] usb 1-1.2.1: New USB device found, idVendor=0cf3, idProduct=9271
[ 3626.799661] usb 1-1.2.1: New USB device strings: Mfr=16, Product=32, SerialNumber=48
[ 3626.799669] usb 1-1.2.1: Product: USB2.0 WLAN
[ 3626.799677] usb 1-1.2.1: Manufacturer: ATHEROS
[ 3626.799684] usb 1-1.2.1: SerialNumber: 12345
[ 3627.944779] usb 1-1.2.1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
[ 3627.944907] usb 1-1.2.1: Direct firmware load for ath9k_htc/htc_9271-1.4.0.fw failed with error -2
[ 3627.944922] usb 1-1.2.1: ath9k_htc: Firmware htc_9271.fw requested
[ 3627.945481] usbcore: registered new interface driver ath9k_htc
[ 3628.241745] usb 1-1.2.1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
[ 3628.487600] ath9k_htc 1-1.2.1:1.0: ath9k_htc: HTC initialized with 33 credits
[ 3633.007736] ath9k_htc 1-1.2.1:1.0: ath9k_htc: FW Version: 1.3
[ 3633.007748] ath9k_htc 1-1.2.1:1.0: FW RMW support: Off
[ 3633.007755] ath: EEPROM regdomain: 0x809c
[ 3633.007759] ath: EEPROM indicates we should expect a country code
[ 3633.007764] ath: doing EEPROM country->regdmn map search
[ 3633.007769] ath: country maps to regdmn code: 0x52
[ 3633.007775] ath: Country alpha2 being used: CN
[ 3633.007779] ath: Regpair used: 0x52
[ 3633.034162] ieee80211 phy1: Atheros AR9271 Rev:1
[ 3633.899923] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready

Second device plugged in: (Normal)
[ 3678.808836] usb 1-1.2.2: new high-speed USB device number 7 using dwc_otg
[ 3678.959885] usb 1-1.2.2: New USB device found, idVendor=0cf3, idProduct=9271
[ 3678.959899] usb 1-1.2.2: New USB device strings: Mfr=16, Product=32, SerialNumber=48
[ 3678.959907] usb 1-1.2.2: Product: USB2.0 WLAN
[ 3678.959915] usb 1-1.2.2: Manufacturer: ATHEROS
[ 3678.959940] usb 1-1.2.2: SerialNumber: 12345
[ 3678.961096] usb 1-1.2.2: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
[ 3678.962086] usb 1-1.2.2: Direct firmware load for ath9k_htc/htc_9271-1.4.0.fw failed with error -2
[ 3678.962102] usb 1-1.2.2: ath9k_htc: Firmware htc_9271.fw requested
[ 3679.255303] usb 1-1.2.2: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
[ 3679.500607] ath9k_htc 1-1.2.2:1.0: ath9k_htc: HTC initialized with 33 credits
[ 3682.993741] ath9k_htc 1-1.2.2:1.0: ath9k_htc: FW Version: 1.3
[ 3682.993753] ath9k_htc 1-1.2.2:1.0: FW RMW support: Off
[ 3682.993760] ath: EEPROM regdomain: 0x809c
[ 3682.993765] ath: EEPROM indicates we should expect a country code
[ 3682.993769] ath: doing EEPROM country->regdmn map search
[ 3682.993775] ath: country maps to regdmn code: 0x52
[ 3682.993780] ath: Country alpha2 being used: CN
[ 3682.993784] ath: Regpair used: 0x52
[ 3683.005653] ieee80211 phy2: Atheros AR9271 Rev:1
[ 3683.869106] IPv6: ADDRCONF(NETDEV_UP): wlan2: link is not ready

Third and subsequent devices: (ERRORS)
[ 3826.729283] usb 1-1.2.4.1: new high-speed USB device number 8 using dwc_otg
[ 3826.880406] usb 1-1.2.4.1: New USB device found, idVendor=0cf3, idProduct=9271
[ 3826.880420] usb 1-1.2.4.1: New USB device strings: Mfr=16, Product=32, SerialNumber=48
[ 3826.880453] usb 1-1.2.4.1: Product: USB2.0 WLAN
[ 3826.880461] usb 1-1.2.4.1: Manufacturer: ATHEROS
[ 3826.880469] usb 1-1.2.4.1: SerialNumber: 12345
[ 3826.881665] usb 1-1.2.4.1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
[ 3826.883288] usb 1-1.2.4.1: Direct firmware load for ath9k_htc/htc_9271-1.4.0.fw failed with error -2
[ 3826.883344] usb 1-1.2.4.1: ath9k_htc: Firmware htc_9271.fw requested
[ 3827.176355] usb 1-1.2.4.1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
[ 3828.429300] usb 1-1.2.4.1: Service connection timeout for: 256
[ 3828.429347] ath9k_htc 1-1.2.4.1:1.0: ath9k_htc: Unable to initialize HTC services
[ 3828.429374] ath9k_htc: Failed to initialize the device
[ 3828.431265] usb 1-1.2.4.1: ath9k_htc: USB layer deinitialized

all devices are shown with the 'lsusb' command

[rodizio1]

Yes, more than two Atheros USB sticks give problems on the Pi.

You may get three to work if you make sure that nothing else is accessing the USB bus (ethernet for example ...) while the Atheros sticks are being initialized and iwconfig/ifconfig commands are being run. Also make sure to not run iwconfig/ifconfig commands "too fast", configure one adapter after another with a little delay in-between.

Four or more adapters never work though.

See here for more info:
#1763
qca/open-ath9k-htc-firmware#114

[P33M]

@rodizio1 From an examination of seller comments on Amazon, it looks like there is a v2 of the WN-722N that doesn't use the Atheros chipset. Do you have a guaranteed source for the v1.x devices?

[pi-resource]

Hi P33M. I simply crossed my fingers and hoped for the best and I received v1.10 which works fine. I purchased from a UK seller, Skydigital https://www.amazon.co.uk/s?merchant=A3FPBXRLKM9OSB
Hope that helps.
Cheers,
Dusty
www.pi-resource.com

[rodizio1]

@P33M Sorry, don't know any sure sources for the WN-722N V1.x

Alfa AWUS036NHA would be a sure bet. It has the UART of the AR9271 on solder pads, could become handy for debugging I guess. Expensive though.

Another option would be searching for "AR9271" on AliExpress, for example such a dongle for 5 bucks:
https://www.aliexpress.com/item/Azurewave-AW-NU138-150M-Wifi-802-11BGN-USB-High-Gain-Atheros-AR9271-150Mbps-Wireless-Mini-150M/32797793917.html

[P33M]

I have acquired 4 wifi adapters using this chipset. I see the same behaviour, but with 3 devices plugged in and not 4. When I plug the 4th device in, I get nothing in dmesg and the device is not detected. Eventually ntpd times out and I get hung task callbacks in the kernel message log.

If I remove device 3, suddenly device 4 shows up:

[ 2108.176805] usb 1-1.4: USB disconnect, device number 5
[ 2108.688802] ath: phy1: RX failed to go idle in 10 ms RXSM=0x7053b1b9
[ 2108.699164] ath: phy1: Failed to wakeup in 500us
[ 2108.710116] ath: phy1: Failed to wakeup in 500us
[ 2108.823845] ath: phy1: RX failed to go idle in 10 ms RXSM=0x0
[ 2108.834186] ath: phy1: Failed to wakeup in 500us
[ 2108.949469] ath: phy1: RX failed to go idle in 10 ms RXSM=0xe7ba12b9
[ 2109.126297] usb 1-1.4: ath9k_htc: USB layer deinitialized
[ 2109.625500] usb 1-1.5: new high-speed USB device number 8 using dwc_otg
[ 2109.776801] usb 1-1.5: New USB device found, idVendor=0cf3, idProduct=9271
[ 2109.776851] usb 1-1.5: New USB device strings: Mfr=16, Product=32, SerialNumber=48
[ 2109.776860] usb 1-1.5: Product: UB91C
[ 2109.776867] usb 1-1.5: Manufacturer: ATHEROS
[ 2109.776874] usb 1-1.5: SerialNumber: 12345
[ 2109.778309] usb 1-1.5: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
[ 2109.779767] usb 1-1.5: Direct firmware load for ath9k_htc/htc_9271-1.4.0.fw failed with error -2
[ 2109.779792] usb 1-1.5: ath9k_htc: Firmware htc_9271.fw requested
[ 2110.075063] usb 1-1.5: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
[ 2110.320194] ath9k_htc 1-1.5:1.0: ath9k_htc: HTC initialized with 33 credits

The clue I think is the interrupt endpoint descriptors. I see my host channel mask pegged at 0x7f meaning 7 of 8 channels are used, which is the limit for either periodic or non-periodic transfers.

Bus 001 Device 009: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass       255 Vendor Specific Subclass
  bDeviceProtocol       255 Vendor Specific Protocol
  bMaxPacketSize0        64
  idVendor           0x0cf3 Atheros Communications, Inc.
  idProduct          0x9271 AR9271 802.11n
  bcdDevice            1.08
  iManufacturer          16
  iProduct               32
  iSerial                48
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           60
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           6
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x05  EP 5 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x06  EP 6 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0

The two interrupt endpoints have an interval of 1 microframe. Periodic transfers happen in the microframe after they were queued to the hardware, so the host channel is allocated but idle for 125uS until it transmits the interrupt token. From a cursory examination of host channel masks with 1 device + ethernet active, it looks like two host channels are semi-permanently idle per device added - which would follow for a bulk endpoint + interval-1 interrupt endpoint being active.

This explains why things break with 3 devices - 6 + 1 = 7 active host channels, plus intermittent hub status and Ethernet interrupt/control endpoint polling (+2 host channels). At least one endpoint is going to get starved if the hardware ends up in a suboptimal scheduling state.

[P33M]

I have a naive fix that seems to make things better for me - in dwc_otg_hcd_queue.c:qh_init(), by munging the qh->interval for Interrupt endpoints to be a minimum of 2 (i.e. 2 microframes), all 4 devices appear to be working. I can scan APs on all 4 wireless devices and have 2 of them associated to our local wireless network.

This does of course mean that the Interrupt endpoint gets serviced only half as regularly as it is requesting, but this is 250uS vs 125uS. I doubt there would be much real-world effect, but this makes me think that this needs to be an explicitly enabled module parameter rather than a blanket constraint.

[popcornmix]

Latest rpi-update kernel includes the int_ep_interval_min kernel config option.

[P33M]

@pi-resource @rodizio1 on a rpi-updated Pi, can you add dwc_otg.int_ep_interval_min=2 to /boot/cmdline.txt and reboot, then try using up to 4 Atheros wifi devices? Note that eventually with more than 4 devices you will run up against the limitation described in #2050 as a bulk IN endpoint is used for RX data, so on quiet networks endpoint servicing latency will increase.

[rodizio1]

Thanks a lot @P33M.

Back-ported the change in #2067 to the kernel 4.4.11 I'm using. (There are delays in the order of several milliseconds sometimes when one card receives many packets per second and others only a few. This is worse with newer kernels, that's why I stick with this one at the moment).

Just did a quick test, so far it seems to be working. Need to do more testing though.

00c0ca849ea1 Link encap:UNSPEC  HWaddr 00-C0-CA-84-9E-A1-A8-02-00-00-00-00-00-00-00-00  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:66005 errors:0 dropped:4 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:71183610 (67.8 MiB)  TX bytes:0 (0.0 B)

c46e1f21bbf1 Link encap:UNSPEC  HWaddr C4-6E-1F-21-BB-F1-00-00-00-00-00-00-00-00-00-00  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:65928 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:71993376 (68.6 MiB)  TX bytes:0 (0.0 B)

ec086b1c4645 Link encap:UNSPEC  HWaddr EC-08-6B-1C-46-45-00-00-00-00-00-00-00-00-00-00  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:65919 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:71983548 (68.6 MiB)  TX bytes:0 (0.0 B)

ec086b1c7834 Link encap:UNSPEC  HWaddr EC-08-6B-1C-78-34-00-00-00-00-00-00-00-00-00-00  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:65928 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:71993376 (68.6 MiB)  TX bytes:0 (0.0 B)

[rodizio1]

shortly after I see this in dmesg:

[10614.131493] ------------[ cut here ]------------
[10614.131520] WARNING: CPU: 0 PID: 3373 at drivers/misc/vc04_services/interface/vchiq_arm/vchiq_arm.c:2502 vchiq_release_internal+0xb4/0x24c()
[10614.131551] Modules linked in: arc4 ath9k_htc ath9k_common ath9k_hw ath brcmfmac mac80211 brcmutil cfg80211 bcm2835_gpiomem smsc95xx usbnet mii i2c_dev i2c_bcm2708 i2c_core
[10614.131607] CPU: 0 PID: 3373 Comm: HTV Notify Not tainted 4.4.11-v7+ #32
[10614.131614] Hardware name: BCM2709
[10614.131619] Backtrace: 
[10614.131642] [<80012940>] (dump_backtrace) from [<80012b38>] (show_stack+0x18/0x1c)
[10614.131652]  r6:60000013 r5:8054c648 r4:00000000 r3:00000000
[10614.131679] [<80012b20>] (show_stack) from [<8020f61c>] (dump_stack+0xac/0xcc)
[10614.131689] [<8020f570>] (dump_stack) from [<80020428>] (warn_slowpath_common+0x8c/0xbc)
[10614.131692]  r7:000009c6 r6:8029d0dc r5:00000009 r4:00000000
[10614.131705] [<8002039c>] (warn_slowpath_common) from [<800204fc>] (warn_slowpath_null+0x24/0x2c)
[10614.131708]  r8:80591154 r7:ffffffff r6:b6266608 r5:805518a8 r4:ad26f244
[10614.131722] [<800204d8>] (warn_slowpath_null) from [<8029d0dc>] (vchiq_release_internal+0xb4/0x24c)
[10614.131730] [<8029d028>] (vchiq_release_internal) from [<8029dd6c>] (vchiq_ioctl+0x7ec/0x1870)
[10614.131733]  r9:ad26f200 r8:0376e006 r7:ad26e000 r6:0000c40d r5:805518a8 r4:0000c40c
[10614.131757] [<8029d580>] (vchiq_ioctl) from [<800e94b4>] (do_vfs_ioctl+0x41c/0x60c)
[10614.131761]  r10:00000000 r9:ad1d8000 r8:00000003 r7:0000c40d r6:b63b5cc0 r5:0376e006
[10614.131772]  r4:b62f8648
[10614.131779] [<800e9098>] (do_vfs_ioctl) from [<800e96e0>] (SyS_ioctl+0x3c/0x64)
[10614.131783]  r9:ad1d8000 r8:00000003 r7:0000c40d r6:b63b5cc0 r5:0376e006 r4:b63b5cc1
[10614.131798] [<800e96a4>] (SyS_ioctl) from [<8000f760>] (ret_fast_syscall+0x0/0x34)
[10614.131801]  r8:8000f904 r7:00000036 r6:7eb8fadc r5:00000002 r4:76e4f2f0 r3:000000a4
[10614.131827] ---[ end trace c94ee286a508b55b ]---
[10614.131833] vchiq: vchiq_ioctl: cmd VCHIQ_IOC_RELEASE_SERVICE returned error -1 for service TVNT:3369

The system seems to be still working normally though.

[P33M]

Regarding the millisecond latencies with 4.9 - this is not an isolated issue, Libreelec DVB-T users have reported "worse" latency in the transition from 4.8-4.9.

The warning has an existing issue open: #1808

@pi-resource have you re-tested with latest rpi-update kernel? If so, does it work for you?

[popcornmix]

Libreelec DVB-T users have reported "worse" latency in the transition from 4.8-4.9.

Actually we are still bisecting but the 4.8-4.9 regression has been narrowed down to:

    Merge tag 'usb-4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
    
    Pull usb/phy/extcon updates from Greg KH:
     "Here is the big USB, and PHY, and extcon, patchsets for 4.9-rc1.
    
      Full details are in the shortlog, but generally a lot of new hardware
      support, usb gadget updates, and Wolfram's great cleanup of USB error
      message handling, making the kernel image a tad bit smaller.
    
      All of this has been in linux-next with no reported issues"

That is still a merge of hundreds of commits, but it looks like an upstream issue (that also affects x86) rather than a dwc_otg issue. Thread here.