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
