Firmware load of athn-ar9271 fails

[IdOp]

I've installed OpenBSD 5.3 release onto two machines: the laptop (amd64) and main "desktop" (i386). dmesgs for each are attached to this post.

On each machine I have the same trouble with a USB wireless N adapter: the firmware won't load. The adapter is a NETGEAR WNA1100, based on Atheros chip. Excerpted from one of the dmesgs are the following lines:

athn0 at uhub0 port 2 "NETGEAR WNA WNA1100" rev 2.00/1.08 addr 2
...
athn0: failed loadfirmware of file athn-ar9271 (error 2)
athn0: could not load firmware

The firmware package athn-firmware-1.1p0 was installed using fw_update(1). I also tried an older package athn-firmware-1.1, with the same result (not surprising since the firmware file athn-ar9271 is the same in the two versions of the package).

The man page for the loadfirmware(9) function says it returns an errno(2) code on failure, and errno code 2 is "No such file or directory". Well the files seem to be there:

-r--r--r-- 1 root bin 70624 Jun 16  2011 /etc/firmware/athn-ar7010
-r--r--r-- 1 root bin 70624 Jun 16  2011 /etc/firmware/athn-ar7010-11
-r--r--r-- 1 root bin 51280 Jun 16  2011 /etc/firmware/athn-ar9271
-r--r--r-- 1 root bin  2221 Jun 16  2011 /etc/firmware/athn-license

I also tried replacing athn-ar9271 with the firmware file from Linux, htc_9271.fw; same result, it wouldn't load. (The adapter works under Linux.)

Another data point: when I first got the adapter (1-2 years ago), I tried it under OpenBSD on another machine, and it did work then. So, there was at that time no problem loading the firmware for it.

I tried google-ing the error message above, but didn't find anything useful.

I wanted to try loading the firmware manually by writing a simple C wrapper for loadfirmware(9), to see what happens, but the man page doesn't say what library to link it with.

Any suggestions for how to proceed? Thanks!

[vanGrimoire]

I forget exactly which tools, but linux usually has something you can poke the device with. If the storage on the card is faulty and or it works on linux you've narrowed things down a bit. FreeBSD might be preferable to linux too, I don't know. Is it the hardware?

[IdOp]

Originally Posted by vanGrimoire

I forget exactly which tools, but linux usually has something you can poke the device with. If the storage on the card is faulty and or it works on linux you've narrowed things down a bit.

Hi and thanks for replying . That's a good idea, I should have a look for such tools and see if there are any I haven't installed.

FreeBSD might be preferable to linux too, I don't know.

It wouldn't be something I'd consider, but that's just me!

Is it the hardware?

Good question too. As mentioned, the device does work under Linux (Slackware 14.0). But ... the card was refurbished when I bought it, and there is a little bit of funkyness worth mention. To scout the network neighbourhood, I use airodump-ng. In that program, with the Netgear/Atheros device, the ESSID (or network name) sometimes gets corrupted with random characters. (Other than that it works great, and was under $10, so not worth returning.)

So what's causing that random bug? I doubt it's airodump-ng, since it doesn't happen with other wireless devices I used. It could very well be a bug in the Linux ath9k driver. Or it could be a bug in the hardware. But, even if so, the device otherwise works which indicates that the firmware is getting loaded. (Note to self: try to load the OpenBSD firmware under Linux.)

The other thing I should do is search the OpenBSD mailing lists about this (I'd sorta assumed google might pick them up, but maybe not.)

ADDED: The following is from the Linux dmesg, indicating firmware htc_9271.fw is loaded (the file size in this case is 51272 bytes):

[   12.555628] usb 1-1.4: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
[   12.799589] ath9k_htc 1-1.4:1.0: ath9k_htc: HTC initialized with 33 credits
[   13.231526] ath9k_htc 1-1.4:1.0: ath9k_htc: FW Version: 1.3
[   13.231634] ath: EEPROM regdomain: 0x60
[   13.231639] ath: EEPROM indicates we should expect a direct regpair map
[   13.231656] ath: Country alpha2 being used: 00
[   13.231661] ath: Regpair used: 0x60
[   13.235546] ieee80211 phy0: Atheros AR9271 Rev:1
[   13.241914] Registered led device: ath9k_htc-phy0
[   13.241935] usb 1-1.4: ath9k_htc: USB layer initialized
[   13.243799] usbcore: registered new interface driver ath9k_htc

[IdOp]

I searched openbsd-bugs and openbsd-misc on marc.info for "athn-ar9271". There is one very relevant, unresolved, mailing dated yesterday!

atheros AR9271 fails to load firmware

Given the coincidence in dates, for the record, no, it was not me who submitted that.

[IdOp]

This gets weirder. This morning I booted (i386) directly into OpenBSD. This time the firmware loaded, and the athn0 interface was there! Was it a case of cold boot vs warm boot? I rebooted, and again it was working.

So decided to check it out. Scan for APs:

# ifconfig athn0 scan

>> half a dozen reasonable results were returned

Scanned for APs again.

>> Lots of repeated kernel error messages fill the screen, after several seconds they stop.

Scan again.

>> Lots of repeated kernel error messages fill the screen, but they never stop.

So I disconnected the Netgear USB adapter. System crashes into debugger.

Tried rebooting a few more times. Firmware wouldn't load again.

As an experiment, I tried loading the firmware from OpenBSD under Linux. It would load, but the device never initialized. I have no idea if this ever had any chance of working, but it didn't.

Obviously, a lot of difficult and specialized work goes into writing these device drivers. Hopefully with a little more testing and debugging athn+9271 will come to full fruition.

[vanGrimoire]

Okay, it worked in Linux, not in OpenBSD. It shows in the man page for obsd, so if I were you I would feel okay going to the lists, unless you can buy another card and test that. I did check freebsd and it's not supported, hehe.

[vanGrimoire]

https://wiki.freebsd.org/dev/ath_hal...ardwareSupport

The developer says he'll help others that want to work on it, yet he refuses, maybe there's an issue with the USB portion?

[ocicat]

Originally Posted by vanGrimoire

...maybe there's an issue with the USB portion?

While I applaud you for attempting to identify causes, I don't believe that questioning the USB subsystem is likely to be a fruitful endeavour.

Integrated circuit manufacture has at multiple points in the process opportunities which features/bug fixes can be layered on to the chips themselves. In the case of wireless chips (which is a volatile market...), chips with the same model number may or may not have features enabled. The production of any particular chip may be interrupted in order to fix identified problems or add/subtract features -- all while the model number remains the same. Who gets what chip depends upon the time contracts are finalized with customers & what is specified in the contract.

I have no knowledge of what chip was used when the driver was developed & what are the differences between it & the chip discussed in this thread, but I suspect there are driver differences between the operating systems mentioned. This would account for why differences are seen in the behaviour between operating systems.

When it comes to compatibility questions where wireless chips work in one operating system but not another, the most direct approach to isolating root causes is to study the source code to the driver itself. Given the contention between the GNU & most other licences, Linux driver code cannot be officially ported to the *BSD's & vice versa. Note that the supporting structure around either environment is likely to be different, so thinking that code from one platform can be dropped into another without modification is not realistic. Nevertheless, if you are serious about attempting to resolve compatibility problems, study the driver code, & debug. If you get something to work, post diff(1)'s to OpenBSD's tech@ mailing list, & see what the project developers say.

[unkmail]

But loadfirmware() just read whole file into malloced kernel memory buffer, it known nothing about underlaing wifi chip. So for me this looks like strange FS problem.

[IdOp]

Originally Posted by unkmail

But loadfirmware() just read whole file into malloced kernel memory buffer, it known nothing about underlaing wifi chip. So for me this looks like strange FS problem.

Glad you mentioned that. I took another look at the dmesg's. The part related to potential filesystem problem is this line:

athn0: failed loadfirmware of file athn-ar9271 (error 2)

This line was not displayed all the time, in fact it may have only happened the first time. What I now suspect is that there is no problem related to that line, probably the firmware was just not installed yet on that boot. How it got into my problem report here is that the dmesg command (run after several reboots) printed several complete dmesg's (it seems to print a whole buffer). Only the first one had this particular error (which may have happened just once on each machine). The above line occurs only in the amd64 dmesg I posted, for example.

So I strongly suspect that little part of the mystery is now solved. The main events remain, of course.