Red Hat Bugzilla – Bug 238938
iwl3945 (was iwlwifi) blocks suspend/hibernate on T60p
Last modified: 2013-01-10 05:18:40 EST
Description of problem:
Whether I choose to suspend/hibernate using the g-p-m interface or by closing
the lid, my Lenovo T60p (2007-8DU) stops at the "Suspending console..." prompt
and the CPU kicks into high gear.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Suspend to either RAM or disk
2. Watch machine freeze.
3. Wait 15 minutes, then toast marshmallows.
CPU chews up time and machine never suspends.
Suspend/hibernate as requested; this worked fine in kernel 3116.
Any pointers on providing useful info gladly accepted and followed.
If I rmmod iwlwifi before suspend/hibernate, it works OK. However, then I can't
re-enable wireless by doing a new insmod/modprobe. I'm thinking that should be
a separate bug.
I confirm this on 1.3132...
I having problems also with suspend/hibernate and reboot/shutdown:all hang my
So i tried rmmod iwl3945 but this command cannot be completed succesfully and
also triggers high cpu usage.
Many are reporting identical problems -- I'm investigating this and consulting
w/ the intel wireless team...stay tuned!
*** Bug 239987 has been marked as a duplicate of this bug. ***
*** Bug 240530 has been marked as a duplicate of this bug. ***
2.6.21-1.3175 experiments (service NetworkManager running, but knetworkmanager
iwl3945 loaded and "ifconfig wlan0 up", suspend works but device is
unregistered after resume
iwl3945 loaded, "ifconfig wlan0 up", and associated w/ AP, suspend hangs
For the people that this bug annoys can implement the work-around described in
the "Dodgy modules" section:
The workaround suggested in #8 doesn't work for me.
SUSPEND_MODULES="iwl3945 mac80211 cfg80211"
doesn't actually unload iwl3945,
nor does manually rmmod'ing it.
Apparently NetworkManager immediately tries to reinitialize the device after the
Symptoms of this problem are a long list of messages like
iwl3945: Cahnnel 145 [5.2GHz] is Tx only -- skipping.
on the text console on attempt to suspend, combined with lack of actually
A work-around for this problem is to do
service NetworkManager stop
rmmod iwl3945 mac80211
Then we're back to resume hanging. :-)
Created attachment 157553 [details]
iwl3945 temporary blacklist
I confirm that module iwl3945 is automatically reloaded by NetworkManager, even
after receiving the sleep notification by dbus in
A workaround is to do an echo "install iwl3945 /bin/true" >
/etc/modprobe.d/iwl3945 in a script located in /etc/pm/sleep.d. This script
will be executed before all other scripts from /usr/lib/pm-utils/sleep.d
FWIW, latest upstream (0.0.34) seems to fix this.
James - any way one can easily test this? Has this version of the driver been
pushed into rawhide?
There's a kernel dated July 2nd in rawhide, but I can't tell if it has an
updated iwlwifi since there appears to be no corresponding SRPM :(
There seems to have been quite a bit of work done on the driver upstream
recently, so it would be good to get that into the F7 kernel - it would probably
end up closing off a number of open bugs.
Please try the kernels from here:
Do they work any better for you?
(In reply to comment #14)
> Do they work any better for you?
Suspended a few times without a problem on my Dell D420, although you need a
newer firmware for this version of the driver, so the package would need to be
The system now suspends and resumes fine with iwl3945 loaded, although I can
confirm the iwlwifi-firmware indeed requires an update. Thanks John et al.!
You can get the updated firmware package from here :
Can someone confirm that this newer firmware could be pushed as an update for
F-7 without breaking iwlwifi for those still using the latest released errata
Matthias, I confirm that the older driver does NOT work with the newer
(In reply to comment #18)
> Matthias, I confirm that the older driver does NOT work with the newer
Ouch. Well, I've rebuilt it for F-7 but haven't pushed it anywhere. Feel free to
push it to updates-testing if/when you also push a new kernel containing the new
driver. If all then works, we'll be able to also push the renamed package
(iwlwifi-firmware will become iwlwifi-3945-firmware) and the new
iwlwifi-4965-firmware both at once in order to have them installed on all
computers which previously had iwlwifi-firmware installed (since both will