Bug 235247 - iwlwifi doesn't associate/loses association regularly
iwlwifi doesn't associate/loses association regularly
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
high Severity medium
: ---
: ---
Assigned To: John W. Linville
Brian Brock
:
: 235139 (view as bug list)
Depends On:
Blocks: FC7Target 237760
  Show dependency treegraph
 
Reported: 2007-04-04 13:55 EDT by Jeremy Katz
Modified: 2009-01-28 12:22 EST (History)
22 users (show)

See Also:
Fixed In Version: 2.6.22.1-27.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-24 09:48:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Symptoms of WEP flakiness (1.06 KB, text/plain)
2007-04-12 02:50 EDT, Bryan O'Sullivan
no flags Details
Symptoms of WEP flakiness, dmesg output (2.68 KB, text/plain)
2007-04-12 02:52 EDT, Bryan O'Sullivan
no flags Details
/var/log/messages of iwlwifi 'failure to associate' (6.92 KB, text/plain)
2007-04-27 10:02 EDT, Tom London
no flags Details
result of "iwlist wlan0 scanning" and /var/log/messages using wireless manager (5.05 KB, application/octet-stream)
2007-05-18 09:03 EDT, Daniel Pugh
no flags Details
/var/log/messages (93.25 KB, text/plain)
2007-05-19 09:04 EDT, Daniel Pugh
no flags Details
NetworkManager / netlink / iwl3945 / ondemand Oops (12.32 KB, text/plain)
2007-05-23 08:34 EDT, Robin Humble
no flags Details
/var/log/messages (6.21 KB, text/plain)
2007-05-24 08:04 EDT, Daniel Pugh
no flags Details
BUG during resume (4.38 KB, text/plain)
2007-06-16 04:51 EDT, Robin Humble
no flags Details

  None (edit)
Description Jeremy Katz 2007-04-04 13:55:39 EDT
iwlwifi doesn't seem to ever want to associate with access points automatically;
setting the access point and frequency manually seems to be able to get things
working but the default case and with NetworkManager does not
Comment 1 John W. Linville 2007-04-10 17:07:34 EDT
James, have you investigate this at all?  FWIW, I recall that Michael Wu had a 
theory about the cause, but I can't remember what it was ATM... :-(
Comment 2 Bryan O'Sullivan 2007-04-10 17:20:43 EDT
BTW, this is a feature that has worked fine with ipw3945 for a while, so it's a
regression relative to that code base.
Comment 3 Tom London 2007-04-11 10:25:37 EDT
With .3056, I can finally associate with non-encrypted access points: I am
running on Thinkpad x60 with Intel 3945.

All works fine with older ipw3945 driver and daemon. Also, I can associate with
GoogleWifi (unencrypted access point) with iwlwifi and NM.

Below is snipped from /var/log/messages:

Apr 11 06:48:33  localhost NetworkManager: <WARN> 
nm_device_802_11_wireless_set_mode(): error setting card eth0 to Infrastructure
mode: Device or resource busy 
Apr 11 06:48:34  localhost NetworkManager: <info>  SWITCH: no current
connection, found better connection 'eth0'. 
Apr 11 06:48:35  localhost dhcdbd: message_handler: message handler not found
under /com/redhat/dhcp/eth0 for sub-path eth0.dbus.get.reason
Apr 11 06:48:36  localhost NetworkManager: <info>  Will activate connection
'eth0/free4all'. 
Apr 11 06:48:36  localhost NetworkManager: <info>  Device eth0 activation
scheduled... 
Apr 11 06:48:37  localhost NetworkManager: <info>  Activation (eth0) started... 
Apr 11 06:48:38  localhost NetworkManager: <info>  Activation (eth0) Stage 1 of
5 (Device Prepare) scheduled... 
Apr 11 06:48:38  localhost kernel: iwlwifi: TODO: Look into long/short preamble
change handling.
Apr 11 06:48:38  localhost NetworkManager: <info>  Activation (eth0) Stage 1 of
5 (Device Prepare) started... 
Apr 11 06:48:39  localhost kernel: iwlwifi: TODO: Look into long/short preamble
change handling.
Apr 11 06:48:39  localhost NetworkManager: <info>  Activation (eth0) Stage 2 of
5 (Device Configure) scheduled... 
Apr 11 06:48:40  localhost kernel: iwlwifi: TODO: Look into long/short preamble
change handling.
Apr 11 06:48:40  localhost NetworkManager: <info>  Activation (eth0) Stage 1 of
5 (Device Prepare) complete. 
Apr 11 06:48:41  localhost kernel: iwlwifi: TODO: Look into long/short preamble
change handling.
Apr 11 06:48:41  localhost NetworkManager: <info>  Activation (eth0) Stage 2 of
5 (Device Configure) starting... 
Apr 11 06:48:41  localhost kernel: iwlwifi: TODO: Look into long/short preamble
change handling.
Apr 11 06:48:41  localhost NetworkManager: <info>  Activation (eth0/wireless):
access point 'free4all' is encrypted, but NO valid key exists.  New key needed. 
Apr 11 06:48:41  localhost kernel: iwlwifi: TODO: Look into long/short preamble
change handling.
Apr 11 06:48:41  localhost NetworkManager: <info>  Activation (eth0) New
wireless user key requested for network 'free4all'. 
Apr 11 06:48:41  localhost kernel: iwlwifi: TODO: Look into long/short preamble
change handling.
Apr 11 06:48:41  localhost NetworkManager: <info>  Activation (eth0) Stage 2 of
5 (Device Configure) complete. 
Apr 11 06:48:41  localhost kernel: iwlwifi: TODO: Look into long/short preamble
change handling.
Apr 11 06:48:42  localhost last message repeated 6 times
Apr 11 06:48:50  localhost NetworkManager: <info>  Activation (eth0) New
wireless user key for network 'free4all' received. 
Apr 11 06:48:50  localhost NetworkManager: <info>  Activation (eth0) Stage 1 of
5 (Device Prepare) scheduled... 
Apr 11 06:48:50  localhost NetworkManager: <info>  Activation (eth0) Stage 1 of
5 (Device Prepare) started... 
Apr 11 06:48:50  localhost NetworkManager: <info>  Activation (eth0) Stage 2 of
5 (Device Configure) scheduled... 
Apr 11 06:48:50  localhost NetworkManager: <info>  Activation (eth0) Stage 1 of
5 (Device Prepare) complete. 
Apr 11 06:48:50  localhost NetworkManager: <info>  Activation (eth0) Stage 2 of
5 (Device Configure) starting... 
Apr 11 06:48:50  localhost NetworkManager: <info>  Activation (eth0/wireless):
access point 'free4all' is encrypted, and a key exists.  No new key needed. 
Apr 11 06:48:51  localhost NetworkManager: <info>  SUP: sending command
'INTERFACE_ADD eth0             wext    /var/run/wpa_supplicant ' 
Apr 11 06:48:51  localhost kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Apr 11 06:48:51  localhost NetworkManager: <info>  SUP: response was 'OK' 
Apr 11 06:48:51  localhost NetworkManager: <info>  SUP: sending command 'AP_SCAN 1' 
Apr 11 06:48:51  localhost NetworkManager: <info>  SUP: response was 'OK' 
Apr 11 06:48:51  localhost NetworkManager: <info>  SUP: sending command
'ADD_NETWORK' 
Apr 11 06:48:51  localhost NetworkManager: <info>  SUP: response was '0' 
Apr 11 06:48:51  localhost NetworkManager: <info>  SUP: sending command
'SET_NETWORK 0 ssid 6672656534616c6c' 
Apr 11 06:48:51  localhost NetworkManager: <info>  SUP: response was 'OK' 
Apr 11 06:48:51  localhost NetworkManager: <info>  SUP: sending command
'SET_NETWORK 0 key_mgmt NONE' 
Apr 11 06:48:51  localhost NetworkManager: <info>  SUP: response was 'OK' 
Apr 11 06:48:51  localhost NetworkManager: <info>  SUP: sending command
'SET_NETWORK 0 wep_key0 <key>' 
Apr 11 06:48:51  localhost NetworkManager: <info>  SUP: response was 'OK' 
Apr 11 06:48:51  localhost NetworkManager: <info>  SUP: sending command
'SET_NETWORK 0 wep_tx_keyidx 0' 
Apr 11 06:48:51  localhost NetworkManager: <info>  SUP: response was 'OK' 
Apr 11 06:48:51  localhost NetworkManager: <info>  SUP: sending command
'ENABLE_NETWORK 0' 
Apr 11 06:48:51  localhost NetworkManager: <info>  SUP: response was 'OK' 
Apr 11 06:48:51  localhost NetworkManager: <info>  Activation (eth0) Stage 2 of
5 (Device Configure) complete. 
Apr 11 06:48:51  localhost kernel: iwlwifi: TODO: Look into long/short preamble
change handling.
Apr 11 06:48:52  localhost last message repeated 6 times
Apr 11 06:48:52  localhost avahi-daemon[2956]: Joining mDNS multicast group on
interface eth0.IPv6 with address fe80::213:2ff:fe6f:fc3c.
Apr 11 06:48:52  localhost avahi-daemon[2956]: New relevant interface eth0.IPv6
for mDNS.
Apr 11 06:48:52  localhost avahi-daemon[2956]: Registering new address record
for fe80::213:2ff:fe6f:fc3c on eth0.*.
Apr 11 06:48:52  localhost kernel: iwlwifi: TODO: Look into long/short preamble
change handling.
Apr 11 06:48:54  localhost last message repeated 6 times
Apr 11 06:48:54  localhost wpa_supplicant[3572]: Trying to associate with
00:12:17:46:42:51 (SSID='free4all' freq=2457 MHz) 
Apr 11 06:48:54  localhost kernel: hwcrypto disabled!
Apr 11 06:48:54  localhost kernel: iwlwifi: TODO: Look into long/short preamble
change handling.
Apr 11 06:48:54  localhost wpa_supplicant[3572]: Association request to the
driver failed 
Apr 11 06:48:54  localhost kernel: iwlwifi: Network RSSI: -40
Apr 11 06:48:55  localhost kernel: iwlwifi: REPLY_ADD_STA failed
Apr 11 06:48:55  localhost kernel: iwlwifi: Network RSSI: -40
Apr 11 06:48:55  localhost kernel: iwlwifi: REPLY_ADD_STA failed
Apr 11 06:48:55  localhost kernel: iwlwifi: Network RSSI: -38
Apr 11 06:48:59  localhost NetworkManager: <info>  Old device 'eth0' activating,
won't change. 
Apr 11 06:49:09  localhost wpa_supplicant[3572]: Authentication with
00:00:00:00:00:00 timed out. 
Comment 4 Bryan O'Sullivan 2007-04-11 13:55:03 EDT
Tom, please don't paste wads of output into the bug; add them as attachments
instead.

I'm also running the 3054 kernel on an X60 with a 3945abg card inside, and I
can't associate with any access points, either encrypted or unencrypted.
Comment 5 Jeremy Katz 2007-04-11 17:03:41 EDT
Bryan -- 3056 seems to be a turning point for a lot of people.  And for me too.

Tom -- what access points are you connecting to?
Comment 6 Bryan O'Sullivan 2007-04-11 17:06:50 EDT
Jeremy, I'm glad it's working for you.  It's not much of an inconvenience for me
that it's not working, because I can fall back to ipw3945.  But it sure isn't
working :-)
Comment 7 Jeremy Katz 2007-04-11 17:14:41 EDT
(In reply to comment #6)
> Jeremy, I'm glad it's working for you.  It's not much of an inconvenience for me
> that it's not working, because I can fall back to ipw3945.  But it sure isn't
> working :-)

With 3056 or 3054?
Comment 8 Bryan O'Sullivan 2007-04-11 17:26:11 EDT
Oops, I misread 3054 for 3056.  What an idiot :-(

I just installed 3056 (yum doesn't believe in its existence yet, so I had to do
it by hand).  And it associated with an unencrypted AP on the first try!  Nice.
 I've not had a chance to try with WEP yet.
Comment 9 Tom London 2007-04-11 17:40:25 EDT
WEP fails with a Linksys WRT54G.

WPA fails with Cisco APs.  Tracking down model #s.....

Unencrypted works on GoogleWiFi.  Believe they use Tropos.
Comment 10 Bryan O'Sullivan 2007-04-12 02:40:40 EDT
*** Bug 235139 has been marked as a duplicate of this bug. ***
Comment 11 Bryan O'Sullivan 2007-04-12 02:47:18 EDT
I have WEP "working" with a WRT54GL running OpenWRT.  However, the packet loss
rate is 15%.  Every minute or two, the card loses its association.  I'll post
some sample output from logs and dmesg.
Comment 12 Bryan O'Sullivan 2007-04-12 02:50:06 EDT
Created attachment 152360 [details]
Symptoms of WEP flakiness

I've added a snippet of /var/log/messages output that shows the symptoms of the
WEP flakiness problem.
Comment 13 Bryan O'Sullivan 2007-04-12 02:52:34 EDT
Created attachment 152361 [details]
Symptoms of WEP flakiness, dmesg output

Here's the raw dmesg output that corresponds to the stuff from
/var/log/messages, again relating to the problem of association flapping with
WEP.
Comment 14 Bryan O'Sullivan 2007-04-12 03:02:52 EDT
Bumping the priority on this, due to its wide impact.  Please feel free to push
the priority back down if you disagree with me.
Comment 15 Bryan O'Sullivan 2007-04-18 00:31:09 EDT
Tried the 3069 and 3079 kernels, both of which regress in stability relative to
3056.  3079 associates for about 30 seconds, then printk's an "out of Tx space"
error message that only goes to the console and dmesg.  Unfortunately, I forgot
to capture it before rebooting.  Can reproduce if needed.
Comment 16 Jeremy Katz 2007-04-19 17:12:34 EDT
(In reply to comment #15)
> Tried the 3069 and 3079 kernels, both of which regress in stability relative to
> 3056.  3079 associates for about 30 seconds, then printk's an "out of Tx space"
> error message that only goes to the console and dmesg.  Unfortunately, I forgot
> to capture it before rebooting.  Can reproduce if needed.

Going to track the oops + "out of Tx space" thing as a separate bug (bug 237182)
and use this one to track the frequent drops when things were associating.
Comment 17 Tom London 2007-04-26 14:24:20 EDT
(In reply to comment #9)
> WEP fails with a Linksys WRT54G.
> 
> WPA fails with Cisco APs.  Tracking down model #s.....
> 
> Unencrypted works on GoogleWiFi.  Believe they use Tropos.

I'm still having this exact problem with 2.6.20-1.3104.fc7PAE: I can
associate/use with unencrypted networks, but cannot associate with any tested
WEP or WPA network. NetworkManager reports all scanned networks at 100%, etc.

This is with Intel 3945 on Thinkpad X60.

Release notes for T4 appear to indicate iwlwifi is working...?

Only way I get Wifi is to install old ipw3945 module/userspace daemon.
Comment 18 Tom London 2007-04-27 10:02:50 EDT
Created attachment 153622 [details]
/var/log/messages of iwlwifi 'failure to associate'

.3116: iwlwifi remains borked for me.

Attached is snippet from /var/log/messages of attempt to associate using WPA
with Linksys WRT54G with NetworkManager on Thinkpad X60, but this fails with
other (encrypted) access points as well.

I'm trying to use NetworkManager..... 

Continue to get lots of 'long/short preamble' and 'REPLY_ADD_STA failed'
messages.

[This all works fine if I compile/install the older ipw3945 driver/user
daemon.]

Is this a known issue? Is there some other testing/probing I can do?
Comment 19 Bryan O'Sullivan 2007-05-02 00:18:39 EDT
3125 seems better.
Comment 20 John W. Linville 2007-05-02 16:27:05 EDT
Tom/Jeremy, are you still seeing this on the 3122 or later kernels?
Comment 21 Tom London 2007-05-02 16:33:00 EDT
I'm running .3125 and can associate properly only if I kill off NetworkManager
and run wpa_supplicant/dhclient manually.

System is quite stable if I run that way.

If I start NM something with its regular scans cause the association to drop.  I
can reconnect only after rebooting. (Haven't tried rmmod'ing iwlwifi......)
Comment 22 Gary Case 2007-05-03 09:36:37 EDT
I'm seeing this wireless problem too on the .3116 kernel. I can associate to my
Linksys WRV200 using WPA2 and NetworkManager, but the connection only stays live
for an extremely short period of time, then it dies. NetworkManager says it's
still associated, but it's not. The laptop is a Thinkpad T60p with 3945 wireless
running F7 with the latest code from the public devel server. 
Comment 23 Thomas J. Baker 2007-05-08 14:10:00 EDT
Similar experience with the 3142 kernel. Important dmesg seems to be

iwl3945: Error not a valid ipw_rxon_assoc_cmd field values
iwl3945: Invalid RXON configuration.  Not committing.

I can post more if it helps.
Comment 24 Robin Humble 2007-05-17 08:22:24 EDT
with DaveJ's 3163 kernel and the new v2.14.3 firmware just released today-ish on
http://intellinuxwireless.org/?p=iwlwifi the iwl3945 on my sparkly new x86_64
dell xps 1210 seems to connect and work ok.

all the other fedora7-test4 combinations that I tried (kernel 3149/3163 with
firmware from the iwlwifi-firmware-2.14.1 rpm, or kernel 3149 with new ucode)
didn't associate. I'm connecting to a WEP 128 billion 7404vgpm if that matters.

HTH. let me know if you'd like more info or me to try something.
Comment 25 Daniel Pugh 2007-05-18 09:02:00 EDT
still not working for me (lenovo t60 laptop) 2.6.21-1.3167 kernel and all latest
updates.

works when standing right next to access point only. logs attached
Comment 26 Daniel Pugh 2007-05-18 09:03:27 EDT
Created attachment 154993 [details]
result of "iwlist wlan0 scanning" and /var/log/messages using wireless manager
Comment 27 Tom London 2007-05-18 09:23:57 EDT
Have same 'only works when 3 feet or less from AP' issue.... 

Running .3163, 2.14.3 firmware on Thinkpad X60.
Comment 28 Daniel Pugh 2007-05-18 15:00:10 EDT
more success (hopefully)   Also manually installed the latest microcode
(/lib/firmware)  3 times out of 3 wireless worked. 3rd time it lost connection
after a while, but removing and reinserting module (and deleting all settings
from network manager allowed me to manually reconnect - writing this now over
wireless.  

http://intellinuxwireless.org/iwlwifi/downloads/iwlwifi-3945-ucode-2.14.3.tgz
not sure if that helped - (was very confused that initial install of test 4
didnt by default install microcode rpm - lots of problems till that point i
installed it as device wlan0 didnt exist at all).  

Comment 29 Daniel Pugh 2007-05-19 07:49:54 EDT
2.6.21-1.3174 installed - scanning working fine - seems much more stable. 
Network manager breaks everything, but thats because it doesn't seem to support
the newer iwlwifi driver (when you run it it doesnt find wlan0 device, but tries
to force wmaster0 which is older version of driver).

Comment 30 Daniel Pugh 2007-05-19 09:01:13 EDT
spoke too soon. log attached
Comment 31 Daniel Pugh 2007-05-19 09:04:20 EDT
Created attachment 155046 [details]
/var/log/messages
Comment 32 Robin Humble 2007-05-23 08:26:04 EDT
running latests 2.6.21-1.3175.fc7 iwlwifi-firmware-2.14.3-2.

it connects reliably, but disconnects pretty regularly (especially with a bit of
network traffic, sometimes for no reason) with extreme prejudice requiring a
complete power-button shutdown. usually the last sensible thing seen is
  kernel: iwl3945: REPLY_ADD_STA failed

oops'd once - attached.
Comment 33 Robin Humble 2007-05-23 08:34:07 EDT
Created attachment 155233 [details]
NetworkManager / netlink / iwl3945 / ondemand Oops
Comment 34 Daniel Pugh 2007-05-24 08:02:46 EDT
some progress (kernel .3189)
Network manager now sees correct devices. 
open network now connects and is basically stable for long periods of time 1-2
hrs (although still some random disconnections)

not working:
using cisco 1100 access point with wpa1/tkip :
failed to find access point initially.  removed module (which seemed to
automatically re-insert!) allowed it to scan network and find the access point. 
correctly identifies encryption/authentication level and brings up password box
attempting to associate fails with same errors as previously.
i think this links to iwlwifi/wext wpa2 bug in bugzilla for iwlwifi

log attached
Comment 35 Daniel Pugh 2007-05-24 08:04:45 EDT
Created attachment 155334 [details]
/var/log/messages
Comment 36 Robin Humble 2007-05-29 09:32:18 EDT
it seems better for me also. now it mostly associates ok. it disconnects about
once an hour or two - especially when there are other laptops in the vicinity,
but usually reconnects automatically or after prompting networkmanager - after
30s or so, or failing that, sometimes with a rmmod/modprobe iwl3945.
it's much better than it was in that it hasn't hung the machine and forced a
power-button reset with kernel 3194. so kinda less than normal linux standard
wireless reliability, but it doesn't seem dangerous any more :-)
Comment 37 Will Woods 2007-05-29 10:10:29 EDT
No longer messing up people's systems, hooray - moving to FC7Tracker
Comment 38 Marc Wiriadisastra 2007-06-01 01:10:34 EDT
I'm having the exact same situation with all the details posted with an 
install of fedora 7.  Stock standard didn't work.  I've had to post this at 
Uni cause if I reboot it connects but then any sort of traffic it disconnects 
and generates the errors in the first post.

Comment 39 Hans de Goede 2007-06-10 07:50:42 EDT
There is an F7 kernel-update candidate available here:
http://people.redhat.com/davej/kernels/Fedora/fc7/RPMS.kernel/

Which amongst other things contains various fixes to the iwl3945 driver. Please
try this kernel and report back how it works for you.

Always be carefull when testing new kernels. Use rpm -ivh to install the new
kernel besides your current one so that you can always boot back into the old
kernel.
Comment 40 Tim Niemueller 2007-06-10 08:37:51 EDT
With 2.6.21-1.3226.fc7 I can associate with a La Fonera and get an IP, but no
traffic would go through. I once got traffic through and even the connection
didn't get lost for a few hours, but it seems this was just a lucky day. Also no
luck with a WPA connection. It won't even associate again after a rmmod/modprobe
iwl3945 :-/
Comment 41 Marc Wiriadisastra 2007-06-10 21:27:16 EDT
The new kernel generates this error for me constantly rendering my computer very
slow.  It just keeps generating this same log output.

Jun 11 09:00:37 localhost kernel: iwl3945: Can't stop Rx DMA.
Jun 11 09:00:37 localhost kernel: iwl3945: Grabbing access while already held at
line 825.
Jun 11 09:00:37 localhost kernel: iwl3945: Microcode SW error detected. 
Restarting 0x82000000.
Jun 11 09:00:37 localhost kernel: iwl3945: Error Reply type 0x0000003A cmd
REPLY_RXON_ASSOC (0x11) seq 0x0402 ser 0x00000000
Jun 11 09:00:37 localhost kernel: iwl3945: Error setting RXON_ASSOC
configuration (-5).
Jun 11 09:00:37 localhost kernel: iwl3945: Error sending REPLY_TX_PWR_TABLE_CMD:
time out after 500ms.
Jun 11 09:00:37 localhost kernel: iwl3945: ipw going down 
Comment 42 Marc Wiriadisastra 2007-06-11 18:58:14 EDT
It attempts to work and does if I'm closer to the access point.  However the
issue is getting an equivalent signal strength.  I'm on 75% with the ipw3945
driver and with the iwl3945 driver I'm on 25%.
Comment 43 Robin Humble 2007-06-16 04:47:12 EDT
with kernels 3226 and 3228 an attempt to rmmod the iwl3945 after a
suspend/resume hangs the machine. ie. rmmod hangs, ifconfig hangs, iwconfig
hangs and pretty soon there's a dozen processes in D state, it won't reboot, and
I have to lean on the power button to turn off the machine. A BUG during resume
once is attached.

this hang doesn't happen with kernel 3194.

as rmmod/modprobe'ing the iwl3945 is currently a necessary part of
NetworkManager Applet getting a wireless connection after a suspend/resume, then
I'm sticking with the 3194 kernel.

hardware is a Dell m1210 laptop, x86_64. 
Comment 44 Robin Humble 2007-06-16 04:51:36 EDT
Created attachment 157182 [details]
BUG during resume
Comment 45 John W. Linville 2007-07-13 11:52:52 EDT
Please try the kernels from here:

   http://koji.fedoraproject.org/koji/buildinfo?buildID=10941

Do they work any better for you?
Comment 46 Thomas J. Baker 2007-07-13 15:50:11 EDT
The included newer driver needs newer firmware available from
intellinuxwireless.org. I'm using the 2.6.22.1-20 version and I still am getting
many of these:

iwl3945: REPLY_ADD_STA failed

in dmesg. I'll be able to better test wireless this weekend.
Comment 47 Uwe Kubosch 2007-07-15 17:22:14 EDT
I am also still getting "REPLY_ADD_STA failed" with kernel 2.6.22-8.fc7
downloaded from the given link.  The wireless netework interface now shuts down
within seconds after connect, while it lasted many minutes with kernel 3194 and
3228.

I am also getting lines like this:

"NetworkManager: <WARN>  request_and_convert_scan_results(): card took too much
time scanning.  Get a better one. "

I don't know if this is related.

I can provide more logs if needed.
Comment 48 Marc Wiriadisastra 2007-07-16 04:26:12 EDT
It doesn't even find my wireless card which is a concern.  The error message I
receive is as follows.

Jul 16 16:00:02 localhost system-config-network[2859]: Error: Unknown not in
DeviceFactory!
Jul 16 16:00:04 localhost NetworkManager: <info>  Error getting killswitch
power: org.freedesktop.Hal.Device.KillSwitch.NotSupported - Access type not
supported
Comment 49 John W. Linville 2007-07-16 10:12:26 EDT
I think you need to update your firmware.  It is available here:

http://intellinuxwireless.org/iwlwifi/downloads/iwlwifi-3945-ucode-2.14.4.tgz

You will need to copy the firmware files into /lib/firmware.  Does that work 
better for you with the 2.6.22-8 kernel?
Comment 50 Robin Humble 2007-07-16 10:44:57 EDT
2.6.22-8.fc7 doesn't even boot for me on x86_64 dell m1210.

however 2.6.22.1-21.fc7 boots and iwl3945 works a little better than before -
the module doesn't always need rmmod/modprobe after a suspend/resume any more -
twice it's reconnected on it's own successfully - yay!
and although I have had to do a rmmod to get re-associated once out of the 3
times I've tried suspend/resume, this time the rmmod didn't seem to halt the
whole kernel (previously characters were lost, whole machine froze for a few
seconds) which is also an improvement.

2.6.22.1-21.fc7 needs the new firmware too.

signal strength seems roughly the same as kernel 3194 and doesn't seem bad to
me. I can't test behaviour with other network traffic (which previously was a
problem) as there is none here at the moment. I still get the "iwl3945:
REPLY_ADD_STA failed" messages regularly.
Comment 51 Marc Wiriadisastra 2007-07-16 11:29:22 EDT
Magnificent work.  I put the new firmware in as recommended.  It works
perfectly.  I tried shifting my laptop to where it usually doesn't have the same
connections strength and it's brilliant.

Jul 16 23:26:39 localhost avahi-daemon[2339]: New relevant interface wlan0.IPv4
for mDNS.
Jul 16 23:26:39 localhost avahi-daemon[2339]: Registering new address record for
192.168.1.235 on wlan0.IPv4.
Jul 16 23:26:40 localhost NetworkManager: <info>  Activation (wlan0) Finish
handler scheduled. 
Jul 16 23:26:40 localhost NetworkManager: <info>  Activation (wlan0) Stage 5 of
5 (IP Configure Commit) complete. 
Jul 16 23:26:40 localhost NetworkManager: <info>  Activation (wlan0) successful,
device activated. 
Jul 16 23:26:40 localhost kernel: wlan0: duplicate address detected!
Jul 16 23:26:42 localhost NetworkManager: <info>  Error getting killswitch
power: org.freedesktop.Hal.Device.KillSwitch.NotSupported - Access type not
supported 

I'm still getting that org.freedesktop output but apart from that it's perfect.

I for one am sticking to this kernel.  Thanks so much :)
Comment 52 Marc Wiriadisastra 2007-07-16 12:23:56 EDT
Sadly I'm spoke to soon.  The improvements are there and I had a really good
connection but putting a strain on the data seemed to cause issues.  Rebooting
helped but there is no output in the log files.

Nearly there from the looks of it.
Comment 53 Uwe Kubosch 2007-07-23 10:43:35 EDT
I can report a stable network using kernel 2.6.22.1-27.fc7.

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