[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)



Hi Shannon and others,

 

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


Reply to: