Re: "athn0: could not load firmware" for AR9271
> There's a problem where this chip does not get enough juice from the USB host > >controller in some cases. I have tested it, feeding +5Vcc from the computer power supply, it is not about "juice". I had the same problem on the SB700. I bet it is another hw bug masked of by software.
Re: "athn0: could not load firmware" for AR9271
Hi, Another data point..(sorry to top post... but felt it's appropriate) I've got APU as well. Running OpenBSD 6.1: OpenBSD 6.1 (GENERIC.MP) #24: Wed Oct 4 18:47:09 CEST 2017 rob...@syspatch-61-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP # dmesg | grep athn athn0 at pci4 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 5 int 16 athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:1b:b3:68 Wireless was very poorly performing. I'm not actually using the wireless because of this. I anticipated the performance challenges from reading the mailing lists, so it's not a show stopper for me. Cheers, Steve W. On 15/10/2017 6:50 AM, Stefan Sperling wrote: On Sat, Oct 14, 2017 at 11:59:11AM -0400, Tim Stewart wrote: Maximilian Pichler writes: The dmesg is the same as previously (this is on the APU), except for: athn0 at pci5 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 16 athn0: AR9280 rev 2 (2T2R), ROM rev 22, address xx:xx:xx:xx:xx:e2 I'm debugging some issues with my wle200nx in a PC Engines apu2c4, and I have a very similar dmesg output: athn0 at pci4 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 5 int 16 athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:26:d3:28 I am curious, is it expected that the first line says "Atheros AR9281" and the second says "AR9280"? In particular, athn(4) makes the AR9281 sound less capable: The AR9281 is a single-chip PCIe 802.11n solution. It exists in PCIe Mini Card (XB91) and half Mini Card (HB91) form factors. It operates in the 2GHz spectrum and supports 1 transmit path and 2 receiver paths (1T2R). This is indeed contradictory information. The string "AR9281" comes from a static list in OpenBSD's kernel and bears no actual relation to what's in the hardware. Provided the in-kernl list is correct, It means the manufacturor has written the PCI ID of an AR9281 into the card's PCI config space. The OS will try to attach a driver which matches on this PCI ID. Once attached, the driver performs actual probing and finds an AR9280 chip. If the driver were misidentifying the chip this could lead to all sorts of problems and misbehaviours. Whether the driver's probing or the vendor's PCI ID is correct, I cannot tell. I'll note though that no code which is specific to the 9281 seems to exist in our driver. That's a bad sign, and could indicate that this chip isn't properly supported yet. I will reply with more details if I can better quantify the issues I'm having. Please do.
Re: "athn0: could not load firmware" for AR9271
On Sat, Oct 14, 2017 at 11:59:11AM -0400, Tim Stewart wrote: > Maximilian Pichler writes: > > > The dmesg is the same as previously (this is on the APU), except for: > > athn0 at pci5 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 16 > > athn0: AR9280 rev 2 (2T2R), ROM rev 22, address xx:xx:xx:xx:xx:e2 > > I'm debugging some issues with my wle200nx in a PC Engines apu2c4, and I > have a very similar dmesg output: > > athn0 at pci4 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 5 int 16 > athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:26:d3:28 > > I am curious, is it expected that the first line says "Atheros AR9281" > and the second says "AR9280"? In particular, athn(4) makes the AR9281 > sound less capable: > > The AR9281 is a single-chip PCIe 802.11n solution. It exists in PCIe > Mini Card (XB91) and half Mini Card (HB91) form factors. It operates in > the 2GHz spectrum and supports 1 transmit path and 2 receiver paths > (1T2R). This is indeed contradictory information. The string "AR9281" comes from a static list in OpenBSD's kernel and bears no actual relation to what's in the hardware. Provided the in-kernl list is correct, It means the manufacturor has written the PCI ID of an AR9281 into the card's PCI config space. The OS will try to attach a driver which matches on this PCI ID. Once attached, the driver performs actual probing and finds an AR9280 chip. If the driver were misidentifying the chip this could lead to all sorts of problems and misbehaviours. Whether the driver's probing or the vendor's PCI ID is correct, I cannot tell. I'll note though that no code which is specific to the 9281 seems to exist in our driver. That's a bad sign, and could indicate that this chip isn't properly supported yet. > I will reply with more details if I can better quantify the issues I'm > having. Please do.
Re: "athn0: could not load firmware" for AR9271
Maximilian Pichler writes: > The dmesg is the same as previously (this is on the APU), except for: > athn0 at pci5 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 16 > athn0: AR9280 rev 2 (2T2R), ROM rev 22, address xx:xx:xx:xx:xx:e2 I'm debugging some issues with my wle200nx in a PC Engines apu2c4, and I have a very similar dmesg output: athn0 at pci4 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 5 int 16 athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:26:d3:28 I am curious, is it expected that the first line says "Atheros AR9281" and the second says "AR9280"? In particular, athn(4) makes the AR9281 sound less capable: The AR9281 is a single-chip PCIe 802.11n solution. It exists in PCIe Mini Card (XB91) and half Mini Card (HB91) form factors. It operates in the 2GHz spectrum and supports 1 transmit path and 2 receiver paths (1T2R). I will reply with more details if I can better quantify the issues I'm having. -TimS -- Tim Stewart --- Mail: t...@stoo.org Matrix: @tim:stoo.org
Re: "athn0: could not load firmware" for AR9271
Thanks a lot for sharing the details! By the way, there seems to be an issue with the test results I sent because dd sometimes copied fewer bytes than intended. I'll try to pin it down and either update this thread or open a new one.
Re: "athn0: could not load firmware" for AR9271
On Sat, May 27, 2017 at 08:31:23PM -0400, Maximilian Pichler wrote:
> I've tried a PPD-AR5BHB92-H (AR9280 miniPCIe) in AP mode and connected
> clients get ~12 Mbit/s downstream and ~35 Mbit/s upstream (i.e. the
> card appears to receive data much faster than it sends). Selecting a
> less crowded 5GHz channel helped quite a bit. Is this performance more
> or less what is currently to be expected?
There is an issue where the card won't transmit at rates beyond 18M / MCS 12.
Whenever rate scaling selects a higher transmit rate it drops back down
right away, even on a clean channel. I haven't figured out why.
I expect fixing this will involve a dive into the dark magic of the
chip's low-level configuration since it looks as if OFDM modulations
at the higher end don't work (and never ever worked) with our driver.
Also, we do not support Tx aggregation in 11n mode yet.
This is why other 11n implementations manage to send more data
per second at a given data rate than we do.
> The measurements were conducted by running the following commands on a
> Macbook connected to the AP's wireless network:
>
> $ for i in {1..10}; do nc 192.168.0.1 1234 | dd of=/dev/null
> count=10240 bs=1000; sleep 1; done 2>&1 | grep trans
> 6899272 bytes transferred in 4.307439 secs (1601711 bytes/sec)
> 6864520 bytes transferred in 4.275299 secs (1605623 bytes/sec)
> 6837456 bytes transferred in 4.256377 secs (1606403 bytes/sec)
> 6734200 bytes transferred in 4.194057 secs (1605653 bytes/sec)
> 6952848 bytes transferred in 4.311542 secs (1612613 bytes/sec)
> 6898272 bytes transferred in 4.294667 secs (1606241 bytes/sec)
> 6867864 bytes transferred in 4.256106 secs (1613650 bytes/sec)
> 6906512 bytes transferred in 4.291027 secs (1609524 bytes/sec)
> 6757816 bytes transferred in 4.182866 secs (1615595 bytes/sec)
> 6871760 bytes transferred in 5.059761 secs (1358119 bytes/sec)
>
> $ for i in {1..10}; do dd if=/dev/urandom count=10240 bs=1000 | nc
> 192.168.0.1 1234; sleep 1; done 2>&1 | grep trans
> 1024 bytes transferred in 2.290328 secs (4470975 bytes/sec)
> 1024 bytes transferred in 2.251763 secs (4547548 bytes/sec)
> 1024 bytes transferred in 2.160710 secs (4739183 bytes/sec)
> 1024 bytes transferred in 2.031869 secs (5039695 bytes/sec)
> 1024 bytes transferred in 2.215611 secs (4621750 bytes/sec)
> 1024 bytes transferred in 3.615391 secs (2832335 bytes/sec)
> 1024 bytes transferred in 2.340003 secs (4376063 bytes/sec)
> 1024 bytes transferred in 2.185185 secs (4686102 bytes/sec)
> 1024 bytes transferred in 2.509382 secs (4080686 bytes/sec)
> 1024 bytes transferred in 2.333018 secs (4389164 bytes/sec)
>
> On the AP box:
> $ nc -kl 1234 < /dev/urandom
> $ nc -kl 1234 > /dev/null
Thanks for sharing this.
Re: "athn0: could not load firmware" for AR9271
On Sat, May 27, 2017 at 11:03 AM, Stefan Sperling wrote:
> The ATI SB700 is known to suffer from this issue.
Good to know, thanks.
> Get a 9280 miniPCIe. Pcengines sells them as "wle200nx".
> A list of similar products can be found on wikidevi:
> https://wikidevi.com/wiki/Atheros -> Search for the entry
> called "AR9280 (Merlin)" and follow the "19 devices" link.
I've tried a PPD-AR5BHB92-H (AR9280 miniPCIe) in AP mode and connected
clients get ~12 Mbit/s downstream and ~35 Mbit/s upstream (i.e. the
card appears to receive data much faster than it sends). Selecting a
less crowded 5GHz channel helped quite a bit. Is this performance more
or less what is currently to be expected?
The dmesg is the same as previously (this is on the APU), except for:
athn0 at pci5 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 16
athn0: AR9280 rev 2 (2T2R), ROM rev 22, address xx:xx:xx:xx:xx:e2
$ ifconfig athn0
athn0: flags=8943 mtu 1500
lladdr xx:xx:xx:xx:xx:e2
index 4 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect mode 11n hostap
status: active
ieee80211: nwid chan 161 bssid xx:xx:xx:xx:xx:e2
wpakey xx
wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp
The measurements were conducted by running the following commands on a
Macbook connected to the AP's wireless network:
$ for i in {1..10}; do nc 192.168.0.1 1234 | dd of=/dev/null
count=10240 bs=1000; sleep 1; done 2>&1 | grep trans
6899272 bytes transferred in 4.307439 secs (1601711 bytes/sec)
6864520 bytes transferred in 4.275299 secs (1605623 bytes/sec)
6837456 bytes transferred in 4.256377 secs (1606403 bytes/sec)
6734200 bytes transferred in 4.194057 secs (1605653 bytes/sec)
6952848 bytes transferred in 4.311542 secs (1612613 bytes/sec)
6898272 bytes transferred in 4.294667 secs (1606241 bytes/sec)
6867864 bytes transferred in 4.256106 secs (1613650 bytes/sec)
6906512 bytes transferred in 4.291027 secs (1609524 bytes/sec)
6757816 bytes transferred in 4.182866 secs (1615595 bytes/sec)
6871760 bytes transferred in 5.059761 secs (1358119 bytes/sec)
$ for i in {1..10}; do dd if=/dev/urandom count=10240 bs=1000 | nc
192.168.0.1 1234; sleep 1; done 2>&1 | grep trans
1024 bytes transferred in 2.290328 secs (4470975 bytes/sec)
1024 bytes transferred in 2.251763 secs (4547548 bytes/sec)
1024 bytes transferred in 2.160710 secs (4739183 bytes/sec)
1024 bytes transferred in 2.031869 secs (5039695 bytes/sec)
1024 bytes transferred in 2.215611 secs (4621750 bytes/sec)
1024 bytes transferred in 3.615391 secs (2832335 bytes/sec)
1024 bytes transferred in 2.340003 secs (4376063 bytes/sec)
1024 bytes transferred in 2.185185 secs (4686102 bytes/sec)
1024 bytes transferred in 2.509382 secs (4080686 bytes/sec)
1024 bytes transferred in 2.333018 secs (4389164 bytes/sec)
On the AP box:
$ nc -kl 1234 < /dev/urandom
$ nc -kl 1234 > /dev/null
Re: "athn0: could not load firmware" for AR9271
On Sat, May 27, 2017 at 10:51:08AM -0400, Maximilian Pichler wrote: > On Sat, May 27, 2017 at 4:05 AM, Stefan Sperling wrote: > > What is the model of your USB host controller? (please always send a > > complete dmesg in problem reports -- you cannot guess exactly what people > > will want to know about your machine, so by sending a complete dmesg > > you'll save people a round-trip to get more information they need) > > It appears to be an ATI SB700, on the PC Engines APU board > (https://www.pcengines.ch/apu.htm). Full dmesg below. The ATI SB700 is known to suffer from this issue. > By the way, if you had any advice on which WiFi adapter (mini PCIe or > USB) gives best performance as a Host AP right now, I'd be most > grateful. Get a 9280 miniPCIe. Pcengines sells them as "wle200nx". A list of similar products can be found on wikidevi: https://wikidevi.com/wiki/Atheros -> Search for the entry called "AR9280 (Merlin)" and follow the "19 devices" link.
Re: "athn0: could not load firmware" for AR9271
On Sat, May 27, 2017 at 4:05 AM, Stefan Sperling wrote: > What is the model of your USB host controller? (please always send a > complete dmesg in problem reports -- you cannot guess exactly what people > will want to know about your machine, so by sending a complete dmesg > you'll save people a round-trip to get more information they need) It appears to be an ATI SB700, on the PC Engines APU board (https://www.pcengines.ch/apu.htm). Full dmesg below. > There's a problem where this chip does not get enough juice from the USB > host controller in some cases. The firmware failing to load is a symptom > of this. The cause has not been pinned down. It could probably be fixed > in software, somewhere in the USB stack. I just plugged the same adapter into a more powerful machine and it was properly recognized, which would confirm the hypothesis. By the way, if you had any advice on which WiFi adapter (mini PCIe or USB) gives best performance as a Host AP right now, I'd be most grateful. Thanks! #dmesg OpenBSD 6.1 (GENERIC.MP) #20: Sat Apr 1 13:45:56 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4246003712 (4049MB) avail mem = 4112646144 (3922MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdf16d820 (6 entries) bios0: vendor coreboot version "SageBios_PCEngines_APU-45" date 04/05/2014 bios0: PC Engines APU acpi0 at bios0: rev 0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD G-T40E Processor, 1000.13 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: TSC frequency 1000125140 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD G-T40E Processor, 1000.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins acpiprt0 at acpi0: bus -1 (AGPB) acpiprt1 at acpi0: bus -1 (HDMI) acpiprt2 at acpi0: bus 1 (PBR4) acpiprt3 at acpi0: bus 2 (PBR5) acpiprt4 at acpi0: bus 3 (PBR6) acpiprt5 at acpi0: bus -1 (PBR7) acpiprt6 at acpi0: bus 5 (PE20) acpiprt7 at acpi0: bus -1 (PE21) acpiprt8 at acpi0: bus -1 (PE22) acpiprt9 at acpi0: bus -1 (PE23) acpiprt10 at acpi0: bus 0 (PCI0) acpiprt11 at acpi0: bus 4 (PIBR) acpicpu0 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS acpicpu1 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS acpibtn0 at acpi0: PWRB cpu0: 1000 MHz: speeds: 1000 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD AMD64 14h Host" rev 0x00 ppb0 at pci0 dev 4 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi pci1 at ppb0 bus 1 re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:35:a4:78 rgephy0 at re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 4 ppb1 at pci0 dev 5 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi pci2 at ppb1 bus 2 re1 at pci2 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:35:a4:79 rgephy1 at re1 phy 7: RTL8169S/8110S/8211 PHY, rev. 4 ppb2 at pci0 dev 6 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi pci3 at ppb2 bus 3 re2 at pci3 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:35:a4:7a rgephy2 at re2 phy 7: RTL8169S/8110S/8211 PHY, rev. 4 ahci0 at pci0 dev 17 function 0 "ATI SBx00 SATA" rev 0x40: apic 2 int 19, AHCI 1.2 ahci0: port 0: 6.0Gb/s scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct fixed naa.5002538844584d30 sd0: 953869MB, 512 bytes/sector, 1953525168 sectors, thin ohci0 at pci0 dev 18 function 0 "ATI SB700 USB" rev 0x00: apic 2 int 18, version 1.0, legacy support ehci0 at pci0 dev 18 function
Re: "athn0: could not load firmware" for AR9271
On Fri, May 26, 2017 at 08:39:14PM -0400, Maximilian Pichler wrote: > I'm trying to use an Olimex MOD-WIFI-AR9271-ANT USB wireless adapter, but: > # dmesg > OpenBSD 6.1 (GENERIC.MP) #20: Sat Apr 1 13:45:56 MDT 2017 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > [...] > athn0 at uhub0 port 5 configuration 1 interface 0 "ATHEROS UB93" rev > 2.00/1.08 addr 2 > athn0: could not load firmware What is the model of your USB host controller? (please always send a complete dmesg in problem reports -- you cannot guess exactly what people will want to know about your machine, so by sending a complete dmesg you'll save people a round-trip to get more information they need) > According to the manufacturer > (https://www.olimex.com/Products/USB-Modules/MOD-WIFI-AR9271-ANT/) > this is an AR9271 chip, which is listed on the athn man page. What am > I missing? There's a problem where this chip does not get enough juice from the USB host controller in some cases. The firmware failing to load is a symptom of this. The cause has not been pinned down. It could probably be fixed in software, somewhere in the USB stack. On one of my laptops, firmware fails to load when I plug a USB athn into a hub, but the device works fine when inserted directly into a port on the machine. But it works with a hub on other laptops so I stopped investigating...
"athn0: could not load firmware" for AR9271
Hi, I'm trying to use an Olimex MOD-WIFI-AR9271-ANT USB wireless adapter, but: # dmesg OpenBSD 6.1 (GENERIC.MP) #20: Sat Apr 1 13:45:56 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP [...] athn0 at uhub0 port 5 configuration 1 interface 0 "ATHEROS UB93" rev 2.00/1.08 addr 2 athn0: could not load firmware [...] The athn firmware is installed: # fw_update -i Installed: athn-firmware-1.1p1 Installed, extra: iwi-firmware-3.1p2 radeondrm-firmware-20150927 pgt-firmware-1.2p4 bwi-firmware-1.4p4 urtwn-firmware-1.2 ipw-firmware-1.3p2 iwn-firmware-5.11p1 uath-firmware-2.0p1 iwm-firmware-0.20161101 otus-firmware-1.0p1 wpi-firmware-3.2p1 vmm-firmware-1.10.2p2 rsu-firmware-1.2p0 acx-firmware-1.4p5 upgt-firmware-1.1p4 rtwn-firmware-1.0 malo-firmware-1.4p4 uvideo-firmware-1.2p2 And the device is there: # usbdevs -vdf /dev/usb0 Controller /dev/usb0: addr 1: high speed, self powered, config 1, EHCI root hub(0x), ATI(0x1002), rev 1.00 uhub0 port 1 powered port 2 powered port 3 powered port 4 powered port 5 addr 2: high speed, power 500 mA, config 1, UB93(0x3327), ATHEROS(0x13d3), rev 1.08, iSerialNumber 12345 athn0 According to the manufacturer (https://www.olimex.com/Products/USB-Modules/MOD-WIFI-AR9271-ANT/) this is an AR9271 chip, which is listed on the athn man page. What am I missing? Thanks Max
