Bug#928121: Same problem on Lenovo T480
I'm having what appears to be the same problem with a few differences of note: - Lenovo T480 (original report was for a T580) - Linux kernel 4.19.0-6-amd64 - lxdm - xfce4 - External monitor connected via HDMI Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | Biotechnology Development Services Telephone USA: +1 541-929-4089 | USA and the Netherlands Netherlands: +31 85 208 5570 | www.deatech.com
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 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
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
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: Info received (iwlagn - MAC is in deep sleep, cannot restore wifi operation)
Thought I should note that the addition of pcie_aspm=off to my command line has not cured my link problems, but it has changed the behavior of the problems. It is now more likely to recover on its own without me reloading the driver and when I do reload the driver, it is far more likely to fix the problem for a while on the first or second try (in the past I often reloaded the driver six or more times to get it working again) It also appears to be far more likely for the link to fail right when I begin using it. This is a strange behavior where if I haven't been doing anything on the web and then attempt to use the web browser, the link fails at that point in time. I leave a one second ping to my server running most of the time and usually have my email program open which maintains an imap connection to the server. When I access the web browser and don't get a response from the web, a quick check shows the ping has stopped receiving responses, but that the email program has not detected a timeout on its link (which I believe takes 15 seconds of down time). The implication is that web access from a relatively inactive state (just the ping and idle imap connection) actually kills the link for some reason. 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.1203072250390.25...@nashapur.deatech.com
Bug#628444: Info received (iwlagn - MAC is in deep sleep, cannot restore wifi operation)
Thought I should note that the addition of pcie_aspm=off to my command line has not cured my link problems, but it has changed the behavior of the problems. It is now more likely to recover on its own without me reloading the driver and when I do reload the driver, it is far more likely to fix the problem for a while on the first or second try (in the past I often reloaded the driver six or more times to get it working again) It also appears to be far more likely for the link to fail right when I begin using it. This is a strange behavior where if I haven't been doing anything on the web and then attempt to use the web browser, the link fails at that point in time. I leave a one second ping to my server running most of the time and usually have my email program open which maintains an imap connection to the server. When I access the web browser and don't get a response from the web, a quick check shows the ping has stopped receiving responses, but that the email program has not detected a timeout on its link (which I believe takes 15 seconds of down time). The implication is that web access from a relatively inactive state (just the ping and idle imap connection) actually kills the link for some reason. 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.1203072309020.25...@nashapur.deatech.com
Bug#628444: Info received (iwlagn - MAC is in deep sleep, cannot restore wifi operation)
On Wed, 29 Feb 2012, Bjørn Mork wrote: Juha Jäykkä ju...@iki.fi writes: One thing just occurred to me: I added 2 GB of memory (total 4 GB) at about the time these problems started. I cannot say for sure the problems did not start earlier, but it is quite possible they started after! (Please do not [snip] This brings up an interesting point, while I have been having assorted other problems, my deep sleep issues may have stopped around the time that I upgraded to 8GB of RAM. FWIW I am using the exact same card in an X301 with 8 GB memory and have never seen any such problems. Don't think a RAM upgrade can have any impact, except maybe by causing the card to move in its slot. I assume that the memory slots and mini-pcie slots are behind the same cover in the X201 as well? Replugging it seems like a good idea... [snip] Actually, a RAM upgrade can most definitely have an impact. Replacing any hardware on the bus changes bus loads, propagation delays and overall timing of the bus. These changes may be minor, but if the system is running near the limits of the specifications and/or any component on the bus violates the specs, then all sorts of flakey behavior can ensue. Even if everyone plays by the rules, some aspects of bus timings are programmable on some hardware, so a software/firmware bug can also be a source of what would appear to be a hardware problems. Unfortunately, I'm not current on the hardware/buses involved here, so I don't know how these potential issues might apply to this case. 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: Info received (iwlagn - MAC is in deep sleep, cannot restore wifi operation)
On Wed, 29 Feb 2012, Juha Jäykkä wrote: that the memory slots and mini-pcie slots are behind the same cover in the X201 as well? Replugging it seems like a good idea... I wish they were! They are in X4? and X30? but not X200s, where I had to remove the keyboard and handrest to get to the card. Most annoying. This is why I haven't tried it on my system. Nevertheless, the RAM is quit directly on the opposite side of the motherboard compared to the miniPCI slots (there are two: one is empty, I guess it is meant for 3g), so I would not rule out the miniPCI card moving when addin RAM. Especially since I now have almost 3 days of uptime without problems! This is the record since my problems started except for disabling 802.11n and powersave completely, which gave me about a week. I will report back when I loose wifi again or in two weeks if I do not loose it by then (in which case I will assume it was indeed loose in its socket). You are forgetting that you also added: pcie_aspm=off to your kernel boot command line. Since I did the same thing and have also suddenly enjoyed quite stable WIFI for the first time, I would venture to guess that your problem was not the seating of the card but the pcie_aspm option setting. If you want to confirm, you might want to remove that boot option and see if the problem returns. If so, this would be the first really useful confirmation of a specific source for the deep sleep problem and provide a workaround for it that others can use, though someone who is familiar with this aspect of the Linux kernel will have to decide what this means in terms of hardware/software issues, what is causing the fault, and how to fix it. 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: Info received (iwlagn - MAC is in deep sleep, cannot restore wifi operation)
On Thu, 1 Mar 2012, Ben Hutchings wrote: On Wed, 2012-02-29 at 21:09 -0800, Shannon Dealy wrote: [...] Actually, a RAM upgrade can most definitely have an impact. Replacing any hardware on the bus changes bus loads, propagation delays and overall timing of the bus. [...] Unfortunately, I'm not current on the hardware/buses involved here, so I don't know how these potential issues might apply to this case. I don't think RAM and PCI cards have ever been on the same bus. And with PCIe there is a separate link to each card. Unfortunately, that doesn't actually isolate them, though it does usually reduce some of the sources of problems. There are always interface chips tying them together (otherwise DMA transfers would not be possible) and the behavior of these chips will change depending on the load and temperature, so activity on the bus on one side of the chip can significantly affect the timing behavior of the chip on the other side (I track down bugs like this for a living, just not on PC's in a very long time). I have seen bugs in software show up due to a change in manufacturing processes used to produce an interface chip in the system and hardware glitches on an isolated bus that were due to transmission line effects that rippled right through the chip that was supposed to be isolating the two buses. Of course there is always the old standby of noise passed between chips via the power supply traces. There are many more examples. 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.1202292245520.6...@nashapur.deatech.com
Bug#628444: Info received (iwlagn - MAC is in deep sleep, cannot restore wifi operation)
On Sun, 26 Feb 2012, Ben Hutchings wrote: [snip] No, wasn't even aware of its existance. System shows it is currently at default unfortunately, the debug kernel I am currently running has the pcie_aspm regression which prevents it from being changed without rebooting which is rather time consuming with my setup. There doesn't seem to be an obvious way to tell what the default is. [...] I'm not recommending that you set it. I was concerned that forcing ASPM on could possibly trigger this problem. After looking up the setting, I had assumed that was your concern. However, it seems to me that if it is currently on, then forcing it to off might possibly help with the issues with this card. Power management has caused a lot of issues on Linux over the years. Unfortunately, default doesn't tell me which state it is actually in. Will give it a try next time I reboot. 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.1202260747570.9...@nashapur.deatech.com
Bug#628444: Info received (iwlagn - MAC is in deep sleep, cannot restore wifi operation)
On Fri, 24 Feb 2012, Juha Jäykkä wrote: [snip] I never had any issues with hibernate or suspend and certainly neither was ever needed to trigger the bug. For example yesterday, I hit the bug after about 3 hours without ever putting the laptop off my lap meanwhile. It wasn't required to trigger the problem on my system either, but it seemed to happen a lot more often in the first few minutes after coming out of hibernation. [snip] What is VERY strange here is the fact that I did not have this problem before going from 2.6.39 to 3.0.0, but not I have it even with 2.6.39! How can that be?!? What else is involved with talking to the wifi card except the kernel and the firmware? Do I need to downgrade iwconfig et al, too? [snip] On my system I could go for weeks without incident, and then have it happen three times in a couple hours. It also appeared to be more prevalent with some versions of the kernel than others (though this may be an illusion due to the irratic nature of the problem). How long did you run it on 2.6.39 previously? Perhaps it would have happened with 2.6.39 previously had you used it for a longer period? 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: Info received (iwlagn - MAC is in deep sleep, cannot restore wifi operation)
On Sun, 26 Feb 2012, Juha Jäykkä wrote: [snip] Shannon: FWIF, I have now rebooted with pci_aspm=off and we'll see what happens. Ben: I also replugged the wifi card. I have also rebooted with pci_aspm=off, and while it has only been a few hours, I have not seen any of the usual irratic behavior that I am used to seeing from the wireless card. Usually this is an ongoing source of irritation to me, though some times it works for a while without problems, so we will see if it lasts. I would have replugged the wifi card a long time ago, but if I recall correctly, it is a little more complicated on this laptop than most I have owned, I don't have the time for it, and am a little wary of tinkering with my main computer when everything I am doing is time critical right now (maybe after I get out of school in a few months). 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: Info received (iwlagn - MAC is in deep sleep, cannot restore wifi operation)
On Sun, 26 Feb 2012, Ben Hutchings wrote: On Thu, 2012-02-23 at 17:59 -0800, Shannon Dealy wrote: [...] some point, outside software MUST be providing bogus information to the driver. I say this because after the deep sleep bug occcurs and the hardware has been power cycled (through hibernate), the device driver and firmware have been reloaded and right from the start they show the deep sleep state again. For a complete power-cycle, you may need to remove both the power cord and the battery. I don't think the Intel wireless cards have any support for wake-on-WAN, but in general devices may still be partly powered as long as any power source is connected to the system. True enough, and I don't remember if I pulled the battery back when I was going after this problem (it has been almost a year since I did all my tests). There is also a switch on the side that kills all RF devices (WLAN and Bluetooth) but I can't verify that it completely kills power to the devices. The log messages you sent are indicative of a total failure of communication with the card. My suspicion would be that the hardware has developed a fault, but it could be as simple as the card being slightly loose in its slot. Hardware failure might make sense except that it has always behaved this way, others have similar symptoms, and most importantly, regardless of what behaviors are occurring (there are a number of problems this card exhibits), while hibernate won't clear the deep sleep problem, rebooting the system (without power cycling) clears the problems EVERY time. Whatever the trigger (intermittent hardware fault or driver bug), it appears the kernel is getting into a state from which it is incapable of recovering. Having said that, are you setting the pcie_aspm kernel parameter? No, wasn't even aware of its existance. System shows it is currently at default unfortunately, the debug kernel I am currently running has the pcie_aspm regression which prevents it from being changed without rebooting which is rather time consuming with my setup. There doesn't seem to be an obvious way to tell what the default is. I should note that I have not seen the deep sleep problem in many months, though it is hard to say when or if it has stopped since it often took weeks to show up and my usage patterns have changed considerably. In particular I noticed that hibernate for my system seemed to be a significant contributor to triggering the bug since the problem often showed up in the first few minutes after bringing the computer out of hibernation. This is not a requirement to trigger the problem, just significantly increased the odds. NOTE: I stopped using hibernate in large part because of the deep sleep bug. Unfortunately, the other problems of this card continue to plague me (chronic random communication failures being the big one). 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.1202252309490.9...@nashapur.deatech.com
Bug#628444: Info received (iwlagn - MAC is in deep sleep, cannot restore wifi operation)
On Wed, 22 Feb 2012, Juha Jäykkä wrote: Replying to myself, really, but two new observations: 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. As much as I thought and hoped this was true, it is not. I just had the problem with 2.6.39, so... [snip] As my original report noted, I have had the problem in everything from 2.6.36 to 2.6.39 (I also think 2.6.32 but am not certain and didn't have the time to check). I don't recall what I said about firmware, but have tried at least 5 different versions. I have almost completely stopped using hibernate (suspend only) on my system and have not seen the problem in a long time and for my system at least, hibernate seems to be related to the number of incidents of the deep sleep bug. While the firmware may play a role in the problem, at its core, there are issues that must be occurring outside the firmware or even the iwlagn driver, namely a kernel bug or bug in a supporting driver - there is simply no way around this. When a machine has been through a hibernation cycle and completely powered off with the driver unloaded before shutdown, it simply cannot come back up with the deep sleep problem still in place unless there is a bug in the kernel or some other driver involved. At some point, outside software MUST be providing bogus information to the driver. I say this because after the deep sleep bug occcurs and the hardware has been power cycled (through hibernate), the device driver and firmware have been reloaded and right from the start they show the deep sleep state again. Everything related to the device has been completely reinitialized so they cannot have any knowledge of past history or status, so some piece of outside software is holding on to outdated information and not updating. I demonstrated this repeatedly when I first started fighting with the problem. I also have other stability issues with the driver, the most irritating of them is randomly pausing for periods of a few seconds up to several minutes where no data gets through, as well as assorted other symptoms consistent with race conditions between the driver and the kernel or other drivers. Again, reloading the driver and/or firmware does not fix these problems, or only does so sporadically. Based on this behavior and the fact that Juha appears to have similar hardware (though not the same model), and my previously noting that many of the people complaining on the internet seemed to be using Lenovo hardware, my recommendation to anyone who has time to investigate would be to look at the Linux driver(s) for the flavor of PCI interface bus these cards plug-in to and the particular chip sets used to implement this bus on the known Lenovo machines having the problem (x201i, x200, ...). My guess is they are using the same hardware and therefore, the same interface driver. I don't know where else the bogus device status information might come from or be stored, but I haven't been keeping up with the Linux kernel for quite a while. Note: my contact at Intel has not responded to my request for status, so I don't know what if anything is happening at their end. 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: Debian bug #628444
On Sat, 11 Feb 2012, Juha Jäykkä wrote: Hi Shannon! 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. Hi Juha, Sorry, I haven't heard from him in a couple months. I think both of us are pretty backed up with other things to deal with (as an embedded systems developer, I would have just tracked it down myself if I could spare the time). One thing that seems to have made a difference for me is that I use suspend rather than hibernate these days. This seems to give me much better system stability, particularly with the iwlagn driver, though it shows a number of quirks other than this bug, at least the other ones (so far) can be cured by simply waiting and/or reloading the device driver. I'll send him a message and see what is happening. 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
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
Bug#628444: linux-image-2.6.39-1-686-pae: iwlagn - MAC is in deep sleep, cannot restore wifi operation
On Sat, 17 Sep 2011, maximilian attems wrote: I wasn't aware that the 3.0 kernels were out until you sent this message. Unfortunately, since this bug takes time to manifest, it will require that I run with 3.0 as my default kernel, this means I have to get vmware to run with it (since I use it heavily), and that is usually a problem for bleeding edge kernels. I will look into it, but it may be a week or so before I can even try running a 3.0 kernel. bleeding edge would be against linux-next, 3.1-rcX is in experimental. that would be next target if problem persists. Bleeding edge is anything which hasn't been in use long enough that there is still significant potential for major bugs. Having had very long experience with the Linux kernel (and having fixed the bugs myself on several occasions), the 3.x kernels qualify. Anyway according to your description you are loading binary blobs into your OS, so you just voided our support and this bug report can be closed away unless you can reproduce without. 1- Actually, VMWare provides the source code for their kernel interface code which uses loadable modules, but usually someone has to work up a source code patch for the latest versions of the kernel ( 6-9 months old) and then users have to patch and rebuild the kernel interface. I have worked up patches myself on a few occasions, but I don't really have the time. 2- I wasn't running VMWare at the time I reported these problems, I use it only for customer software development and there weren't any customers back then. Now I am rather busy. So no, this bug report cannot be closed on that basis and as I stated before, even a cursory scan of the internet shows this is a common problem for people running similar hardware, so even if I were running binary blobs, the bug should remain open. NOTE: If one were to assume that VMWare were in any way relevant to this problem, then the bug should move from machine to machine as I migrate my development environment. Instead, the bug showed up when I moved to a new machine with different hardware and device drivers, but the same kernel. I upgraded to a variety of different kernels in the hope that one of them would work and have settled on the current one I am running because it seems to have the problem less often. 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.1109170852490.14...@nashapur.deatech.com
Bug#628444: linux-image-2.6.39-1-686-pae: iwlagn - MAC is in deep sleep, cannot restore wifi operation
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). 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.1109170948510.14...@nashapur.deatech.com
Bug#628444: linux-image-2.6.39-1-686-pae: iwlagn - MAC is in deep sleep, cannot restore wifi operation
On Tue, 13 Sep 2011, maximilian attems wrote: tags 628444 moreinfo stop This bug actually applies to all Debian kernels I have tried including 2.6.36, 2.6.37, 2.6.38, and 2.6,39 Did you try since newer 3.0 images, how are they performing? thank you I wasn't aware that the 3.0 kernels were out until you sent this message. Unfortunately, since this bug takes time to manifest, it will require that I run with 3.0 as my default kernel, this means I have to get vmware to run with it (since I use it heavily), and that is usually a problem for bleeding edge kernels. I will look into it, but it may be a week or so before I can even try running a 3.0 kernel. 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.1109142348290.19...@nashapur.deatech.com
Bug#628444: linux-image-2.6.39-1-686-pae: iwlagn - MAC is in deep sleep, cannot restore wifi operation
Package: linux-2.6 Version: 2.6.39-1 Severity: important After some arbitrary period of use, wifi fails and errors show up in syslog indicating MAC is in deep sleep after which nothing can be done to restore wifi functionality other than rebooting the system. In most (possibly all) cases, the failure occurs after the laptop has been suspended and resumed at least once, though the actual occurance may not be immediately after resuming, it often occurs within a few minutes after resume. Unloading and reloading the iwlagn driver and the drivers it relies on have no effect. Speculation: there is a mechanical switch on the side of the laptop which cuts power to both bluetooth and wifi on this machine. Unloading iwlagn turning off the switch waiting ten seconds, then turning it on and reloading iwlagn also has no effect. Assuming this switch actually is a hardware power off of the devices, this should reset the device and a reload of the driver should restore functionality. Since this does not occur, I see only two possibilities, either the power switch does not completely power off the device, or the kernel is retaining some bogus information (possibly placed there by iwlagn) about the device in spite of the driver being unloaded and reloaded. Even if it doesn't prevent the problem, simply curing this issue so the device can be restarted without rebooting would be a major improvement. I have tried a number of different versions of the firmware as well as different kernels, all combinations have the problem, though some seem to be more stable than others. In some combinations it make take one to two weeks of usage with perhaps a dozen suspend resume cycles per day, in others it seems to happen every day. I have noted in my search of the net that Lenovo laptops seem to be most (possibly all, I wasn't paying close attention) of the cases where this bug occurs. My system is a Lenovo x201i, the wifi adapter was listed as an: Intel Centrino Advanced-N 6200 (2x2 AGN) This bug actually applies to all Debian kernels I have tried including 2.6.36, 2.6.37, 2.6.38, and 2.6,39 (various versions of each and I think it included earlier ones, but I don't remember which ones and no longer have them installed). NOTE: this appears to be the same as closed bug 589383 which was closed upstream and tagged unreproducible. Even the most cursory search of the net shows there are lots of people having no problems reproducing it. It strikes me as inappropriate to close a bug as unreproducible when it is quite clear that many people are seeing it. May 28 15:19:12 nashapur kernel: [16275.165421] iwlagn :02:00.0: Error sending REPLY_ADD_STA: time out after 500ms. May 28 15:19:12 nashapur kernel: [16275.165428] HW problem - can not stop rx aggregation for tid 0 May 28 15:19:12 nashapur ifd[1923]: executing: '/usr/share/laptop-net/link-change wlan0 unmanaged up,running,connected up,running,disconnected' May 28 15:19:12 nashapur kernel: [16275.664639] iwlagn :02:00.0: Error sending REPLY_QOS_PARAM: time out after 500ms. May 28 15:19:12 nashapur kernel: [16275.664644] iwlagn :02:00.0: Failed to update QoS May 28 15:19:12 nashapur kernel: [16275.748419] iwlagn :02:00.0: Queue 2 stuck for 2000 ms. May 28 15:19:12 nashapur kernel: [16275.748429] iwlagn :02:00.0: On demand firmware reload May 28 15:19:13 nashapur kernel: [16276.163702] iwlagn :02:00.0: Error sending REPLY_RXON: time out after 500ms. May 28 15:19:13 nashapur kernel: [16276.163709] iwlagn :02:00.0: Error clearing ASSOC_MSK on BSS (-110) May 28 15:19:13 nashapur kernel: [16276.180377] iwlagn :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x May 28 15:19:13 nashapur kernel: [16276.196983] iwlagn :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x May 28 15:19:13 nashapur kernel: [16276.213584] iwlagn :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x May 28 15:19:13 nashapur kernel: [16276.230200] iwlagn :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x May 28 15:19:13 nashapur kernel: [16276.246801] iwlagn :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x May 28 15:19:13 nashapur kernel: [16276.263411] iwlagn :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x May 28 15:19:13 nashapur kernel: [16276.280011] iwlagn :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x May 28 15:19:13 nashapur kernel: [16276.296612] iwlagn :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x May 28 15:19:13 nashapur kernel: [16276.313214] iwlagn :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x May 28 15:19:13 nashapur kernel: [16276.329830] iwlagn :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x May 28 15:19:13 nashapur kernel: [16276.346433] iwlagn :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x May 28 15:19:13 nashapur kernel: [16276.363037] iwlagn
Bug#628444: Acknowledgement (linux-image-2.6.39-1-686-pae: iwlagn - MAC is in deep sleep, cannot restore wifi operation)
Oops, the previously closed bug I mentioned should have been: #589353 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589353 NOT #589383 Sorry for the confusion. 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.1105281923590.4...@nashapur.deatech.com
