Bug#550534: firmware-iwlwifi: iwlagn 0000:03:00.0: Microcode SW error detected. Restarting 0x82000000.
On 04/07/11 04:51, Ben Hutchings wrote: On Sat, 2009-10-10 at 23:05 +0200, Wouter Cloetens wrote: A combination of kernel driver and firmware version perhaps? Presumably it was. Has this been fixed by a kernel upgrade? Is it still a problem in the current stable release (Debian 6.0.3)? I just upgraded to firmware-iwlwifi 0.30. This contains the same buggy firmware release 228.61.2.24 as in 0.18. I'm now running the kernel from linux-image-2.6.38-2-686. Sure enough, a couple of minutes after unloading and reloading the iwlagn module: iwlagn :03:00.0: Microcode SW error detected. Restarting 0x8200. Loaded firmware version: 228.61.2.24 Start IWL Error Log Dump: Status: 0x000213E4, count: 5 Desc Time data1 data2 line FH_ERROR (0x000C) 3067148809 0x0008 0x0313 208 pc blink1 blink2 ilink1 ilink2 hcmd 0x0046C 0x0A332 0x004C2 0x006DA 0x0A39A 0x240001C FH register values: FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X00559000 FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X0033ddb0 FH_RSCSR_CHNL0_WPTR: 0X00a0 FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X00819004 FH_MEM_RSSR_SHARED_CTRL_REG: 0X003c FH_MEM_RSSR_RX_STATUS_REG: 0X0313 FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X FH_TSSR_TX_STATUS_REG: 0X07ff0002 FH_TSSR_TX_ERROR_REG: 0X Start IWL Event Log Dump: display last 20 entries EVT_LOGT:3067145742:0x:0301 EVT_LOGT:3067145821:0x12bf:0353 EVT_LOGT:3067148434:0x0107:0106 EVT_LOGT:3067148435:0x:0302 EVT_LOGT:3067148470:0x00d4:0321 EVT_LOGT:3067148472:0x:1350 EVT_LOGT:3067148472:0x:1351 EVT_LOGT:3067148473:0x:1352 EVT_LOGT:3067148473:0x0003:1353 EVT_LOGT:3067148481:0x0029:0357 EVT_LOGT:3067148714:0x0107:0106 EVT_LOGT:3067148715:0x:0302 EVT_LOGT:3067148751:0x00d4:0321 EVT_LOGT:3067148752:0x:1350 EVT_LOGT:3067148753:0x:1351 EVT_LOGT:3067148753:0x:1352 EVT_LOGT:3067148754:0x0003:1353 EVT_LOGT:3067148774:0x00d4:0322 EVT_LOGT:3067148804:0x1bc3:0310 EVT_LOGT:3067148812:0x:0125 However, it recovered from that by itself, and after that initial dump, my wlan connection has remained stable. It may be unrelated to this bug. Over the last two years, this bug has been discussed thousands of times in the forums and bug tracking tools of every distribution out there. Most people are just using old firmware, like I have been. Some people have had success setting this module option: swcrypto=1 which disables offloading encryption to the hardware. That doesn't always solve the problem, apparently, or at least not permanently. I will keep running with this firmware version and report if it breaks after longer use. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e188338.3020...@e2big.org
Bug#550534: firmware-iwlwifi: iwlagn 0000:03:00.0: Microcode SW error detected. Restarting 0x82000000.
Package: firmware-iwlwifi Version: 0.18 Severity: grave Justification: renders package unusable Firmware iwlwifi-4965-2.ucode version 228.61.2.24 in firmware-iwlwifi 0.18 renders the wlan interface unusable. After a couple of minutes, the following message appears in syslog: iwlagn :03:00.0: Microcode SW error detected. Restarting 0x8200. after which no packets can be sent, though the interface appears up. Simply restarting the interface brings it up again. Downgrading to 0.17 with firmware 228.57.2.23 solves the problem for me. However, since 0.18 is already in squeeze, that version was hard to track down. I found it in lenny-backports ultimately: http://www.backports.org/debian/pool/non-free/f/firmware-nonfree/firmware-iwlwifi_0.17~bpo50+1_all.deb Googling this problem turns up hits in every distribution imaginable. Other Debian bugs that are possibly related are 546213 and 548749. Allegedly Ubunty Karmic Koala fixes the problem, however, package linux-firmware_1.21_all.deb also contains 228.61.2.24. A combination of kernel driver and firmware version perhaps? Intel seems unaware of the problem. 228.61.2.24 is still the latest version on: http://intellinuxwireless.org/?p=iwlwifin=downloads This is very serious. Please revert to the older microcode version. More information about my environment: Intel Wireless WiFi 4965AGN. (ThinkPad R61, 802.11n draft WPA2 AP). From lspci: 03:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN [Kedron] Network Connection (rev 61) wlan0 IEEE 802.11abgn ESSID:censored Mode:Managed Frequency:2.437 GHz Access Point: censored Bit Rate=54 Mb/s Tx-Power=15 dBm Retry min limit:7 RTS thr:off Fragment thr:off Power Management:off Link Quality=48/70 Signal level=-62 dBm Noise level=-91 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash firmware-iwlwifi depends on no packages. firmware-iwlwifi recommends no packages. Versions of packages firmware-iwlwifi suggests: ii initramfs-tools 0.93.4 tools for generating an initramfs di linux-image-2.6.30-1-686 [lin 2.6.30-6 Linux 2.6.30 image on PPro/Celeron ii linux-image-2.6.30-2-686 [lin 2.6.30-8 Linux 2.6.30 image on PPro/Celeron -- no debconf information -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490704: Final update
The same problem has been observed by someone else with an R61 with an Ubuntu 2.6.26 kernel. After I upgraded to 2.6.28, the problem disappeared altogether. As Lenny was released with 2.6.26, but I'm running sid and have been using sid's 2.6.28 for a while, and now a self-built 2.6.29, I can neither confirm nor deny whether Lenny's kernel is stable on a ThinkPad R61. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490704:
Happened again with HPET enabled. linux-image-2.6.26-1-686 2.6.26-8 I had 6 days of uptime with that kernel at one point. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490704:
On Wed, Jul 30, 2008 at 01:07:06AM +0200, Wouter Cloetens wrote: On Sat, Jul 26, 2008 at 01:26:50AM +0200, Wouter Cloetens wrote: My next step is hpet=disable. And no hangs since. ... until now, after 4 days of uptime. The HPET is not (the only) culprit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490704:
On Thu, Jul 24, 2008 at 02:06:44AM +0200, Wouter Cloetens wrote: Three days without hang... ... but that didn't last; it just did it again. My next step is hpet=disable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490704:
2.6.26 hangs too, in the same way, and again after up to two days of uptime. The new iwlwifi driver can drive the wireless LED, and that still works while the system is hung. Going to try to enable HPET_RTC_IRQ and HPET_RTC_IRQ as suggested in 479709, and if that fails, hpet=disable on the kernel cmdline. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490704: (no subject)
Problem occurred again on my custom kernel after 2 days of operation without a problem. No reaction to anything; magic sysrq, caps/scroll lock, ctrl+alt+backspace/del, any of the Fn-key combinations or short power button press. I'm willing and able to debug this, but I have no idea how to proceed... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490704:
On Fri, Jul 18, 2008 at 12:14:31AM +0200, maximilian attems wrote: try out 2.6.26, see trunk apt lines - http://wiki.debian.org/DebianKernel This mail sent from a freshly built custom 2.6.26 on my laptop. Now let's see if this one hangs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490704: (no subject)
It actually happened on my customer kernel too now, after over 11h uptime. Magic sysrq is enabled; will try to gather more details. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
