Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation
reassign 628444 src:linux thanks On Wed, Mar 14, 2012 at 08:37:17PM -0700, Shannon Dealy wrote: Like others, the problems seemed to start around 2.6.39. Thought I should note here, my system showed this problem with 2.6.36 through 2.6.39. It seems to have stopped showing the problem (possibly due to a memory upgrade many months ago), but it still has chronic instability of the connection (drops out for varying intervals), and often, network-manager doesn't seem aware of the failure - reloading the driver isn't a reliable solution (sometimes appears to work, often does not) Does this bug still occur with more recent kernels/firmware, e.g. Wheezy? Cheers, Moritz -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130815163651.gb15...@inutil.org
Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation
Shannon Dealy de...@deatech.com writes:
I have not seen this problem or any of the other iwl instabilities in
a long time, however, I have been running with these option lines
disabling 11n functionality in order to achieve that stability:
options iwlagn 11n_disable50=1
options iwlwifi 11n_disable=1
since I am no longer running kernels which use iwlagn (currently
running 3.2.xx), I can't really speak to the original issue anymore.
Of course iwlwifi has had 11n related stability issues as well,
however, I have never seen the:
MAC is in deep sleep
bug (as far as I can recall) while running a newer kernel with iwlwifi
instead of iwlagn. Not sure how much code (if any) is common between
iwlwifi and the older iwlagn module.
AFAIK the code printing that particular error message is still the same
in 3.2. The error message was changed and a stack trace was added in
v3.4, so you have to look for another message if testing newer kernels:
commit aa5affbacb24cb5d8fd6f7c66e57d62164ed6d34
Author: Stanislaw Gruszka sgrus...@redhat.com
Date: Wed Mar 7 09:52:23 2012 -0800
iwlwifi: dump stack when fail to gain access to the device
Print dump stack when the device is not responding. This should give
some more clue about the reason of failure. Also change the message we
print, since MAC in deep sleep is kinda confusing.
On the way add unlikely(), as fail to gain NIC access is hmm ...
unlikely.
Signed-off-by: Stanislaw Gruszka sgrus...@redhat.com
Signed-off-by: Johannes Berg johannes.b...@intel.com
Signed-off-by: Wey-Yi Guy wey-yi.w@intel.com
Signed-off-by: John W. Linville linvi...@tuxdriver.com
diff --git a/drivers/net/wireless/iwlwifi/iwl-io.c
b/drivers/net/wireless/iwlwifi/iwl-io.c
index e2e3b5c..fc36535 100644
--- a/drivers/net/wireless/iwlwifi/iwl-io.c
+++ b/drivers/net/wireless/iwlwifi/iwl-io.c
@@ -121,10 +121,10 @@ int iwl_grab_nic_access_silent(struct iwl_trans *trans)
int iwl_grab_nic_access(struct iwl_trans *trans)
{
int ret = iwl_grab_nic_access_silent(trans);
- if (ret) {
+ if (unlikely(ret)) {
u32 val = iwl_read32(trans, CSR_GP_CNTRL);
- IWL_ERR(trans,
- MAC is in deep sleep!. CSR_GP_CNTRL = 0x%08X\n, val);
+ WARN_ONCE(1, Timeout waiting for hardware access
+(CSR_GP_CNTRL 0x%08x)\n, val);
}
return ret;
This code has since been refactored and moved into
drivers/net/wireless/iwlwifi/pcie/trans.c but the Timeout waiting for
hardware access message is still there.
I suppose I should try enabling 11n again to see what happens (I had
forgotten it was disabled).
Time to move on to 11ac now :)
Bjørn
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ppte7rg9@nemi.mork.no
Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation
Hi Moritz, I have not seen this problem or any of the other iwl instabilities in a long time, however, I have been running with these option lines disabling 11n functionality in order to achieve that stability: options iwlagn 11n_disable50=1 options iwlwifi 11n_disable=1 since I am no longer running kernels which use iwlagn (currently running 3.2.xx), I can't really speak to the original issue anymore. Of course iwlwifi has had 11n related stability issues as well, however, I have never seen the: MAC is in deep sleep bug (as far as I can recall) while running a newer kernel with iwlwifi instead of iwlagn. Not sure how much code (if any) is common between iwlwifi and the older iwlagn module. I suppose I should try enabling 11n again to see what happens (I had forgotten it was disabled). The upgrade to wheezy is most notable for much shorter times required to make wireless connections, though I am not sure if it is the driver or network-manager responsible for that improvement. FWIW. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com On Thu, 15 Aug 2013, Moritz Muehlenhoff wrote: reassign 628444 src:linux thanks On Wed, Mar 14, 2012 at 08:37:17PM -0700, Shannon Dealy wrote: Like others, the problems seemed to start around 2.6.39. Thought I should note here, my system showed this problem with 2.6.36 through 2.6.39. It seems to have stopped showing the problem (possibly due to a memory upgrade many months ago), but it still has chronic instability of the connection (drops out for varying intervals), and often, network-manager doesn't seem aware of the failure - reloading the driver isn't a reliable solution (sometimes appears to work, often does not) Does this bug still occur with more recent kernels/firmware, e.g. Wheezy? Cheers, Moritz -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.02.1308151022300.20...@nashapur.deatech.com
Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation
On Tue, Mar 20, 2012 at 12:28:01AM +, Juha Jäykkä wrote: I am starting to believe I am in the clear here, but I am not yet convinced since the root cause is still unknown. In any case, thanks for all of you for helping hunt this down. Dafydd: I think you might want to try pcie_asmp=off next Cheers, Juha As I think I mentioned before, pice_aspm=off doesn't seem to help much for me. I still get wireless failure after a day or two, although they seem to be more often correlated with resuming from suspend. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120402024231.GE31750@nia
Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation
This may or may not be related, but I thought it best to inform you about what I just saw anyway: I accidentally toggled the physical RF kill switch on my laptop and the result was very much reminiscent of the bug we are discussing (note the QoS and failure to remove key): Mar 22 20:13:47 rigel kernel: [1259943.614216] iwlwifi :03:00.0: RF_KILL bit toggled to disable radio. Mar 22 20:13:47 rigel kernel: [1259943.614350] iwlwifi :03:00.0: Not sending command - RF KILL Mar 22 20:13:47 rigel kernel: [1259943.614359] iwlwifi :03:00.0: Error sending REPLY_QOS_PARAM: enqueue_hcmd failed: -5 Mar 22 20:13:47 rigel kernel: [1259943.614366] iwlwifi :03:00.0: Failed to update QoS Mar 22 20:13:47 rigel kernel: [1259943.614374] iwlwifi :03:00.0: Not sending command - RF KILL Mar 22 20:13:47 rigel kernel: [1259943.614381] iwlwifi :03:00.0: Error sending REPLY_RXON: enqueue_hcmd failed: -5 Mar 22 20:13:47 rigel kernel: [1259943.614388] iwlwifi :03:00.0: Error clearing ASSOC_MSK on BSS (-5) Mar 22 20:13:47 rigel kernel: [1259943.614400] iwlwifi :03:00.0: Not sending command - RF KILL Mar 22 20:13:47 rigel kernel: [1259943.614407] iwlwifi :03:00.0: Error sending REPLY_RXON: enqueue_hcmd failed: -5 Mar 22 20:13:47 rigel kernel: [1259943.614414] iwlwifi :03:00.0: Error clearing ASSOC_MSK on BSS (-5) Mar 22 20:13:47 rigel kernel: [1259943.614422] wlan0: deauthenticating from 00:24:17:33:f4:f5 by local choice (reason=3) Mar 22 20:13:47 rigel kernel: [1259943.624234] iwlwifi :03:00.0: Not sending command - RF KILL Mar 22 20:13:47 rigel kernel: [1259943.624238] iwlwifi :03:00.0: Error sending REPLY_ADD_STA: enqueue_hcmd failed: -5 Mar 22 20:13:47 rigel kernel: [1259943.624242] ieee80211 phy0: failed to remove key (1, ff:ff:ff:ff:ff:ff) from hardware (-5) Mar 22 20:13:47 rigel kernel: [1259943.624339] iwlwifi :03:00.0: Not sending command - RF KILL Mar 22 20:13:47 rigel kernel: [1259943.624342] iwlwifi :03:00.0: Error sending REPLY_ADD_STA: enqueue_hcmd failed: -5 Mar 22 20:13:47 rigel kernel: [1259943.624346] ieee80211 phy0: failed to remove key (0, 00:24:17:33:f4:f5) from hardware (-5) Mar 22 20:13:47 rigel kernel: [1259943.624351] iwlwifi :03:00.0: Not sending command - RF KILL Mar 22 20:13:47 rigel kernel: [1259943.624354] iwlwifi :03:00.0: Error sending REPLY_REMOVE_STA: enqueue_hcmd failed: -5 Mar 22 20:13:47 rigel kernel: [1259943.624358] iwlwifi :03:00.0: Error removing station 00:24:17:33:f4:f5 Mar 22 20:13:47 rigel kernel: [1259943.624391] iwlwifi :03:00.0: Not sending command - RF KILL Mar 22 20:13:47 rigel kernel: [1259943.624394] iwlwifi :03:00.0: Error sending REPLY_RXON: enqueue_hcmd failed: -5 Mar 22 20:13:47 rigel kernel: [1259943.624397] iwlwifi :03:00.0: Error clearing ASSOC_MSK on BSS (-5) Mar 22 20:13:47 rigel kernel: [1259943.624425] iwlwifi :03:00.0: Not sending command - RF KILL Mar 22 20:13:47 rigel kernel: [1259943.624428] iwlwifi :03:00.0: Error sending REPLY_LEDS_CMD: enqueue_hcmd failed: -5 Mar 22 20:13:47 rigel kernel: [1259943.624433] iwlwifi :03:00.0: Not sending command - RF KILL Mar 22 20:13:47 rigel kernel: [1259943.624436] iwlwifi :03:00.0: Error sending REPLY_RXON: enqueue_hcmd failed: -5 Mar 22 20:13:47 rigel kernel: [1259943.624439] iwlwifi :03:00.0: Error clearing ASSOC_MSK on BSS (-5) Mar 22 20:13:47 rigel kernel: [1259943.624459] cfg80211: Calling CRDA to update world regulatory domain Mar 22 20:13:47 rigel kernel: [1259943.640238] iwlwifi :03:00.0: Not sending command - RF KILL Mar 22 20:13:47 rigel kernel: [1259943.640245] iwlwifi :03:00.0: Error sending REPLY_RXON: enqueue_hcmd failed: -5 Mar 22 20:13:47 rigel kernel: [1259943.640249] iwlwifi :03:00.0: Error clearing ASSOC_MSK on BSS (-5) After switching the radios back on, I get Mar 22 20:14:22 rigel kernel: [1259978.719860] iwlwifi :03:00.0: RF_KILL bit toggled to enable radio. but *absolutely* *nothing* *else*. No RF LED, nothing. However, unlike the bug we are discussing, reloading the iwlwifi module fixed this. Hope this helps, Juha -- --- | Juha Jäykkä, ju...@iki.fi | | http://www.maths.leeds.ac.uk/~juhaj | --- signature.asc Description: This is a digitally signed message part.
Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation
Hi Juha, Mar 22 20:13:47 rigel kernel: [1259943.614216] iwlwifi :03:00.0: RF_KILL bit toggled to disable radio. Mar 22 20:13:47 rigel kernel: [1259943.614350] iwlwifi :03:00.0: Not sending command - RF KILL [MV] These are not technically error messages, and we had a patch fixing these error messages in the recent past. What kernel version are you running? Mar 22 20:13:47 rigel kernel: [1259943.624242] ieee80211 phy0: failed to remove key (1, ff:ff:ff:ff:ff:ff) from hardware (-5) [MV] This could potentially be an issue -- we'll look into this. After switching the radios back on, I get Mar 22 20:14:22 rigel kernel: [1259978.719860] iwlwifi :03:00.0: RF_KILL bit toggled to enable radio. but *absolutely* *nothing* *else*. No RF LED, nothing. [MV] Ouch. This is likely also a bug in mac80211/driver...can you file a separate bug for this on the intel linux wireless bugzilla: http://bugzilla.intellinuxwireless.org/; so we can have someone look at it? Thanks, Meenakshi
Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation
My update (after a reboot caused by a crashed hibernation attempt at uptime ~8 days): juhaj@rigel uptime 00:18:27 up 14 days, 6:50, 9 users, load average: 0.00, 0.03, 0.05 juhaj@rigel cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.2.0-1-amd64 root=/dev/mapper/system-root ro quiet usbcore.autosuspend=1 video=intelfb:1440x900M@60 pcie_aspm=off juhaj@rigel grep . /sys/module/iwlwifi/parameters/* /sys/module/iwlwifi/parameters/11n_disable:0 /sys/module/iwlwifi/parameters/ack_check:N /sys/module/iwlwifi/parameters/amsdu_size_8K:1 /sys/module/iwlwifi/parameters/antenna_coupling:0 /sys/module/iwlwifi/parameters/auto_agg:Y /sys/module/iwlwifi/parameters/bt_ch_inhibition:Y /sys/module/iwlwifi/parameters/bt_coex_active:Y /sys/module/iwlwifi/parameters/fw_restart:1 /sys/module/iwlwifi/parameters/led_mode:0 /sys/module/iwlwifi/parameters/no_sleep_autoadjust:Y /sys/module/iwlwifi/parameters/plcp_check:Y /sys/module/iwlwifi/parameters/power_level:0 /sys/module/iwlwifi/parameters/power_save:N /sys/module/iwlwifi/parameters/queues_num:0 /sys/module/iwlwifi/parameters/swcrypto:0 /sys/module/iwlwifi/parameters/ucode_alternative:1 /sys/module/iwlwifi/parameters/wd_disable:0 (I think these are all defaults.) rigel kernel: [1073316.734468] iwlwifi :03:00.0: L1 Enabled; Disabling L0S juhaj@rigel uname -a Linux rigel 3.2.0-1-amd64 #1 SMP Fri Feb 17 05:17:36 UTC 2012 x86_64 GNU/Linux There have been TWO changes since I last had problems: 1. pcie_aspm=off 2. re-seating the iwlwifi mini-pci card in its socket I am starting to believe I am in the clear here, but I am not yet convinced since the root cause is still unknown. In any case, thanks for all of you for helping hunt this down. Dafydd: I think you might want to try pcie_asmp=off next Cheers, Juha -- --- | Juha Jäykkä, ju...@iki.fi | | http://www.maths.leeds.ac.uk/~juhaj | --- signature.asc Description: This is a digitally signed message part.
Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation
On Fri, 16 Mar 2012, Bjørn Mork wrote: Shannon Dealy de...@deatech.com writes: I created a file /etc/modprobe.d/iwlagn.conf and placed the following line in it: options iwlagn 11n_disable=1 11n_disable50=1 Note that the 11n_disable50 options was removed in 3.0 and the iwlagn module was renamed to iwlwifi in 3.2. Unfortunate, since further testing shows that it is the 11n_disable50=1 that matters. Disabling either of the above options makes my link stable, and since 11n_disable=1 would effectively cause 11n_disable50 to happen as well, the implication is that the problem is in the code which is/was controlled by the 11n_disable50. Would be nice if anyone can confirm if this fixes the deep sleep problem as well. Which makes this workaround pretty much irrelevant to any current Debian kernel as noone(?) has seen the bug in 2.6.32. While it may not be relevant to you, it is completely relevant in that it: - provides developers with a narrowed range of places to look for the problem in all versions of the kernel/driver code, including those were the option was removed (they can easily check what part of the code it previously disabled) - using just the 11n_disable option should still solve the stability problems I am seeing and possibly the deep sleep as well (need confirmation on that) for people running 3.x (though granted it is not a great workaround given the performance hit) - I assume you are speaking with regard to 2.6.32 being the default stable kernel so it won't affect people running stock Debian stable? I don't recall seeing confirmation from anyone that the problem went away by downgrading to 2.6.32. Are you still using the 2.6.39-1 kernel you originally opened this bug against? [snip] Yes, though it has been rebuilt for debug tracing of the iwlagn driver. Unfortunately I can't afford the down time right now that a kernel upgrade beyond 2.6.39 would entail (other software would have to be upgraded and that might require that I write some code as well to deal with the kernel changes). I also can't downgrade to 2.6.32 (assuming that it would make any difference) as it doesn't support some of my hardware. FWIW Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com
Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation
Shannon Dealy de...@deatech.com writes: I created a file /etc/modprobe.d/iwlagn.conf and placed the following line in it: options iwlagn 11n_disable=1 11n_disable50=1 Note that the 11n_disable50 options was removed in 3.0 and the iwlagn module was renamed to iwlwifi in 3.2. Which makes this workaround pretty much irrelevant to any current Debian kernel as noone(?) has seen the bug in 2.6.32. Are you still using the 2.6.39-1 kernel you originally opened this bug against? FWIW, I enabled power_save a few days ago (was previously at default) after the nice summary from Meenakshi, just to see if I could replicate this issue. My module parameters are now: bjorn@nemi:~$ grep . /sys/module/iwlwifi/parameters/* /sys/module/iwlwifi/parameters/11n_disable:0 /sys/module/iwlwifi/parameters/ack_check:N /sys/module/iwlwifi/parameters/amsdu_size_8K:1 /sys/module/iwlwifi/parameters/antenna_coupling:0 /sys/module/iwlwifi/parameters/auto_agg:Y /sys/module/iwlwifi/parameters/bt_ch_inhibition:Y /sys/module/iwlwifi/parameters/bt_coex_active:Y /sys/module/iwlwifi/parameters/fw_restart:1 /sys/module/iwlwifi/parameters/led_mode:0 /sys/module/iwlwifi/parameters/no_sleep_autoadjust:Y /sys/module/iwlwifi/parameters/plcp_check:Y /sys/module/iwlwifi/parameters/power_level:0 /sys/module/iwlwifi/parameters/power_save:Y /sys/module/iwlwifi/parameters/queues_num:0 /sys/module/iwlwifi/parameters/swcrypto:0 /sys/module/iwlwifi/parameters/ucode_alternative:1 /sys/module/iwlwifi/parameters/wd_disable:0 And I am often using 802.11n at 5GHz. Still haven't seen the issue. But I wonder about Juha's observation about this difference between my setup: [ 12.611061] iwlwifi :03:00.0: L1 Disabled; Enabling L0S and his: [245082.407512] iwlwifi :03:00.0: L1 Enabled; Disabling L0S This looks extremely suspicious to me in light of Meenakshi's comment on known issues with L1 on these devices and that Intel therefore use L0S by default. How come Juha end up with L1 enabled, then? And is that the case for everyone seeing this bug? Bjørn -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5r0ex39@nemi.mork.no
Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation
On Fri, Mar 16, 2012 at 10:03:54AM +0100, Bjørn Mork wrote: But I wonder about Juha's observation about this difference between my setup: [ 12.611061] iwlwifi :03:00.0: L1 Disabled; Enabling L0S and his: [245082.407512] iwlwifi :03:00.0: L1 Enabled; Disabling L0S This looks extremely suspicious to me in light of Meenakshi's comment on known issues with L1 on these devices and that Intel therefore use L0S by default. How come Juha end up with L1 enabled, then? And is that the case for everyone seeing this bug? Today I got a failure, and on my machine it was using L0S, not L1S: Mar 16 11:38:45 localhost kernel: [ 9045.913617] iwlwifi :02:00.0: L1 Disabled; Enabling L0S So I don't think this is the difference necessarily. Syslog from today attached. Mar 16 11:37:49 localhost kernel: [ 8989.631323] iwlwifi :02:00.0: Error sending REPLY_QOS_PARAM: time out after 2000ms. Mar 16 11:37:49 localhost kernel: [ 8989.631332] iwlwifi :02:00.0: Current CMD queue read_ptr 59 write_ptr 63 Mar 16 11:37:49 localhost kernel: [ 8989.631336] iwlwifi :02:00.0: Failed to update QoS Mar 16 11:37:51 localhost kernel: [ 8991.626456] iwlwifi :02:00.0: Error sending REPLY_RXON: time out after 2000ms. Mar 16 11:37:51 localhost kernel: [ 8991.626463] iwlwifi :02:00.0: Current CMD queue read_ptr 59 write_ptr 66 Mar 16 11:37:51 localhost kernel: [ 8991.626468] iwlwifi :02:00.0: Error clearing ASSOC_MSK on BSS (-110) Mar 16 11:37:53 localhost kernel: [ 8993.621540] iwlwifi :02:00.0: Error sending REPLY_RXON: time out after 2000ms. Mar 16 11:37:53 localhost kernel: [ 8993.621547] iwlwifi :02:00.0: Current CMD queue read_ptr 59 write_ptr 69 Mar 16 11:37:53 localhost kernel: [ 8993.621552] iwlwifi :02:00.0: Error clearing ASSOC_MSK on BSS (-110) Mar 16 11:37:55 localhost kernel: [ 8995.616627] iwlwifi :02:00.0: Error sending REPLY_RXON: time out after 2000ms. Mar 16 11:37:55 localhost kernel: [ 8995.616634] iwlwifi :02:00.0: Current CMD queue read_ptr 59 write_ptr 70 Mar 16 11:37:55 localhost kernel: [ 8995.616638] iwlwifi :02:00.0: Error clearing ASSOC_MSK on BSS (-110) Mar 16 11:37:57 localhost kernel: [ 8997.611717] iwlwifi :02:00.0: Error sending REPLY_SCAN_CMD: time out after 2000ms. Mar 16 11:37:57 localhost kernel: [ 8997.611724] iwlwifi :02:00.0: Current CMD queue read_ptr 59 write_ptr 71 Mar 16 11:37:59 localhost kernel: [ 8999.606756] iwlwifi :02:00.0: Error sending REPLY_ADD_STA: time out after 2000ms. Mar 16 11:37:59 localhost kernel: [ 8999.606764] iwlwifi :02:00.0: Current CMD queue read_ptr 59 write_ptr 72 Mar 16 11:38:01 localhost kernel: [ 9001.601883] iwlwifi :02:00.0: Error sending REPLY_REMOVE_STA: time out after 2000ms. Mar 16 11:38:01 localhost kernel: [ 9001.601891] iwlwifi :02:00.0: Current CMD queue read_ptr 59 write_ptr 73 Mar 16 11:38:01 localhost kernel: [ 9001.601898] iwlwifi :02:00.0: Error removing station 00:50:7f:cb:4b:58 Mar 16 11:38:03 localhost kernel: [ 9003.596977] iwlwifi :02:00.0: Error sending REPLY_RXON: time out after 2000ms. Mar 16 11:38:03 localhost kernel: [ 9003.596984] iwlwifi :02:00.0: Current CMD queue read_ptr 59 write_ptr 74 Mar 16 11:38:03 localhost kernel: [ 9003.596989] iwlwifi :02:00.0: Error clearing ASSOC_MSK on BSS (-110) Mar 16 11:38:05 localhost kernel: [ 9005.600071] iwlwifi :02:00.0: fail to flush all tx fifo queues Mar 16 11:38:07 localhost kernel: [ 9007.595140] iwlwifi :02:00.0: Error sending POWER_TABLE_CMD: time out after 2000ms. Mar 16 11:38:07 localhost kernel: [ 9007.595148] iwlwifi :02:00.0: Current CMD queue read_ptr 59 write_ptr 75 Mar 16 11:38:09 localhost kernel: [ 9007.595154] iwlwifi :02:00.0: set power fail, ret = -110 Mar 16 11:38:09 localhost kernel: [ 9009.590164] iwlwifi :02:00.0: Error sending REPLY_RXON: time out after 2000ms. Mar 16 11:38:09 localhost kernel: [ 9009.590171] iwlwifi :02:00.0: Current CMD queue read_ptr 59 write_ptr 76 Mar 16 11:38:09 localhost kernel: [ 9009.590175] iwlwifi :02:00.0: Error clearing ASSOC_MSK on BSS (-110) Mar 16 11:38:11 localhost kernel: [ 9011.621214] iwlwifi :02:00.0: Error sending REPLY_ADD_STA: time out after 2000ms. Mar 16 11:38:11 localhost kernel: [ 9011.621221] iwlwifi :02:00.0: Current CMD queue read_ptr 59 write_ptr 77 Mar 16 11:38:13 localhost kernel: [ 9013.616306] iwlwifi :02:00.0: Error sending REPLY_RXON: time out after 2000ms. Mar 16 11:38:13 localhost kernel: [ 9013.616312] iwlwifi :02:00.0: Current CMD queue read_ptr 59 write_ptr 78 Mar 16 11:38:13 localhost kernel: [ 9013.616317] iwlwifi :02:00.0: Error clearing ASSOC_MSK on BSS (-110) Mar 16 11:38:15 localhost kernel: [ 9015.611391] iwlwifi :02:00.0: Error sending REPLY_RXON: time out after 2000ms. Mar 16 11:38:15 localhost kernel: [ 9015.611397] iwlwifi :02:00.0: Current CMD queue read_ptr 59 write_ptr 79 Mar 16 11:38:15 localhost
Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation
On Fri, Mar 16, 2012 at 01:30:46PM +0100, Dafydd Harries wrote: Today I got a failure, and on my machine it was using L0S, not L1S: Mar 16 11:38:45 localhost kernel: [ 9045.913617] iwlwifi :02:00.0: L1 Disabled; Enabling L0S So I don't think this is the difference necessarily. Syslog from today attached. And I got a failure very quickly (50m) after I tried booting with power_save=1. Mar 16 13:05:15 localhost kernel: [ 31.986202] iwlwifi :02:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 Mar 16 13:05:15 localhost kernel: [ 31.986239] iwlwifi :02:00.0: setting latency timer to 64 Mar 16 13:05:15 localhost kernel: [ 31.986285] iwlwifi :02:00.0: pci_resource_len = 0x2000 Mar 16 13:05:15 localhost kernel: [ 31.986287] iwlwifi :02:00.0: pci_resource_base = c90011794000 Mar 16 13:05:15 localhost kernel: [ 31.986288] iwlwifi :02:00.0: HW Revision ID = 0x35 Mar 16 13:05:15 localhost kernel: [ 31.986414] iwlwifi :02:00.0: irq 42 for MSI/MSI-X Mar 16 13:05:15 localhost kernel: [ 31.986494] iwlwifi :02:00.0: Detected Intel(R) Centrino(R) Ultimate-N 6300 AGN, REV=0x74 Mar 16 13:05:15 localhost kernel: [ 31.986602] iwlwifi :02:00.0: L1 Enabled; Disabling L0S Mar 16 13:05:15 localhost kernel: [ 32.003127] iwlwifi :02:00.0: device EEPROM VER=0x436, CALIB=0x6 Mar 16 13:05:15 localhost kernel: [ 32.003132] iwlwifi :02:00.0: Device SKU: 0X1f0 Mar 16 13:05:15 localhost kernel: [ 32.003136] iwlwifi :02:00.0: Valid Tx ant: 0X7, Valid Rx ant: 0X7 Mar 16 13:05:15 localhost kernel: [ 32.003190] iwlwifi :02:00.0: Tunable channels: 13 802.11bg, 24 802.11a channels Mar 16 13:05:15 localhost kernel: [ 32.716291] iwlwifi :02:00.0: loaded firmware version 9.221.4.1 build 25532 Mar 16 13:05:25 localhost kernel: [ 1033.032388] iwlwifi :02:00.0: L1 Enabled; Disabling L0S Mar 16 13:05:25 localhost kernel: [ 1033.039190] iwlwifi :02:00.0: Radio type=0x0-0x3-0x1 Mar 16 13:05:26 localhost kernel: [ 1033.281070] iwlwifi :02:00.0: L1 Enabled; Disabling L0S Mar 16 13:05:26 localhost kernel: [ 1033.287845] iwlwifi :02:00.0: Radio type=0x0-0x3-0x1 Mar 16 13:36:18 localhost kernel: [ 2880.810592] iwlwifi :02:00.0: Error sending POWER_TABLE_CMD: time out after 2000ms. Mar 16 13:36:18 localhost kernel: [ 2880.810599] iwlwifi :02:00.0: Current CMD queue read_ptr 4 write_ptr 6 Mar 16 13:36:21 localhost kernel: [ 2880.810603] iwlwifi :02:00.0: set power fail, ret = -110 Mar 16 13:36:21 localhost kernel: [ 2883.304348] iwlwifi :02:00.0: Error sending REPLY_QOS_PARAM: time out after 2000ms. Mar 16 13:36:21 localhost kernel: [ 2883.304355] iwlwifi :02:00.0: Current CMD queue read_ptr 4 write_ptr 9 Mar 16 13:36:21 localhost kernel: [ 2883.304360] iwlwifi :02:00.0: Failed to update QoS Mar 16 13:36:23 localhost kernel: [ 2885.299347] iwlwifi :02:00.0: Error sending REPLY_RXON: time out after 2000ms. Mar 16 13:36:23 localhost kernel: [ 2885.299355] iwlwifi :02:00.0: Current CMD queue read_ptr 4 write_ptr 12 Mar 16 13:36:23 localhost kernel: [ 2885.299360] iwlwifi :02:00.0: Error clearing ASSOC_MSK on BSS (-110) Mar 16 13:36:25 localhost kernel: [ 2887.294339] iwlwifi :02:00.0: Error sending REPLY_RXON: time out after 2000ms. Mar 16 13:36:25 localhost kernel: [ 2887.294346] iwlwifi :02:00.0: Current CMD queue read_ptr 4 write_ptr 15 Mar 16 13:36:25 localhost kernel: [ 2887.294350] iwlwifi :02:00.0: Error clearing ASSOC_MSK on BSS (-110) Mar 16 13:36:27 localhost kernel: [ 2889.289307] iwlwifi :02:00.0: Error sending REPLY_RXON: time out after 2000ms. Mar 16 13:36:27 localhost kernel: [ 2889.289315] iwlwifi :02:00.0: Current CMD queue read_ptr 4 write_ptr 18 Mar 16 13:36:27 localhost kernel: [ 2889.289320] iwlwifi :02:00.0: Error clearing ASSOC_MSK on BSS (-110) Mar 16 13:36:29 localhost kernel: [ 2891.284303] iwlwifi :02:00.0: Error sending REPLY_ADD_STA: time out after 2000ms. Mar 16 13:36:29 localhost kernel: [ 2891.284309] iwlwifi :02:00.0: Current CMD queue read_ptr 4 write_ptr 21 Mar 16 13:36:31 localhost kernel: [ 2893.279199] iwlwifi :02:00.0: Error sending REPLY_REMOVE_STA: time out after 2000ms. Mar 16 13:36:31 localhost kernel: [ 2893.279208] iwlwifi :02:00.0: Current CMD queue read_ptr 4 write_ptr 24 Mar 16 13:36:31 localhost kernel: [ 2893.279215] iwlwifi :02:00.0: Error removing station 00:50:7f:cb:4b:58 Mar 16 13:36:33 localhost kernel: [ 2895.278267] iwlwifi :02:00.0: Error sending REPLY_RXON: time out after 2000ms. Mar 16 13:36:33 localhost kernel: [ 2895.278275] iwlwifi :02:00.0: Current CMD queue read_ptr 4 write_ptr 27 Mar 16 13:36:33 localhost kernel: [ 2895.278280] iwlwifi :02:00.0: Error clearing ASSOC_MSK on BSS (-110) Mar 16 13:36:35 localhost kernel: [ 2897.281201] iwlwifi :02:00.0: fail to flush all tx fifo queues Mar 16 13:36:37 localhost kernel: [ 2899.276196] iwlwifi :02:00.0:
Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation
Another failure today, but this time the device failed to come out of a sleep state after a resume cycle. ... Mar 15 16:10:52 localhost kernel: [79800.936071] ehci_hcd :00:1d.0: power state changed by ACPI to D0 Mar 15 16:10:52 localhost kernel: [79800.936173] ahci :00:1f.2: restoring config space at offset 0x1 (was 0x2b7, writing 0x2b00407) Mar 15 16:10:52 localhost kernel: [79800.936240] intel ips :00:1f.6: restoring config space at offset 0xf (was 0x400, writing 0x40b) Mar 15 16:10:52 localhost kernel: [79800.936261] intel ips :00:1f.6: restoring config space at offset 0x1 (was 0x10, writing 0x12) Mar 15 16:10:52 localhost kernel: [79800.951431] iwlwifi :02:00.0: Refused to change power state, currently in D3 Mar 15 16:10:52 localhost kernel: [79800.951443] iwlwifi :02:00.0: restoring config space at offset 0xf (was 0x, writing 0x10b) Mar 15 16:10:52 localhost kernel: [79800.951451] iwlwifi :02:00.0: restoring config space at offset 0xe (was 0x, writing 0x0) Mar 15 16:10:52 localhost kernel: [79800.951458] iwlwifi :02:00.0: restoring config space at offset 0xd (was 0x, writing 0xc8) ... Mar 15 16:10:53 localhost kernel: [79803.655115] iwlwifi :02:00.0: L1 Enabled; Disabling L0S Mar 15 16:10:53 localhost kernel: [79803.672140] iwlwifi :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x Mar 15 16:10:53 localhost kernel: [79803.689187] iwlwifi :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x ... Mar 15 16:10:59 localhost kernel: [79809.254554] iwlwifi :02:00.0: Could not load the INST uCode section Mar 15 16:10:59 localhost kernel: [79809.254563] iwlwifi :02:00.0: Failed to start RT ucode: -110 Mar 15 16:10:59 localhost kernel: [79809.271456] iwlwifi :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x Next iteration: wd_disable=1 power_save=0 bt_coex_active=0 Note that power_save=0 seems to be the default anyway. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120315151842.GA7166@nia
Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation
Found these two pages discussing what appears to be the same problem: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/575492 http://ubuntuforums.org/showthread.php?t=1470820 in at least one case, it is definitely the same problem (deep sleep message shows up in the posted log). Note: while there were Lenovo computers, there were a number of other brands also having problems. Wireless card in the discussion was the Intel 5100 AGN. I created a file /etc/modprobe.d/iwlagn.conf and placed the following line in it: options iwlagn 11n_disable=1 11n_disable50=1 and reloaded my driver. Wireless has been rock solid for 14 hours, no dropped packets, no long pauses, no mysterious disconnects. Normally I would at least see short pauses, a few disconnects and 100's of dropped packets in this time frame. Since I haven't been seeing the deep sleep problem lately, someone else will have to disable N on their system to test if this prevents that issue. This doesn't really constitute a fix and it isn't a great work-around either given the major lost of network performance, but if it works for others, it would significantly narrow the range of possible causes for the problem. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.1203152139090.28...@nashapur.deatech.com
Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation
On Mon, Mar 12, 2012 at 12:44:29PM -0500, Jonathan Nieder wrote: Dafydd Harries wrote: Ar 12/03/2012 am 17:11, ysgrifennodd Venkataraman, Meenakshi: Dafydd Harries wrote: Like others, the problems seemed to start around 2.6.39. [...] Sadly, my dpkg.log only goes back to 3.0, which was installed last July (!). Thanks for checking, and sorry for the lack of clarity. /var/log/dpkg.log.1 et al might go back further. Yes, my logs go back as far as dpkg.log.8, which is last July. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120314153724.GB7496@nia
Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation
Like others, the problems seemed to start around 2.6.39. Thought I should note here, my system showed this problem with 2.6.36 through 2.6.39. It seems to have stopped showing the problem (possibly due to a memory upgrade many months ago), but it still has chronic instability of the connection (drops out for varying intervals), and often, network-manager doesn't seem aware of the failure - reloading the driver isn't a reliable solution (sometimes appears to work, often does not) FWIW. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.1203142027440.28...@nashapur.deatech.com
Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation
Hi, Venkataraman, Meenakshi wrote: Hi Shannon and others, Thanks for a helpful note. Forwarding to Shannon, Juha, and Bjørn: First up, my sincere apologies for not responding earlier. I've been swamped with other work, and have had a chance to look at this only now. I just got caught up with the email thread, and it appears that you're seeing a problem with the following configuration most frequently: 1) Enable power saving in the driver (power_save) 2) Enabling 11n 3) Leaving aspm at its default 4) wd_disable=0 (the default) Our devices are known to have issues with being in L1 (a PCIe sleep state), and so we use L0S by default - this is a lower latency and higher power state. We've also not been able to reproduce the MAC in deep sleep problem at our end, so not sure at the moment what is causing it. However, there was one issue with queue-stuck detection that we found and fixed very recently. The patch is available in the wireless-next tree, and will likely improve the situation if a stuck queue was the initial cause of your problem. You can get the source here: http://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next.git And the patch I'm talking about is this: git.kernel.org/?p=linux/kernel/git/linville/wireless-next.git;a=commit;h=342bbf3fee2fa9a18147e74b2e3c4229a4564912 My suggestion is to load the module with power_save=0, wd_disable=1. Enabling 11n should not be a problem, but if it is, then please let us know. You should not need to use the wd_disable=1 in the upcoming versions of the kernel, but for now, I'd suggest using it. Since your problem seems to be reducing significantly by using pcie_aspm=off, I would appreciate it much if you could tell us what the behaviour is with all other parameters being the same (power_save=0, wd_disable=1), and just toggling the state of this variable. We'll try to reproduce the suspend/hibernate/resume issue in-house and let you know if we were able to reproduce the problem at our end. If not, we'd like you to try out a newer WiFi card; as the 5100 is a fairly old device, and will likely not get any firmware updates (if it is some weird firmware/driver combo that produced the PCIe error). Thanks! Meenakshi Venkataraman -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120312160738.GA18721@burratino
Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation
found 628444 linux-2.6/3.2.9-1 tags 628444 + upstream patch moreinfo quit Hi Dafydd, Dafydd Harries wrote: I've been seeing similar problems with my Intel Corporation Centrino Ultimate-N 6300. Like others, the problems seemed to start around 2.6.39. Odd. What kernel did you use before then? (/var/log/dpkg.log might tell.) Like othes, the card flakes out a day or two after booting, and a reboot always fixes the problem. Occasionally it stays working for longer. Like others, I've added RAM. But as far as I can recall the upgrade happened well before any poblems started appearing. Interesting and useful. Any ASPM settings are at their default. I'll try wd_disable=1 as a workaround for now. Meenakshi, will the patch you mentioned be applied in 3.3? Cc-ing her. The patch currently seems to be part of the wireless-next tree but not davem's net tree. Below is a syslog excerpt from around the time of failue. It seems to support Meenakshi's suggestion that it's related to the queue getting stuck. Well, that can be tested. Could you try the patch against current master? It works like this: 0. Prerequisites: apt-get install git build-essential 1. Get the kernel history, if you don't already have it: git clone \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 2. Configure and build: cd linux git checkout origin/master cp /boot/config-$(uname -r) .config; # current configuration make localmodconfig; # optional: minimize configuration make deb-pkg; # optionally with -jnum for parallel build dpkg -i ../name of package; # as root reboot ... test test test ... 3. Hopefully it reproduces the problem. So try the attached patch: git am -3sc the patch make deb-pkg; # maybe with -j4 dpkg -i ../name of package; # as root reboot If it works, we can pass this to Dave with information about what happened and your test result, to get the patch fast-tracked. Thanks, Jonathan Below is a syslog excerpt from around the time of failue. It seems to support Meenakshi's suggestion that it's related to the queue getting stuck. [...] iwlwifi :02:00.0: Queue 4 stuck for 2000 ms. iwlwifi :02:00.0: Current read_ptr 112 write_ptr 115 iwlwifi :02:00.0: On demand firmware reload iwlwifi :02:00.0: Command REPLY_QOS_PARAM failed: FW Error iwlwifi :02:00.0: Failed to update QoS iwlwifi :02:00.0: fw recovery, no hcmd send iwlwifi :02:00.0: Error sending REPLY_RXON: enqueue_hcmd failed: -5 iwlwifi :02:00.0: Error clearing ASSOC_MSK on BSS (-5) iwlwifi :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x iwlwifi :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x [...] ieee80211 phy0: Hardware restart was requested wpa_supplicant[1472]: CTRL-EVENT-DISCONNECTED bssid=00:50:7f:cb:4b:58 reason=4 ieee80211 phy0: failed to remove key (1, ff:ff:ff:ff:ff:ff) from hardware (-2) [] iwlwifi :02:00.0: Could not load the INST uCode section iwlwifi :02:00.0: Failed to start RT ucode: -110 [...] iwlwifi :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x [...] I get some kind of OOPS but I'm guessing this is just because the driver can't communicate with the card when the module is being unloaded: [...] WARNING: at /build/buildd-linux-2.6_3.2.9-1-amd64-KTPapN/linux-2.6-3.2.9/debian/build/source_amd64_none/drivers/net/wireless/iwlwifi/iwl-core.c:1330 iwlagn_mac_remove_interface+0x48/0xdd [iwlwifi]() Hardware name: 3249CTO Modules linked in: uvcvideo videodev v4l2_compat_ioctl32 media snd_usb_audio snd_usbmidi_lib pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) acpi_cpufreq mperf cpufreq_stats cpufreq_userspace cpu Mar 12 13:15:04 localhost kernel: sync_memcpy async_tx raid1 raid0 multipath linear md_mod sd_mod crc_t10dif usbhid hid ahci libahci ehci_hcd libata scsi_mod usbcore thermal thermal_sys usb_common e1000e [last unloaded: scsi_wait_scan] Mar 12 13:15:04 localhost kernel: [48290.674508] Pid: 1405, comm: NetworkManager Tainted: G O 3.2.0-2-amd64 #1 Mar 12 13:15:04 localhost kernel: [48290.674511] Call Trace: Mar 12 13:15:04 localhost kernel: [48290.674520] [81046879] ? warn_slowpath_common+0x78/0x8c Mar 12 13:15:04 localhost kernel: [48290.674531] [a03ea9af] ? iwlagn_mac_remove_interface+0x48/0xdd [iwlwifi] [...] Mar 12 13:15:04 localhost kernel: [48290.674647] [812a35a5] ? netlink_rcv_skb+0x36/0x7a [...] iwlwifi :02:00.0: ctx-vif = (null), vif = 8801b1c72df0 iwlwifi :02:00.0: ID = 0: ctx = 8801b1a834b0 ctx-vif = (null) From: Johannes Berg johannes.b...@intel.com Date: Sun, 4 Mar 2012 08:50:46 -0800 Subject: iwlwifi: always monitor for stuck queues commit 342bbf3fee2fa9a18147e74b2e3c4229a4564912 upstream. If we only monitor while associated, the following can happen: -
Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation
Hi, Dafydd Harries wrote: I've been seeing similar problems with my Intel Corporation Centrino Ultimate-N 6300. Like others, the problems seemed to start around 2.6.39. Odd. What kernel did you use before then? (/var/log/dpkg.log might tell.) Like othes, the card flakes out a day or two after booting, and a reboot always fixes the problem. Occasionally it stays working for longer. [MV] what platform are you using? And does your problem appear after a system hibernate? Like others, I've added RAM. But as far as I can recall the upgrade happened well before any poblems started appearing. Interesting and useful. Any ASPM settings are at their default. [MV] Can you try pcie_aspm=off during boot? Meenakshi, will the patch you mentioned be applied in 3.3? [MV] Yes...it should be applied to 3.3 as well (it is also slated to be backported to stable kernels); but it is a fairly recent fix, so it will take some time before it gets accepted to the other Linux trees. Below is a syslog excerpt from around the time of failue. It seems to support Meenakshi's suggestion that it's related to the queue getting stuck. [...] iwlwifi :02:00.0: Queue 4 stuck for 2000 ms. [MV] Any idea what happened before this? Did you see any error sending host commands? Did you resume from a hibernate? Can you send me the log? Thanks for your patience, Meenakshi -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4595b4d22ab93c4fabba84aad5aa37fd0dc...@orsmsx103.amr.corp.intel.com
Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation
Ar 12/03/2012 am 17:11, ysgrifennodd Venkataraman, Meenakshi: Hi, Dafydd Harries wrote: I've been seeing similar problems with my Intel Corporation Centrino Ultimate-N 6300. Like others, the problems seemed to start around 2.6.39. Odd. What kernel did you use before then? (/var/log/dpkg.log might tell.) Sadly, my dpkg.log only goes back to 3.0, which was installed last July (!). I could try installing e.g. 2.6.32 from snapshot.debian.org if other things don't help. But that would be a lot of patches to bisect, especially when reproduction iterations are so long... Like othes, the card flakes out a day or two after booting, and a reboot always fixes the problem. Occasionally it stays working for longer. [MV] what platform are you using? And does your problem appear after a system hibernate? Linux nia 3.2.0-2-amd64 #1 SMP Sun Mar 4 22:48:17 UTC 2012 x86_64 GNU/Linux The system is Debian unstable. I don't use hibernation. I do suspend regularly, but I haven't noticed any correlation with suspend/resume. Like others, I've added RAM. But as far as I can recall the upgrade happened well before any poblems started appearing. Interesting and useful. Any ASPM settings are at their default. [MV] Can you try pcie_aspm=off during boot? I'm currently waiting to see if wd_disable=1 help at all. This might take a few days, though, since I don't have any way to reproduce it. Meenakshi, will the patch you mentioned be applied in 3.3? [MV] Yes...it should be applied to 3.3 as well (it is also slated to be backported to stable kernels); but it is a fairly recent fix, so it will take some time before it gets accepted to the other Linux trees. Below is a syslog excerpt from around the time of failue. It seems to support Meenakshi's suggestion that it's related to the queue getting stuck. [...] iwlwifi :02:00.0: Queue 4 stuck for 2000 ms. [MV] Any idea what happened before this? Did you see any error sending host commands? Did you resume from a hibernate? Can you send me the log? I haven't noticed any pattern. The first thing that happens is that the NetworkManager applet seems to be trying to reconnect to the wireless. The log seems pretty quiet beforehand. Mar 12 10:09:43 localhost dhclient: DHCPREQUEST on wlan0 to 192.168.1.1 port 67 Mar 12 10:09:43 localhost dhclient: DHCPACK from 192.168.1.1 Mar 12 10:09:43 localhost dhclient: bound to 192.168.1.15 -- renewal in 15209 seconds. Mar 12 10:17:01 localhost /USR/SBIN/CRON[12402]: (root) CMD ( cd / run-parts --report /etc/cron.hourly) Mar 12 10:19:46 localhost smartd[2460]: Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 161 to 157 Mar 12 10:25:51 localhost dbus[1395]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper) Mar 12 10:25:51 localhost dbus[1395]: [system] Successfully activated service 'org.freedesktop.PackageKit' Mar 12 11:17:01 localhost /USR/SBIN/CRON[12472]: (root) CMD ( cd / run-parts --report /etc/cron.hourly) Mar 12 11:19:46 localhost smartd[2460]: Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 157 to 161 Mar 12 11:19:59 localhost dbus[1395]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper) Mar 12 11:19:59 localhost dbus[1395]: [system] Successfully activated service 'org.freedesktop.PackageKit' Mar 12 11:25:51 localhost dbus[1395]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper) Mar 12 11:25:51 localhost dbus[1395]: [system] Successfully activated service 'org.freedesktop.PackageKit' Mar 12 11:49:46 localhost smartd[2460]: Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 161 to 157 Mar 12 12:17:01 localhost /USR/SBIN/CRON[15518]: (root) CMD ( cd / run-parts --report /etc/cron.hourly) Mar 12 12:19:20 localhost dbus[1395]: [system] Reloaded configuration Mar 12 12:19:21 localhost dbus[1395]: [system] Reloaded configuration Mar 12 12:19:21 localhost dbus[1395]: [system] Reloaded configuration Mar 12 12:19:21 localhost dbus[1395]: [system] Reloaded configuration Mar 12 12:19:22 localhost dbus[1395]: [system] Reloaded configuration Mar 12 12:19:46 localhost smartd[2460]: Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 157 to 144 Mar 12 12:20:15 localhost anacron[19324]: Anacron 2.3 started on 2012-03-12 Mar 12 12:20:15 localhost anacron[19324]: Normal exit (0 jobs run) Mar 12 12:20:22 localhost dbus[1395]: [system] Reloaded configuration Mar 12 12:20:23 localhost dbus[1395]: [system] Reloaded configuration Mar 12 12:20:23 localhost dbus[1395]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper) Mar 12 12:20:23 localhost dbus[1395]: [system] Successfully activated service 'org.freedesktop.PackageKit' Mar 12 12:34:33 localhost dbus[1395]: [system] Activating service
Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation
Dafydd Harries wrote: Ar 12/03/2012 am 17:11, ysgrifennodd Venkataraman, Meenakshi: Dafydd Harries wrote: Like others, the problems seemed to start around 2.6.39. [...] Sadly, my dpkg.log only goes back to 3.0, which was installed last July (!). Thanks for checking, and sorry for the lack of clarity. /var/log/dpkg.log.1 et al might go back further. what platform are you using? And does your problem appear after a system hibernate? Linux nia 3.2.0-2-amd64 #1 SMP Sun Mar 4 22:48:17 UTC 2012 x86_64 GNU/Linux The system is Debian unstable. Maybe lspci -vvnn output (as an attachment) and dmesg output from booting if you have it could help to pin down the setup a little more. (If I understand correctly, Meenakshi is dreaming of a reliable reproduction recipe. ;-)) Ciao, Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120312174429.GA21040@burratino
Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation
Hi, what platform are you using? And does your problem appear after a system hibernate? Linux nia 3.2.0-2-amd64 #1 SMP Sun Mar 4 22:48:17 UTC 2012 x86_64 GNU/Linux The system is Debian unstable. Maybe lspci -vvnn output (as an attachment) and dmesg output from booting if you have it could help to pin down the setup a little more. (If I understand correctly, Meenakshi is dreaming of a reliable reproduction recipe. ;-)) [MV] That's correct! :-) Meenakshi -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4595b4d22ab93c4fabba84aad5aa37fd0dc...@orsmsx103.amr.corp.intel.com
Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation
Hi Dafydd, I've been seeing similar problems with my Intel Corporation Centrino Ultimate-N 6300. Like others, the problems seemed to start around 2.6.39. [MV] Hmm...this is interesting. Can you load the iwlwifi module with bt_coex_active=0 and see if it changes anything? One of the patches that went in between 2.6.38 and 2.6.39 changed the behaviour of coexistence with Bluetooth devices on some platforms, and caused users some grief; although their symptoms were different. The module parameter I mention above solved this problem for them. Odd. What kernel did you use before then? (/var/log/dpkg.log might tell.) Sadly, my dpkg.log only goes back to 3.0, which was installed last July (!). I could try installing e.g. 2.6.32 from snapshot.debian.org if other things don't help. But that would be a lot of patches to bisect, especially when reproduction iterations are so long... [MV] No...let's leave bisecting as the last option for this problem. [MV] what platform are you using? And does your problem appear after a system hibernate? Linux nia 3.2.0-2-amd64 #1 SMP Sun Mar 4 22:48:17 UTC 2012 x86_64 GNU/Linux [MV] Oh...I was asking about hardware...who is the manufacturer of your system? I don't use hibernation. I do suspend regularly, but I haven't noticed any correlation with suspend/resume. [MV] Interesting as well. [MV] Any idea what happened before this? Did you see any error sending host commands? Did you resume from a hibernate? Can you send me the log? I haven't noticed any pattern. The first thing that happens is that the NetworkManager applet seems to be trying to reconnect to the wireless. [MV] Hmm...the queue stuck patch could potentially help here, but only provided that a queue was stuck prior to the reconnect. Your log doesn't run that far back, so I'm not able to say. :-) Thanks, Meenakshi -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4595b4d22ab93c4fabba84aad5aa37fd0dc...@orsmsx103.amr.corp.intel.com
Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation
Hi Jonathan! Sorry I took a while to respond and apologies in advance for them being quite useless... - steps to reproduce, assuming I had the same hardware Use the computer. My maximum time without hitting the bug has been less than 48 hours before I added the following module options: 11n_disable=1 power_save=0 wd_disable=1 which some googling suggested might solve it. They do not, but they make it less frequent. With them, I can even get a WEEK without seeing this. But notice I have different hw than the original reporter: mine is X200s with Intel Corporation Ultimate N WiFi Link 5300 (pci-id: 8086:4236). - expected result, actual result, and how the difference indicates a bug (should be simple enough in this case) =) Expected result: wifi keeps working unless I switch it off using rf_kill, physical switch, unload the module, or turn off the computer. Actual result: suddenly, out of the blue, in the middle of typing an email in kmail, see attachment. Bug: the wifi card has certainly not changed into Unknown hardware type suddenly. - how reproducible it is (100% of the time? 50%?) 100% when waiting long enough between reboots. - which kernel versions you have tested, and results with each There were no problems in the 2.6-series. The bug occurs at least in the Debian kernel versions 3.2.0-1-amd64, 3.0.0-2-amd64, and 3.0.0-1-amd64. - full dmesg output from booting and reproducing the bug, as an attachment Do not have it now, if really necessary, will get it next time it occurs (which may be a while: I am back to 2.6.39 because I need to get work done). - any other weird observations or workarounds No workaround. Above module parameters alleviate the issue. This is a regression, so I suggest someone with time (if anyone has it) bisects 2.6 and 3.2... horrible task, I do not envy anyone doing that. upstream to a public mailing list. So the purpose of these questions is to collect data on what's known so far as a starting point. Please CC me if you do. Cheers, Juha -- --- | Juha Jäykkä, ju...@iki.fi | | http://www.maths.leeds.ac.uk/~juhaj | --- [252832.820219] iwlwifi :03:00.0: Error sending POWER_TABLE_CMD: time out after 2000ms. [252832.820229] iwlwifi :03:00.0: Current CMD queue read_ptr 134 write_ptr 135 [252832.820237] iwlwifi :03:00.0: set power fail, ret = -110 [252835.320320] iwlwifi :03:00.0: Error sending REPLY_QOS_PARAM: time out after 2000ms. [252835.320331] iwlwifi :03:00.0: Current CMD queue read_ptr 134 write_ptr 137 [252835.320338] iwlwifi :03:00.0: Failed to update QoS [252837.320249] iwlwifi :03:00.0: Error sending REPLY_RXON: time out after 2000ms. [252837.320259] iwlwifi :03:00.0: Current CMD queue read_ptr 134 write_ptr 140 [252837.320267] iwlwifi :03:00.0: Error clearing ASSOC_MSK on BSS (-110) [252839.320130] iwlwifi :03:00.0: Error sending REPLY_RXON: time out after 2000ms. [252839.320140] iwlwifi :03:00.0: Current CMD queue read_ptr 134 write_ptr 143 [252839.320148] iwlwifi :03:00.0: Error clearing ASSOC_MSK on BSS (-110) [252841.320273] iwlwifi :03:00.0: Error sending REPLY_ADD_STA: time out after 2000ms. [252841.320283] iwlwifi :03:00.0: Current CMD queue read_ptr 134 write_ptr 146 [252841.320296] ieee80211 phy0: failed to remove key (0, 00:24:17:33:f4:f5) from hardware (-110) [252843.320053] iwlwifi :03:00.0: Error sending REPLY_REMOVE_STA: time out after 2000ms. [252843.320057] iwlwifi :03:00.0: Current CMD queue read_ptr 134 write_ptr 149 [252843.320061] iwlwifi :03:00.0: Error removing station 00:24:17:33:f4:f5 [252845.324086] iwlwifi :03:00.0: Error sending REPLY_RXON: time out after 2000ms. [252845.324096] iwlwifi :03:00.0: Current CMD queue read_ptr 134 write_ptr 152 [252845.324104] iwlwifi :03:00.0: Error clearing ASSOC_MSK on BSS (-110) [252847.328250] iwlwifi :03:00.0: fail to flush all tx fifo queues [252849.328175] iwlwifi :03:00.0: Error sending POWER_TABLE_CMD: time out after 2000ms. [252849.328185] iwlwifi :03:00.0: Current CMD queue read_ptr 134 write_ptr 154 [252849.328192] iwlwifi :03:00.0: set power fail, ret = -110 [252851.328203] iwlwifi :03:00.0: Error sending REPLY_RXON: time out after 2000ms. [252851.328214] iwlwifi :03:00.0: Current CMD queue read_ptr 134 write_ptr 155 [252851.328222] iwlwifi :03:00.0: Error clearing ASSOC_MSK on BSS (-110) [252853.328234] iwlwifi :03:00.0: Error sending REPLY_ADD_STA: time out after 2000ms. [252853.328245] iwlwifi :03:00.0: Current CMD queue read_ptr 134 write_ptr 156 [252853.328258] ieee80211 phy0: failed to remove key (1, ff:ff:ff:ff:ff:ff) from hardware (-110) [252853.328380] cfg80211: Calling CRDA to update world regulatory domain
Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation
Hi Juha, Juha Jäykkä wrote: What is the status of the fix from Intel? I have the same problem since upgrading to 3.x series and it is VERY annoying - only way I can fix it is rebooting the kernel, so it really seems a kernel bug. Hibernating the system and doing a full power-off (unplug AC, remove battery, wait 60 seconds – this should do it) the laptop does NOT fix it, so I concur: the kernel must retain some bogus information somewhere since the hw has definitely lost its status info. Please provide: - steps to reproduce, assuming I had the same hardware - expected result, actual result, and how the difference indicates a bug (should be simple enough in this case) - how reproducible it is (100% of the time? 50%?) - which kernel versions you have tested, and results with each - full dmesg output from booting and reproducing the bug, as an attachment - any other weird observations or workarounds I believe the best way to move forward would be to take this report upstream to a public mailing list. So the purpose of these questions is to collect data on what's known so far as a starting point. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120211193827.GE6944@burratino
Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation
On Wed, 23 Nov 2011, Jonathan Nieder wrote: Shannon Dealy wrote: A developer at Intel contacted me regarding this bug the other day (he was following up on a similar bug report from another source) and I am working with him on the problem (currently doing a debug build of the module to collect data on what is happening). That's good to hear. Did it bear any fruit? (Any test results or public mailing list messages we can look at?) Nothing so far, both he and I are very busy so it is a slow process, waiting for each of us to work the next step into our schedules. Currently I am waiting for his response to a set of data I captured from the driver surrounding one failure. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.250814390.11...@nashapur.deatech.com
