Bug 319071 - iwl3945 and 4965: Failed to read scan data : Resource temporarily unavailable
Summary: iwl3945 and 4965: Failed to read scan data : Resource temporarily unavailable
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F8Target
TreeView+ depends on / blocked
Reported: 2007-10-04 19:04 UTC by Warren Togami
Modified: 2008-04-17 01:49 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-01-24 20:19:15 UTC
Type: ---

Attachments (Terms of Use)

Description Warren Togami 2007-10-04 19:04:04 UTC
iwl3945 often gets into a state where it has no scan results.  iwlscan says:
wlan0     Failed to read scan data : Resource temporarily unavailable

Reloading the iwl3945 module allows it to scan again.  dcbw says this is a
driver issue.  It happens often enough that it is crippling to the user experience.

Thinkpad T60 x86_64

Comment 1 Warren Togami 2007-10-05 01:35:22 UTC
iwl4965 seems to be affected as well.

But surprise!  217 works while 218 doesn't.  Untagging 218 from rawhide so it
wont break our Test3 users.

Comment 2 John W. Linville 2007-10-05 13:44:15 UTC
Warren, is it only these two drivers?  Have you had a chance to try any other 
mac80211-based drivers, e.g. zd1211rw-mac80211, b43, rt73usb, etc?

Comment 3 Warren Togami 2007-10-05 14:08:03 UTC
I don't have hardware for anything else.

Comment 4 Jarod Wilson 2007-10-05 21:06:08 UTC
Ooh, I'm excited! Finally got around to poking b43 + latest network manager, and
for the first time ever, I'm actually able to get my laptop to connect to the
office wifi, stay connected, pass traffic, etc... Haven't yet seen any issues
with scanning, but haven't been paying attention that long.

Comment 5 Jarod Wilson 2007-10-09 15:43:18 UTC
So I was working from home yesterday, and brought up ye olde laptope in Linux,
connected to my wireless base station, and all was well for a little while...
Had a few things going on, then fired up a little yum upgrade action. A few
packages into downloading, my network connection suddenly died. The
NetworkManager doohickey in the menu bar disappeared, the interface no longer
had an IP address, and I couldn't get anything back restarting NetworkManager.
Turned out my wireless base station was also deep-sixed in the process. It was
still powered up, but had disappeared from radar -- couldn't even see it back
under OS X. After a power-cycle of the base station, all was well again, but I
stuck with working under OS X the rest of the day... :) (never seen anything
like this before, have had this laptop and base station for at least 2 years now).

Comment 6 Bill Nottingham 2007-10-09 15:49:02 UTC
FWIW, the behavior in comment #1 has been happening forever with iwl3945; I've
yet to see a version where it *didn't* happen. It goes into bozo mode more often:
- if I'm further from the AP
- if I close the lid (presumably changing the antenna characteristics)

Comment 7 John W. Linville 2007-10-16 17:56:06 UTC
Is this still a problem with current rawhide of fc8 kernels?

Comment 8 Warren Togami 2007-10-16 18:37:56 UTC
As of -6, no.

Comment 9 John W. Linville 2007-10-16 19:10:59 UTC
I'm going to close for now, please reopen if it is still busted when new 
updates go back into rawhide.

Comment 10 Bill Nottingham 2007-10-30 23:48:34 UTC
Reopening. I still see this with -37 and -41. However, marking as F8Target, as
this has happened in every F7 kernel as well, it's not really any *more* broken
than it was before.

Comment 12 John W. Linville 2007-10-31 13:43:58 UTC
FWIW, the "new updates" referenced in comment 9 are still not in the F8 
kernels.  The current version of them is available here:


I have found them to be quite reliable on my T61.  BTW, those kernels contain 
the fixes referenced in comment 11.  Do they help you?

Comment 13 Bill Nottingham 2007-11-01 01:47:06 UTC
Using, I still get occasions where it does:

wlan0: No ProbeResp from current AP 00:13:10:a6:40:59 - assume out of range
wlan0: No STA entry for own AP 00:13:10:a6:40:59
wlan0: No STA entry for own AP 00:13:10:a6:40:59

and it's then dead until I reload the module.

Comment 14 John W. Linville 2007-11-01 13:50:11 UTC
FWIW, I think that is a different problem -- I've looked into it, but not 
found a solution yet.

When you are in that situation, please try 'iwlist wlan0 scan'.  After a few 
seconds, does it reassociate?  If not, please follow-up with 'iwconfig wlan0 
essid XXXXXX' (you know what to do w/ XXXXXX).  Does that cause it to 

Comment 13 and this follow-up might should be a different bug...

Comment 15 Jonathan Underwood 2007-11-04 22:05:44 UTC
I am having the same issue. I have installed F8-RC3 on a Dell XPS M1210 with an
iwl3945 wireless adapter. NetworkManager doesn't see any of the wireless
networks around me, and fails to connect to one when I give it an SSID. 

Running /sbin/iwlist scan gives 
wlan0     Failed to read scan data : Resource temporarily unavailable

I installed the kernels in Comment #12 and still NM doesn't see any wireless
networks or associate. However, /sbin/iwlist scan now gives
wlan0     No scan results

So, a different message, but same end result.

Comment 16 Jonathan Underwood 2007-11-04 22:08:59 UTC
Also, I tried adding the disable_hw_scan=0 option to the loading of iwl3945, but
no change.

Comment 17 Jonathan Underwood 2007-11-04 23:20:54 UTC
Oooh. All my problems go away when adding the option disable_hw_scan=1 to the
module options in combination with the Linville kernels in Comment #12.

Comment 18 Jonathan Underwood 2007-11-05 00:12:36 UTC
I can also confirm that all issues are resolved for me using disable_hw_scan=1

Comment 19 Bill Nottingham 2007-11-05 13:22:20 UTC
(In reply to comment #14)
> FWIW, I think that is a different problem -- I've looked into it, but not 
> found a solution yet.
> When you are in that situation, please try 'iwlist wlan0 scan'.  After a few 
> seconds, does it reassociate?  If not, please follow-up with 'iwconfig wlan0 
> essid XXXXXX' (you know what to do w/ XXXXXX).  Does that cause it to 
> reassociate?

Didn't seem to help. However, I'm using WPA, so that does complicate things.

Comment 20 Bill Nottingham 2007-11-07 16:25:12 UTC
OK, using disable_hw_scan=1, it still randomly disconnects; however, it will
actually reconnect without reloading the module. So that's an improvement.

Comment 21 John W. Linville 2007-11-09 19:44:54 UTC
Please try these kernels:


Do they work better for you?

Comment 22 Erik Pedersen 2008-01-06 18:28:35 UTC
Just installed fedora 8 on a Lenovo T61, choosing to install both gnome and kde.
Wireless worked just fine, but after a yum update I cannot make it work any
more, just like described above. Have tried everything above

Comment 23 John W. Linville 2008-01-07 02:31:25 UTC
What kernel are you using?  FWIW, current F8 kernels work just fine on my T61.

Comment 24 Erik Pedersen 2008-01-07 07:13:46 UTC, and I have added 
options iwl3945 disable_hw_scan=1
to modprobe.conf

It is erratic, it just worked fine a whole evening without me knowing what 
made it work, but now it stopped working again. I tried to turn it off and on  
using the NetworkManager. I succeeded in turning it off, but now I cannot turn 
it on again

Comment 25 Erik Pedersen 2008-01-07 07:39:16 UTC
Just rebooted to, and now it works again. I have no idea what 
is going on, totally erratic. fwiw the asus eee pc standing next to it 
connects with no problems, so there is nothing wrong with thw wireless network

Comment 26 Rui Matos 2008-01-07 10:30:58 UTC
For me it's not so erratic. I just found a couple of steps that always work.
I'll describe:

I have a Dell Latitude D630 with a

0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network
Connection (rev 02)

running kernel-

Trying to use NM to connect to the university network is asking for trouble as
it keeps disassociating and asking for the network's configurations all the time.

I can get a more stable connection using wpa_supplicant and dhclient
directly (after disabling NM) with this config:


but still from time to time the wlan0 interface gets into the NO_CARRIER state.

I found that the first time (after reboot) that I try to connect it will go into
NO_CARRIER. If I then kill wpa_supplicant and dhclient and quickly put them
running again I can get a lasting connection. Nothing of this is needed at home
on a WEP network where NM works fine.

It seems plenty of people were having trouble with both the 3945 and 4945
hardware, even on windows, to the point that the univ.'s network admins asked
that everyone with said hardware downloaded the latest drivers from intel's website.

Comment 27 John W. Linville 2008-01-07 20:08:22 UTC
Please try the kernels here:


Do these work any better or differently?

Comment 28 Erik Pedersen 2008-01-07 22:24:33 UTC
Well so far it does indeed seem to work better. I turned off wireless, and I 
could turn it back on, so yes indeed, so far I say because it has been so 

Comment 29 Erik Pedersen 2008-01-08 07:06:53 UTC
Ok  kernel- so far seems to work for me, thanks. I 
will get back if I run into poroblems, but it has been perfect so far

Comment 30 John W. Linville 2008-01-24 20:19:15 UTC
I'm going to close this on the basis of comment 29...

Comment 31 joel jaeggli 2008-04-17 01:49:25 UTC
I continue to experience this all the way out in

The only thing I can characterize the experience of it as homicidal rage because
you never quite know if your ap is broken or your wireless chipset...

disabling hardware scan does work but still it sure as heck isn't fixed... 

this is a thinkpad t6op 2008cto model with intel 3945

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