On Thu, Mar 23, 2017 at 09:30:43AM +0900, Stefan Sperling wrote: > On Wed, Mar 22, 2017 at 02:42:19PM +0000, Kevin Chadwick wrote: > > In case it is of any help to anyone. I tried 11n on a ar9271 a few weeks > > ago and also an ar2133. Both would give athn0: device timeouts but the usb > > ar9271 needed a ifconfig down up to recover whereas the card recovered by > > itself. Using 11g made them far less likely and whilst I have hardly used > > the 11b ssid, I haven't had any with 11b on the 9271 so far. > > > > Also after using 11n and getting multiple resets I had to plug the card > > into another laptop to get the firmware to load again without saying could > > not read ROM, even after reboots. So maybe some state is kept on OpenBSD or > > more likely perhaps it was unplugged for long enough to clear the cards > > memory or something. > > There is a known issue which looks like ehci(4) on some USB host controllers > does not feed sufficient power to athn(4) devices and then they won't work > reliably.
The problem is unrelated to the USB controllers. Some boards are not well designed and feed the current to the USB port unfiltered. That's is why the problem is more common in cheap ARM boards than PCs motherboards. Olimex has this "workaround": https://www.olimex.com/Products/USB-Modules/USB-CAP/ OK to this change in the man page? diff --git athn.4 athn.4 index eb7b951c289..f8f20f39aca 100644 --- athn.4 +++ athn.4 @@ -215,8 +215,10 @@ The driver will turn the interface down. .It "athn0: error N, could not read firmware ..." For some reason, the driver was unable to read the firmware file from the filesystem. The file might be missing or corrupted. +This is also a common error on systems where the power source doesn't feed +enough current to the USB port during the initialization of the device. .El .Sh SEE ALSO .Xr arp 4 , .Xr cardbus 4 ,
