#10232 NORM Not Tri: WiFi dies on suspended XO-1, os300

[Zarro Boogs per Child]

#10232: WiFi dies on suspended XO-1, os300
------------------------------------+---------------------------------------
           Reporter:  hal.murray    |       Owner:               
               Type:  defect        |      Status:  new          
           Priority:  normal        |   Milestone:  Not Triaged  
          Component:  not assigned  |     Version:  not specified
         Resolution:                |    Keywords:               
        Next_action:  never set     |    Verified:  0            
Deployment_affected:                |   Blockedby:               
           Blocking:                |  
------------------------------------+---------------------------------------

Comment(by hal.murray):

 Comments from Sascha

 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

-- 
Ticket URL: <http://dev.laptop.org/ticket/10232#comment:8>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system