wake-on-WLAN doesn't always work

[dsd]

XO-1.5 os103 on B3. While pinging a system with autosuspend enabled works OK (system suspends, wakes up soon after due to incoming ping), interestingly it fails to wake if a ping flood is happening. I guess this exposes some kind of timing condition with a packet arriving at the wrong time.

To reproduce:

On 1 system as root:

ping -f <ip of XO>

XO will autosuspend and will not wake up. Resorting to a "slow" ping will not wake the system up.

Wake up the system with a mouse movement and repeat without the -f -- the system will suspend and resume nicely.

[dsd]

Now I reproduced it with the "slow" ping. It just takes a few S/R cycles. "ping -f" is a trivial way to reproduce the issue, seemingly every time.

[dsd]

reverting the following commit does not help:

commit 14f2fe76fe0b16685b409ab1d2471b9f4c1dc54d
Author: Amitkumar Karwar <akarwar@marvell.com>
Date:   Thu Dec 10 14:30:31 2009 +0530

    libertas: Added callback functions to support SDIO suspend/resume.

will send mail to Marvell

[Quozl]

http://lists.laptop.org/pipermail/devel/2010-March/027759.html shows a test on build 112 ... which may be just loss of association.

[pgf]

unfortunately it's gotten harder to test wake-on-wlan, since powerd implements "don't sleep if recent wlan" policy as well as enabling wake-on-wlan. to re-test this, try disabling the behavior of cpu_or_network_busy() in the powerd script.

[dsd]

Reported on marvell symplicity as #451146

[dsd]

Still present in "new" firmware 9.70.20.p0, trivial pingflood test continues to reliably reproduce the issue.

[pgf]

i think this may be the result of a suspend race. as soon as we configure libertas with wakeup conditions, it may generate a wakeup before we reach suspend. if it does so, it's plausible that it doesn't generate a second wakeup on the next packet received, and, in any case, we've lost the first wakeup. i think the new .../power/wakeup_count mechanism in 3.0 and later can help, so we may be able to fix this for 12.1.0.