Bug 863424

Summary: iwlwifi: fail to flush all tx fifo queues
Product: [Fedora] Fedora Reporter: Michal Fojtik <mfojtik>
Component: kernelAssignee: fedora-kernel-wireless-iwl
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: a.izotov, anto.trande, arnoT, balazs.huvely, bill-bugzilla.redhat.com, bojan.axievski, bughunt, camico, dan.ghete, daniell1, dave, dcharlesm, fedyapupkin, gansalmon, ilw, itamar, jason, jboggs, jbrouer, jonathan, js, jwboyer, kernel-maint, kevin, leho, limguowei, limor.naftali, maciek.borzecki, madhu.chinakonda, malarkannan.p, mfojtik, michele, mikko.cal, nmetro, oscarcosta, rderooy, rjones, sbathe, sbogrin.bugs, shayan.pooya, social, sven, viprog
Target Milestone: ---Keywords: Reopened
Target Release: ---Flags: jforbes: needinfo?
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:3c182b2d09ca5113a46b09adabfdb6a8db5e664b
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-03-17 18:43:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
queue flush fix
none
better fix
none
dmesg output with 3.8-rc1
none
dmesg output after applying the patch and setting power_save to 0
none
get better logs
none
get better logs
none
get better logs
none
get better logs
none
fix rate scaling
none
fix rate scaling
none
iwlwifi_print_flush.patch
none
dmesg output with 3.9.2
none
microcode error dmesg - 3.8.13-100.fc17.x86_64
none
dmesg output with 3.9.6-200.fc18.x86_64
none
dmesg exerpt from kernel-PAE-3.10.12-100.fc18.i686 none

Description Michal Fojtik 2012-10-05 13:00:49 UTC
Description of problem:
1. Close the LID (suspend)
2. Open the LID


Additional info:
libreport version: 2.0.14
abrt_version:   2.0.13
cmdline:        BOOT_IMAGE=/vmlinuz-3.6.0-0.rc7.git1.4.fc18.x86_64 root=UUID=bce86c8d-2823-47f8-9259-0a1fad78c8b2 ro rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0 rhgb quiet LANG=en_US.UTF-8 KEYTABLE=us
kernel:         3.6.0-0.rc7.git1.4.fc18.x86_64

backtrace:
:WARNING: at drivers/net/wireless/iwlwifi/dvm/sta.c:888 iwl_send_lq_cmd+0x282/0x290 [iwldvm]()
:Hardware name: 2325F51
:Modules linked in: fuse ebtable_nat ebtables ipt_MASQUERADE nf_conntrack_netbios_ns nf_conntrack_broadcast ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables be2iscsi iscsi_boot_sysfs iptable_nat nf_nat lockd iptable_mangle bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio libcxgbi ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack rfcomm bnep snd_hda_codec_hdmi snd_hda_codec_realtek arc4 iwldvm mac80211 iTCO_wdt iTCO_vendor_support coretemp microcode btusb bluetooth joydev uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev media snd_hda_intel snd_hda_codec snd_hwdep i2c_i801 snd_seq snd_seq_device snd_pcm lpc_ich mfd_core iwlwifi snd_page_alloc cfg80211 snd_timer mei thinkpad_acpi snd soundcore rfkill vhost_net tpm_tis tpm tun tpm_bios macvtap macvlan kvm_intel kvm uinput crc32c_intel ghash_clmulni_in
:tel sdhci_pci i915 sdhci mmc_core i2c_algo_bit drm_kms_helper drm e1000e i2c_core wmi video sunrpc
:Pid: 776, comm: wpa_supplicant Not tainted 3.6.0-0.rc7.git1.4.fc18.x86_64 #1
:Call Trace:
: [<ffffffff8106788f>] warn_slowpath_common+0x7f/0xc0
: [<ffffffff810678ea>] warn_slowpath_null+0x1a/0x20
: [<ffffffffa05ada32>] iwl_send_lq_cmd+0x282/0x290 [iwldvm]
: [<ffffffff81167a1e>] ? free_pages+0x5e/0x80
: [<ffffffffa05adcda>] iwl_restore_stations+0x29a/0x3e0 [iwldvm]
: [<ffffffffa05b5801>] iwlagn_commit_rxon+0x801/0xdd0 [iwldvm]
: [<ffffffffa05ae8c5>] ? iwl_update_bcast_station+0x75/0xe0 [iwldvm]
: [<ffffffffa05b60a6>] iwlagn_mac_config+0x286/0x3d0 [iwldvm]
: [<ffffffffa04ccd92>] ieee80211_hw_config+0x142/0x3f0 [mac80211]
: [<ffffffffa0515bf0>] ieee80211_prep_connection+0xe0/0x640 [mac80211]
: [<ffffffffa0515ea8>] ? ieee80211_prep_connection+0x398/0x640 [mac80211]
: [<ffffffffa051dc28>] ieee80211_mgd_assoc+0x438/0x5e0 [mac80211]
: [<ffffffffa04e93d6>] ieee80211_assoc+0x56/0x80 [mac80211]
: [<ffffffffa0315fbb>] __cfg80211_mlme_assoc+0x34b/0x390 [cfg80211]
: [<ffffffff810d6f00>] ? mark_held_locks+0x70/0x130
: [<ffffffffa03160c0>] cfg80211_mlme_assoc+0xc0/0xf0 [cfg80211]
: [<ffffffff816db38d>] ? __mutex_unlock_slowpath+0xdd/0x180
: [<ffffffffa0306a21>] nl80211_associate+0x221/0x2b0 [cfg80211]
: [<ffffffff816da667>] ? mutex_lock_nested+0x2e7/0x390
: [<ffffffff815c9a60>] genl_rcv_msg+0x250/0x2d0
: [<ffffffff815c9810>] ? genl_rcv+0x40/0x40
: [<ffffffff815c9351>] netlink_rcv_skb+0xa1/0xb0
: [<ffffffff815c97f5>] genl_rcv+0x25/0x40
: [<ffffffff815c8c4d>] netlink_unicast+0x19d/0x220
: [<ffffffff815c8fd5>] netlink_sendmsg+0x305/0x3f0
: [<ffffffff815829d8>] ? sock_update_classid+0x148/0x2e0
: [<ffffffff8157d62c>] sock_sendmsg+0xbc/0xf0
: [<ffffffff810ac98f>] ? local_clock+0x6f/0x80
: [<ffffffff810d6157>] ? lock_release_non_nested+0x2f7/0x330
: [<ffffffff8157da0c>] __sys_sendmsg+0x3ac/0x3c0
: [<ffffffff811d176a>] ? fget_light+0x3ea/0x520
: [<ffffffff81580039>] sys_sendmsg+0x49/0x90
: [<ffffffff816e7369>] system_call_fastpath+0x16/0x1b

Comment 1 Stanislaw Gruszka 2012-10-05 14:15:07 UTC
Is this 100% reproducible or happen at random?

Comment 2 Michal Fojtik 2012-10-06 09:31:07 UTC
This happens random, not a blocker or something, just annoying :)

Comment 3 Malar Kannan 2012-10-08 18:44:53 UTC
intel wifi driver crashes frequently

Package: kernel
OS Release: Fedora release 17 (Beefy Miracle)

Comment 4 Malar Kannan 2012-10-08 18:47:37 UTC
happens mostly when reconnecting to an ap which has gone offline and comes back up...

Comment 5 Stanislaw Gruszka 2012-10-18 11:59:19 UTC
Please test this kernel and report back if it fixes the problem or not:
http://koji.fedoraproject.org/koji/taskinfo?taskID=4602595

Comment 6 Stanislaw Gruszka 2012-10-23 13:57:14 UTC
Patch claimed to fix this issue was already applied to F-18: 3.6.3-2 kernel:
http://koji.fedoraproject.org/koji/buildinfo?buildID=361643
Please test.

Comment 7 Stanislaw Gruszka 2012-11-02 15:15:59 UTC
Closing due to lack of response ...

Comment 8 Shayan Pooya 2012-11-26 03:25:36 UTC
I am frequently hitting this problem in Fedora 18 (Beta-RC with the latest updates).

$ uname -a
Linux localhost.localdomain 3.6.7-5.fc18.x86_64 #1 SMP Tue Nov 20 19:40:08 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

I did not have this in previous versions so this is a regressions. I am guessing the patch your talking about is already in my kernel. I have the following wifi card:

03:00.0 Network controller: Intel Corporation PRO/Wireless 5100 AGN [Shiloh] Network Connection

Comment 9 Stanislaw Gruszka 2012-11-27 15:51:19 UTC
Please provide full dmesg when this problem happen, perhaps there are some firmware crashes before the warning.

Comment 10 Shayan Pooya 2012-12-03 03:59:07 UTC
I have not seen the bug since then.
However, I still have transient connection failure on my machine. It might be related to this bug.

After failing to connect to the router (network manager thinks I am connected, but I cannot ping anything), the onlly thing that works is turning the wireless on and then off (from the network manager applet). After turning wifi off, the OS hangs for about 10 seconds (I think failing to flush tx io) and then I can turn it back on.

dmesg output follows:
[114005.290520] wlan0: authenticate with 78:cd:8e:70:2e:00
[114005.292664] wlan0: send auth to 78:cd:8e:70:2e:00 (try 1/3)
[114005.294483] wlan0: authenticated
[114005.295022] wlan0: associate with 78:cd:8e:70:2e:00 (try 1/3)
[114005.303982] wlan0: RX AssocResp from 78:cd:8e:70:2e:00 (capab=0x411 status=0 aid=1)
[114005.306980] wlan0: associated
[114005.307086] cfg80211: Calling CRDA for country: US
[114005.309503] cfg80211: Regulatory domain changed to country: US
[114005.309505] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[114005.309507] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
[114005.309509] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
[114005.309510] cfg80211:   (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[114005.309511] cfg80211:   (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[114005.309512] cfg80211:   (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[114005.309514] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
[114026.296085] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[114088.821050] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[114171.684119] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[114274.913116] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[114395.244052] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[114427.762044] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[114429.763120] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[114431.764150] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[114433.767061] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[114435.771027] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[114437.772048] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[114439.774152] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[114441.777079] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[114443.779068] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[114445.783115] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[114447.785083] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[114449.787138] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[114451.790117] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[114453.792117] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[114455.796091] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[114457.800120] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[114459.802042] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[114459.802096] wlan0: deauthenticating from 78:cd:8e:70:2e:00 by local choice (reason=3)
[114461.806157] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[114463.809150] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[114465.826063] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[114465.829060] cfg80211: Calling CRDA to update world regulatory domain
[114465.849477] cfg80211: World regulatory domain updated:
[114465.849481] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[114465.849483] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[114465.849485] cfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[114465.849486] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[114465.849488] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[114465.849489] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)

Comment 11 Oscar Costa 2012-12-08 21:51:07 UTC
Hi all,

I believe that had this problem today in Fedora 17 x86_64 (Linux version 3.6.8-2.fc17.x86_64). That is my message log:

Dec  8 17:28:23 xps NetworkManager[758]: <info> (wlan0): bringing up device.
Dec  8 17:28:23 xps NetworkManager[758]: <info> WiFi hardware radio set enabled
Dec  8 17:28:23 xps NetworkManager[758]: <info> WiFi now enabled by radio killswitch
Dec  8 17:28:23 xps NetworkManager[758]: <info> (wlan0): bringing up device.
Dec  8 17:28:23 xps kernel: [  288.253220] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
Dec  8 17:28:23 xps kernel: [  288.259976] iwlwifi 0000:03:00.0: Radio type=0x2-0x2-0x1
Dec  8 17:28:23 xps kernel: [  288.380693] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Dec  8 17:28:23 xps NetworkManager[758]: <info> (wlan0) supports 5 scan SSIDs
Dec  8 17:28:23 xps NetworkManager[758]: <info> (wlan0): supplicant interface state: starting -> ready
Dec  8 17:28:23 xps NetworkManager[758]: <info> (wlan0): device state change: unavailable -> disconnected (reason 'supplicant-available') [20 30 42]
Dec  8 17:28:23 xps NetworkManager[758]: <warn> Trying to remove a non-existant call id.
Dec  8 17:28:23 xps NetworkManager[758]: <info> (wlan0): supplicant interface state: ready -> inactive
Dec  8 17:28:23 xps NetworkManager[758]: <info> (wlan0) supports 5 scan SSIDs
Dec  8 17:28:23 xps NetworkManager[758]: <info> Auto-activating connection 'Auto MY_WIFI'.
Dec  8 17:28:23 xps NetworkManager[758]: <info> Activation (wlan0) starting connection 'Auto MY_WIFI'
Dec  8 17:28:23 xps NetworkManager[758]: <info> (wlan0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Dec  8 17:28:23 xps NetworkManager[758]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Dec  8 17:28:23 xps NetworkManager[758]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
Dec  8 17:28:23 xps NetworkManager[758]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
Dec  8 17:28:23 xps NetworkManager[758]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
Dec  8 17:28:23 xps NetworkManager[758]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
Dec  8 17:28:23 xps NetworkManager[758]: <info> (wlan0): device state change: prepare -> config (reason 'none') [40 50 0]
Dec  8 17:28:23 xps NetworkManager[758]: <info> Activation (wlan0/wireless): access point 'Auto MY_WIFI' has security, but secrets are required.
Dec  8 17:28:23 xps NetworkManager[758]: <info> (wlan0): device state change: config -> need-auth (reason 'none') [50 60 0]
Dec  8 17:28:23 xps NetworkManager[758]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
Dec  8 17:28:23 xps NetworkManager[758]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Dec  8 17:28:23 xps NetworkManager[758]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
Dec  8 17:28:23 xps NetworkManager[758]: <info> (wlan0): device state change: need-auth -> prepare (reason 'none') [60 40 0]
Dec  8 17:28:23 xps NetworkManager[758]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
Dec  8 17:28:23 xps NetworkManager[758]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
Dec  8 17:28:23 xps NetworkManager[758]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
Dec  8 17:28:23 xps NetworkManager[758]: <info> (wlan0): device state change: prepare -> config (reason 'none') [40 50 0]
Dec  8 17:28:23 xps NetworkManager[758]: <info> Activation (wlan0/wireless): connection 'Auto MY_WIFI' has security, and secrets exist.  No new secrets needed.
Dec  8 17:28:23 xps NetworkManager[758]: <info> Config: added 'ssid' value 'MY_WIFI'
Dec  8 17:28:23 xps NetworkManager[758]: <info> Config: added 'scan_ssid' value '1'
Dec  8 17:28:23 xps NetworkManager[758]: <info> Config: added 'key_mgmt' value 'WPA-PSK'
Dec  8 17:28:23 xps NetworkManager[758]: <info> Config: added 'psk' value '<omitted>'
Dec  8 17:28:23 xps NetworkManager[758]: <info> Config: added 'proto' value 'WPA RSN'
Dec  8 17:28:23 xps NetworkManager[758]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
Dec  8 17:28:23 xps NetworkManager[758]: <info> Config: set interface ap_scan to 1
Dec  8 17:28:23 xps NetworkManager[758]: <info> (wlan0): supplicant interface state: inactive -> scanning
Dec  8 17:28:24 xps kernel: [  289.701980] wlan0: authenticate with <ROUTER_MAC>
Dec  8 17:28:24 xps kernel: [  289.715583] wlan0: send auth to <ROUTER_MAC> (try 1/3)
Dec  8 17:28:24 xps NetworkManager[758]: <info> (wlan0): supplicant interface state: scanning -> authenticating
Dec  8 17:28:24 xps kernel: [  289.745211] wlan0: authenticated
Dec  8 17:28:24 xps kernel: [  289.746582] wlan0: associate with <ROUTER_MAC> (try 1/3)
Dec  8 17:28:24 xps NetworkManager[758]: <info> (wlan0): supplicant interface state: authenticating -> associating
Dec  8 17:28:24 xps kernel: [  289.752933] wlan0: RX AssocResp from <ROUTER_MAC> (capab=0x411 status=0 aid=2)
Dec  8 17:28:24 xps kernel: [  289.760734] wlan0: associated
Dec  8 17:28:24 xps kernel: [  289.760799] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Dec  8 17:28:24 xps NetworkManager[758]: <info> (wlan0): supplicant interface state: associating -> associated
Dec  8 17:28:24 xps NetworkManager[758]: <info> (wlan0): supplicant interface state: associated -> 4-way handshake
Dec  8 17:28:25 xps NetworkManager[758]: <info> (wlan0): supplicant interface state: 4-way handshake -> completed
Dec  8 17:28:25 xps NetworkManager[758]: <info> Activation (wlan0/wireless) Stage 2 of 5 (Device Configure) successful.  Connected to wireless network 'MY_WIFI'.
Dec  8 17:28:25 xps NetworkManager[758]: <info> Activation (wlan0) Stage 3 of 5 (IP Configure Start) scheduled.
Dec  8 17:28:25 xps NetworkManager[758]: <info> Activation (wlan0) Stage 3 of 5 (IP Configure Start) started...
Dec  8 17:28:25 xps NetworkManager[758]: <info> (wlan0): device state change: config -> ip-config (reason 'none') [50 70 0]
Dec  8 17:28:25 xps NetworkManager[758]: <info> Activation (wlan0) Beginning DHCPv4 transaction (timeout in 45 seconds)
Dec  8 17:28:25 xps NetworkManager[758]: <info> dhclient started with pid 2329
Dec  8 17:28:25 xps NetworkManager[758]: <info> Activation (wlan0) Beginning IP6 addrconf.
Dec  8 17:28:25 xps NetworkManager[758]: <info> Activation (wlan0) Stage 3 of 5 (IP Configure Start) complete.
Dec  8 17:28:25 xps dhclient[2329]: Internet Systems Consortium DHCP Client 4.2.4-P2
Dec  8 17:28:25 xps dhclient[2329]: Copyright 2004-2012 Internet Systems Consortium.
Dec  8 17:28:25 xps dhclient[2329]: All rights reserved.
Dec  8 17:28:25 xps dhclient[2329]: For info, please visit https://www.isc.org/software/dhcp/
Dec  8 17:28:25 xps dhclient[2329]: 
Dec  8 17:28:25 xps NetworkManager[758]: <info> (wlan0): DHCPv4 state changed nbi -> preinit
Dec  8 17:28:25 xps dhclient[2329]: Listening on LPF/wlan0/<INTERFACE_MAC>
Dec  8 17:28:25 xps dhclient[2329]: Sending on   LPF/wlan0/<INTERFACE_MAC>
Dec  8 17:28:25 xps dhclient[2329]: Sending on   Socket/fallback
Dec  8 17:28:25 xps dhclient[2329]: DHCPREQUEST on wlan0 to 255.255.255.255 port 67 (xid=0x3a0e5450)
Dec  8 17:28:26 xps avahi-daemon[765]: Registering new address record for fe80::4e80:93ff:fe5c:7e0c on wlan0.*.
Dec  8 17:28:31 xps dhclient[2329]: DHCPREQUEST on wlan0 to 255.255.255.255 port 67 (xid=0x3a0e5450)
Dec  8 17:28:41 xps dhclient[2329]: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4 (xid=0x74e2faa2)
Dec  8 17:28:45 xps dhclient[2329]: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4 (xid=0x74e2faa2)
Dec  8 17:28:45 xps NetworkManager[758]: <info> (wlan0): IP6 addrconf timed out or failed.
Dec  8 17:28:45 xps NetworkManager[758]: <info> Activation (wlan0) Stage 4 of 5 (IPv6 Configure Timeout) scheduled...
Dec  8 17:28:45 xps NetworkManager[758]: <info> Activation (wlan0) Stage 4 of 5 (IPv6 Configure Timeout) started...
Dec  8 17:28:45 xps NetworkManager[758]: <info> Activation (wlan0) Stage 4 of 5 (IPv6 Configure Timeout) complete.
Dec  8 17:28:49 xps dhclient[2329]: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8 (xid=0x74e2faa2)
Dec  8 17:28:57 xps dhclient[2329]: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 19 (xid=0x74e2faa2)
Dec  8 17:29:10 xps NetworkManager[758]: <warn> (wlan0): DHCPv4 request timed out.
Dec  8 17:29:10 xps NetworkManager[758]: <info> (wlan0): canceled DHCP transaction, DHCP client pid 2329
Dec  8 17:29:10 xps NetworkManager[758]: <info> Activation (wlan0) Stage 4 of 5 (IPv4 Configure Timeout) scheduled...
Dec  8 17:29:10 xps NetworkManager[758]: <info> Activation (wlan0) Stage 4 of 5 (IPv4 Configure Timeout) started...
Dec  8 17:29:10 xps NetworkManager[758]: <info> (wlan0): device state change: ip-config -> failed (reason 'ip-config-unavailable') [70 120 5]
Dec  8 17:29:10 xps kernel: [  335.881962] wlan0: deauthenticating from <ROUTER_MAC> by local choice (reason=3)
Dec  8 17:29:10 xps NetworkManager[758]: <warn> Activation (wlan0) failed for connection 'Auto MY_WIFI'
Dec  8 17:29:10 xps NetworkManager[758]: <info> Activation (wlan0) Stage 4 of 5 (IPv4 Configure Timeout) complete.
Dec  8 17:29:10 xps NetworkManager[758]: <info> (wlan0): device state change: failed -> disconnected (reason 'none') [120 30 0]
Dec  8 17:29:10 xps NetworkManager[758]: <info> (wlan0): deactivating device (reason 'none') [0]
Dec  8 17:29:10 xps kernel: [  335.918137] cfg80211: Calling CRDA to update world regulatory domain
Dec  8 17:29:10 xps NetworkManager[758]: <info> (wlan0): supplicant interface state: completed -> disconnected
Dec  8 17:29:10 xps kernel: [  335.927959] cfg80211: World regulatory domain updated:
Dec  8 17:29:10 xps kernel: [  335.927969] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Dec  8 17:29:10 xps kernel: [  335.927976] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Dec  8 17:29:10 xps kernel: [  335.927982] cfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Dec  8 17:29:10 xps kernel: [  335.927987] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Dec  8 17:29:10 xps kernel: [  335.927992] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Dec  8 17:29:10 xps kernel: [  335.927996] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Dec  8 17:29:10 xps kernel: [  335.928042] cfg80211: Calling CRDA for country: BR
Dec  8 17:29:10 xps kernel: [  335.933732] cfg80211: Regulatory domain changed to country: BR
Dec  8 17:29:10 xps kernel: [  335.933739] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Dec  8 17:29:10 xps kernel: [  335.933744] cfg80211:   (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Dec  8 17:29:10 xps kernel: [  335.933748] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
Dec  8 17:29:10 xps kernel: [  335.933751] cfg80211:   (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Dec  8 17:29:10 xps kernel: [  335.933754] cfg80211:   (5490000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Dec  8 17:29:10 xps kernel: [  335.933757] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
Dec  8 17:29:13 xps NetworkManager[758]: <info> Auto-activating connection 'Auto MY_WIFI'.
Dec  8 17:29:13 xps NetworkManager[758]: <info> Activation (wlan0) starting connection 'Auto MY_WIFI'
Dec  8 17:29:13 xps NetworkManager[758]: <info> (wlan0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Dec  8 17:29:13 xps NetworkManager[758]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Dec  8 17:29:13 xps NetworkManager[758]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
Dec  8 17:29:13 xps NetworkManager[758]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
Dec  8 17:29:13 xps NetworkManager[758]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
Dec  8 17:29:13 xps NetworkManager[758]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
Dec  8 17:29:13 xps NetworkManager[758]: <info> (wlan0): device state change: prepare -> config (reason 'none') [40 50 0]
Dec  8 17:29:13 xps NetworkManager[758]: <info> Activation (wlan0/wireless): access point 'Auto MY_WIFI' has security, but secrets are required.
Dec  8 17:29:13 xps NetworkManager[758]: <info> (wlan0): device state change: config -> need-auth (reason 'none') [50 60 0]
Dec  8 17:29:13 xps NetworkManager[758]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
Dec  8 17:29:13 xps NetworkManager[758]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Dec  8 17:29:13 xps NetworkManager[758]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
Dec  8 17:29:13 xps NetworkManager[758]: <info> (wlan0): device state change: need-auth -> prepare (reason 'none') [60 40 0]
Dec  8 17:29:13 xps NetworkManager[758]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
Dec  8 17:29:13 xps NetworkManager[758]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
Dec  8 17:29:13 xps NetworkManager[758]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
Dec  8 17:29:13 xps NetworkManager[758]: <info> (wlan0): device state change: prepare -> config (reason 'none') [40 50 0]
Dec  8 17:29:13 xps NetworkManager[758]: <info> Activation (wlan0/wireless): connection 'Auto MY_WIFI' has security, and secrets exist.  No new secrets needed.
Dec  8 17:29:13 xps NetworkManager[758]: <info> Config: added 'ssid' value 'MY_WIFI'
Dec  8 17:29:13 xps NetworkManager[758]: <info> Config: added 'scan_ssid' value '1'
Dec  8 17:29:13 xps NetworkManager[758]: <info> Config: added 'key_mgmt' value 'WPA-PSK'
Dec  8 17:29:13 xps NetworkManager[758]: <info> Config: added 'psk' value '<omitted>'
Dec  8 17:29:13 xps NetworkManager[758]: <info> Config: added 'proto' value 'WPA RSN'
Dec  8 17:29:13 xps NetworkManager[758]: <info> Config: set interface ap_scan to 1
Dec  8 17:29:13 xps NetworkManager[758]: <info> (wlan0): supplicant interface state: disconnected -> scanning
Dec  8 17:29:14 xps kernel: [  339.275298] wlan0: authenticate with <ROUTER_MAC>
Dec  8 17:29:14 xps kernel: [  339.284920] wlan0: send auth to <ROUTER_MAC> (try 1/3)
Dec  8 17:29:14 xps NetworkManager[758]: <info> (wlan0): supplicant interface state: scanning -> authenticating
Dec  8 17:29:14 xps kernel: [  339.293562] wlan0: authenticated
Dec  8 17:29:14 xps kernel: [  339.293919] wlan0: associate with <ROUTER_MAC> (try 1/3)
Dec  8 17:29:14 xps NetworkManager[758]: <info> (wlan0): supplicant interface state: authenticating -> associating
Dec  8 17:29:14 xps kernel: [  339.301774] wlan0: RX AssocResp from <ROUTER_MAC> (capab=0x411 status=0 aid=2)
Dec  8 17:29:14 xps kernel: [  339.309294] wlan0: associated
Dec  8 17:29:14 xps NetworkManager[758]: <info> (wlan0): supplicant interface state: associating -> associated
Dec  8 17:29:14 xps NetworkManager[758]: <info> (wlan0): supplicant interface state: associated -> 4-way handshake
Dec  8 17:29:14 xps NetworkManager[758]: <info> (wlan0): supplicant interface state: 4-way handshake -> completed
Dec  8 17:29:14 xps NetworkManager[758]: <info> Activation (wlan0/wireless) Stage 2 of 5 (Device Configure) successful.  Connected to wireless network 'MY_WIFI'.
Dec  8 17:29:14 xps NetworkManager[758]: <info> Activation (wlan0) Stage 3 of 5 (IP Configure Start) scheduled.
Dec  8 17:29:14 xps NetworkManager[758]: <info> Activation (wlan0) Stage 3 of 5 (IP Configure Start) started...
Dec  8 17:29:14 xps NetworkManager[758]: <info> (wlan0): device state change: config -> ip-config (reason 'none') [50 70 0]
Dec  8 17:29:14 xps NetworkManager[758]: <info> Activation (wlan0) Beginning DHCPv4 transaction (timeout in 45 seconds)
Dec  8 17:29:14 xps NetworkManager[758]: <info> dhclient started with pid 2336
Dec  8 17:29:14 xps NetworkManager[758]: <info> Activation (wlan0) Beginning IP6 addrconf.
Dec  8 17:29:14 xps avahi-daemon[765]: Withdrawing address record for fe80::4e80:93ff:fe5c:7e0c on wlan0.
Dec  8 17:29:14 xps NetworkManager[758]: <info> Activation (wlan0) Stage 3 of 5 (IP Configure Start) complete.
Dec  8 17:29:14 xps dhclient[2336]: Internet Systems Consortium DHCP Client 4.2.4-P2
Dec  8 17:29:14 xps dhclient[2336]: Copyright 2004-2012 Internet Systems Consortium.
Dec  8 17:29:14 xps dhclient[2336]: All rights reserved.
Dec  8 17:29:14 xps dhclient[2336]: For info, please visit https://www.isc.org/software/dhcp/
Dec  8 17:29:14 xps dhclient[2336]: 
Dec  8 17:29:14 xps NetworkManager[758]: <info> (wlan0): DHCPv4 state changed nbi -> preinit
Dec  8 17:29:14 xps dhclient[2336]: Listening on LPF/wlan0/<INTERFACE_MAC>
Dec  8 17:29:14 xps dhclient[2336]: Sending on   LPF/wlan0/<INTERFACE_MAC>
Dec  8 17:29:14 xps dhclient[2336]: Sending on   Socket/fallback
Dec  8 17:29:14 xps dhclient[2336]: DHCPREQUEST on wlan0 to 255.255.255.255 port 67 (xid=0x42360c53)
Dec  8 17:29:16 xps avahi-daemon[765]: Registering new address record for fe80::4e80:93ff:fe5c:7e0c on wlan0.*.
Dec  8 17:29:19 xps dhclient[2336]: DHCPREQUEST on wlan0 to 255.255.255.255 port 67 (xid=0x42360c53)
Dec  8 17:29:20 xps dhclient[2336]: DHCPACK from 192.168.1.1 (xid=0x42360c53)
Dec  8 17:29:20 xps dhclient[2336]: bound to 192.168.1.3 -- renewal in 40805 seconds.
Dec  8 17:29:20 xps NetworkManager[758]: <info> (wlan0): DHCPv4 state changed preinit -> reboot
Dec  8 17:29:20 xps NetworkManager[758]: <info>   address 192.168.1.3
Dec  8 17:29:20 xps NetworkManager[758]: <info>   prefix 24 (255.255.255.0)
Dec  8 17:29:20 xps NetworkManager[758]: <info>   gateway 192.168.1.1
Dec  8 17:29:20 xps NetworkManager[758]: <info>   nameserver '192.168.1.1'
Dec  8 17:29:20 xps NetworkManager[758]: <info>   domain name 'Home'
Dec  8 17:29:20 xps NetworkManager[758]: <info> Activation (wlan0) Stage 5 of 5 (IPv4 Configure Commit) scheduled...
Dec  8 17:29:20 xps NetworkManager[758]: <info> Activation (wlan0) Stage 5 of 5 (IPv4 Commit) started...
Dec  8 17:29:20 xps avahi-daemon[765]: Joining mDNS multicast group on interface wlan0.IPv4 with address 192.168.1.3.
Dec  8 17:29:20 xps avahi-daemon[765]: New relevant interface wlan0.IPv4 for mDNS.
Dec  8 17:29:20 xps avahi-daemon[765]: Registering new address record for 192.168.1.3 on wlan0.IPv4.
Dec  8 17:29:21 xps NetworkManager[758]: <info> (wlan0): device state change: ip-config -> activated (reason 'none') [70 100 0]
Dec  8 17:29:21 xps NetworkManager[758]: <info> Policy set 'Auto MY_WIFI' (wlan0) as default for IPv4 routing and DNS.
Dec  8 17:29:21 xps NetworkManager[758]: <info> Activation (wlan0) successful, device activated.
Dec  8 17:29:21 xps NetworkManager[758]: <info> Activation (wlan0) Stage 5 of 5 (IPv4 Commit) complete.
Dec  8 17:29:21 xps dbus-daemon[801]: dbus[801]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
Dec  8 17:29:21 xps dbus[801]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
Dec  8 17:29:21 xps dbus-daemon[801]: dbus[801]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Dec  8 17:29:21 xps dbus[801]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Dec  8 17:29:34 xps NetworkManager[758]: <info> (wlan0): IP6 addrconf timed out or failed.
Dec  8 17:29:34 xps NetworkManager[758]: <info> Activation (wlan0) Stage 4 of 5 (IPv6 Configure Timeout) scheduled...
Dec  8 17:29:34 xps NetworkManager[758]: <info> Activation (wlan0) Stage 4 of 5 (IPv6 Configure Timeout) started...
Dec  8 17:29:34 xps NetworkManager[758]: <info> Activation (wlan0) Stage 4 of 5 (IPv6 Configure Timeout) complete.
Dec  8 17:29:40 xps kernel: [  365.069671] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Dec  8 17:30:21 xps kernel: [  406.888483] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Dec  8 17:30:23 xps kernel: [  408.886559] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Dec  8 17:30:25 xps kernel: [  410.884601] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Dec  8 17:30:27 xps kernel: [  412.882627] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Dec  8 17:30:29 xps kernel: [  414.880660] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues

Comment 12 Emmanuel Grumbach 2012-12-09 07:14:09 UTC
(In reply to comment #11)
> Hi all,
> 
> I believe that had this problem today in Fedora 17 x86_64 (Linux version
> 3.6.8-2.fc17.x86_64). That is my message log:
> 

No this is the name the same log. Not the same WARN_ON.

Comment 13 Stanislaw Gruszka 2012-12-10 12:14:06 UTC
WARNING seems to gone, but there is "fail to flush all tx fifo queues" problem. Does someone have reliable way to reproduce this?

Comment 14 Emmanuel Grumbach 2012-12-10 12:17:14 UTC
Stanislaw, I would suggest to look at http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2387 too.

We didn't reclaim frames in certain circumstances. Not reclaiming can prevent queues from being flushed...

Comment 15 Emmanuel Grumbach 2012-12-10 12:18:10 UTC
And here is direct link to the fix:
http://bugzilla.intellinuxwireless.org/attachment.cgi?id=2818

It will be sent soon (probably when the 3.8 merge window gets closed)

Comment 16 Stanislaw Gruszka 2012-12-10 15:12:56 UTC
Lunched kernel build with patch from above comment here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=4773192

Reporters: please run this kernel in a long run and check if "fail to flush all tx fifo queues" problem is gone.

Comment 17 Stanislaw Gruszka 2012-12-17 16:56:53 UTC
*** Bug 882342 has been marked as a duplicate of this bug. ***

Comment 18 Stanislaw Gruszka 2012-12-17 16:58:12 UTC
Please test kernel from comment 16.

Comment 19 Emmanuel Grumbach 2012-12-23 09:48:26 UTC
Created attachment 667944 [details]
queue flush fix

May solve the issue

Comment 20 Emmanuel Grumbach 2012-12-31 08:07:11 UTC
Created attachment 670702 [details]
better fix

Comment 21 Emmanuel Grumbach 2012-12-31 08:28:25 UTC
There is also another direction I am trying to track.

Can you please see what happens when you load the driver without powersave?
modprobe iwlwifi power_save=0

Thanks

Comment 22 Philipp Dreimann 2013-01-01 12:21:02 UTC
Created attachment 670947 [details]
dmesg output with 3.8-rc1

The connection needed to be reset manually after the first iwlwifi: fail to flush all tx fifo queues messages.

Comment 23 Emmanuel Grumbach 2013-01-01 12:24:03 UTC
can you please apply the patch in comment 20?

Comment 24 Philipp Dreimann 2013-01-01 12:38:36 UTC
The first part of the patch seems to be in 3.8-rc1 already. 

I'm testing the patch now.

By the way: The error is happening more often since the wifi ap was relocated to a location resulting in a worse signal for myself.

Comment 25 Philipp Dreimann 2013-01-01 17:37:05 UTC
Created attachment 671008 [details]
dmesg output after applying the patch and setting power_save to 0

The first two warnings appeared often and redundant warnings are removed.

Comment 26 Emmanuel Grumbach 2013-01-02 10:25:01 UTC
Created attachment 671345 [details]
get better logs

Please reproduce the bug with debug=0xC0800000

and provide all the logs. It will be chatty, but I need all the logs.
Send your /var/log/kern.log if needed.

You can also send the log to me privately if you feel more comfortable.

Comment 27 Philipp Dreimann 2013-01-02 17:23:01 UTC
I guess that the patch is incomplete:

  CC [M]  drivers/net/wireless/iwlwifi/pcie/trans.o
drivers/net/wireless/iwlwifi/pcie/trans.c: In function ‘iwl_trans_pcie_wait_txq_empty’:
drivers/net/wireless/iwlwifi/pcie/trans.c:801:2: error: implicit declaration of function ‘iwl_trans_read_mem_bytes’ [-Werror=implicit-function-declaration]
drivers/net/wireless/iwlwifi/pcie/trans.c:814:4: error: implicit declaration of function ‘iwl_trans_read_mem32’ [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[4]: *** [drivers/net/wireless/iwlwifi/pcie/trans.o] Error 1

Comment 28 Emmanuel Grumbach 2013-01-02 19:56:02 UTC
stupid me

I made this patch on top of another patch that I haven't published yet... Sorry for the mess. I will fix that tomorrow morning....

Comment 29 Emmanuel Grumbach 2013-01-02 20:09:19 UTC
Created attachment 671662 [details]
get better logs

so in the end I fixed the patch tonight :-)

thanks for your help testing

Comment 30 Emmanuel Grumbach 2013-01-03 11:16:27 UTC
Created attachment 671997 [details]
get better logs

unfortunately, some logs were aggregated and didn't appear correctly.
I made another patch that should improve the situation.
Can you please retry with this one?

Thanks!

Comment 31 Emmanuel Grumbach 2013-01-03 12:00:29 UTC
Created attachment 672014 [details]
get better logs

Oops. This new patch will save quite a few prints

Comment 32 Emmanuel Grumbach 2013-01-09 08:23:09 UTC
Created attachment 675302 [details]
fix rate scaling

Comment 33 Emmanuel Grumbach 2013-01-09 08:25:12 UTC
I am kinda hoping that this patch can help.
Can you test please?

Thanks!

Comment 34 Emmanuel Grumbach 2013-01-09 20:46:00 UTC
Created attachment 675851 [details]
fix rate scaling

same patch as before, but nicer :-)

Comment 35 Kevin Fenzi 2013-01-11 04:25:33 UTC
I'm possibly seeing this here on the latest rawhide nodebug kernel. 

3.8.0-0.rc2.git4.2.fc19.x86_64

I get: 

[80335.180291] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[80454.904379] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[80460.097327] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[80574.405088] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[80694.112326] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[80933.540652] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[81053.254828] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[81172.966047] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues

and file transfers are very very slow. ;( I don't get the oops or any crashes/disconnects tho. 

Same bug? or should I open a new one on this issue?

Comment 36 Emmanuel Grumbach 2013-01-11 04:58:43 UTC
(In reply to comment #35)
> I'm possibly seeing this here on the latest rawhide nodebug kernel. 
> 
> 3.8.0-0.rc2.git4.2.fc19.x86_64
> 
> I get: 
> 
> [80335.180291] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
> [80454.904379] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
> [80460.097327] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
> [80574.405088] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
> [80694.112326] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
> [80933.540652] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
> [81053.254828] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
> [81172.966047] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
> 
> and file transfers are very very slow. ;( I don't get the oops or any
> crashes/disconnects tho. 
> 
> Same bug? or should I open a new one on this issue?

yes - and please test the fix in comment 33

Comment 37 Philipp Dreimann 2013-01-11 09:52:00 UTC
(In reply to comment #34)

The patch does unfortunately not fix the issue for me.

If the module is being loaded with power_save=1, the connection appears to be stable (with or without the patch), but feels somehow slower. (I could look into quantizing this if needed.)

Comment 38 Emmanuel Grumbach 2013-01-11 10:30:12 UTC
does 3.7 work for you?

Comment 39 Kevin Fenzi 2013-01-11 17:22:30 UTC
I was pointed to: 

see https://patchwork.kernel.org/patch/1927911/ , which is heading upstream: http://article.gmane.org/gmane.linux.kernel/1419214

on IRC. May be related?

3.7 worked fine here. It was only the 3.8 RC's that seem to be showing the issue.

Comment 40 Emmanuel Grumbach 2013-01-12 18:06:28 UTC
right - so this patch is on the way (merged to wireless.git, but not yet to net.git and of course not in mainline).

In any case:
Kevin, please test the patch in comment 34.

Philipp, can you please tell me if 3.7 works for you?

Thanks to both of you

Comment 41 Kay Schubert 2013-01-13 21:42:55 UTC
problem happened immediately after wakeup from S4
notebook uses WLAN-connection


Package: kernel
OS Release: Fedora release 18 (Spherical Cow)

Comment 42 Kevin Fenzi 2013-01-13 23:06:59 UTC
I've only tested for a few minutes with the patch in comment 34, but for me here it's MUCH MUCH faster. 
Before I would see transfers drop to 100k/sec or something, but now I am seeing 3-4MB/sec as before. 

Scratch build with patch: 

http://koji.fedoraproject.org/koji/taskinfo?taskID=4865819

Comment 43 Emmanuel Grumbach 2013-01-14 07:04:04 UTC
(In reply to comment #41)
> problem happened immediately after wakeup from S4
> notebook uses WLAN-connection

Can you please provide logs?
What kernel / code are you using?

Comment 44 Kay Schubert 2013-01-14 08:45:46 UTC
(In reply to comment #43)
> (In reply to comment #41)
> > problem happened immediately after wakeup from S4
> > notebook uses WLAN-connection
> 
> Can you please provide logs?
> What kernel / code are you using?

Sorry, my comment came by abrt, I wasn't aware it didn't attach any further info. I'm not even sure, that my issue and that issue here are at all related - it was abrt, that picked this.

System is a Lenovo T400s.

output of lcpci:

00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:03.0 Communication controller: Intel Corporation Mobile 4 Series Chipset MEI Controller (rev 07)
00:03.2 IDE interface: Intel Corporation Mobile 4 Series Chipset PT IDER Controller (rev 07)
00:03.3 Serial controller: Intel Corporation Mobile 4 Series Chipset AMT SOL Redirection (rev 07)
00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)
00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03)
00:1a.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03)
00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03)
00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 03)
00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
00:1f.0 ISA bridge: Intel Corporation ICH9M-E LPC Interface Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation 82801IBM/IEM (ICH9M/ICH9M-E) 4 port SATA Controller [AHCI mode] (rev 03)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)
03:00.0 Network controller: Intel Corporation Ultimate N WiFi Link 5300
05:00.0 SD Host controller: Ricoh Co Ltd MMC/SD Host Controller (rev 01)
05:00.1 System peripheral: Ricoh Co Ltd R5U2xx (R5U230 / R5U231 / R5U241) [Memory Stick Host Controller] (rev 01)

BOOT_IMAGE=/vmlinuz-3.6.11-3.fc18.x86_64 root=/dev/mapper/system-fedora_root ro rd.md=0 rd.dm=0 rd.lvm.lv=system/fedora_root SYSFONT=True rd.luks=0 KEYTABLE=de-latin1-nodeadkeys LANG=de_DE.utf8 rhgb quiet

WARNING: at drivers/net/wireless/iwlwifi/dvm/sta.c:888 iwl_send_lq_cmd+0x282/0x290 [iwldvm]()
Hardware name: 2808D4G
Modules linked in: tcp_lp fuse ipt_MASQUERADE nf_conntrack_netbios_ns nf_conntrack_broadcast ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tables rfcomm bnep uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev media arc4 iTCO_wdt iTCO_vendor_support iwldvm mac80211 snd_hda_codec_conexant coretemp kvm_intel kvm microcode joydev i2c_i801 cdc_wdm cdc_ether usbnet mii cdc_acm snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device lpc_ich mfd_core snd_pcm iwlwifi snd_page_alloc cfg80211 snd_timer btusb bluetooth e1000e mei thinkpad_acpi snd soundcore rfkill tpm_tis tpm tpm_bios uinput sdhci_pci i915 sdhci mmc_core i2c_algo_bit ata_generic drm_kms_helper drm pata_acpi i2c_core wmi video
Pid: 798, comm: wpa_supplicant Not tainted 3.6.11-3.fc18.x86_64 #1
Jan 13 22:33:51 somehostname kernel: [65611.754255] wlan0: authenticate with xx:xx:xx:xx:xx:xx
Jan 13 22:33:51 somehostname kernel: [65611.758417] wlan0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
Jan 13 22:33:51 somehostname NetworkManager[670]: <info> (wlan0): supplicant interface state: scanning -> authenticating
Jan 13 22:33:51 somehostname kernel: [65611.959062] wlan0: send auth to xx:xx:xx:xx:xx:xx (try 2/3)
Jan 13 22:33:51 somehostname kernel: [65611.960202] wlan0: authenticated
Jan 13 22:33:51 somehostname kernel: [65611.960987] ------------[ cut here ]------------
Jan 13 22:33:51 somehostname kernel: [65611.961025] WARNING: at drivers/net/wireless/iwlwifi/dvm/sta.c:888 iwl_send_lq_cmd+0x282/0x290 [iwldvm]()
Jan 13 22:33:51 somehostname kernel: [65611.961062] Hardware name: 2808D4G
Jan 13 22:33:51 somehostname kernel: [65611.961065] Modules linked in: tcp_lp fuse ipt_MASQUERADE nf_conntrack_netbios_ns nf_conntrack_broadcast ip
6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_
conntrack ebtable_filter ebtables ip6table_filter ip6_tables rfcomm bnep uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev m
edia arc4 iTCO_wdt iTCO_vendor_support iwldvm mac80211 snd_hda_codec_conexant coretemp kvm_intel kvm microcode joydev i2c_i801 cdc_wdm cdc_eth
er usbnet mii cdc_acm snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device lpc_ich mfd_core snd_pcm iwlwifi snd_page_alloc cfg80211 sn
d_timer btusb bluetooth e1000e mei thinkpad_acpi snd soundcore rfkill tpm_tis tpm tpm_bios uinput sdhci_pci i915 sdhci mmc_core i2c_algo_bit a
ta_generic drm_kms_helper drm pata_acpi i2c_core wmi video
Jan 13 22:33:51 somehostname kernel: [65611.961194] Pid: 798, comm: wpa_supplicant Not tainted 3.6.11-3.fc18.x86_64 #1
Jan 13 22:33:51 somehostname kernel: [65611.961198] Call Trace:
Jan 13 22:33:51 somehostname kernel: [65611.961213]  [<ffffffff8105c8df>] warn_slowpath_common+0x7f/0xc0
Jan 13 22:33:51 somehostname kernel: [65611.961220]  [<ffffffff8105c93a>] warn_slowpath_null+0x1a/0x20
Jan 13 22:33:51 somehostname kernel: [65611.961240]  [<ffffffffa04c4ff2>] iwl_send_lq_cmd+0x282/0x290 [iwldvm]
Jan 13 22:33:51 somehostname kernel: [65611.961249]  [<ffffffff8113461e>] ? free_pages+0x5e/0x80
Jan 13 22:33:51 somehostname kernel: [65611.961268]  [<ffffffffa04c52ba>] iwl_restore_stations+0x2ba/0x410 [iwldvm]
Jan 13 22:33:51 somehostname kernel: [65611.961290]  [<ffffffffa04cc251>] iwlagn_commit_rxon+0x7f1/0xdc0 [iwldvm]
Jan 13 22:33:51 somehostname kernel: [65611.961300]  [<ffffffff81623c15>] ? _raw_write_trylock+0x5/0x30
Jan 13 22:33:51 somehostname kernel: [65611.961319]  [<ffffffffa04c5d95>] ? iwl_update_bcast_station+0x75/0xe0 [iwldvm]
Jan 13 22:33:51 somehostname kernel: [65611.961337]  [<ffffffffa04ccaf6>] iwlagn_mac_config+0x286/0x3d0 [iwldvm]
Jan 13 22:33:51 somehostname kernel: [65611.961372]  [<ffffffffa0408527>] ieee80211_hw_config+0x117/0x240 [mac80211]
Jan 13 22:33:51 somehostname kernel: [65611.961416]  [<ffffffffa04402de>] ieee80211_prep_connection+0xde/0x590 [mac80211]
Jan 13 22:33:51 somehostname kernel: [65611.961424]  [<ffffffff8117b48d>] ? __kmalloc+0x14d/0x1a0
Jan 13 22:33:51 somehostname kernel: [65611.961464]  [<ffffffffa0445828>] ieee80211_mgd_assoc+0x438/0x5e0 [mac80211]
Jan 13 22:33:51 somehostname kernel: [65611.961498]  [<ffffffffa041c1c6>] ieee80211_assoc+0x56/0x80 [mac80211]
Jan 13 22:33:51 somehostname kernel: [65611.961531]  [<ffffffffa02600c6>] __cfg80211_mlme_assoc+0x276/0x2b0 [cfg80211]
Jan 13 22:33:51 somehostname kernel: [65611.961548]  [<ffffffff81096cc9>] ? update_curr+0x99/0x180
Jan 13 22:33:51 somehostname kernel: [65611.961571]  [<ffffffffa02601b9>] cfg80211_mlme_assoc+0xb9/0xf0 [cfg80211]
Jan 13 22:33:51 somehostname kernel: [65611.961592]  [<ffffffffa0251631>] nl80211_associate+0x221/0x2b0 [cfg80211]
Jan 13 22:33:51 somehostname kernel: [65611.961607]  [<ffffffff815404c0>] genl_rcv_msg+0x250/0x2d0
Jan 13 22:33:51 somehostname kernel: [65611.961615]  [<ffffffff81540270>] ? genl_rcv+0x40/0x40
Jan 13 22:33:51 somehostname kernel: [65611.961622]  [<ffffffff8153fde1>] netlink_rcv_skb+0xa1/0xb0
Jan 13 22:33:51 somehostname kernel: [65611.961628]  [<ffffffff81540255>] genl_rcv+0x25/0x40
Jan 13 22:33:51 somehostname kernel: [65611.961635]  [<ffffffff8153f73d>] netlink_unicast+0x19d/0x220
Jan 13 22:33:51 somehostname kernel: [65611.961643]  [<ffffffff8153fa98>] netlink_sendmsg+0x2d8/0x390
Jan 13 22:33:51 somehostname kernel: [65611.961651]  [<ffffffff814feedc>] sock_sendmsg+0xbc/0xf0
Jan 13 22:33:51 somehostname kernel: [65611.961658]  [<ffffffff8153f745>] ? netlink_unicast+0x1a5/0x220
Jan 13 22:33:51 somehostname kernel: [65611.961665]  [<ffffffff8153f8f0>] ? netlink_sendmsg+0x130/0x390
Jan 13 22:33:51 somehostname kernel: [65611.961673]  [<ffffffff814ff2bc>] __sys_sendmsg+0x3ac/0x3c0
Jan 13 22:33:51 somehostname kernel: [65611.961682]  [<ffffffff81501159>] sys_sendmsg+0x49/0x90
Jan 13 22:33:51 somehostname kernel: [65611.961690]  [<ffffffff8162bd69>] system_call_fastpath+0x16/0x1b
Jan 13 22:33:51 somehostname kernel: [65611.961695] ---[ end trace f0bd6c92eb69e863 ]---
Jan 13 22:33:51 somehostname kernel: [65611.962061] wlan0: associate with xx:xx:xx:xx:xx:xx (try 1/3)
Jan 13 22:33:51 somehostname kernel: [65611.963437] wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x411 status=0 aid=2)
Jan 13 22:33:51 somehostname kernel: [65611.964978] wlan0: associated

Comment 45 Emmanuel Grumbach 2013-01-14 08:48:50 UTC
this log shows that your issue is not related to the bug being discussed here.

I will therefore ignore it in the context of this bug.

Comment 46 Emmanuel Grumbach 2013-01-14 08:50:57 UTC
The current state of this bug is that we have one user (Kevin) reporting big improvements.
Another user (Philipp) says that the issue still reproduces.

Philipp can you please provide logs of the issue with the "fix rate scaling" patch applied?

Thanks

Comment 47 Philipp Dreimann 2013-01-14 10:29:18 UTC
(In reply to comment #40),
3.7 works, but is fairly slow.

(In reply to comment #46)
I'll have a look at it. Which combinations would be most important to test?

3.7.2, 3.8-rc1 (the one I previously used) or 3.8-rc2 , each with "get better logs", and together with "better fix" and/or "fix rate scaling"?

(I guess best would be all, but time is limited..)

Comment 48 Emmanuel Grumbach 2013-01-14 10:32:40 UTC
(In reply to comment #47)
> (In reply to comment #40),
> 3.7 works, but is fairly slow.
> 
> (In reply to comment #46)
> I'll have a look at it. Which combinations would be most important to test?
> 
> 3.7.2, 3.8-rc1 (the one I previously used) or 3.8-rc2 , each with "get
> better logs", and together with "better fix" and/or "fix rate scaling"?
> 
No, only one :-)
3.8-rcX (whatever X is) with "get better logs" and the second "fix rate scaling' (https://bugzilla.redhat.com/show_bug.cgi?id=863424).
Thanks!

Comment 49 jeefoo 2013-01-15 12:49:16 UTC
Hi all, Hi Gruszka again,

I have a similar problem, with my lenovo notebook, here are my dmesg logs:

fail to flush all tx fifo queues
[17316.995017] CIFS VFS: Server 10.1.1.1 has not responded in 120 seconds. Reconnecting...
[17353.201132] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[17594.029378] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[17713.777893] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[17789.744922] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[17791.745845] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[17791.768196] ------------[ cut here ]------------
[17791.768237] WARNING: at drivers/net/wireless/iwlwifi/dvm/tx.c:1187 iwlagn_rx_reply_tx+0x9b6/0x9f0 [iwldvm]()
[17791.768240] Hardware name: 5016NW6
[17791.768243] Modules linked in: tun cdc_acm usb_storage des_generic md4 fcoe libfcoe libfc scsi_transport_fc scsi_tgt 8021q garp stp llc nls_utf8 cifs dns_resolver fscache vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio libcxgbi ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev media snd_hda_codec_hdmi snd_hda_codec_realtek arc4 iwldvm snd_hda_intel mac80211 snd_hda_codec thinkpad_acpi snd_hwdep coretemp kvm_intel snd_seq snd_seq_device iwlwifi kvm snd_pcm cfg80211 rfkill r8169 iTCO_wdt iTCO_vendor_support snd_page_alloc snd_timer snd mei lpc_ich mii mfd_core soundcore microcode i2c_i801 serio_raw ecryptfs encrypted_keys trusted tpm tpm_bios binfmt_misc uinput crc32c_intel ghash_clmulni_intel wmi i915 video i2c_algo_bit drm_kms_helper drm i2c_core
[17791.768378] Pid: 0, comm: swapper/1 Tainted: G         C O 3.6.11-1.fc17.x86_64 #1
[17791.768381] Call Trace:
[17791.768384]  <IRQ>  [<ffffffff8105c8ef>] warn_slowpath_common+0x7f/0xc0
[17791.768403]  [<ffffffff8105c94a>] warn_slowpath_null+0x1a/0x20
[17791.768422]  [<ffffffffa02ff3c6>] iwlagn_rx_reply_tx+0x9b6/0x9f0 [iwldvm]
[17791.768443]  [<ffffffffa0309193>] iwl_rx_dispatch+0xa3/0x110 [iwldvm]
[17791.768460]  [<ffffffffa0450fa8>] iwl_irq_tasklet+0x7e8/0xba0 [iwlwifi]
[17791.768472]  [<ffffffff81065a53>] tasklet_action+0x63/0xd0
[17791.768480]  [<ffffffff810654c0>] __do_softirq+0xd0/0x210
[17791.768488]  [<ffffffff8101b933>] ? native_sched_clock+0x13/0x80
[17791.768495]  [<ffffffff816284bc>] call_softirq+0x1c/0x30
[17791.768503]  [<ffffffff81016205>] do_softirq+0x75/0xb0
[17791.768511]  [<ffffffff810658b5>] irq_exit+0xb5/0xc0
[17791.768517]  [<ffffffff81628d13>] do_IRQ+0x63/0xe0
[17791.768525]  [<ffffffff8161f5ea>] common_interrupt+0x6a/0x6a
[17791.768527]  <EOI>  [<ffffffff810ac312>] ? ktime_get+0x52/0xe0
[17791.768544]  [<ffffffff81338a7d>] ? intel_idle+0xed/0x150
[17791.768550]  [<ffffffff81338a5e>] ? intel_idle+0xce/0x150
[17791.768558]  [<ffffffff814cbee9>] cpuidle_enter+0x19/0x20
[17791.768563]  [<ffffffff814cc579>] cpuidle_idle_call+0xa9/0x250
[17791.768570]  [<ffffffff8101d52f>] cpu_idle+0xaf/0x120
[17791.768577]  [<ffffffff8160df19>] start_secondary+0x23e/0x240
[17791.768582] ---[ end trace 7e0a66d56bd847f5 ]---
[17791.778981] cfg80211: Calling CRDA to update world regulatory domain
[17791.782723] cfg80211: World regulatory domain updated:
[17791.782729] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[17791.782735] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[17791.782769] cfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[17791.782775] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[17791.782780] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[17791.782786] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[17791.782845] cfg80211: Calling CRDA for country: HU
[17791.787200] cfg80211: Regulatory domain changed to country: HU
[17791.787206] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[17791.787211] cfg80211:   (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[17791.787215] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[17791.787219] cfg80211:   (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[17791.787223] cfg80211:   (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
[17793.779764] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[17794.267679] wlan0: authenticate with 74:ea:3a:a5:d3:28
[17794.278895] wlan0: send auth to 74:ea:3a:a5:d3:28 (try 1/3)
[17794.283361] wlan0: authenticated
[17794.283782] wlan0: waiting for beacon from 74:ea:3a:a5:d3:28
[17794.386448] wlan0: associate with 74:ea:3a:a5:d3:28 (try 1/3)
[17794.390521] wlan0: RX AssocResp from 74:ea:3a:a5:d3:28 (capab=0x431 status=0 aid=1)
[17794.394388] wlan0: associated
[17833.525321] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[17865.736867] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[17867.736786] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[17867.771966] cfg80211: Calling CRDA to update world regulatory domain

This happens in fedora 17 x86_64. Kernel: 3.6.11-1.fc17.x86_64

Before a year I had a problem with another intel wireless 5100 agn card, it still hasn't got fixed. 

I'm afraid, there will be no support in the future for intel wifi cards under linux. I think linux users do better if they choose not intel wireless cards, these card fails many times under linux and no fixes for it.

Cheers, Balazs

Comment 50 Emmanuel Grumbach 2013-01-15 12:55:34 UTC
(In reply to comment #49)
> Hi all, Hi Gruszka again,
> 
> I have a similar problem, with my lenovo notebook, here are my dmesg logs:
> 
What code, what kernel, etc....

And please try to the patch attached to this bug.

Comment 51 jeefoo 2013-01-15 13:13:56 UTC
Kernel: 3.6.11-1.fc17.x86_64 As I wrote before. I downloaded the patch in comment 34, but what kernel I have to patch with it? 

May I download the new stable kernel (linux-3.7.2) from kernel.org, and patch that with this patch?

Comment 52 Emmanuel Grumbach 2013-01-15 13:15:43 UTC
that patch is irrelevant for any stable kernel

Comment 53 Emmanuel Grumbach 2013-01-15 13:33:13 UTC
can you please reproduce with the "get better logs" patch?

Comment 54 Stanislaw Gruszka 2013-01-17 15:39:14 UTC
*** Bug 866866 has been marked as a duplicate of this bug. ***

Comment 55 Philipp Dreimann 2013-01-23 11:40:45 UTC
I used 3.8-rc1 again with get better logs (which does not apply cleanly to mainline, could you rebase it to 3.8-rc1?) and the latest fix.

What I experienced was the following:
1. Very slow, but working connection (hundreds of kilobyte/s)
2. A fast connection- (~ 2.5MB/s)
3. The connection basically did not let any data through and I had to reset it 
4. A slow connection (hundreds of kilobyte/s)
5. Varying speed after a while

While using a laptop with a iwl3945 supported wifi card, I noticed that it also suffers from the fail to flush all tx fifo queues issue (using a 3.6 kernel) but the connection re-establishes itself so that I only noticed it while browsing through the kernel messages.

(The logfile was sent by mail.)

Comment 56 Kevin Fenzi 2013-01-23 20:55:43 UTC
The last two rawhide kernels have been worse for me. ;( 

kernel-3.8.0-0.rc4.git1.1.fc19.x86_64
and
kernel-3.8.0-0.rc4.git3.1.fc19.x86_64

both give me the fail to flush all tx fifo queues message and stop working after a few minutes. 

I've not tried the one line patch from comment 34 on them. Is there any ETA when that might land upstream?

Comment 57 Emmanuel Grumbach 2013-01-26 19:22:54 UTC
(In reply to comment #56)
> The last two rawhide kernels have been worse for me. ;( 
> 
> kernel-3.8.0-0.rc4.git1.1.fc19.x86_64
> and
> kernel-3.8.0-0.rc4.git3.1.fc19.x86_64
> 
> both give me the fail to flush all tx fifo queues message and stop working
> after a few minutes. 
> 
> I've not tried the one line patch from comment 34 on them. Is there any ETA
> when that might land upstream?

Dunno. It is not yet in net.git even though John sent the pull request to davem.

Comment 58 Stanislaw Gruszka 2013-01-28 13:04:29 UTC
I do not see those patches even on John wireless tree. Let's apply them.

Josh, please apply to 3.8:
http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi-fixes.git;a=commitdiff;h=c3e5d7181afb66657393066bccce0956fab09ab3

and to 3.7 and 3.8:
http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi-fixes.git;a=commitdiff;h=ae023b2795d36f0f077e157428eb7eafa29ee412

Those two patches should fix most problems here. Apparently they will not fix 3.6, but since F-16 is near to EOL, users are encourage to update to F-17. 

If you will still have the same problem, please open a new bug report and add link to it here.

Comment 59 Josh Boyer 2013-01-28 13:37:39 UTC
OK.  I'll get these in shortly.

Comment 60 Emmanuel Grumbach 2013-01-28 15:11:13 UTC
(In reply to comment #58)
> I do not see those patches even on John wireless tree. Let's apply them.
> 
> Josh, please apply to 3.8:
> http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi-fixes.git;
> a=commitdiff;h=c3e5d7181afb66657393066bccce0956fab09ab3

In davem's tree:
http://git.kernel.org/?p=linux/kernel/git/davem/net.git;a=commit;h=c3e5d7181afb66657393066bccce0956fab09ab3

> 
> and to 3.7 and 3.8:
> http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi-fixes.git;
> a=commitdiff;h=ae023b2795d36f0f077e157428eb7eafa29ee412
> 

Right - it hasn't been published yet. We should do that soon.

Comment 61 Josh Boyer 2013-01-29 12:35:52 UTC
These were added to F17/F18 and rawhide yesterday.  Thanks.

Comment 62 Fedora Update System 2013-01-29 16:08:51 UTC
kernel-3.7.5-101.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/kernel-3.7.5-101.fc17

Comment 63 Fedora Update System 2013-01-29 16:25:02 UTC
kernel-3.7.5-201.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/kernel-3.7.5-201.fc18

Comment 64 Fedora Update System 2013-02-01 16:45:44 UTC
Package kernel-3.7.5-101.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.7.5-101.fc17'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-1706/kernel-3.7.5-101.fc17
then log in and leave karma (feedback).

Comment 65 Fedora Update System 2013-02-04 21:57:06 UTC
kernel-3.7.6-102.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/kernel-3.7.6-102.fc17

Comment 66 Fedora Update System 2013-02-05 03:07:37 UTC
kernel-3.7.5-201.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 67 Fedora Update System 2013-02-16 01:20:20 UTC
kernel-3.7.6-102.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 68 charalambos papaloizou 2013-02-17 15:57:13 UTC
[18475.933923] iwlwifi 0000:04:00.0: fail to flush all tx fifo queues
[18477.933896] iwlwifi 0000:04:00.0: fail to flush all tx fifo queues
[18479.946872] iwlwifi 0000:04:00.0: fail to flush all tx fifo queues
[18481.955813] iwlwifi 0000:04:00.0: fail to flush all tx fifo queues
[18483.956807] iwlwifi 0000:04:00.0: fail to flush all tx fifo queues
[18485.956729] iwlwifi 0000:04:00.0: fail to flush all tx fifo queues
[18487.956703] iwlwifi 0000:04:00.0: fail to flush all tx fifo queues
[18489.957697] iwlwifi 0000:04:00.0: fail to flush all tx fifo queues
[18491.958637] iwlwifi 0000:04:00.0: fail to flush all tx fifo queues

uname -r : 3.7.7-201.fc18.x86_64
lspci : 04:00.0 Network controller: Intel Corporation Centrino Wireless-N 2230 (rev c4)

i realized my connection was slower than usual the past week so i checked the log files and found this. hope the info helps.

Comment 69 Robert de Rooy 2013-03-07 08:05:53 UTC
This is still happening with kernel 3.8.1-201.fc18.x86_64

Mar  7 08:41:49 t410 kernel: [25538.906746] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Mar  7 08:41:51 t410 kernel: [25540.905249] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Mar  7 08:41:53 t410 kernel: [25542.903742] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Mar  7 08:41:55 t410 kernel: [25544.902300] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Mar  7 08:41:57 t410 kernel: [25546.900847] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Mar  7 08:41:59 t410 kernel: [25548.898429] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Mar  7 08:42:01 t410 kernel: [25550.895978] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Mar  7 08:42:03 t410 kernel: [25552.894566] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues

ThinkPad T410 with
03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6200 (rev 35)

This happens several times a day. Networking stops with with the above errors in the log. This also happened with previous (3.7 and 3.6) kernels.
workaround is to toggle the rfkill switch, but that also breaks various other things I may have running (e.g. vpn, ssh). It seems to be easiest to trigger when streaming some video.

Comment 70 Bill McGonigle 2013-03-19 23:53:18 UTC
after resume from hibernate on 3.7.9-104.fc17.x86_64:

[232889.375283] cfg80211:   (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4000 mBm)
[232892.313730] wlan0: authenticate with e0:91:f5:01:c5:59
[232892.315760] wlan0: send auth to e0:91:f5:01:c5:59 (try 1/3)
[232892.319530] wlan0: authenticated
[232892.319648] wlan0: waiting for beacon from e0:91:f5:01:c5:59
[232892.420057] wlan0: associate with e0:91:f5:01:c5:59 (try 1/3)
[232892.423569] wlan0: RX AssocResp from e0:91:f5:01:c5:59 (capab=0x411 status=0 aid=2)
[232892.425199] wlan0: associated

--- wifi works for a short time ---

[232937.162743] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[232939.162228] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues

--- repeat a few dozen more times ---

hardware is Thinkpad E430 with:
 03:00.0 Network controller: Intel Corporation Device 0888 (rev c4)

I'm running this to "fix" it:

 $ cat /usr/local/sbin/reload_iwlwifi 
 #!/bin/sh
 /usr/sbin/modprobe -r iwldvm iwlwifi
 /usr/sbin/modprobe iwlwifi

What would be the most helpful way to help with debugging at this point?

Comment 71 nmetro 2013-03-21 22:48:44 UTC
This problem is also affecting 3.7.9-104.fc17.x86_64 #1 SMP Sun Feb 24 19:19:12 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux. This is with a 08:00.0 Network controller: Intel Corporation WiMAX/WiFi Link 5150. 

The following seems to help:

Create or update /etc/modprobe.d/iwlwifi.conf and insert:
options iwlwifi 11n_disable=1
options iwlwifi bt_coex_active=0

FYI, if one is using VPN, or pushing data through their wifi connection, the Wifi crashes with the above error. This happened to me printing a PDF file and not a big one at that. Though, the wifi starts up again, after the crash and the generation of the "fail to flush" message. 

It was far worse when N was turned on; at that point, one would have to force a restart, push their wifi start/stop key or reboot the laptop. 

The "bt_coex_active=0" does help with suspend and resume of the laptop; making things a bit more stable, but again, the wifi will still crash, but not as frequently.

This problem seemed to have started with the 3.6 variant of the kernel, based upon what I found, and has propagated from there. This issue also affects several ports of Linux. bedsides Fedora 17/18, I have seen reports of this issue on Unbutu and Debian. The options noted above came from both Fedora and Unbuntu sources.

The bottom line is that those who are responsible for Kernel development proper have to fix what is broken, In other words, this is not a Fedora or Unbuntu problem per se, but a problem with the Kernel source code provided. 

I hope, someone who reads this, is helped by these notes.

Comment 72 Daniel 2013-03-26 00:09:05 UTC
Confirming the problem on stable kernel 3.7.9-104.fc17.x86_64, I am on a secure network AP. 

I am toggling wifi hardware switch and it comes back.  It not necessarily happens on suspend/resume.  I think it is related to the AP.  If someone knows what I should be looking for or explain better how to debug it I can help.

My Wireless card is  
01:00.0 Network controller: Intel Corporation Centrino Wireless-N 1000



[47392.129950] wlan0: RX AssocResp from 1c:17:d3:cb:d3:51 (capab=0x431 status=0 aid=1)
[47392.135805] wlan0: associated
[47392.136015] cfg80211: Calling CRDA for country: US
[47392.140586] cfg80211: Regulatory domain changed to country: US
[47392.140593] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[47392.140599] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
[47392.140604] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
[47392.140608] cfg80211:   (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[47392.140613] cfg80211:   (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[47392.140617] cfg80211:   (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[47392.140621] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
[47392.140625] cfg80211:   (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4000 mBm)
[47397.706141] iwlwifi 0000:01:00.0: fail to flush all tx fifo queues
[47399.707497] iwlwifi 0000:01:00.0: fail to flush all tx fifo queues
[47401.708902] iwlwifi 0000:01:00.0: fail to flush all tx fifo queues
[47403.710269] iwlwifi 0000:01:00.0: fail to flush all tx fifo queues
[47405.711587] iwlwifi 0000:01:00.0: fail to flush all tx fifo queues
[47407.712949] iwlwifi 0000:01:00.0: fail to flush all tx fifo queues
[47409.714313] iwlwifi 0000:01:00.0: fail to flush all tx fifo queues
[47411.715723] iwlwifi 0000:01:00.0: fail to flush all tx fifo queues
[47413.715992] iwlwifi 0000:01:00.0: fail to flush all tx fifo queues
[47415.716450] iwlwifi 0000:01:00.0: fail to flush all tx fifo queues
[47417.717707] iwlwifi 0000:01:00.0: fail to flush all tx fifo queues
[47419.719098] iwlwifi 0000:01:00.0: fail to flush all tx fifo queues
[47421.720504] iwlwifi 0000:01:00.0: fail to flush all tx fifo queues
[47423.721911] iwlwifi 0000:01:00.0: fail to flush all tx fifo queues
[47424.521997] iwlwifi 0000:01:00.0: RF_KILL bit toggled to disable radio.
[47425.723274] iwlwifi 0000:01:00.0: fail to flush all tx fifo queues

Comment 73 Joey Boggs 2013-03-29 03:48:34 UTC
Same problem here, only noticed it within the past week. Turning wireless off and back on solves the problem

03:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300

kernel version 3.8.1-201.fc18.x86_64

Mar 28 23:39:57 localhost kernel: [111276.430759] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Mar 28 23:39:59 localhost kernel: [111278.430985] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Mar 28 23:40:01 localhost kernel: [111280.431154] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Mar 28 23:40:03 localhost kernel: [111282.432340] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Mar 28 23:40:05 localhost kernel: [111284.433463] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Mar 28 23:40:07 localhost kernel: [111286.433646] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Mar 28 23:40:09 localhost kernel: [111288.434841] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Mar 28 23:40:11 localhost kernel: [111290.435889] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Mar 28 23:40:13 localhost kernel: [111292.436149] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Mar 28 23:40:15 localhost kernel: [111294.436328] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Mar 28 23:40:17 localhost kernel: [111296.436493] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Mar 28 23:40:19 localhost kernel: [111298.440594] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Mar 28 23:40:21 localhost kernel: [111300.440733] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Mar 28 23:40:23 localhost kernel: [111302.441980] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Mar 28 23:40:25 localhost kernel: [111304.442169] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Mar 28 23:40:27 localhost kernel: [111306.442282] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Mar 28 23:40:29 localhost kernel: [111308.443513] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Mar 28 23:40:31 localhost kernel: [111310.443547] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues

Comment 74 Valentin Palade 2013-04-09 20:16:53 UTC
Same problem here. It appears after trying to watch an online video.

ASUS Zenbook UX32VD: 3.8.5-201.fc18.x86_64

Apr  9 22:56:26 zenbook NetworkManager[761]: <info> (wlan0): supplicant interface state: disconnected -> scanning
Apr  9 22:56:27 zenbook dbus-daemon[631]: dbus[631]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper)
Apr  9 22:56:27 zenbook dbus[631]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper)
Apr  9 22:56:27 zenbook dbus-daemon[631]: dbus[631]: [system] Successfully activated service 'org.freedesktop.PackageKit'
Apr  9 22:56:27 zenbook dbus[631]: [system] Successfully activated service 'org.freedesktop.PackageKit'
Apr  9 22:56:28 zenbook kernel: [ 1314.471596] wlan0: authenticate with 00:22:75:60:21:f8
Apr  9 22:56:28 zenbook kernel: [ 1314.473389] wlan0: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded
Apr  9 22:56:28 zenbook kernel: [ 1314.475739] wlan0: send auth to 00:22:75:60:21:f8 (try 1/3)
Apr  9 22:56:28 zenbook NetworkManager[761]: <info> (wlan0): supplicant interface state: scanning -> authenticating
Apr  9 22:56:28 zenbook kernel: [ 1314.484366] wlan0: authenticated
Apr  9 22:56:28 zenbook kernel: [ 1314.485479] wlan0: associate with 00:22:75:60:21:f8 (try 1/3)
Apr  9 22:56:28 zenbook NetworkManager[761]: <info> (wlan0): supplicant interface state: authenticating -> associating
Apr  9 22:56:28 zenbook kernel: [ 1314.514215] wlan0: RX AssocResp from 00:22:75:60:21:f8 (capab=0x401 status=0 aid=1)
Apr  9 22:56:29 zenbook kernel: [ 1314.519136] wlan0: associated
Apr  9 22:56:29 zenbook NetworkManager[761]: <info> (wlan0): supplicant interface state: associating -> completed
Apr  9 22:57:55 zenbook kernel: [ 1400.722925] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Apr  9 22:57:57 zenbook kernel: [ 1402.721934] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Apr  9 22:57:59 zenbook kernel: [ 1404.719973] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Apr  9 22:58:01 zenbook kernel: [ 1406.734851] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Apr  9 22:58:03 zenbook kernel: [ 1408.714093] nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers ins
tead.
Apr  9 22:58:03 zenbook kernel: [ 1408.732939] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Apr  9 22:58:05 zenbook kernel: [ 1410.730903] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Apr  9 22:58:07 zenbook kernel: [ 1412.729898] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Apr  9 22:58:09 zenbook kernel: [ 1414.727841] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Apr  9 22:58:11 zenbook kernel: [ 1416.726839] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Apr  9 22:58:13 zenbook kernel: [ 1418.724886] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Apr  9 22:58:15 zenbook kernel: [ 1420.722862] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Apr  9 22:58:17 zenbook kernel: [ 1422.721879] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Apr  9 22:58:19 zenbook kernel: [ 1424.719865] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Apr  9 22:58:21 zenbook kernel: [ 1426.717870] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Apr  9 22:58:23 zenbook kernel: [ 1428.716904] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Apr  9 22:58:25 zenbook kernel: [ 1430.715892] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Apr  9 22:58:27 zenbook kernel: [ 1432.714893] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Apr  9 22:58:29 zenbook kernel: [ 1434.713939] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
Apr  9 22:58:30 zenbook dbus-daemon[631]: dbus[631]: [system] Activating service name='net.reactivated.Fprint' (using servicehelper)
Apr  9 22:58:30 zenbook dbus[631]: [system] Activating service name='net.reactivated.Fprint' (using servicehelper)
Apr  9 22:58:30 zenbook dbus-daemon[631]: dbus[631]: [system] Successfully activated service 'net.reactivated.Fprint'
Apr  9 22:58:30 zenbook dbus[631]: [system] Successfully activated service 'net.reactivated.Fprint'
Apr  9 22:58:30 zenbook dbus-daemon[631]: Launching FprintObject
Apr  9 22:58:30 zenbook dbus-daemon[631]: ** Message: D-Bus service launched with name: net.reactivated.Fprint
Apr  9 22:58:30 zenbook dbus-daemon[631]: ** Message: entering main loop
Apr  9 22:58:31 zenbook kernel: [ 1436.712941] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues

Comment 75 Bill McGonigle 2013-04-10 19:13:34 UTC
FWIW, I was running a big unison sync (20GB or so) over a DSL connection, which ran for about 3 days, and everything was great.  Once that was done, I picked up the laptop and moved to another room, where the signal for a different AP (same SSID) was likely much stronger, and I got this problem within a minute or so.

Anybody else here running multiple AP's?  I notice some comments about an AP being rebooted above which might cause an association change in certain environments.

Comment 76 Valentin Palade 2013-04-17 08:53:12 UTC
Still happening on latest fedora 18 kernel

ASUS Zenbook UX32VD: kernel-3.8.7-201.fc18.x86_64

Just try to watch an youtube movie and after few seconds, the connection drops and the log shows "fail to flush all tx fifo queues" messages.

Comment 77 Stanislaw Gruszka 2013-05-02 07:34:33 UTC
Intel, this is currently most frequent iwlwifi bug that Fedora users hit.  Any progress on fixing it ?

Comment 78 Jesper Brouer 2013-05-09 18:51:41 UTC
Confirming the problem.

F18 running kernel 3.8.9-200.fc18.x86_64

HW Lenovo T520
Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 3e)

(ps. I'm a RH kernel devel, I can thus easily test any proposed fixes, just point them my way...)

Comment 79 Jesper Brouer 2013-05-09 19:51:15 UTC
My current work-around is to unload and load the kernel module:

# rmmod iwldvm iwlwifi
# modprobe iwlwifi

(I don't know how "stable" this is yet...)

Comment 80 Stanislaw Gruszka 2013-05-10 06:48:55 UTC
Intel, any test or debug patches here ?

Comment 81 Stanislaw Gruszka 2013-05-10 09:48:13 UTC
Created attachment 746018 [details]
iwlwifi_print_flush.patch

Jesper, if Intel folks have no better idea, you can apply this patch and provide dmesg here when it will print "fail to flush all tx fifo queues" warning. It should give some more clue where flush start to fail.

Is possible that this problem happen because we do not stop queues and request flush. That can confuse driver & firmware and result hung. But also is possible that firmware hangs for some other reason and just fail to transmit frames, if so, this will not be easy to solve.

Comment 82 Jesper Brouer 2013-05-13 07:43:19 UTC
The following upstream commit caught my eye, as its seems to touch code in the same area. Perhaps its related?

The commit seems to be part of v3.10-rc1 (v3.10-rc1~132^2~18^2^2~8^2~9)

commit 2d055afdcada4bd8b510e9d2a8566fbded3c9696
Author: Emmanuel Grumbach <emmanuel.grumbach>
Date:   Sun Apr 7 10:13:44 2013 +0300

    iwlwifi: dvm: handle FLUSH ampdu actions from mac80211
    
    Until now we didn't handle properly the FLUSH ampdu action
    coming from mac80211. This could result in SCD queue leak:
    mac80211 would STOP_FLUSH an AMPDU Tx session and remove
    the station. If we had still packets on the ring, we
    wouldn't deallocate the SCD queue and wait for it to be
    empty.
    The indication of the queue being empty comes from the Tx
    response flow which relies on the tid_data structure. The
    problem is that this structure has been cleared when the
    station has been removed.
    In order to solve this issue, block in the STOP_FLUSH
    ampdu_action until the SCD queue is flushed, and only then,
    let mac80211 move forward to remove the station.
    iwlagn_txfifo_flush had to be enhanced to allow this.
    
    The bug fixed here caused the "txq_id mismatch: 12 0" print.
    
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach>
    Signed-off-by: Johannes Berg <johannes.berg>

Comment 83 Jesper Brouer 2013-05-15 12:15:58 UTC
(In reply to comment #81)
> Created attachment 746018 [details]
> iwlwifi_print_flush.patch
> 
> Jesper, if Intel folks have no better idea, you can apply this patch and
> provide dmesg here when it will print "fail to flush all tx fifo queues"
> warning. It should give some more clue where flush start to fail.

I have "unfortunately" not been able to provoke the wifi bug.

I've been running with your patch for 2 days now (I just based it on stable kernel 3.8.13, which should be okay as I didn't notice any changes in this area).

Comment 84 Joey Boggs 2013-05-15 16:38:48 UTC
I'm on kernel-3.8.5-201.fc18.x86_64 and the problem hasn't reappeared. Typically it happened to me multiple times per day but haven't had any issues within the last week or so. Only other change was moving the wireless router to a higher shelf...?

Comment 85 Julian Stecklina 2013-05-19 19:09:02 UTC
Created attachment 750255 [details]
dmesg output with 3.9.2

Comment 86 David Tonhofer 2013-05-31 09:10:59 UTC
Hit this today on 

Fedora 18
kernel 3.9.4-200.fc18.x86_64
Network controller: Intel Corporation WiFi Link 5100

This is the first time it happened on this machine ever.

Also: 

https://bugzilla.kernel.org/show_bug.cgi?id=48921
"iwlwifi triggers HW restart each 300 seconds" 

"It is necessary not all kernel's fault; instead it is Intel's iwlwifi driver
which is mostly screwed up to its fullest. To the best, Intel and Intel's
developers seem to turning deaf ears and blind eyes to all these bug reports.
Well done Intel, you better be not making any more networking hardware as
nothing tells me that you are any needles' capable of doing that." (Bassu 2012-11-08 13:03:53)

Comment 87 Stanislaw Gruszka 2013-05-31 10:04:30 UTC
I hope Intal works on that, though this issue happens at random usually after big uptime, hence it's not easy to diagnose and fix ...

Comment 88 Bill McGonigle 2013-05-31 16:22:00 UTC
Created attachment 755318 [details]
microcode error dmesg - 3.8.13-100.fc17.x86_64

(In reply to Stanislaw Gruszka from comment #87)
> I hope Intal works on that, though this issue happens at random usually
> after big uptime, hence it's not easy to diagnose and fix ...

Thinkpad E430, Centrino wireless, Fedora 17 - large transfers (e.g. play a movie over NFS) in the presence of multiple AP's will usually let me reproduce this within an hour (much to my chagrin).  I'm happy to run whatever tests are available/useful as I actually bought this machine knowing that Intel had open source drivers for their chipset (and didn't search for bug reports ahead of time).  I'd rather not use a USB NIC but this gets fairly embarrassing at client sites ("oh, the linux guy can't even keep a network connection...").

Stanislaw, should I be running the patch you posted recently? 

Oh, that reminds me, new dmesg from the other day ... long, I'll make an attachment.

May 25 22:11:19 aughra kernel: [536106.934541] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
May 25 22:11:19 aughra kernel: [536106.942722] iwlwifi 0000:03:00.0: Microcode SW error detected.  Restarting 0x2000000
...
May 25 22:11:19 aughra kernel: [536106.943696] iwlwifi 0000:03:00.0: Loaded firmware version: 18.168.6.1
May 25 22:11:19 aughra kernel: [536106.943756] iwlwifi 0000:03:00.0: FW error in SYNC CMD REPLY_ADD_STA

Comment 89 Jesper Brouer 2013-05-31 17:44:16 UTC
Hi Stanislaw

Just for the record, I have not been able to reproduce while running the kernel with your debug patches.  I'm now running on kernel 3.9.3-201.fc18.x86_64.

--Jesper

Comment 90 Mikko C. 2013-06-24 19:30:52 UTC
Created attachment 764757 [details]
dmesg output with 3.9.6-200.fc18.x86_64

This is still valid on 3.9.6-200.fc18.x86_64 with Dell XPS 13 with Centrino N 6235.

It has been happening very often to me during the past few months, also on a different laptop with different Intel wifi chipset (1000 BGN).

It might be happening more often if signal is not so strong.

Bit Rate=43.3 Mb/s   Tx-Power=15 dBm
Link Quality=39/70  Signal level=-71 dBm

Comment 91 Arno Teigseth 2013-09-02 06:51:20 UTC
this bugs me also, on linux mint 15 with messages like

kernel: [134055.180663] iwlwifi 0000:02:00.0: fail to flush all tx fifo queues

sys info see

http://pastebin.com/2ia2bU2j

temporary WORKAROUND: rfkill block all; rfkill unblock all or just switch off/on wireless in NetworkManagerApplet


This seems to happen specially if I am downloading something and then suddenly change networks or access points. As stated above, taking down the card and up again with rfkill straightens out the wrinkles till next time. Please tell me what to do to help out with more info on this bug.

Comment 92 Jason Merrill 2013-09-23 21:24:20 UTC
I've been seeing this a lot on my Thinkpad T510 with the wifi in the hotel I'm staying at, with

kernel-PAE-3.8.13-100.fc17.i686
kernel-PAE-3.9.8-100.fc17.i686
kernel-PAE-3.9.10-100.fc17.i686

The /var/log/messages output looks very like attachment 764757 [details].

Comment 93 Leho Kraav 2013-09-23 21:31:15 UTC
I have not had the queue flush wifi problems on 3.10.11 at all, even in the environments where I used to have them constantly on 3.4.y.

Comment 94 Jason Merrill 2013-09-24 16:18:47 UTC
Created attachment 802340 [details]
dmesg exerpt from kernel-PAE-3.10.12-100.fc18.i686

I'm still seeing this issue with kernel-PAE-3.10.12-100.fc18.i686.  dmesg output attached.

Comment 95 Justin M. Forbes 2013-10-18 21:16:12 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 18 kernel bugs.

Fedora 18 has now been rebased to 3.11.4-101.fc18.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 19, and are still experiencing this issue, please change the version to Fedora 19.

If you experience different issues, please open a new bug report for those.

Comment 96 a.izotov 2013-10-27 12:57:12 UTC
Hi 

 F19 kernel 3.11.6-200.fc19.x86_64 laptop samsung U530

Oct 27 23:30:35 F19-home kernel: [33657.949540] iwlwifi 0000:01:00.0: fail to flush all tx fifo queues Q 11
Oct 27 23:30:35 F19-home kernel: [33657.949549] iwlwifi 0000:01:00.0: Current SW read_ptr 95 write_ptr 167
Oct 27 23:30:35 F19-home kernel: [33657.949601] iwl data: 00000000: ff 07 00 00 00 00 00 00 00 00 00 f8 00 00 00 00  ................
Oct 27 23:30:35 F19-home kernel: [33657.949640] iwlwifi 0000:01:00.0: FH TRBs(0) = 0x00000000
Oct 27 23:30:35 F19-home kernel: [33657.949678] iwlwifi 0000:01:00.0: FH TRBs(1) = 0xc010b08a
Oct 27 23:30:35 F19-home kernel: [33657.949716] iwlwifi 0000:01:00.0: FH TRBs(2) = 0x00000000
Oct 27 23:30:35 F19-home kernel: [33657.949753] iwlwifi 0000:01:00.0: FH TRBs(3) = 0x803000b8
Oct 27 23:30:35 F19-home kernel: [33657.949776] iwlwifi 0000:01:00.0: FH TRBs(4) = 0x00000000
Oct 27 23:30:35 F19-home kernel: [33657.949813] iwlwifi 0000:01:00.0: FH TRBs(5) = 0x00000000
Oct 27 23:30:35 F19-home kernel: [33657.949852] iwlwifi 0000:01:00.0: FH TRBs(6) = 0x00000000
Oct 27 23:30:35 F19-home kernel: [33657.949888] iwlwifi 0000:01:00.0: FH TRBs(7) = 0x0070901e
Oct 27 23:30:35 F19-home kernel: [33657.949968] iwlwifi 0000:01:00.0: Q 0 is active and mapped to fifo 3 ra_tid 0x0000 [185,185]
Oct 27 23:30:35 F19-home kernel: [33657.950049] iwlwifi 0000:01:00.0: Q 1 is active and mapped to fifo 2 ra_tid 0x0000 [0,0]
Oct 27 23:30:35 F19-home kernel: [33657.950129] iwlwifi 0000:01:00.0: Q 2 is active and mapped to fifo 1 ra_tid 0x0000 [137,137]
Oct 27 23:30:35 F19-home kernel: [33657.950211] iwlwifi 0000:01:00.0: Q 3 is active and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:30:35 F19-home kernel: [33657.950294] iwlwifi 0000:01:00.0: Q 4 is active and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:30:35 F19-home kernel: [33657.950377] iwlwifi 0000:01:00.0: Q 5 is active and mapped to fifo 4 ra_tid 0x0000 [0,0]
Oct 27 23:30:35 F19-home kernel: [33657.950458] iwlwifi 0000:01:00.0: Q 6 is active and mapped to fifo 2 ra_tid 0x0000 [0,0]
Oct 27 23:30:35 F19-home kernel: [33657.950581] iwlwifi 0000:01:00.0: Q 7 is active and mapped to fifo 5 ra_tid 0x0000 [0,0]
Oct 27 23:30:35 F19-home kernel: [33657.950691] iwlwifi 0000:01:00.0: Q 8 is active and mapped to fifo 4 ra_tid 0x0000 [0,0]
Oct 27 23:30:35 F19-home kernel: [33657.950785] iwlwifi 0000:01:00.0: Q 9 is active and mapped to fifo 7 ra_tid 0x0000 [31,31]
Oct 27 23:30:35 F19-home kernel: [33657.950872] iwlwifi 0000:01:00.0: Q 10 is active and mapped to fifo 5 ra_tid 0x0000 [0,0]
Oct 27 23:30:35 F19-home kernel: [33657.950952] iwlwifi 0000:01:00.0: Q 11 is active and mapped to fifo 1 ra_tid 0x0000 [95,167]
Oct 27 23:30:35 F19-home kernel: [33657.951032] iwlwifi 0000:01:00.0: Q 12 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:30:35 F19-home kernel: [33657.951112] iwlwifi 0000:01:00.0: Q 13 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:30:35 F19-home kernel: [33657.951192] iwlwifi 0000:01:00.0: Q 14 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:30:35 F19-home kernel: [33657.951273] iwlwifi 0000:01:00.0: Q 15 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:30:35 F19-home kernel: [33657.951353] iwlwifi 0000:01:00.0: Q 16 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:30:35 F19-home kernel: [33657.951433] iwlwifi 0000:01:00.0: Q 17 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:30:35 F19-home kernel: [33657.951551] iwlwifi 0000:01:00.0: Q 18 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:30:35 F19-home kernel: [33657.951632] iwlwifi 0000:01:00.0: Q 19 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:31:18 F19-home kernel: [33700.925092] iwlwifi 0000:01:00.0: fail to flush all tx fifo queues Q 11
Oct 27 23:31:18 F19-home kernel: [33700.925103] iwlwifi 0000:01:00.0: Current SW read_ptr 67 write_ptr 190
Oct 27 23:31:18 F19-home kernel: [33700.925154] iwl data: 00000000: f8 ff ff ff 00 fc ff ff ff ff 01 00 ff 00 00 00  ................
Oct 27 23:31:18 F19-home kernel: [33700.925190] iwlwifi 0000:01:00.0: FH TRBs(0) = 0x00000000
Oct 27 23:31:18 F19-home kernel: [33700.925226] iwlwifi 0000:01:00.0: FH TRBs(1) = 0xc010b070
Oct 27 23:31:18 F19-home kernel: [33700.925262] iwlwifi 0000:01:00.0: FH TRBs(2) = 0x00000000
Oct 27 23:31:18 F19-home kernel: [33700.925299] iwlwifi 0000:01:00.0: FH TRBs(3) = 0x803000c0
Oct 27 23:31:18 F19-home kernel: [33700.925335] iwlwifi 0000:01:00.0: FH TRBs(4) = 0x00000000
Oct 27 23:31:18 F19-home kernel: [33700.925372] iwlwifi 0000:01:00.0: FH TRBs(5) = 0x00000000
Oct 27 23:31:18 F19-home kernel: [33700.925393] iwlwifi 0000:01:00.0: FH TRBs(6) = 0x00000000
Oct 27 23:31:18 F19-home kernel: [33700.925414] iwlwifi 0000:01:00.0: FH TRBs(7) = 0x00709048
Oct 27 23:31:18 F19-home kernel: [33700.925493] iwlwifi 0000:01:00.0: Q 0 is active and mapped to fifo 3 ra_tid 0x0000 [193,193]
Oct 27 23:31:18 F19-home kernel: [33700.925571] iwlwifi 0000:01:00.0: Q 1 is active and mapped to fifo 2 ra_tid 0x0000 [0,0]
Oct 27 23:31:18 F19-home kernel: [33700.925681] iwlwifi 0000:01:00.0: Q 2 is active and mapped to fifo 1 ra_tid 0x0000 [207,207]
Oct 27 23:31:18 F19-home kernel: [33700.925791] iwlwifi 0000:01:00.0: Q 3 is active and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:31:18 F19-home kernel: [33700.925901] iwlwifi 0000:01:00.0: Q 4 is active and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:31:18 F19-home kernel: [33700.925978] iwlwifi 0000:01:00.0: Q 5 is active and mapped to fifo 4 ra_tid 0x0000 [0,0]
Oct 27 23:31:18 F19-home kernel: [33700.926102] iwlwifi 0000:01:00.0: Q 6 is active and mapped to fifo 2 ra_tid 0x0000 [0,0]
Oct 27 23:31:18 F19-home kernel: [33700.926183] iwlwifi 0000:01:00.0: Q 7 is active and mapped to fifo 5 ra_tid 0x0000 [0,0]
Oct 27 23:31:18 F19-home kernel: [33700.926264] iwlwifi 0000:01:00.0: Q 8 is active and mapped to fifo 4 ra_tid 0x0000 [0,0]
Oct 27 23:31:18 F19-home kernel: [33700.926345] iwlwifi 0000:01:00.0: Q 9 is active and mapped to fifo 7 ra_tid 0x0000 [73,73]
Oct 27 23:31:18 F19-home kernel: [33700.926431] iwlwifi 0000:01:00.0: Q 10 is active and mapped to fifo 5 ra_tid 0x0000 [0,0]
Oct 27 23:31:18 F19-home kernel: [33700.926521] iwlwifi 0000:01:00.0: Q 11 is active and mapped to fifo 1 ra_tid 0x0000 [67,190]
Oct 27 23:31:18 F19-home kernel: [33700.926604] iwlwifi 0000:01:00.0: Q 12 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:31:18 F19-home kernel: [33700.926684] iwlwifi 0000:01:00.0: Q 13 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:31:18 F19-home kernel: [33700.926764] iwlwifi 0000:01:00.0: Q 14 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:31:18 F19-home kernel: [33700.926845] iwlwifi 0000:01:00.0: Q 15 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:31:18 F19-home kernel: [33700.926928] iwlwifi 0000:01:00.0: Q 16 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:31:18 F19-home kernel: [33700.927019] iwlwifi 0000:01:00.0: Q 17 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:31:18 F19-home kernel: [33700.927151] iwlwifi 0000:01:00.0: Q 18 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:31:18 F19-home kernel: [33700.927231] iwlwifi 0000:01:00.0: Q 19 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:32:21 F19-home kernel: [33764.148319] iwlwifi 0000:01:00.0: fail to flush all tx fifo queues Q 2
Oct 27 23:32:21 F19-home kernel: [33764.148330] iwlwifi 0000:01:00.0: Current SW read_ptr 27 write_ptr 96
Oct 27 23:32:21 F19-home kernel: [33764.148382] iwl data: 00000000: 00 00 00 f8 00 00 00 00 ff 07 00 00 00 00 00 00  ................
Oct 27 23:32:21 F19-home kernel: [33764.148420] iwlwifi 0000:01:00.0: FH TRBs(0) = 0x00000000
Oct 27 23:32:21 F19-home kernel: [33764.148456] iwlwifi 0000:01:00.0: FH TRBs(1) = 0x8010202a
Oct 27 23:32:21 F19-home kernel: [33764.148492] iwlwifi 0000:01:00.0: FH TRBs(2) = 0x00000000
Oct 27 23:32:21 F19-home kernel: [33764.148528] iwlwifi 0000:01:00.0: FH TRBs(3) = 0x803000e1
Oct 27 23:32:21 F19-home kernel: [33764.148565] iwlwifi 0000:01:00.0: FH TRBs(4) = 0x00000000
Oct 27 23:32:21 F19-home kernel: [33764.148601] iwlwifi 0000:01:00.0: FH TRBs(5) = 0x00000000
Oct 27 23:32:21 F19-home kernel: [33764.148638] iwlwifi 0000:01:00.0: FH TRBs(6) = 0x00000000
Oct 27 23:32:21 F19-home kernel: [33764.148680] iwlwifi 0000:01:00.0: FH TRBs(7) = 0x00709082
Oct 27 23:32:21 F19-home kernel: [33764.148760] iwlwifi 0000:01:00.0: Q 0 is active and mapped to fifo 3 ra_tid 0x0000 [226,226]
Oct 27 23:32:21 F19-home kernel: [33764.148844] iwlwifi 0000:01:00.0: Q 1 is active and mapped to fifo 2 ra_tid 0x0000 [0,0]
Oct 27 23:32:21 F19-home kernel: [33764.148928] iwlwifi 0000:01:00.0: Q 2 is active and mapped to fifo 1 ra_tid 0x0000 [27,96]
Oct 27 23:32:21 F19-home kernel: [33764.149006] iwlwifi 0000:01:00.0: Q 3 is active and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:32:21 F19-home kernel: [33764.149084] iwlwifi 0000:01:00.0: Q 4 is active and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:32:21 F19-home kernel: [33764.149162] iwlwifi 0000:01:00.0: Q 5 is active and mapped to fifo 4 ra_tid 0x0000 [0,0]
Oct 27 23:32:21 F19-home kernel: [33764.149268] iwlwifi 0000:01:00.0: Q 6 is active and mapped to fifo 2 ra_tid 0x0000 [0,0]
Oct 27 23:32:21 F19-home kernel: [33764.149348] iwlwifi 0000:01:00.0: Q 7 is active and mapped to fifo 5 ra_tid 0x0000 [0,0]
Oct 27 23:32:21 F19-home kernel: [33764.149439] iwlwifi 0000:01:00.0: Q 8 is active and mapped to fifo 4 ra_tid 0x0000 [0,0]
Oct 27 23:32:21 F19-home kernel: [33764.149500] iwlwifi 0000:01:00.0: Q 9 is active and mapped to fifo 7 ra_tid 0x0000 [131,131]
Oct 27 23:32:21 F19-home kernel: [33764.149562] iwlwifi 0000:01:00.0: Q 10 is active and mapped to fifo 5 ra_tid 0x0000 [0,0]
Oct 27 23:32:21 F19-home kernel: [33764.149623] iwlwifi 0000:01:00.0: Q 11 is inactive and mapped to fifo 1 ra_tid 0x0000 [232,232]
Oct 27 23:32:21 F19-home kernel: [33764.149684] iwlwifi 0000:01:00.0: Q 12 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:32:21 F19-home kernel: [33764.149745] iwlwifi 0000:01:00.0: Q 13 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:32:21 F19-home kernel: [33764.149802] iwlwifi 0000:01:00.0: Q 14 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:32:21 F19-home kernel: [33764.149880] iwlwifi 0000:01:00.0: Q 15 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:32:21 F19-home kernel: [33764.149959] iwlwifi 0000:01:00.0: Q 16 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:32:21 F19-home kernel: [33764.150035] iwlwifi 0000:01:00.0: Q 17 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:32:21 F19-home kernel: [33764.150113] iwlwifi 0000:01:00.0: Q 18 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 27 23:32:21 F19-home kernel: [33764.150191] iwlwifi 0000:01:00.0: Q 19 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]

Comment 97 Mikko C. 2013-10-28 18:27:18 UTC
$ uname -a
Linux fedora 3.11.6-200.fc19.x86_64 

Laptop: DELL XPS13


[ 3267.956835] iwlwifi 0000:01:00.0: fail to flush all tx fifo queues Q 2
[ 3267.956840] iwlwifi 0000:01:00.0: Current SW read_ptr 143 write_ptr 146
[ 3267.956930] iwl data: 00000000: 00 80 03 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[ 3267.956986] iwlwifi 0000:01:00.0: FH TRBs(0) = 0x00000000
[ 3267.957040] iwlwifi 0000:01:00.0: FH TRBs(1) = 0x80102091
[ 3267.957095] iwlwifi 0000:01:00.0: FH TRBs(2) = 0x00000000
[ 3267.957144] iwlwifi 0000:01:00.0: FH TRBs(3) = 0x80300059
[ 3267.957198] iwlwifi 0000:01:00.0: FH TRBs(4) = 0x00000000
[ 3267.957253] iwlwifi 0000:01:00.0: FH TRBs(5) = 0x00000000
[ 3267.957307] iwlwifi 0000:01:00.0: FH TRBs(6) = 0x00000000
[ 3267.957362] iwlwifi 0000:01:00.0: FH TRBs(7) = 0x00709083
[ 3267.957610] iwlwifi 0000:01:00.0: Q 0 is active and mapped to fifo 3 ra_tid 0x0000 [90,90]
[ 3267.957778] iwlwifi 0000:01:00.0: Q 1 is active and mapped to fifo 2 ra_tid 0x0000 [0,0]
[ 3267.957983] iwlwifi 0000:01:00.0: Q 2 is active and mapped to fifo 1 ra_tid 0x0000 [143,146]
[ 3267.958153] iwlwifi 0000:01:00.0: Q 3 is active and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 3267.958322] iwlwifi 0000:01:00.0: Q 4 is active and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 3267.958490] iwlwifi 0000:01:00.0: Q 5 is active and mapped to fifo 4 ra_tid 0x0000 [0,0]
[ 3267.958659] iwlwifi 0000:01:00.0: Q 6 is active and mapped to fifo 2 ra_tid 0x0000 [0,0]
[ 3267.958833] iwlwifi 0000:01:00.0: Q 7 is active and mapped to fifo 5 ra_tid 0x0000 [0,0]
[ 3267.959007] iwlwifi 0000:01:00.0: Q 8 is active and mapped to fifo 4 ra_tid 0x0000 [0,0]
[ 3267.959174] iwlwifi 0000:01:00.0: Q 9 is active and mapped to fifo 7 ra_tid 0x0000 [132,132]
[ 3267.959336] iwlwifi 0000:01:00.0: Q 10 is active and mapped to fifo 5 ra_tid 0x0000 [0,0]
[ 3267.959504] iwlwifi 0000:01:00.0: Q 11 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 3267.959671] iwlwifi 0000:01:00.0: Q 12 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 3267.959847] iwlwifi 0000:01:00.0: Q 13 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 3267.960027] iwlwifi 0000:01:00.0: Q 14 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 3267.960196] iwlwifi 0000:01:00.0: Q 15 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 3267.960364] iwlwifi 0000:01:00.0: Q 16 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 3267.960533] iwlwifi 0000:01:00.0: Q 17 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 3267.960702] iwlwifi 0000:01:00.0: Q 18 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 3267.960896] iwlwifi 0000:01:00.0: Q 19 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]

Comment 98 dan.ghete 2013-12-20 18:47:01 UTC
This is still happening on Fedora 20 with latest kernel 3.12.5-1.fc21.x86_64 form rawhide.

[ 3504.914317] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues Q 11
[ 3504.914325] iwlwifi 0000:03:00.0: Current SW read_ptr 157 write_ptr 163
[ 3504.914376] iwl data: 00000000: 00 00 00 e0 00 00 00 40 07 00 00 00 00 00 00 00  .......@........
[ 3504.914412] iwlwifi 0000:03:00.0: FH TRBs(0) = 0x00000000
[ 3504.914448] iwlwifi 0000:03:00.0: FH TRBs(1) = 0xc010b0a2
[ 3504.914484] iwlwifi 0000:03:00.0: FH TRBs(2) = 0x00000000
[ 3504.914505] iwlwifi 0000:03:00.0: FH TRBs(3) = 0x80300029
[ 3504.914541] iwlwifi 0000:03:00.0: FH TRBs(4) = 0x00000000
[ 3504.914562] iwlwifi 0000:03:00.0: FH TRBs(5) = 0x00000000
[ 3504.914582] iwlwifi 0000:03:00.0: FH TRBs(6) = 0x00000000
[ 3504.914603] iwlwifi 0000:03:00.0: FH TRBs(7) = 0x00709060
[ 3504.914666] iwlwifi 0000:03:00.0: Q 0 is active and mapped to fifo 3 ra_tid 0x0000 [42,42]
[ 3504.914743] iwlwifi 0000:03:00.0: Q 1 is active and mapped to fifo 2 ra_tid 0x0000 [0,0]
[ 3504.914821] iwlwifi 0000:03:00.0: Q 2 is active and mapped to fifo 1 ra_tid 0x0000 [54,54]
[ 3504.914899] iwlwifi 0000:03:00.0: Q 3 is active and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 3504.914960] iwlwifi 0000:03:00.0: Q 4 is active and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 3504.915022] iwlwifi 0000:03:00.0: Q 5 is active and mapped to fifo 4 ra_tid 0x0000 [0,0]
[ 3504.915084] iwlwifi 0000:03:00.0: Q 6 is active and mapped to fifo 2 ra_tid 0x0000 [0,0]
[ 3504.915146] iwlwifi 0000:03:00.0: Q 7 is active and mapped to fifo 5 ra_tid 0x0000 [0,0]
[ 3504.915208] iwlwifi 0000:03:00.0: Q 8 is active and mapped to fifo 4 ra_tid 0x0000 [0,0]
[ 3504.915320] iwlwifi 0000:03:00.0: Q 9 is active and mapped to fifo 7 ra_tid 0x0000 [97,97]
[ 3504.915406] iwlwifi 0000:03:00.0: Q 10 is active and mapped to fifo 5 ra_tid 0x0000 [0,0]
[ 3504.915485] iwlwifi 0000:03:00.0: Q 11 is active and mapped to fifo 1 ra_tid 0x0000 [157,163]
[ 3504.915564] iwlwifi 0000:03:00.0: Q 12 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 3504.915643] iwlwifi 0000:03:00.0: Q 13 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 3504.915723] iwlwifi 0000:03:00.0: Q 14 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 3504.915801] iwlwifi 0000:03:00.0: Q 15 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 3504.915882] iwlwifi 0000:03:00.0: Q 16 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 3504.915961] iwlwifi 0000:03:00.0: Q 17 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 3504.916040] iwlwifi 0000:03:00.0: Q 18 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 3504.916121] iwlwifi 0000:03:00.0: Q 19 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]

Comment 99 Fedora End Of Life 2013-12-21 15:07:42 UTC
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. 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 '18'.

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 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 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, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

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.

Comment 100 Maciek Borzecki 2013-12-30 21:08:44 UTC
(In reply to dan.ghete from comment #98)
> This is still happening on Fedora 20 with latest kernel 3.12.5-1.fc21.x86_64
> form rawhide.
And now in kernel-3.12.5-302.fc20.x86_64 as well. Can we bump the version to 20 or should another bug be reported?

Comment 101 Michele Baldessari 2014-01-01 18:21:32 UTC
Setting F20 since people are still seeing this

Comment 102 Michele Baldessari 2014-01-02 19:12:11 UTC
*** Bug 1047831 has been marked as a duplicate of this bug. ***

Comment 103 Justin M. Forbes 2014-02-24 13:59:58 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.13.4-200.fc20.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

Comment 104 Justin M. Forbes 2014-03-17 18:43:25 UTC
*********** MASS BUG UPDATE **************

This bug has been in a needinfo state for several weeks and is being closed with insufficient data due to inactivity. If this is still an issue with Fedora 20, please feel free to reopen the bug and provide the additional information requested.