[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#628444: Info received (iwlagn - "MAC is in deep sleep", cannot restore wifi operation)

On Thu, 2012-02-23 at 17:59 -0800, Shannon Dealy wrote:
> 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.

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.

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.

Having said that, are you setting the pcie_aspm kernel parameter?

> 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.

The same code is used for PCI and PCIe devices and bridges of all kinds.
The only slot drivers are there to support hotplug.


Ben Hutchings
Lowery's Law:
             If it jams, force it. If it breaks, it needed replacing anyway.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: