#10757 NORM Not Tri: XO-1.5 system time failed to adjust forward by rtcwake period

[Zarro Boogs per Child]

#10757: XO-1.5 system time failed to adjust forward by rtcwake period
------------------------------------+---------------------------------------
           Reporter:  Quozl         |       Owner:               
               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 dsd):

 Section 3 of http://lwn.net/images/pdf/suspend_blockers.pdf is good for
 understanding some of Linux's challenges in timekeeping in suspend.
 Basically, the system clock naturally does not advance during suspend, so
 Linux must re-read the time during resume.

 This happens in kernel/time/timekeeping.c : timekeeping_resume()

 The kernel reads a clock source thats known to keep incrementing during
 suspend via a call to read_persistent_clock(). It then compares the value
 produced by that clock to the timestamp of when we went into suspend.

  * If the persistent clock reads a time value more recent than the pre-
 suspend timestamp, Linux uses these 2 values to calculate the amount of
 time we were in suspend, and then increments its internal clock by that
 amount.
  * If the persistent clock reads a time value older than the pre-suspend
 timestamp, no time adjustment happens.

 So, I suspect we have a bug in read_persistent_clock(), which sometimes
 produces a value in the past (which is outright ignored by Linux,
 resulting in no time ticking during suspend), or a wacky value 10 years in
 the future (#10756).

 Digging further, read_persistent_clock() seems to be implemented by
 mach_get_cmos_time() (in arch/x86/kernel/rtc.c) which in turn seems to use
 IO ports 0x70 and 0x71 to implement READ_CMOS().

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