[8086:4238] iwlwifi: fail to flush all tx fifo queues Q 0

[Ronald J. Wright]

I have a Lenovo ThinkPad X201 Tablet with an Intel Centrino Ultimate-N 6300 AGN wireless card. Ever since I have upgraded to Ubuntu 13.10 from Ubuntu 12.10, I keep experiencing this annoying issue on wireless networks with multiple APs: a TX queue gets stuck, and the wireless card cannot send any packets. The Wi-Fi LED constantly flashes, and sometimes, it becomes nearly impossible to restart the wireless card using Fn+F5.

The NetworkManager connection is setup as follows:

SSID: IllinoisNet
BSSID: DA:BE:76:xx:xx:xx
Security: WPA/WPA2 Enterprise
Authentication: Protected EAP (PEAP)
CA Certificate: /etc/ssl/certs/AddTrust_External_Root.pem
PEAP Version: Automatic
Inner Authentication: MSCHAPv2

Notice that I have manually specified a BSSID to force the system to use only one AP (since I have not found a way to reduce the roaming aggressiveness on Intel wireless cards in Linux).

Attached is the Wireshark log and the syslog output while TX queue 0 is stuck.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-19-generic 3.11.0-19.33
ProcVersionSignature: Ubuntu 3.11.0-19.33-generic 3.11.10.5
Uname: Linux 3.11.0-19-generic x86_64
ApportVersion: 2.12.5-0ubuntu2.2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: ron 2599 F.... pulseaudio
Date: Wed Apr 9 21:36:49 2014
HibernationDevice: RESUME=UUID=70381092-dbb1-458c-8c5c-68850e61086c
InstallationDate: Installed on 2013-02-28 (405 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5)
MachineType: LENOVO 0831CTO
MarkForUpload: True
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.11.0-19-generic root=UUID=606d1eed-eeca-4acb-a739-6796a7f7432b ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.11.0-19-generic N/A
 linux-backports-modules-3.11.0-19-generic N/A
 linux-firmware 1.116.2
SourcePackage: linux
UpgradeStatus: Upgraded to saucy on 2014-01-22 (77 days ago)
dmi.bios.date: 04/26/2012
dmi.bios.vendor: LENOVO
dmi.bios.version: 6QET69WW (1.39 )
dmi.board.name: 0831CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr6QET69WW(1.39):bd04/26/2012:svnLENOVO:pn0831CTO:pvrThinkPadX201Tablet:rvnLENOVO:rn0831CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 0831CTO
dmi.product.version: ThinkPad X201 Tablet
dmi.sys.vendor: LENOVO

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.14 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14-trusty/

[Ronald J. Wright (logiconcepts819)]

I have just finished testing the latest upstream kernel, and I confirm that the bug still exists (i.e. I am still occasionally seeing 'fail to flush all tx fifo queues Q 0' messages).

[Ronald J. Wright (logiconcepts819)]

I have tested the latest upstream kernel even more, and I have noticed something that may or may not help. I have found a "degradation effect" in which the total length of time the connection is hung within a given time frame increases the longer the system is running. To illustrate this effect, here are time frames from a sample system run in which I saw the aforementioned messages in the system log:

130.027554-277.358228 seconds since startup (147.330674 seconds long)
279.384357-299.437885 seconds since startup (20.053528 seconds long)
51257.090718-51261.102655 seconds since startup (4.011937 seconds long)
51575.931991-51579.948176 seconds since startup (4.016185 seconds long)
53066.713218-53099.649674 seconds since startup (32.936456 seconds long)
68674.880550-68738.963402 seconds since startup (64.082852 seconds long)
83473.503976-83619.708034 seconds since startup (146.204058 seconds long)
84739.202166-84739.204135 seconds since startup (0.001969 of a second long)
87142.062085-87198.136332 seconds since startup (56.074247 seconds long)
. . .

Suppose we group these time frames into 40,000 second time intervals. Between 0 and 40,000 seconds since startup, there are 56.074247 seconds worth of these messages. Between 40,000 and 80,000 seconds since startup, there are 105.04743 seconds worth of these messages. Between 80,000 and 120,000 seconds since startup, there are at least 202.280274 seconds worth of these messages.

[Emmanuel Grumbach (egrumbach)]

Please test the patch attached