FS#17696 - Kernel breaks Intel 3945 wireless driver

Attached to Project: Arch Linux
Opened by Brian Hanna (brianhanna) - Sunday, 03 January 2010, 14:16 GMT
Last edited by Tobias Powalowski (tpowa) - Friday, 08 January 2010, 08:00 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


Description: After upgrading to Kernel, Intel 3945 connection becomes unstable and cannot stay connected longer than a minute or two. Restarting networking completely is the only way I've found to get it working again (for a minute or two). Connecting using wicd and manually gave same result.

Based on the error messages in dmesg (below), I suspected a firmware problem but loading an older version of the firmware gives the same problem. The new firmware ( works as it should with any 2.6.30 or 2.6.31 kernel.

A forum thread on this issue is at: http://bbs.archlinux.org/viewtopic.php?id=87802&p=2

I haven't found any mention of issues of this problem outside Arch so this may be a configuration issue?

Additional info:
* package version(s) - Kernel iwl3945 with firmware ver

* config and/or log files etc.

iwl3945 0000:02:00.0: Microcode SW error detected. Restarting 0x82000008.
iwl3945 0000:02:00.0: Error Reply type 0x00000000 cmd REPLY_TX (0x1C) seq 0x0000 ser 0x00000000
Registered led device: iwl-phy0::radio
Registered led device: iwl-phy0::assoc
Registered led device: iwl-phy0::RX
Registered led device: iwl-phy0::TX

Steps to reproduce:

Upgrade to kernel, connect to wireless router using Intel 3945
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Friday, 08 January 2010, 08:00 GMT
Reason for closing:  Fixed
Comment by Thomas Dziedzic (tomd123) - Sunday, 03 January 2010, 20:52 GMT
I also noticed that it did stop working for a brief period of time, but after I reconnected (netcfg -a, then netcfg-menu) it worked. I have been using .32.2 and I've been connected wirelessly for a while now (left it on overnight) and haven't had problems about it disconnecting.
Comment by Thomas Bächler (brain0) - Sunday, 03 January 2010, 22:11 GMT
I've been using wireless on this kernel/driver for many hours at a time without any noticable problems.
Comment by Brian Hanna (brianhanna) - Monday, 04 January 2010, 03:12 GMT
I did a fair amount of testing to ensure this was a valid bug. After a clean install of 2009.08, I set pacman.conf to ignore kernel26 and did a pacman -Syu. My 3945 wireless still works. If I then remove kernel26 from ignored packages and pacman -Syu, it breaks with the error message above. This may be specific to x86_64 kernel. I have not tested with i686.
Comment by Rob (Painless) - Monday, 04 January 2010, 12:22 GMT
Since upgrading to 2.6.32 I noticed ssh sessions would lock (rather than disconnect). I also noticed that wireless signal strength would fluctuate much more than usual (85% - 55% then back again). Once (and only once) the interface connection actually dropped completely requiring me to stop and restart netcfg. Running a constant ping did seem to help. I did not encounter any unusual errors (such as the microcode messages) in system logs.

I have since downgraded to 2.6.31 and have noticed no ill effects yet.

I did notice that while running kernel 2.6.32, the contents of /sys/module/iwl3945/parameters did not contain the 'queues_num' parm. Since reverting back to 2.6.31, this parm is back again, along with wifi stability.

I am running a 32-bit kernel.
Comment by Luís Moreira (knap) - Tuesday, 05 January 2010, 19:13 GMT
Looks like I'm also experiencing this problem.

iwl3945 + + x86-64

wlan0: deauthenticated from 00:14:bf:3c:cd:80 (Reason: 7)

Just had two random disconects
Comment by Thomas Dziedzic (tomd123) - Thursday, 07 January 2010, 05:31 GMT
This has been worked around in
The commit that works around this (in disables the powersavings mode for intel 3945 until the issue has been resolved:
Upstream bug report.
Comment by Thomas Bächler (brain0) - Thursday, 07 January 2010, 09:17 GMT
This seems to be different depending on the AP. I'm at work now, and the problem appeared for me too, while it happened neither at home nor at my brother's AP.