#9755 HIGH Not Tri: XO-1.5 WLAN can't talk to network after multiple suspend/resumes

[Zarro Boogs per Child]

#9755: XO-1.5 WLAN can't talk to network after multiple suspend/resumes
-------------------------+--------------------------------------------------
 Reporter:  wad          |                 Owner:  mbletsas                         
     Type:  defect       |                Status:  new                              
 Priority:  high         |             Milestone:  Not Triaged                      
Component:  wireless     |               Version:  Development build as of this date
 Keywords:  XO-1.5 WLAN  |           Next_action:  diagnose                         
 Verified:  0            |   Deployment_affected:                                   
Blockedby:               |              Blocking:                                   
-------------------------+--------------------------------------------------
 On an XO-1.5 B3 prototype, running Q3A16 and os45, multiple times I have
 seen that after a number of suspend/resume cycles the WLAN was still
 present and accounted for (iwconfig/ifconfig return fine), but that any
 attempt to use the network fails.   From the laptop, you get Network
 unreachable messages.

 The laptop was modified with the XO1.5 WLAN SR ECO:

     http://wiki.laptop.org/go/XO1.5_WLAN_SR_ECO

 The laptop was set to autowack by adding:

     50 autowack-delay

     autowack-on

 to the olpc.fth file.

 It was associated with an access point.

 From the terminal activity, I enabled EC wakeup events using:

     sudo sh

     echo EC > /proc/acpi/wakeup

 I then started a script (dosr) running:

     for i in seq 1 100000; do echo $i; sleep 1; echo mem >
 /sys/power/state; done;

 Unlike trac ticket 9744, where the WLAN LED starts flashing quickly when
 the WLAN fails, in this case the WLAN LED stays lit (with one off flash
 per suspend cycle).

 I start a remote host pinging the laptop, and wait until pings stop being
 responded to, then stop the suspend/resume cycling.  At this time,
 iwconfig reports that the WLAN is still present and associated, but any
 attempt to actually use the network results in an error message that the
 destination is unreachable.

 ARP on the remote (pinging) machine still shows a valid MAC address, so
 this isn't a loss of ARP due to S/R.

 Looking at the dmesg and /var/log/messages logs, there isn't anything that
 appears out of the ordinary.

 This is easy to reproduce.

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