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:

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:

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?

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.

Quote:

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

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

Quote:

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):

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.

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.

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.

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:

Code:

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.

Welcome to the forum! Unfortunately, I haven't had a chance to pursue this problem any further. The only vaguely related info to relate is that last year the OpenBSD athn(4) driver was ported to NetBSD -current. I had slightly more luck with it there, at that time, but only slightly: in the end it was also unstable and unreliable. Again, haven't tried it in the last few months there either.

...I'll try reporting a bug once I figure out how to get reportbug to work (I assume I need to set something else up, e.g. sendmail first)...

Welcome!

sendmail(8) will already be configured for sending mail from one account to another within the same system, however, this is not a requirement for sending bug reports.

The point of using sendbug(1) is to fill in the existing template to create as complete a report as possible which will be more useful to the developers. The template can be saved as text & mailed from a different system and/or mail system if this is more convenient.

Completeness is key. It will help you in articulating your findings, & it will help developers discern root causes. More information on what information is useful can be found at the following: