Bug 238938 - iwl3945 (was iwlwifi) blocks suspend/hibernate on T60p
Summary: iwl3945 (was iwlwifi) blocks suspend/hibernate on T60p
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: rawhide
Hardware: i686 Linux
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Brian Brock
: 239987 240530 (view as bug list)
Depends On:
Blocks: 237760
TreeView+ depends on / blocked
Reported: 2007-05-04 00:59 UTC by Paul W. Frields
Modified: 2013-01-10 10:18 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-24 13:50:01 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
iwl3945 temporary blacklist (651 bytes, text/plain)
2007-06-21 16:27 UTC, Fabrice Bellet
no flags Details

Description Paul W. Frields 2007-05-04 00:59:50 UTC
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):

How reproducible:
Every time

Steps to Reproduce:
1. Suspend to either RAM or disk
2. Watch machine freeze.
3. Wait 15 minutes, then toast marshmallows.
Actual results:
CPU chews up time and machine never suspends.

Expected results:
Suspend/hibernate as requested; this worked fine in kernel 3116.

Any pointers on providing useful info gladly accepted and followed.

Comment 1 Paul W. Frields 2007-05-04 01:38:32 UTC
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.

Comment 2 John W. Linville 2007-05-04 20:10:21 UTC
I confirm this on 1.3132...

Comment 3 Nikos Charonitakis 2007-05-14 20:44:01 UTC
I having problems also with suspend/hibernate and reboot/shutdown:all hang my
dell d620
So i tried rmmod iwl3945 but this command cannot be completed succesfully and
also triggers high cpu usage.

Comment 4 John W. Linville 2007-05-14 21:27:40 UTC
Many are reporting identical problems -- I'm investigating this and consulting 
w/ the intel wireless team...stay tuned!

Comment 5 John W. Linville 2007-05-14 21:29:32 UTC
*** Bug 239987 has been marked as a duplicate of this bug. ***

Comment 6 John W. Linville 2007-05-22 13:18:26 UTC
*** Bug 240530 has been marked as a duplicate of this bug. ***

Comment 7 John W. Linville 2007-05-22 13:25:46 UTC
2.6.21-1.3175 experiments (service NetworkManager running, but knetworkmanager 
not running):

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

Comment 8 Bastien Nocera 2007-05-22 16:52:03 UTC
For the people that this bug annoys can implement the work-around described in
the "Dodgy modules" section:

Comment 9 John Heidemann 2007-06-15 17:52:47 UTC
The workaround suggested in #8 doesn't work for me.
SUSPEND_MODULES="iwl3945 mac80211 cfg80211"
in /etc/pm/config.d/unload_modules

doesn't actually unload iwl3945,
nor does manually rmmod'ing it. 

Apparently NetworkManager immediately tries to reinitialize the device after the
rmmod command.

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. :-)

Comment 10 Fabrice Bellet 2007-06-21 16:27:26 UTC
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

Comment 11 James Bowes 2007-07-02 14:25:41 UTC
FWIW, latest upstream (0.0.34) seems to fix this.

Comment 12 Jens Knutson 2007-07-03 00:13:34 UTC
James - any way one can easily test this?  Has this version of the driver been
pushed into rawhide?

Comment 13 Steve Hill 2007-07-04 08:22:18 UTC
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.

Comment 14 John W. Linville 2007-07-13 15:52:15 UTC
Please try the kernels from here:


Do they work any better for you?

Comment 15 Bastien Nocera 2007-07-13 16:21:00 UTC
(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

Comment 16 Paul W. Frields 2007-07-13 18:09:41 UTC
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.!

Comment 17 Matthias Saou 2007-07-14 17:35:15 UTC
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

Comment 18 John W. Linville 2007-07-16 13:50:47 UTC
Matthias, I confirm that the older driver does NOT work with the newer 

Comment 19 Matthias Saou 2007-07-16 14:48:00 UTC
(In reply to comment #18)
> Matthias, I confirm that the older driver does NOT work with the newer 
> firmware...ick.

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
obsolete it).

Note You need to log in before you can comment on or make changes to this bug.