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, thereare 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. dealy@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com