I have a ZyDas 1211-based USB wifi adaptor. It works fine on my desktop, but the driver is unable to load the firmware when I connect it to my server. Steps to reproduce: 1. modprobe zd1211rw 2. plug in USB adaptor dmesg says this: usbcore: registered new interface driver zd1211rw usb 1-1: new full speed USB device using ppc-of-ohci and address 4 usb 1-1: configuration #1 chosen from 1 choice usb 1-1: reset full speed USB device using ppc-of-ohci and address 4 phy1: Selected rate control algorithm 'pid' zd1211rw 1-1:1.0: phy1 Everything OK so far. 3. ifconfig wlan0 up (wait ages) SIOCSIFFLAGS: No such file or directory ...and dmesg says this: usb 1-1: firmware: requesting zd1211/zd1211b_ub usb 1-1: Could not load firmware file zd1211/zd1211b_ub. Error number -2 zd1211rw 1-1:1.0: couldn't load firmware. Error number -2 Now I definitely have all the firmware installed in the right directory - I downloaded the tarball from the site mentioned in the zd1211rw module's menuconfig help text and installed it according to the README, and then I found out about the zd1211-firmware ebuild and unmasked and installed the latest version of that, but none of it made any difference. My guess is that whichever utility is responsible for firmware loading is for some reason unable to access the filesystem. The affected box is a bit unusual, in the following ways: * hardened-sources (2.6.28-r9) with GrSec (CONFIG_GRKERNSEC_HARDENED_SERVER) and PaX * uClibc system * USB-1.1 ports only Kernel issue? Driver issue? It's beyond my expertise. Any important information I've omitted will of course be supplied on request. Cheers :)
hi, you should have CONFIG_FW_LOADER=y on the system, and you can compile the fw files into the kernel blob file. For example CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE="iwlwifi-3945-2.ucode microcode.dat" CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware" This removes the dependency on the external firmware loader support via `/sbin/hotplug`. You should check that this file exists as `/lib/firmware/zd1211/zd1211b_ub` on both systems. That's all info I can provide, I've no experience with hardened sources/GrSec/PaX. Can you please report back if this doesn't help? I'll assign it to hardened@ then. Thanks, Michael
Nowadays it is udev's responsibility to get the firmware loaded, so checking out udev is a good place to start. Let's start out with 'emerge --info' output and also 'emerge -pv udev' on this box. First check is whether udev looks new enough, and then we can turn on debugging to verify whether udev is actually receiving the firmware load events.
I don't run udev on that system any more, so that's probably it. Udev went badly wrong a while ago, rendering the system unbootable. I turned it off and this is the first repurcussion I've had. I'll try compiling-in the blob, see if that works.
Ok, that explains it. Compiling in the firmware should work.
Ok to close this bug as solved?
Yep, sorry :)
