Red Hat Bugzilla – Bug 171319
ipw- -bss_ucode.fw load failed: Reason -2
Last modified: 2007-11-30 17:11:15 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7
Description of problem:
The errors i usually get on 2.6.13 are:
firmware_loading_store: unexpected value (0)
ipw-2.3-bss_ucode.fw load failed: Reason -2
Version-Release number of selected component (if applicable):
ipw2200: tried default (1.0), 1.0.6, 1.0.7
Steps to Reproduce:
1. Boot into FC4
2. open /var/log/messages
3. search for PRO
Actual Results: Found errors in the lg.
Expected Results: Successful loading of the driver.
I think it worked during boot on 2.6.11 kernel, while i had it for a
couple of boots before i overwrote it. Yesterday, i tried it again on .11, and also got a similar error to below. It never worked in 2.6.12, and .13.
I have done
echo 100 > /sys/class/firmware/timeout
but i have a feeling, there is a better place to put it. I placed it in
rc.sysinit (first at the end, then in the beginning, then in the middle,
before interface modules are loaded). Failures continue during boot.
Where exactly should this command go in start-up scripts? A guy on ipw2100-devel suggested to ask on FC list, although i think it shouldn't really be that distro-dependent.
I've tried the latest version: 1.1.5, 1.0.7, 2.4. Same outcome: get
failures on boot, but can modprobe (most of the time w/o errors), manually
If somebody could
give me some feedback on where in rc.sysinit or another script to put
echo 100 >, that could help.
did you ask on the mailing list??
I don't know what's going wrong... maybe you need a new firmware file? Maybe
it's the driver in the new kernel?
Yes, it's on the list:
I got tired of putting diff. firmware files in and out, and now have 2.2, 2.3,
and 2.4 firmware in /lib/firmware.
Lately, i tried putting echo 100 > in cpuspeed, and kudzu files, but then i
decided the best place was probably rc.sysinit, right after /sys is mounted:
however, none of these resolve the on-boot firmware failure.
The workaround i've been thinking about worked:
modprobe -r ipw2200
But it didn't work w/o errors even this way: errored out and got restarted right
away (nevertheless, since it restarted automatically and successfully, this is
sufficient to avoid loading the driver manually every time one boots).
Oct 22 12:10:52 localhost kernel: ipw2200: Intel(R) PRO/Wireless 2200/2915
Network Driver, 1.0.0
Oct 22 12:10:52 localhost kernel: ipw2200: Copyright(c) 2003-2004 Intel Corporation
Oct 22 12:10:52 localhost kernel: ACPI: PCI Interrupt 0000:03:03.0[A] -> Link
[LNKB] -> GSI 5 (level, low) -> IRQ 5
Oct 22 12:10:52 localhost kernel: ipw2200: Detected Intel PRO/Wireless 2200BG
Oct 22 12:10:56 localhost kernel: ipw2200: Firmware error detected. Restarting.
Oct 22 12:11:05 localhost dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
Oct 22 12:11:05 localhost dhclient: DHCPACK from 192.168.2.1
Oct 22 12:11:05 localhost NET: /sbin/dhclient-script : updated
Oct 22 12:11:05 localhost dhclient: bound to 192.168.2.4 -- renewal in
More feedback on the "work-around" (i still hope that the original issue will be
fixed though, so that rc.local change isn't needed):
On another boot, modprobe from rc.local didn't generate an error in firmware,
but complained about duplicate address:
Oct 22 15:48:22 localhost kernel: ipw2200: Intel(R) PRO/Wireless 2200/2915
Network Driver, 1.0.0
Oct 22 15:48:22 localhost kernel: ipw2200: Copyright(c) 2003-2004 Intel Corporation
Oct 22 15:48:22 localhost kernel: ACPI: PCI Interrupt 0000:03:03.0[A] -> Link
[LNKB] -> GSI 5 (level, low) -> IRQ 5
Oct 22 15:48:22 localhost kernel: ipw2200: Detected Intel PRO/Wireless 2200BG
Oct 22 15:48:26 localhost kernel: eth1: duplicate address detected!
Oct 22 15:48:31 localhost dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
Oct 22 15:48:31 localhost dhclient: DHCPACK from 192.168.2.1
Oct 22 15:48:31 localhost NET: /sbin/dhclient-script : updated
Oct 22 15:48:31 localhost dhclient: bound to 192.168.2.4 -- renewal in
I installed FC from development pipeline from scratch, and ipw2200 now appears
to successfully load during boot: the only thing i had to do is place 2.2
firmware in /lib/firmware. I didn't need echo 100 >.
The only error i've seen so far on FC5 is this (after disabling eth0, and
enabling eth1 (wireless); this was the first time i enabled eth1, i think):
Oct 23 13:40:35 dizustu2 kernel: ipw2200: Firmware error detected. Restarting.
Oct 23 13:40:40 dizustu2 dhclient: can't create
/var/lib/dhcp/dhclient-eth1.leases: No such file or directory
Given my memory of a successful during-boot loading of ipw2200 on 2.6.11 FC4
kernel (it did require echo 100 > though), before i rpm -Uvh'ed it w/ a higher
version (2.6.12 i think it was), there is a possibility that all the during-boot
errors i've seen and reported above might have been caused by a corruption
introduced during a manual install of ipw2200, of which i tried several,
attempting to get it to work on 2.6.12, and 2.6.13. I'm not sure whether i will
stay on FC5, on go back to FC4, but if and when i try another FC4 install
(perhaps just to establish if the above errors occur w/o a manual install of
ipw2200), i will post an update here.
I believe the problem above was caused by my upgrades of certain libraries on
the previous install. I made a fresh FC4 install over the weeekend, and just
like last time, i had problems w/ sound, so i upgraded my alsa, which required
upgrades of alsa-lib, glibc, and udev from development pipeline (FC5). Before i
did that, wireless was working fine and not erroring out during boot. After the
upgrades, i started getting the errors like above. The following were taken from
the development repos:
In particular, i suspect glibc, which before the upgrade from dev repos was
provided by the following rpms:
FC4 alsa was:
FC4 udev was:
Not sure if there is something to investigate further about this bug. Looks like
an incompatibility between glibc and ipw2200, but of course this is not an
in-depth analysis. Last time (few weeks ago), the i report the same issues after
upgrading alsa, and glibc, but not udev (this is of course by memory, but i
think that was the case).
2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.
As i posted last time, i believe we can close this issue. It only happened after
pulling some FC5 rpms on top of FC4 installed to fix alsa driver. Probably not
worth investigating further, but there might be something about some FC5 rpms
(like glibc) that is incoompatible w/ the firmware when used in an FC4 install...
I think let's close it.