Opened 5 years ago

Last modified 3 years ago

#9960 new defect

wake-on-WLAN doesn't always work

Reported by: dsd Owned by: dsaxena
Priority: normal Milestone: 1.5-software-later
Component: kernel Version: Development build as of this date
Keywords: Cc: sascha_silbe, erikos
Blocked By: Blocking:
Deployments affected: Action Needed: diagnose
Verified: no

Description

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.

Change History (10)

comment:1 Changed 5 years ago by 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.

comment:2 Changed 5 years ago by 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

comment:3 Changed 5 years ago by Quozl

  • Action Needed changed from never set to diagnose
  • Milestone changed from Not Triaged to 1.5-software-later
  • Version changed from not specified to Development build as of this date

comment:4 Changed 5 years ago by sascha_silbe

  • Cc sascha_silbe added

comment:5 Changed 5 years ago by Quozl

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

comment:6 Changed 4 years ago by 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.

comment:7 Changed 3 years ago by dsd

Reported on marvell symplicity as #451146

comment:8 Changed 3 years ago by erikos

  • Cc erikos added

comment:9 Changed 3 years ago by dsd

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

comment:10 Changed 3 years ago by 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.

Note: See TracTickets for help on using tickets.