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

[Jonathan Nieder <jrnieder@gmail.com>]

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