#9420 BLOC 1.5-F11: Crash on resume

[Zarro Boogs per Child]

#9420: Crash on resume
--------------------------------+-------------------------------------------
           Reporter:  cjb       |       Owner:  dsaxena      
               Type:  defect    |      Status:  new          
           Priority:  blocker   |   Milestone:  1.5-F11      
          Component:  kernel    |     Version:  not specified
         Resolution:            |    Keywords:               
        Next_action:  diagnose  |    Verified:  0            
Deployment_affected:            |   Blockedby:               
           Blocking:            |  
--------------------------------+-------------------------------------------

Comment(by wmb at firmworks.com):

 Replying to [comment:11 cjb]:
 > Mitch, I think I recall we had an OFW for XO1 that would check RAM for
 bitrot on resume.  How plausible might it be to do that again?


 It's not as easy as it was before, because the use of ACPI means that OFW
 doesn't get a chance to run on the way down.  So OFW can't create the
 "before" checksum to compare with the "after" checksum.

 There are two ways around this:

 a) Using the SMI handling code that will be in A15, we could put an SMI
 trap on writes to the ACPI "go to sleep" register, thus letting OFW get
 involved in the final steps of suspend.

 b) We could checksum in advance some area of memory that isn't supposed to
 change and see if it has rotted.

 Both are in the category of "not a slam dunk, but not crazy hard".

 > We're hitting the *same* null pointer dereference often, so that
 suggests against random bitrot to me.


 Yeah, I agree.

 > But worth sanity-checking ourselves, perhaps?

 Probably.

 If I do (a), I could also turn off all the bus mastering enable bits to
 guard against self-refresh kick-out.

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