Bug 519154 - iwlagn: Microcode SW error detected.
Summary: iwlagn: Microcode SW error detected.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 12
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Stanislaw Gruszka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 529223 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-25 12:46 UTC by Scott Glaser
Modified: 2010-12-05 06:33 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-12-05 06:33:45 UTC


Attachments (Terms of Use)

Description Scott Glaser 2009-08-25 12:46:28 UTC
Description of problem:
During normal network operations wireless device Intel Corporation PRO/Wireless 4965 AG randomly disconnects causing loss of network connectivity.  In researching this issue the message "kernel: iwlagn: Microcode SW error detected.  Restarting 0x82000000." was discovered in /var/log/messages.  During troubleshooting it was discovered that this only occurred with kernels:

kernel-PAE-2.6.29.6-217.2.7.fc11.i686
kernel-PAE-2.6.29.6-217.2.8.fc11.i686

Once I had reverted back to kernel-PAE-2.6.29.6-217.2.3.fc11.i686, the issue no longer occured.

Version-Release number of selected component (if applicable):

Kernel Impacted:
kernel-PAE-2.6.29.6-217.2.7.fc11.i686
kernel-PAE-2.6.29.6-217.2.8.fc11.i686

Kernel Firmware:
kernel-firmware-2.6.29.6-217.2.8.fc11.noarch

Intel Microcode:
iwl5000-firmware-8.24.2.12-1.fc11.noarch
iwl4965-firmware-228.61.2.24-1.fc11.noarch
iwl3945-firmware-15.32.2.9-1.fc11.noarch


How reproducible:
This issue on my system appears to be extremely reproducible, within 3 hours of restarting the network, the message is displayed and the network will be disconnected till I re-associate with the Access Point.  It does not appear similar to the other Intel microcode bugs as the network load does not appear to be a cause of this issue, it occurs whether the network load is large or small.

Steps to Reproduce:
1. Boot Fedora 11 with an Intel Corporation PRO/Wireless 4965 AG or AGN [Kedron] Network Connection (rev 61) network device.

2. Enable the wireless and connect utilizing WEP or WPA.

3. Utilize the network device with IRC, E-mail, and surfing with Firefox and within 3 hours the wireless device will disconnect, when utilizing kernel-PAE-2.6.29.6-217.2.7.fc11.i686 or kernel-PAE-2.6.29.6-217.2.8.fc11.i686.
  
Actual results:
wlan0 disconnects and the following messages are displayed in /var/log/messages:
Aug 24 07:57:17 localhost kernel: iwlagn: Microcode SW error detected.  Restarting 0x82000000.
Aug 24 07:57:18 localhost kernel: Registered led device: iwl-phy0:radio
Aug 24 07:57:18 localhost kernel: Registered led device: iwl-phy0:assoc
Aug 24 07:57:18 localhost kernel: Registered led device: iwl-phy0:RX
Aug 24 07:57:18 localhost kernel: Registered led device: iwl-phy0:TX


Expected results:
Expect the same sort of network stability that was present in kernel-PAE-2.6.29.6-217.2.3.fc11.i686, with this kernel no issues are/were present.


Additional info:
Messages found in var/log/messages at the time the network fails:
Aug 24 07:57:17 localhost kernel: iwlagn: Microcode SW error detected.  Restarting 0x82000000.
Aug 24 07:57:18 localhost kernel: Registered led device: iwl-phy0:radio
Aug 24 07:57:18 localhost kernel: Registered led device: iwl-phy0:assoc
Aug 24 07:57:18 localhost kernel: Registered led device: iwl-phy0:RX
Aug 24 07:57:18 localhost kernel: Registered led device: iwl-phy0:TX

Smolt ID:
http://www.smolts.org/client/show/pub_c51b9c0c-00e4-48bb-9b10-730a86c8cae9

Comment 1 John W. Linville 2009-08-25 15:01:37 UTC
You are able to reconnect without reloading the iwlagn module, correct?

Are you using NetworkManager?  If not, are you using wpa_supplicant?  Either of those should reconnect automatically.

Have you tried a 2.6.30-based kernel?

Comment 2 Scott Glaser 2009-08-25 15:34:40 UTC
John,

Yes I am able to reconnect without reloading the iwlagn module.

I am using NetworkManager, and no it does not automatically reconnect, it sits in a scanning state till I re-select my Access Point.

No I have not tried the 2.6.30 kernel as of yet, I will try those later this evening and see if there is any difference.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 3 Scott Glaser 2009-08-28 11:42:22 UTC
John,

I have tried kernel-PAE-2.6.30.5-32.fc11.i686 with no change in status the same messages are present:

Aug 28 04:01:33 localhost kernel: iwlagn 0000:02:00.0: Microcode SW error detected.  Restarting 0x82000000.
Aug 28 04:01:33 localhost kernel: Registered led device: iwl-phy0::radio
Aug 28 04:01:33 localhost kernel: Registered led device: iwl-phy0::assoc
Aug 28 04:01:33 localhost kernel: Registered led device: iwl-phy0::RX
Aug 28 04:01:33 localhost kernel: Registered led device: iwl-phy0::TX

There is nothing present that indicates the pending issue, only standard messages.  Not sure which direction to go with this, I also noticed it does occur with kernel-PAE-2.6.29.6-217.2.3.fc11.i686, just it does not seem as often as it does with the newer kernels.  I will check to see that the card is seated correctly and that the machine does not need to be cleaned to eliminate any possibility of overheating causing the issue.  

I have seen other bugs for this in the past where they reference it only occurring under heavy network load but that is not the case here.  It appears to happen randomly sometimes under load, sometimes when the machine is just idling.

Do you have any other things that you would like me to check or try?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 4 Scott Glaser 2009-08-31 13:39:17 UTC
John,

After checking the machine I did not find any loose connections with the card or cabling.  The machine is rather clean so it does not appear to be an overheating issue.  I also ran the machine in Vista for 3 days without loosing connection once, so I am almost positive this is indeed a fedora 11 specific issue.  I ran F10 prior to this and had not issues what so ever with the wireless.

Comment 5 Marek Mahut 2009-09-01 16:26:34 UTC
I just had the same problem, however I had to remove and load iwlagn module again (or I just did not wait so long to have it back).

kernel-2.6.29.6-217.2.16.fc11.x86_64

Sep  1 18:18:17 localhost kernel: iwlagn: Microcode SW error detected.  Restarting 0x82000000.
Sep  1 18:18:17 localhost kernel: Registered led device: iwl-phy0:radio
Sep  1 18:18:17 localhost kernel: Registered led device: iwl-phy0:assoc
Sep  1 18:18:17 localhost kernel: Registered led device: iwl-phy0:RX
Sep  1 18:18:17 localhost kernel: Registered led device: iwl-phy0:TX

http://www.smolts.org/client/show/pub_e4cd1efc-480e-4417-b15a-f5c04d001513

Comment 6 Christian V R Lopes 2009-09-03 03:01:53 UTC
I also have the same problem, here my log

Sep  2 23:40:55 merlin kernel: iwlagn: Microcode SW error detected.  Restarting 0x82000000.
Sep  2 23:40:55 merlin kernel: Registered led device: iwl-phy0:radio
Sep  2 23:40:55 merlin kernel: Registered led device: iwl-phy0:assoc
Sep  2 23:40:55 merlin kernel: Registered led device: iwl-phy0:RX
Sep  2 23:40:55 merlin kernel: Registered led device: iwl-phy0:TX

kernel-2.6.29.6-217.2.16.fc11.x86_64

fully updated F11 connecting via NetworkManager on Wireless G + WPA+PSK .

Sep  2 23:53:39 merlin NetworkManager: <info>  Activation (wlan0) starting connection 'Auto gentelegal2'
Sep  2 23:53:39 merlin NetworkManager: <info>  (wlan0): device state change: 3 -> 4 (reason 0)
Sep  2 23:53:39 merlin NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Sep  2 23:53:39 merlin NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
Sep  2 23:53:39 merlin NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
Sep  2 23:53:39 merlin NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
Sep  2 23:53:39 merlin NetworkManager: <info>  (wlan0): supplicant connection state:  completed -> disconnected
Sep  2 23:53:39 merlin NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
Sep  2 23:53:39 merlin NetworkManager: <info>  (wlan0): device state change: 4 -> 5 (reason 0)
Sep  2 23:53:39 merlin NetworkManager: <info>  Activation (wlan0/wireless): connection 'Auto gentelegal2' has security, and secrets exist.  No new secrets needed.
Sep  2 23:53:39 merlin NetworkManager: <info>  Config: added 'ssid' value 'gentelegal2'
Sep  2 23:53:39 merlin NetworkManager: <info>  Config: added 'scan_ssid' value '1'
Sep  2 23:53:39 merlin NetworkManager: <info>  Config: added 'key_mgmt' value 'WPA-PSK'
Sep  2 23:53:39 merlin NetworkManager: <info>  Config: added 'psk' value '<omitted>'
Sep  2 23:53:39 merlin NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
Sep  2 23:53:39 merlin NetworkManager: <info>  Config: set interface ap_scan to 1
Sep  2 23:53:39 merlin NetworkManager: <info>  (wlan0): supplicant connection state:  disconnected -> scanning
Sep  2 23:53:41 merlin NetworkManager: <info>  (wlan0): supplicant connection state:  scanning -> associating
Sep  2 23:53:41 merlin NetworkManager: <info>  (wlan0): supplicant connection state:  associating -> associated
Sep  2 23:53:41 merlin NetworkManager: <info>  (wlan0): supplicant connection state:  associated -> 4-way handshake
Sep  2 23:53:41 merlin NetworkManager: <info>  (wlan0): supplicant connection state:  4-way handshake -> group handshake
Sep  2 23:53:41 merlin NetworkManager: <info>  (wlan0): supplicant connection state:  group handshake -> completed
Sep  2 23:53:41 merlin NetworkManager: <info>  Activation (wlan0/wireless) Stage 2 of 5 (Device Configure) successful.  Connected to wireless network 'gentelegal2'.

Comment 7 Dinesh Joshi 2009-09-10 16:33:14 UTC
I can confirm this issue exists. Here are my details:

Kernel: Linux linuxbox 2.6.30.5-43.fc11.x86_64 #1 SMP Thu Aug 27 21:39:52 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

firmware: iwl4965-firmware-228.61.2.24-1.fc11.noarch

The system is updated. Please mark this bug has CRITICAL as this wireless adapter is the most popular one out there and its hurting long time Linux users like myself.

Comment 8 Stanislaw Gruszka 2009-09-11 15:05:20 UTC
Bug is reported upstream and resolved yet: 

http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2052

It seems to be a firmware bug. Could some one confirm or deny that using older firmware helps. Previous firmware releases can be downloaded as tarball from:  

http://intellinuxwireless.org/?n=downloads&f=ucodes_4965

However I not fully convince this is only firmware problem. Perhaps we can have bug in driver too, where it can not properly recover after firmware reset.

Comment 9 Stanislaw Gruszka 2009-09-11 15:07:24 UTC
(In reply to comment #8)
> Bug is reported upstream and resolved yet: 
                               ^^^^^^^^
Ee, NOT resolved.

Comment 10 Dinesh Joshi 2009-09-11 15:43:39 UTC
The issue is *not* resolved certainly. There is a workaround though. Passing swcrypto=1 to the iwlagn module seems to prevent it.

Comment 11 Scott Glaser 2009-09-12 01:21:43 UTC
For those not in the know on how to use the fix in comment 10, do the following as root:

echo options iwlagn swcrypto=1 >> /etc/modprobe.d/options

This appears to have stopped the disconnects for me.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 12 Stanislaw Gruszka 2009-10-19 14:16:36 UTC
*** Bug 529223 has been marked as a duplicate of this bug. ***

Comment 13 william 2009-10-21 22:32:03 UTC
Same thing here...

Linux lucifer 2.6.30.8-64.fc11.x86_64 #1 SMP Fri Sep 25 04:43:32 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

kernel-firmware-2.6.30.8-64.fc11.noarch
kernel-2.6.30.8-64.fc11.x86_64
iwl5000-firmware-8.24.2.12-1.fc11.noarch
iwl4965-firmware-228.61.2.24-1.fc11.noarch
iwl3945-firmware-15.32.2.9-1.fc11.noarch

The most notable symptom I felt was when I "overload" the interface like rapidshare downloads or Firefox restoring lots of tabs simultaneously.

Trying the workaround...

Comment 14 Ismael Olea 2009-11-04 15:55:15 UTC
Same here:

kernel-2.6.30.9-90.fc11.i586
kernel-firmware-2.6.30.9-90.fc11.noarch
iwl4965-firmware-228.61.2.24-1.fc11.noarch

Linux lisergia.olea.org 2.6.30.9-90.fc11.i586 #1 SMP Sat Oct 17 11:09:52 EDT 2009 i686 i686 i386 GNU/Linux

# lshw -vv

03:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN
[Kedron] Network Connection (rev 61)
    Subsystem: Intel Corporation Lenovo ThinkPad T61
    Physical Slot: 3
    Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
    Latency: 0, Cache Line Size: 64 bytes
    Interrupt: pin A routed to IRQ 29
    Region 0: Memory at f7f00000 (64-bit, non-prefetchable) [size=8K]
    Capabilities: [c8] Power Management version 3
        Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
        Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
    Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Address: 00000000fee0300c  Data: 418a
    Capabilities: [e0] Express (v1) Endpoint, MSI 00
        DevCap:    MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1
unlimited
            ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
        DevCtl:    Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
            RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
            MaxPayload 128 bytes, MaxReadReq 128 bytes
        DevSta:    CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
        LnkCap:    Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0
<128ns, L1 <64us
            ClockPM+ Surprise- LLActRep- BwNot-
        LnkCtl:    ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain-
CommClk+
            ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
        LnkSta:    Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
    Capabilities: [100] Advanced Error Reporting
        UESta:    DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
        UEMsk:    DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
        UESvrt:    DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
MalfTLP+ ECRC- UnsupReq- ACSViol-
        CESta:    RxErr+ BadTLP+ BadDLLP- Rollover- Timeout- NonFatalErr+
        CEMsk:    RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
        AERCap:    First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
    Capabilities: [140] Device Serial Number 00-1f-3b-ff-ff-25-c7-85
    Kernel driver in use: iwlagn
    Kernel modules: iwlagn

Comment 15 Ismael Olea 2009-11-10 19:25:45 UTC
I've opened a bug at the Intellinux bugzilla: http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2111

Maybe you'd be interested on testing and contributing your reports.

Comment 16 Scott Glaser 2009-11-10 22:35:53 UTC
(In reply to comment #15)
> I've opened a bug at the Intellinux bugzilla:
> http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2111
> 
> Maybe you'd be interested on testing and contributing your reports.  

The actual bug that should be referenced is listed in comment #8 and the workaround is listed in comment #11

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 17 rgb 2009-11-12 11:54:46 UTC
I too have been plagued by this bug since I upgraded to F11, and was eagerly awaiting F12 today in hopes that it would go away.  However, since installing F12 on day one may not be the best idea EITHER, I am trying the workaround.

However, an observation (in case it doesn't go away).  I use my laptop in many locations.  The five-to-fifty minute random disconnect occurs always at some locations (home, for example) and never at others (at Duke, for example).  I've tested this quite carefully, as I thought it might be a hardware issue and I've got a full service contract on my Dell.

This leads me to ask -- could this be an issue only with some WAPs?  I have a netgear upstairs.  The problem persisted after I swapped in another netgear.  Duke uses only Cisco.  Is the bug netgear specific, or does it not happen for some WAPs but for others?  If it is a netgear/F11 issue, it might well persist into F12 as it would be "invisible" to anyone not identically equipped.

rgb

Comment 18 Stanislaw Gruszka 2009-11-12 13:51:12 UTC
(In reply to comment #17)
> I too have been plagued by this bug since I upgraded to F11, and was eagerly
> awaiting F12 today in hopes that it would go away.  However, since installing
> F12 on day one may not be the best idea EITHER, I am trying the workaround.

swcrypto=1 workaround not help in your case? 

> This leads me to ask -- could this be an issue only with some WAPs? 

Yes, many users don't have this problem. This can be related to access point type as well as some other things (like radio noise perhaps).

> netgear upstairs.  The problem persisted after I swapped in another netgear. 
> Duke uses only Cisco.  Is the bug netgear specific, or does it not happen for
> some WAPs but for others?  

I bet this is not only netgear problem. Is someone here who have other AP vendor and enter the issue? 

> If it is a netgear/F11 issue, it might well persist
> into F12 as it would be "invisible" to anyone not identically equipped.

This is firmware bug, not fixed yet. It will still happen on F12. If you want help to solve it please comment on:

http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2052

Intel as well will be able to answer your questions more precisely.

Comment 19 rgb 2009-11-12 14:13:09 UTC
Actually, the swcrypto workaround seems to be working for me.  I haven't had a dropped connection in well over an hour, where before it was in as little as thirty seconds, as much as an hour.  It will have to stay up for hours to be certain, but it is probable that I'm good for now.

I don't think it is radio noise, although that is always possible.  I have quite good signal strength.  OTOH, I've had laptops that would drop connections whenever anyone ran a microwave oven within thirty meters or so.  However, many drops happen very late at night or early in the morning and it doesn't happen at Duke (independent of signal strength) so I somewhat doubt this.

I agree that it is likely a firmware bug.  It started with F11 -- the system ran fine on the same WAPs with F10.  Or rather, it is a bug in either the firmware per se or a mix of the firmware and kernel code.  Another really interesting aspect of the bug is it doesn't drop the actual radio -- I still have signal strength after a drop, and NM shows me still connected to the WAP.  I just don't have an IP number until I drop the radio link and reconnect, rerunning DHCP basically.

rgb

Comment 20 Scott Glaser 2009-11-12 19:52:40 UTC
(In reply to comment #18)
> 
> I bet this is not only netgear problem. Is someone here who have other AP
> vendor and enter the issue? 
> 

I have seen this issue with two different D-Link and one Linksys APs, so I do not believe it is specifically a netgear issue either.


-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 21 msncookie 2009-11-29 20:37:49 UTC
I am also experiencing this issue, but I'm still on older Fedora 10, kernel 2.6.27.37-170.2.104.fc10.i686.PAE.  My router is a Buffalo WHR-HP-G54 and I'm using standard WPA.  

Error message and behaviour is the same though.  Disconnects are completely random... sometimes mid-data stream, sometimes while idle.  No pattern to when it happens, but at least once a day. Sometimes I can go 8 hours or more without a problem.

I will try the modprobe workaround and see.

thanks.

Comment 22 naraesk 2010-03-08 00:44:28 UTC
any news? :(

Comment 23 Stanislaw Gruszka 2010-03-08 14:18:42 UTC
Naraku.

Please ask on http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2052 . Since this is firmware bug we can do much with that here. Ask Intel. 

Ok, we can eventually change swcrypto=1 by default on fedora ... I'm thinking about that.

Comment 24 Christopher 2010-03-11 14:33:35 UTC
I'm seeing similar behavior in RHEL5.4 on a Thinkpad T61 with Intel4965 wireless chipset:

Mar 11 08:08:17 saggitarius kernel: iwlagn: Microcode SW error detected.  Restarting 0x82000000.
Mar 11 08:08:17 saggitarius kernel: iwlagn: Error setting new RXON (-5)
Mar 11 08:08:18 saggitarius kernel: iwlagn: Error sending REPLY_CT_KILL_CONFIG_CMD: time out after 500ms.
Mar 11 08:08:18 saggitarius kernel: iwlagn: REPLY_CT_KILL_CONFIG_CMD failed
Mar 11 08:08:18 saggitarius kernel: Registered led device: iwl-phy0:radio
Mar 11 08:08:18 saggitarius kernel: Registered led device: iwl-phy0:assoc
Mar 11 08:08:18 saggitarius kernel: Registered led device: iwl-phy0:RX
Mar 11 08:08:18 saggitarius kernel: Registered led device: iwl-phy0:TX
Mar 11 08:08:20 saggitarius kernel: iwlagn: Error sending REPLY_RXON: time out after 500ms.
Mar 11 08:08:20 saggitarius kernel: iwlagn: Error setting new RXON (-110)
Mar 11 08:08:21 saggitarius kernel: iwlagn: Microcode SW error detected.  Restarting 0x82000000.
Mar 11 08:08:21 saggitarius kernel: iwlagn: Error setting new RXON (-5)
Mar 11 08:08:21 saggitarius kernel: iwlagn: Error sending REPLY_CT_KILL_CONFIG_CMD: time out after 500ms.
Mar 11 08:08:21 saggitarius kernel: iwlagn: REPLY_CT_KILL_CONFIG_CMD failed
Mar 11 08:08:21 saggitarius kernel: Registered led device: iwl-phy0:radio
Mar 11 08:08:21 saggitarius kernel: Registered led device: iwl-phy0:assoc
Mar 11 08:08:21 saggitarius kernel: Registered led device: iwl-phy0:RX
Mar 11 08:08:21 saggitarius kernel: Registered led device: iwl-phy0:TX
Mar 11 08:08:24 saggitarius kernel: iwlagn: Error sending REPLY_RXON: time out after 500ms.
Mar 11 08:08:24 saggitarius kernel: iwlagn: Error setting new RXON (-110)
Mar 11 08:08:24 saggitarius kernel: iwlagn: Microcode SW error detected.  Restarting 0x82000000.
Mar 11 08:08:24 saggitarius kernel: iwlagn: Error setting new RXON (-5)
Mar 11 08:08:24 saggitarius kernel: iwlagn: Error sending REPLY_CT_KILL_CONFIG_CMD: time out after 500ms.
Mar 11 08:08:24 saggitarius kernel: iwlagn: REPLY_CT_KILL_CONFIG_CMD failed
Mar 11 08:08:24 saggitarius kernel: Registered led device: iwl-phy0:radio
Mar 11 08:08:24 saggitarius kernel: Registered led device: iwl-phy0:assoc
Mar 11 08:08:24 saggitarius kernel: Registered led device: iwl-phy0:RX
Mar 11 08:08:24 saggitarius kernel: Registered led device: iwl-phy0:TX
Mar 11 08:08:27 saggitarius kernel: iwlagn: Error sending REPLY_RXON: time out after 500ms.
Mar 11 08:08:27 saggitarius kernel: iwlagn: Error setting new RXON (-110)


It's occurred a small handful of times with no real regularity.  The only common circumstance is that when it does happen, it happens upon resume from suspend.  When this error occurs, it goes in a constant loop where the system "freezes" for 1-2 seconds (mouse pointer frozen, kb input doesn't work) then becomes responsive for 2-3 seconds...basically it's hiccuping.  Bouncing NetworkManager does nothing.  Shutting off the wireless radio via the physical switch on the front of the machine terminates the error cycle and returns system to normal operation, but turning the switch back on causes the error loop to resume.  Reboot is the only solution I have found that works.

Kernel is 2.6.18-164.11.1.el5PAE SMP

Comment 25 Scott Glaser 2010-03-11 20:08:00 UTC
(In reply to comment #24)

Try the workaround in comment #11 it may help.

Comment 26 Stanislaw Gruszka 2010-03-19 16:03:25 UTC
(In reply to comment #24)
> I'm seeing similar behavior in RHEL5.4 on a Thinkpad T61 with Intel4965
> wireless chipset:
What about new kernel from http://people.redhat.com/jwilson/el5/ ?

Comment 27 Stanislaw Gruszka 2010-03-19 16:05:06 UTC
(In reply to comment #25)
> (In reply to comment #24)
> 
> Try the workaround in comment #11 it may help.    

Hmm, on RHEL5 we have enabled swcrypto by default, I believe updating kernel will help with that problem.

We will make swcrypto=1 by default on fedora as well.

Comment 28 Stanislaw Gruszka 2010-03-19 16:35:06 UTC
(In reply to comment #27)
> Hmm, on RHEL5 we have enabled swcrypto by default, I believe updating kernel
> will help with that problem.
Err, no. That's not true. At least not in RHEL5 newest kernels.

Comment 29 Bug Zapper 2010-04-28 09:57:43 UTC
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 30 Stanislaw Gruszka 2010-05-26 15:05:55 UTC
Move to F-12 since bug is still present there.

Comment 31 Stanislaw Gruszka 2010-05-26 15:13:04 UTC
Some news:

I proposed to change swcrypto by default, but idea was refused by as bug "doesn't affect most people" and these whose are afected may turn swcrypto option on. See this thread for details:
http://lists.fedoraproject.org/pipermail/kernel/2010-March/002329.html

Currently in F-12 and F-12 have new Intel patches recovering from firmware hung, there is a small chance that these patches helps with that issue as well. Please test with swcrypto=0. Thanks.

Comment 32 Bug Zapper 2010-11-04 10:23:11 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 33 Bug Zapper 2010-12-05 06:33:45 UTC
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


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