#11497 BLOC 1.75-so: System do not suspend first when press power button, but second time it test okay

[Zarro Boogs per Child]

#11497: System do not suspend first when press power button, but second time it
test okay
--------------------------------+-------------------------------------------
           Reporter:  Andy Pei  |       Owner:                                   
               Type:  defect    |      Status:  new                              
           Priority:  blocker   |   Milestone:  1.75-software                    
          Component:  kernel    |     Version:  Development build as of this date
         Resolution:            |    Keywords:                                   
        Next_action:  diagnose  |    Verified:  0                                
Deployment_affected:            |   Blockedby:                                   
           Blocking:            |  
--------------------------------+-------------------------------------------
Changes (by pgf):

 * cc: dilinger (added)


Comment:

 i've diagnosed this, but don't yet understand the fix.

 many operations on the rtc will leave an alarm scheduled.  some operations
 do this intentionally ("rtcwake -s 10 -m no") and some, i think, do it
 unintentionally ("hwclock" -- actually, you'll need "hwclock -f /dev/rtc0"
 these days).

 when no process has the rtc device open, interrupts from the chip are
 disabled.  the chip alarm is still configured, of course, and when an
 alarm fires, it will assert its interrupt.  when someone comes along and
 opens the device, alarms become enabled, and the interrupt happens.  this
 generates a pm_wakeup_event() call.  if the process doing the open is
 rtcwake, then that fresh wakeup event correctly interferes with
 suspending, if the /sys/power/wakeup_count protocol is being followed.

 i tried clearing pending alarms from the chip at device open time (while
 still leaving them enabled), and that makes rtcwake work correctly, but
 hwclock starts failing -- it times out, with:
 {{{
 select() to /dev/rtc0 to wait for clock tick timed out
 }}}
 i don't know why this is happening -- it surprises me that hwclock depends
 on previously received interrupts in order to function correctly.

 on the other hand, i also don't understand why the rtc driver goes out of
 its way to disable interrupts when the device isn't open.

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