#7479 BLOC Never A: Suspend failing due to EC warning

[Zarro Boogs per Child]

#7479: Suspend failing due to EC warning
------------------------+---------------------------------------------------
   Reporter:  cjb       |       Owner:  dsaxena       
       Type:  defect    |      Status:  new           
   Priority:  blocker   |   Milestone:  Never Assigned
  Component:  kernel    |     Version:  Update.1      
 Resolution:            |    Keywords:                
Next_action:  diagnose  |    Verified:  0             
  Blockedby:            |    Blocking:                
------------------------+---------------------------------------------------

Comment(by dsaxena):

 The warning is due to the following:

 {{{
         /* the high bit is unused, if it is ever unset, that is a good
 sign
            sign of EC communication corruption! */
         WARN_ON(!(byte & 0x80));

 }}}

 Looking at the logs, we are receiving 0x7f on issuing the READ_SCI_MASK.
 After we receive this, we go ahead and run WRITE_SCI_MASK with a value of
 0x3b, go to sleep, and then get woken back up. At this point, we do
 another READ_SCI_MASK and hit the WARN_ON() again since the high but is
 unset. Richard, Andres, from the WARN_ON() I assume we've seen this
 before...what caused it in the past?

 From the log, it looks like even with the warning we're
 suspending/resuming fine. From a quick walk through the code path, the
 only -EBUSY I see is the following snippet:


 {{{
         if (!mutex_trylock(&pm_mutex))
                 return -EBUSY;
 }}}

 I'll dig more to see if there are any other -EBUSYs in the code path.

 Another oddity from my POV, but might be expected behaviour since I'm
 still figuring out how all our bits work, is "olpm-pm:  PM_PWRBTN wakeup
 event received".  Given that this is on tinderbox, running automatic S/R
 cycles, I'm surprised to see power button events.

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