#9967 NORM 1.0-sof: 2.6.31.6: libertas suspend fails on XO-1

[Zarro Boogs per Child]

#9967: 2.6.31.6: libertas suspend fails on XO-1
------------------------------------+---------------------------------------
           Reporter:  sascha_silbe  |       Owner:  dsaxena                           
               Type:  defect        |      Status:  assigned                          
           Priority:  normal        |   Milestone:  1.0-software-later                
          Component:  kernel        |     Version:  Development source as of this date
         Resolution:                |    Keywords:  libertas suspend                  
        Next_action:  diagnose      |    Verified:  0                                 
Deployment_affected:                |   Blockedby:                                    
           Blocking:                |  
------------------------------------+---------------------------------------
Changes (by dsaxena):

 * cc: pgf (added)


Comment:

 Replying to [comment:10 sascha_silbe]:
 > Replying to [comment:9 dsaxena]:
 > > By default, WOL is disabled, but if I run "ethtool -s eth0 u" and then
 "echo mem > /sys/power/state", the system will go to sleep and I can wake
 it up with a ping from a host. When we resume, I still see a "command
 0x0043 failed" and the reason is b/c the WOL-disable command
 (EHS_REMOVE_WAKEUP) does not seem to be supported by the 8388 firmware.
 This is not fatal as the card keeps running.
 > If the command is not supported, why does the kernel issue it?

 The code was written specifically to handle proper suspend/resume on
 XO-1.5 where the command is supported. Even in the old XO-1 code/kernel,
 we would still issue the command on "ethtool -s eth0 wol d", it would just
 happen at the time of the user command and not later during the suspend
 path.

 > > The proper fix would be to update the userspace on XO-1 F11 to submit
 the proper WOL commands on suspend as we do on XO-1.5 but this still
 leaves us with the case where we are closing the lid and we want full WOL
 disable which we can't issue. :/ A workaround would be to unload the
 driver on lid close and re-load it on lid-open, which is reasonable as
 resume speed is not critical for this use case.
 > I'm a bit confused about the kernel/userspace interaction here, probably
 because I'm on Debian, not on Fedora. Can you please elaborate on what the
 user space parts are and what exactly they do on Fedora? Do you use powerd
 or OHM?

 We are currently using OHM, working on switching to powerd. Paul, (who I'm
 cc:ing) can fill in details.

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