Intel ipw3945 fails to load and the driver seems unable to detect the device. Kernel version is gentoo-sources-2.6.19-r5, and I followed the wiki guide found at http://gentoo-wiki.com/HARDWARE_ipw3945 I've also tried the driver with kernel version 2.6.20 with the same results. #lspci 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) 00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express PCI Express Root Port (rev 03) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02) 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller AHCI (rev 02) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02) 01:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce Go 7600] (rev a1) 02:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) 05:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller 07:05.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller 07:05.1 Class 0805: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19) 07:05.2 System peripheral: Ricoh Co Ltd Unknown device 0843 (rev 01) 07:05.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 0a) 07:05.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 05) #emerge -av ipw3945 wireless-tools wpa_supplicant #modprobe ipw3945 * Starting ipw3945d ... chown: cannot access `/sys/bus/pci/drivers/ipw3945/00*/cmd': No such file or directory chmod: cannot access `/sys/bus/pci/drivers/ipw3945/00*/cmd': No such file or directory or #/etc/init.d/ipw3945d start * Starting ipw3945d ... chown: cannot access `/sys/bus/pci/drivers/ipw3945/00*/cmd': No such file or directory chmod: cannot access `/sys/bus/pci/drivers/ipw3945/00*/cmd': No such file or directory #iwconfig lo no wireless extensions. eth0 no wireless extensions. # Reproducible: Always Steps to Reproduce: 1.Compiled kernel with proper kernel options 2.Install ipw3945 Intel Wireless driver (ipw3945) 3.Start the ipw3945 daemon (/etc/init.d/ipw3945.d) Actual Results: * Starting ipw3945d ... chown: cannot access `/sys/bus/pci/drivers/ipw3945/00*/cmd': No such file or directory chmod: cannot access `/sys/bus/pci/drivers/ipw3945/00*/cmd': No such file or directory Expected Results: Working wireless interface. The wireless kill switch on the front of the laptop is switched to the on position.
Created attachment 111595 [details] Kernel configuration
#ipw3945d ipw3945d - regulatory daemon Copyright (C) 2005-2006 Intel Corporation. All rights reserved. version: 1.7.22 2007-02-28 01:13:01: ERROR: Could not find Intel PRO/Wireless 3945ABG Network Connection
I tried modifying the ipw3945d in modules.conf and modprobe.conf using the aforementioned option: Changed from: install ipw3945 /sbin/modprobe --ignore-install ipw3945; sleep 0.5; /etc/init.d/ipw3945d start remove ipw3945 /etc/init.d/ipw3945d stop; /sbin/modprobe -r --ignore-remove ipw3945 to: install ipw3945 /sbin/modprobe --ignore-install ipw3945; sleep 0.5; ipw3945d --pid-file=/var/run/ipw3945d/ipw3945d.pid remove ipw3945 /etc/init.d/ipw3945d stop; /sbin/modprobe -r --ignore-remove ipw3945 If I try and run the ipw3945 daemon (/etc/init.d/ipw3945d or ipw3945d) I get the output: # ipw3945d ipw3945d - regulatory daemon Copyright (C) 2005-2006 Intel Corporation. All rights reserved. version: 1.7.22 2007-03-02 05:57:17: ERROR: Could not find Intel PRO/Wireless 3945ABG Network Connection # dmesg | grep ipw ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.2.0dmpr ipw3945: Copyright(c) 2003-2006 Intel Corporation ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection ipw3945: ipw3945.ucode load failed: Reason -2 ipw3945: Could not read microcode: -2 ipw3945: probe of 0000:02:00.0 failed with error -2 Still no luck with wireless.
Before anything else you should get the microcode working. - is the microcode properly installed? (/lib/firmware for me) - is the filesystem where the firmware lies readable at boot-time, i.e. not compiled as module?
It appears that the firmware is located in the correct place, and when I emerged hotplug, this is where it noted firmware should be stored for loading. ls /lib/firmware ipw3945.ucode Just to rule out filesystem / boot device support, I recompiled the kernel with the proper serial ATA devices with the monolithic option. ETX3 (root file system) support was compiled in the kernel monolithically. The rest of the kernel configuration is pretty much the standard "genkernel all" with the exception of the SATA support and ieee80211 generic support. Still no luck with the ipw3945 device, and according to dmesg, the microcode still seems to not be loading: #dmesg | grep ipw ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.2.0dmpr ipw3945: Copyright(c) 2003-2006 Intel Corporation ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection ipw3945: ipw3945.ucode load failed: Reason -2 ipw3945: Could not read microcode: -2 ipw3945: probe of 0000:02:00.0 failed with error -2
I'm not sure if this is directly relevant to the microcode problem, but I did notice alternating behavior between the ipw3945 modules loaded by /etc/modules.autoload/kernel-2.6 at bootup and the ip3945d daemon started by /etc/init.d/ipw3945d which is also started at boot. I noticed that either the daemon or module fail to load or start every other boot. For example, during the first boot, the module will load successfully, and the daemon will fail. However, during the subsequent boot, the module will report a failure to load during the boot process, and the daemon will appear to start successfully. If the module loads succesfully, the daemon returns the following output during the boot process: * The pidfile (/var/run/ipw3945d/ipw3945d.pid) is still present. * Please check that the daemon isn't running! * Starting ipw3945d ... chown: cannot access `/sys/bus/pci/drivers/ipw3945/00*/cmd': No such file or directory chmod: cannot access `/sys/bus/pci/drivers/ipw3945/00*/cmd': No such file or directory /sbin/ipw3945d already running. [ !! ] Also, even if the module reports that it failed to load at bootup, the ip3945 module and firmware_class module still seem to be loading: #lsmod Module Size Used by rtc 14496 0 ipw3945 207652 0 firmware_class 15616 1 ipw3945 tg3 110852 0 e1000 122944 0 nfs 237360 0 lockd 71088 1 nfs sunrpc 174536 2 nfs,lockd jfs 166608 0 raid10 27392 0 raid1 27264 0 raid0 12288 0 dm_mirror 25984 0 dm_mod 64336 1 dm_mirror ata_piix 22280 0 ahci 26372 2 libata 112288 2 ata_piix,ahci sbp2 30084 0 ohci1394 38856 0 ieee1394 104824 2 sbp2,ohci1394 sl811_hcd 17664 0 usbhid 55328 0 ff_memless 10376 1 usbhid ohci_hcd 25092 0 uhci_hcd 28816 0 usb_storage 88128 0 ehci_hcd 33928 0 usbcore 144808 7 sl811_hcd,usbhid,ohci_hcd,uhci_hcd,usb_storage,ehci_hcd
you said, that "ipw3945d start" alternates between two failures from boot to boot. Does dmesg | grep ipw change too, or is it always the same?
dmesg | grep ipw reports the same error output regardless of the alternating boot failures. ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.2.0dmpr ipw3945: Copyright(c) 2003-2006 Intel Corporation ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection ipw3945: ipw3945.ucode load failed: Reason -2 ipw3945: Could not read microcode: -2 ipw3945: probe of 0000:02:00.0 failed with error -2 Removing the ipw3945 module and ipw3945d daemon from auto-loading at boot, and loading them manually also reports the same microcode error in dmesg.
It works! 1.) emerge hotplug 2.) nano -w /etc/hotplug/firmware.agent 3.)FIRMWARE_DIR=/lib/firmware --> FIRMWARE_DIR/lib64/firmware 4.) modprobe -r ipw3945 5.) modprobe ip3945 I think the root of the problem was caused by selecting a non-multilib profile when following the Gentoo amd64 handbook. /lib/firmware and /lib64/firmware both contain ipw3945-ucode, but by default hotplug-base searches /lib/firmware and cannot load the 32-bit firmware due to the non-multilib profile selection (I'm not really sure about this)... Thanks for your help Cornelius.
Guess I was wrong. After a reboot, ipw3945 reverted back to failing to load the microcode. /lib/firmware and /lib64/firmware in /etc/hotplug/firmware.agent doesn't seem to matter. What consistently makes the device work is re-emerging udev-104-r11. After emerging udev-104-r11, the module will load, and iwconfig will return eth1. After rebooting, the module fails to load, and will not successfully load until udev-104-r11 is re-emerged.
if you want to check, if a config file changes after the first use of udev, then run the commands (as root) mkdir ~/test; for x in `equery f udev | grep -v -e doc -e man`; do cp -i $x ~/test/; done and afterwards for x in `equery f udev | grep -v -e doc -e man`; do diff $x ~/test/`basename $x` ; done this reveal any change in udev-configs (libvolume_id.so will differ because there are two filed with the same name)
I was able to the narrow the problem down to udevd not properly starting at boot. The problem was resolved by emerging a newer version of sys-apps/baselayout and its dependencies (sysinitv, etc...). I also added the gentoo=nodevfs parameter to the kernel boot line in grub.conf. It looks like that fixed everything. It even found some other devices that I have to figure out what they do :) Thanks again for your help. - Art
