#12704 NORM Not Tri: [CL4]The power LED will keep turn on about 30 secs in S3 mode.Fail rate:1/6 times

[Zarro Boogs per Child]

#12704: [CL4]The power LED will keep turn on about 30 secs in S3 mode.Fail rate:1/6
times
------------------------------------+---------------------------------------
           Reporter:  james         |       Owner:  pgf          
               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 pgf):

 thanks for the report.

 i don't yet know for sure that i've found the specific cause, but i've
 certainly found a bug.

 OLPC drivers whose wakeup events originate from the EC (OLS, battery, AC)
 choose whether to leave their wakeups enabled during suspend, by invoking
 olpc_ec_disable_wakeup().  the EC driver then sends the mask produced as a
 result of all these calls to the EC.  this depends on the EC driver's
 suspend routine running after all the other drivers have had a chance to
 reset their bits.  however, that's not currently the case on XO-4.

 this trace shows the OLS, EC, and battery suspend routines running in an
 inappropriate order:
 {{{
 [  156.799119] PM: Syncing filesystems ... done.
 [  156.805995] Freezing user space processes ... (elapsed 0.02 seconds)
 done.
 [  156.830702] Freezing remaining freezable tasks ... (elapsed 0.01
 seconds) done.
 [  156.850688] Suspending console(s) (use no_console_suspend to debug)
 [  156.868464] MARK:301 olpc_ols_suspend()
 [  156.868507] MARK:303 olpc_ols_suspend()
 [  156.868507] MARK:213 olpc_ec_disable_wakeup() 'olpc_ec->wakeup_mask' is
 0xfbff
 [  156.868512] MARK:213 olpc_ec_disable_wakeup() 'olpc_ec->wakeup_mask' is
 0xf9ff
 [  156.930822] mmp3_usb_phy_deinit_internal: Deinit usb phy!!!
 [  156.930822] MARK:1170 olpc_ec_1_75_suspend() 'ec->wakeup_mask' is
 0xf9ff
 [  156.970661] mmc2: dropping power over suspend
 [  156.970744] mmc1: dropping power over suspend
 [  156.976315] mwifiex_sdio mmc0:0001:1: PREP_CMD: card is removed
 [  156.978791] mmc0: card 0001 removed
 [  156.978891] mmc0: dropping power over suspend
 [  156.979955] [galcore] enter gpu_suspend
 [  156.979977] [galcore] exit gpu_suspend, return 0
 [  156.979988] MARK:776 olpc_bat_suspend()
 [  156.980003] MARK:786 olpc_bat_suspend()
 [  156.980006] MARK:213 olpc_ec_disable_wakeup() 'olpc_ec->wakeup_mask' is
 0xf9fd
 [  156.980074] PM: suspend of devices complete after 120.248 msecs
 [  156.980296] PM: late suspend of devices complete after 0.001 msecs
 [  156.980574] PM: noirq suspend of devices complete after 0.268 msecs
 [  156.980673] mmp3_pm_enter_d2
 [  156.980694] before suspend

 }}}

 the result is that the battery and AC wakeups events are always enabled in
 the EC.

 i see nothing in the 1.75 code that should affect module ordering, though
 i thought we had discussed this issue at that time.

 further, since olpc-battery.c is built-in, i'm not sure we'll be able to
 get its suspend routine to run before that of olpc-ec-1.75.c, which is
 modular.

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