#9755 HIGH 1.5-sof: 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:  1.5-software-beta                
          Component:  wireless   |     Version:  Development build as of this date
         Resolution:             |    Keywords:  XO-1.5 WLAN                      
        Next_action:  reproduce  |    Verified:  0                                
Deployment_affected:             |   Blockedby:                                   
           Blocking:  9858       |  
---------------------------------+------------------------------------------
Changes (by cjb):

  * next_action:  diagnose => reproduce


Old description:

> 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.

New description:

 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.

--

Comment:

 need to reproduce on a build since the wlan fix

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