Bug 863424
Summary: | iwlwifi: fail to flush all tx fifo queues | ||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Michal Fojtik <mfojtik> | ||||||||||||||||||||||||||||||||
Component: | kernel | Assignee: | fedora-kernel-wireless-iwl | ||||||||||||||||||||||||||||||||
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||||||||||||||||||
Severity: | unspecified | Docs Contact: | |||||||||||||||||||||||||||||||||
Priority: | unspecified | ||||||||||||||||||||||||||||||||||
Version: | 20 | CC: | 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
Michal Fojtik
2012-10-05 13:00:49 UTC
Is this 100% reproducible or happen at random? This happens random, not a blocker or something, just annoying :) intel wifi driver crashes frequently Package: kernel OS Release: Fedora release 17 (Beefy Miracle) happens mostly when reconnecting to an ap which has gone offline and comes back up... Please test this kernel and report back if it fixes the problem or not: http://koji.fedoraproject.org/koji/taskinfo?taskID=4602595 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. Closing due to lack of response ... 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 Please provide full dmesg when this problem happen, perhaps there are some firmware crashes before the warning. 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) 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 (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. WARNING seems to gone, but there is "fail to flush all tx fifo queues" problem. Does someone have reliable way to reproduce this? 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... 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) 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. *** Bug 882342 has been marked as a duplicate of this bug. *** Please test kernel from comment 16. Created attachment 667944 [details]
queue flush fix
May solve the issue
Created attachment 670702 [details]
better fix
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 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.
can you please apply the patch in comment 20? 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. 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.
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.
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 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.... Created attachment 671662 [details]
get better logs
so in the end I fixed the patch tonight :-)
thanks for your help testing
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!
Created attachment 672014 [details]
get better logs
Oops. This new patch will save quite a few prints
Created attachment 675302 [details]
fix rate scaling
I am kinda hoping that this patch can help. Can you test please? Thanks! Created attachment 675851 [details]
fix rate scaling
same patch as before, but nicer :-)
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? (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 (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.) does 3.7 work for you? 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. 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 problem happened immediately after wakeup from S4 notebook uses WLAN-connection Package: kernel OS Release: Fedora release 18 (Spherical Cow) 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 (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? (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 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. 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 (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..) (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! 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 (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. 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? that patch is irrelevant for any stable kernel can you please reproduce with the "get better logs" patch? *** Bug 866866 has been marked as a duplicate of this bug. *** 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.) 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? (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. 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. OK. I'll get these in shortly. (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. These were added to F17/F18 and rawhide yesterday. Thanks. 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 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 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). 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 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. 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. [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. 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. 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? 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. 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 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 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 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. 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. Intel, this is currently most frequent iwlwifi bug that Fedora users hit. Any progress on fixing it ? 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...) 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...) Intel, any test or debug patches here ? 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.
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> (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). 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...? Created attachment 750255 [details]
dmesg output with 3.9.2
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) 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 ... 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 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 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
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. 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].
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. 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.
*********** 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. 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] $ 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] 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] 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. (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? Setting F20 since people are still seeing this *** Bug 1047831 has been marked as a duplicate of this bug. *** *********** 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. *********** 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. |