ipw2200 regression in gutsy

There's also this in /var/log/messages:

Sep 12 21:27:09 resist kernel: [ 173.548000] ipw2200: Firmware error detected.

I tried the 3.0 firmware from ipw2200.sf.net and it made no difference. It didn't appear as though gutsy is using an earlier version of the firmware.

Barry - follow the instructions in https://wiki.ubuntu.com/KernelTeamBugPolicies. If you've been following the upgrade path, then you ought to have older kernels to boot from. Verify that they continue to work correctly with your ipw2200.

Hi Tim, thanks for the response. None of the older kernels appear to work either, which includes 2.6.20-16, 2.6.22-10, and 2.6.22-11. However, I am now noticing that my wireless light is not on (the little radio transmitter icon under the screen). Fn-F5 does nothing in any of the kernels. I'm pretty sure this was /not/ the case when the failure first started, but it probably is the case that the wireless is currently disabled. So that needs to be fixed first before I can further debug the connection problems. Unfortunately, there appears to be no way to re-enable the wireless card from the keyboard. Is there any other way to do that (short of booting to Windows which is not an option)?

I'm attaching the requisite log files.

Barry - I think you have hardware problems. 'ipw2200: probe of 0000:02:02.0 failed with error -5'

Does this laptop have an RF kill switch? Make sure it is in the 'wireless enabled' position. You might also open your laptop cabinet (sometimes easier said then done) and see if you can re-seat your wireless card.

Hi Tim,

I don't think it's a hardware problem. I just booted to the Gutsy Tribe 5 live cd and got connected to my network just fine. However, when I reboot from the hd, the RF is still software killed afaict, and Fn-F5 won't turn it back on, and neither can I connect to my network.

I confirm this bug, I get similar debug outputs. rmmod ipw2200 and modprobe ipw2200, restarting the dbus and then relogin gets NetworkManager working again.

Another observation. Even booting off the live cd, it takes several attempts at entering my WPA password before the machine will connect to the network. OTOH, it does eventually connect and the wireless light does come one.

Now however on the HD boot, I can't even got NetworkManager to show me an option of using the wireless device even though lsmod shows ipw2200 loaded. I think something's really hosed with the firmware because now I see error -2's in dmesg.

I tried Hendrick's suggestions but no good. I've even tried reinstalling linux-ubuntu-modules and the kernel, but no luck. I'm almost ready to reinstall this machine from scratch.

One more data point. I've re-installed gutsy tribe 5 from scratch. After applying all updates, I was still unable to connect to my network after several tries. I then re-enabled broadcast of the ssid and then was able to connect to the network, but not until after rebooting, since NetworkManager had crashed. (I had tried both broadcast and w/o after the original update and neither made a difference).

Here's the situation now: if the ssid is broadcast, the machine connects to network just fine after logging in. if the ssid is /not/ broadcast, then NM prompts me for the WPA passphrase, and then connects to the network. I don't understand why NM doesn't automatically connect to the network when the ssid isn't being broadcasted. In the no-broadcast case, NM still correctly identifies the ssid.

Barry - I'm reassigning this to the network manager. Alexander Sack can probably comment on this behavior. Since the driver is working, I do not believe its a kernel problem.

Thanks Tim, I think that's the right thing to do at this point. Clearly Something Went Wrong at some point during the upgrade, but a fresh install repairs the problem and also of course erases all traces of the original problem. At least now we know the h/w and driver still work. Thanks!

Tim, the driver works, but it doesn't behavce nicely from what i can see in the code. Barry, would you be willing to test a patched driver? You won't need to confirm that the problem goes away as you apparently cannot reproduce it anymore. I just would need someone to confirm that it doesn't break with the patch I have in mind.

Thanks,

 - Alexander

Alexander, is this patch supposed to fix the NM behavior when the ssid is not broadcast, or some other problem? If it's helpful to try a patch on a pristine gutsy laptop, and I can get my machine back to its supported happy state :) I'd be willing to give it a shot.

Another problem I've just noticed. After a wake-from-sleep on a lid open, the network connection stays up for a very short time. Then it crashes and is very flaky until reboot. Restarting dbus helps but only for a few minutes, and not every time. I'm often prompted several times for the wpa passphrase. Also, the icon in the toolbar disappears. After a reboot, all is happy again.

when nm crashes, does

  /etc/dbus-1/event.d/25NetworkManager restart

bring you back to a usable state - similar to what you have after reboot?

... and no, the patch i propose probably doesn't directly fix the hidden network issue
but I will look into that too - hopefully soon.

I just want to mention that with the latest set of updates, this issue appears to have been fixed. Lid opens correctly restore my network connection now, so I guess this issue can be closed.

Cheers, and thanks!

Hello, I ran into the same firmware loading issue after upgrading from feisty today. I noticed that the firmware loads correctly for the generic kernel, but not for the 386 kernel. Upon closer inspection, it looks like I was missing the firmware images in the /lib/firmware/2.6.22-13-386 directory, but they were in the /lib/firmware/2.6.22-13-generic directory (In fact, I was missing about 20 different firmware files from the directory). Putting the ipw2200-* files into the 2.6.22-13-386 directory fixed the problem.

I can confirm that Shawn Fisher's fix works just fine on my machine. Thanks for the good eyes Shawn.

With Barry's last comment regarding this being fixed with an update, I'm closing this report. Thanks!