Bugzilla – Bug 232420
ipw3945 wireless NIC not working after S2D or S2R
Last modified: 2007-11-27 17:00:34 UTC
After resuming from a suspend to disk or suspend to ram my wireless NIC is no longer detected by the NetworkManager applet. My wired NIC works fine. I have tried reconfiguring the NIC with YaST, etc. but the only way I can get it to work again is to reboot. Environment: openSUSE 10.2 Dell Inspiron E1505 Wireless NIC: Model: "Intel PRO/Wireless 3945ABG Network Connection" Vendor: pci 0x8086 "Intel Corporation" Device: pci 0x4222 "PRO/Wireless 3945ABG Network Connection" SubVendor: pci 0x8086 "Intel Corporation" SubDevice: pci 0x1020 ... Driver Info #0: Driver Status: ipw3945 is active Driver Activation Cmd: "modprobe ipw3945" Wired NIC: Model: "Dell BCM4401-B0 100Base-TX" Vendor: pci 0x14e4 "Broadcom" Device: pci 0x170c "BCM4401-B0 100Base-TX" SubVendor: pci 0x1028 "Dell" SubDevice: pci 0x01af ... Driver Info #0: Driver Status: b44 is active Driver Activation Cmd: "modprobe b44" I have attached a SIGA. Please let me know if there is any other data/troubleshooting needed.
Created attachment 111735 [details] siga.html
Created attachment 111736 [details] siga.txt
Does rmmod/insmod of ipw3945 fix it? If so (it really should) we can blacklist it in powersave. ipw3945 is a mess, maintained by intel. Not sure what bugzilla they listen at?
I have done a bit of testing... Essentially, I can't cleanly rmmod ipw3945 unless I am in runlevel 1 (I get "in use" messages in any other runlevel). If I do switch to runlevel 1 and do a rmmod/modprobe then re-enter runlevel 5 everything works great. I have also noticed that if I just init 1; init 5 the wireless *sort of* comes back up. A subset of the available wireless networks are found. Mine is not, and I cannot successfully connect to it by specifying it manually. I can also sometimes reach this state by remaining in runlevel 5 and by using YaST to switch the networking to the ifup scripts, then switch back to NetworkManager. The only way to get it cleanly back up is: # init 1 # rmmod ipw3945 # modprobe ipw3945 # init 5
use "modprobe -r" or add it to the module list as described in http://en.opensuse.org/Pm-utils
Stefan, can we add ipw3945 to list of modules to unload? I think it is best solution until someone cleans ipw3945 up.
no. General consensus is that fixable drivers need to be fixed and working around everything by default is just hindering the fixing of the drivers (think of it, it is the same as binary drivers hinder the development of free drivers). So the module unload list is deliberately left empty on 10.2. And we cannot update the config file because of RPM constraints anyway once shipped AFAICT. But somebody could document this on opensuse.org wiki :-)
Both suggestions from comment #5 work. Thanks!
Comment 3: http://www.bughost.org/bugzilla/
Stefan: I'd say this driver is unfixable. It is piece of **** relying on binary-only daemon, and too crappy to be allowed anywhere near mainline. I'm not touching it with 10foot pole, and neither should anyone else... plus improvements would be lost because it will need full rewrite before going to mainline. For drivers of similar quality, I'd say that unloading is okay.
(Are you saying we can't update list of modules to unload due to rpm limitations? That would be bad :( ).
Not without major pain (it is a config variable SUSPEND_MODULES="foo bar baz" and you do not want to override stuff the user has added there. It would need major sed trickery and i'd like to avoid that :-) In this case, the kmp-package should simply provide its own pm-utils hook that unloads the module before suspend and reloads it after resume. No need to work around non-mainline stuff in a "mainline application" :-)
this bug should be fixed by adding an appropriate hook to the ipw3945d package
And this hook, how should it look like?
A good and simple description can be found here: http://en.opensuse.org/Pm-utils#Creating_your_own_hooks
Created attachment 113608 [details] hook "50ipw3945" This should go into /etc/pm/hooks, permission 0755
As the problem can be worked around by adding ipw3945 to SUSPEND_MODULES, I'm not going to make a patch for 10.2. I move the bug to 10.3. For the case ipw3945d will still be required, we can add the hook then.
I really really do not think that's good idea. People don't know that they should add it to SUSPEND_MODULES, and will file duplicate bug reports. Can we fix that, please? Stefan even created neccessary file for you, can you simply add it to ipw3945 package? It can't cause regression, it will a bug, and will prevent about 10 duplicate reports going on my head in bugzilla.
SUSPEND_MODULES is documented here: http://de.opensuse.org/Pm-utils Don't know whether people will find it, though. Furthermore, after resume the ipw3945 interface is still working, but NetworkManager loses it somehow, so I guess it's in fact a NM problem, reloading the module just works around it. I did some tests to reproduce this problem and interestingly I saw the bug only when I triggered the suspend with kpowersave, not when using s2ram/s2disk directly. I guess the difference is that the kpowersave method sets offline mode before suspending. Anyway, reassigning to NM maintainer.
Created attachment 114467 [details] NM log messages before suspend and after resume The log messages show some warnings when deactivating the wlan interface, don't know whether this is the cause.
Kirk, is this replicatable without NM and with the SUSPEND_MODULES hack? If so, this should probably just go to jg.
*** Bug 228847 has been marked as a duplicate of this bug. ***
*** Bug 243085 has been marked as a duplicate of this bug. ***
I hit this bug with a thinkpad x60. Workaround is reloading the driver after resume from disk. When searching for info, other distros hit it to. Ubuntu is tracking it here: http://ubuntuforums.org/showthread.php?p=2765605 comment #19 : I also use kpowersave to suspend. What is the required info in this bug?
*** Bug 255666 has been marked as a duplicate of this bug. ***
Probably a duplicate of bug 255765.
*** Bug 287136 has been marked as a duplicate of this bug. ***
So, is this bug still appropriate, since openSuse seem to switch to the "new" iwl3945 driver in 10.3?
Oke, i've tested 10.3 beta2 x86_64 KDE with the iwl3945 driver and al least S2R works.
S2D works too (nice, a sleeping penquin splash during S2D :-)
We've gone back to ipw3945, but as per bug 268277, it may be solved anyhow. Is this the case Fred/Kirk?
I'm on RC1 and it's not fixed, but I opened a new bug report on it (sorry for that). It's bug 328011
*** Bug 328011 has been marked as a duplicate of this bug. ***
*** Bug 329906 has been marked as a duplicate of this bug. ***
OK, I'm running 10.3 Gold now and things are much better! At startup it autoconnects using kwallet. To make it autoconnect on resume I had to put the ipw3945 driver in the pm-util configuration as described in comments #5 and #19. I'll keep working with this setup for some more days before I declare this bug as closed. I stil think it's a good idea to put ipw3945 in SUSPEND_MODULES by default. I know it's a crap driver, but why irritate people with it?
Well, I cheered too soon (again!). Initially, it worked as described in comment #35. But after some time it's back to the original problem: no auto reconnects. Not on startup and not on resume. Don't know what I did to make is fail again.
I did a complete online reinstall of 10.3 GM (x86_64) (1CD KDE) a few days ago. After adding ipw3945 to SUSPEND_MODULES, I can't break it. It reconnect's in every instance for a number of days, reboot's, and resumes. Don't know what caused this new behaviour, but i'm happy right now. I'll keep monitoring this for another week and then I declare this bug as closed, but maybe other's have problems still.
JFTR: I won't add any broken drivers to SUSPEND_MODULES by default, since it would be an update nightmare (what to do once the driver is unbroken?) Drivers in the kernel should just be fixed. Drivers outside the kernel (kmp-packages) can bring their own pm-utils hook skript and fix the issue by themselves.
Presumably covered in JG's recent work.
As ipw3945 is in its final throes, superseded by iwlwifi, I spare any efforts working on ipw3945. Resolving as WONTIFX.
2nd attempt