#7458 BLOC 8.2.0 (: Intermitent suspend/resume lockup

[Zarro Boogs per Child]

#7458: Intermitent suspend/resume lockup
----------------------------+-----------------------------------------------
   Reporter:  dsaxena       |       Owner:  dsaxena                          
       Type:  defect        |      Status:  assigned                         
   Priority:  blocker       |   Milestone:  8.2.0 (was Update.2)             
  Component:  not assigned  |     Version:  Development build as of this date
 Resolution:                |    Keywords:  joyride-2131:-                   
Next_action:  diagnose      |    Verified:  0                                
  Blockedby:                |    Blocking:  7393                             
----------------------------+-----------------------------------------------

Comment(by dsaxena):

 Replying to [comment:29 dsaxena]:
 > Investigating the timestamp oddness and the way that printk() is getting
 timestamps has changed from 2.6.22 to 2.6.25. In 2.6.22 we just read the
 TSC and used that for the printk() time whereas in the new kernel we're
 doing calling a wrapper function update_rq_clock) that does some range
 checking. Looking at this wrapper, I believe it may be possible to end up
 with duplicate timestamps when coming out of resume, but I need to add
 some debug prints and dig a bit more into the timer code to validate.
 >

 Did a quick test with replacing the call to {{{cpu_clock()}}} (which ends
 up calling {{{update_rq_clock()}}})  with a call to {{{sched_clock()}}}
 and see the duplicate timestamps go away but still see the timeouts and
 lockup;


 {{{
 [    1.714207] olpc_do_sleep!
 +r[    0.005745] olpc-ec:  running cmd 0x34
 [    0.022585] olpc-ec:  running cmd 0x24
 [    0.043417] olpc-ec:  running cmd 0x24
 [    0.067252] olpc-ec:  timeout waiting for EC to read command!
 [    0.073016] olpc-ec:  running cmd 0x1c
 [    0.088828] olpc-ec:  received 0xbb
 [    0.092363] olpc-ec:  running cmd 0x1b
 [    0.102154] olpc-ec:  sending cmd arg 0xff
 [    0.122242] olpc-ec:  running cmd 0x84
 [    0.138055] olpc-ec:  received 0x20
 }}}

 So while the timestamps are somewhat bogus, it is expected (comment for
 {{{cpu_clock()}}}) states "high-speed (but slightly incorrect) per-cpu
 clock constructed from sched_clock()"),
 confusing, and in my opinion should be fixed upstream, it is not related
 to the timeout and lockup issues.

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