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
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?
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
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
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.
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
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'.
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.
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.
(In reply to comment #8) > Bug is reported upstream and resolved yet: ^^^^^^^^ Ee, NOT resolved.
The issue is *not* resolved certainly. There is a workaround though. Passing swcrypto=1 to the iwlagn module seems to prevent it.
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
*** Bug 529223 has been marked as a duplicate of this bug. ***
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...
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
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.
(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
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
(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.
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
(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
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.
any news? :(
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.
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
(In reply to comment #24) Try the workaround in comment #11 it may help.
(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/ ?
(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.
(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.
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
Move to F-12 since bug is still present there.
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.
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
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.