Trac#10232: WiFi dies on suspended XO-1, os300

[Sascha Silbe]

Excerpts from Hal Murray's message of Wed Jul 14 20:27:37 +0000 2010:

> A simple edit makes suspend/wakeup from WiFi work on XO-1 running os300.   So 
> I've been testing it.  It works most of the time, but occasionally stops 
> waking up from WiFi.  Wakeup from touchpad works fine.
There's a very annoying and easy to trigger race condition regarding
suspend. If a wake-up event happens while we are still suspending (either
between the last check in powerd and triggering the suspend using
rtcwake, and/or already on the kernel side) it will be ignored. For
input devices this isn't as bad because any further event (key press /
release, touchpad movement) will wake up the XO. But AIUI the libertas
chip will wait for the host (= CPU / kernel) to confirm the wake-up
event without ever retrying.

>  (delete the "a" from "ethtool -s eth0 wol ua" in /usr/sbin/powerd)
FWIW I'm using "pum". This allows IPv6 to work transparently (IPv6
uses multicast for neighbour discovery).
You could add "b" (broadcast) as a replacement for "a" (ARP), but
at least on some of the networks I'm connected to regularly this
is impractical (both Windows SMB and proprietary Cisco router
management broadcast traffic).

>  The WiFi LED is off.  It blinks when I wake it up by poking the touchpad,
>  but the LED stays off and ping doesn't work.
This suggests you lost association to the access point while in suspend.
Unfortunately this seems to be a firmware bug (specific to the chip in
the XO-1, you won't have this problem on an XO-1.5) that we cannot
easily work around in the kernel. If the chip looses association while
in suspend, it neither wakes up the host nor tells it about having lost
association when the host eventually wakes up. As there's no way for the
host to query the current association status (at least I didn't find one
in the sparse documentation), the kernel has no way to detect this.
The blinking you see upon resume is a WiFi scan. I haven't looked into
who triggers this scan - presumably NetworkManager. But since the kernel
and thus user space never notices we lost association, this isn't really
of interest.
So far my tests suggested that WPA rekeying wakes up the host, so the
reason for disassociation is probably something else. Even without
suspend the XO-1 will disassociate about once or twice a day on
average which makes this plausible. But it's merely a loose time-based
correlation; I haven't done any specific test to be sure about it.

Feel free to copy this to Trac - I just didn't have time to do so yet
(and wanted to do some other tests first, but didn't get around to
that either).

Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.laptop.org/pipermail/devel/attachments/20100715/bb974dd7/attachment.sig>