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/
signature.asc
Description: PGP signature
_______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
