#10002 HIGH Not Tri: kernel crash on boot

[Zarro Boogs per Child]

#10002: kernel crash on boot
--------------------------------+-------------------------------------------
           Reporter:  wad       |       Owner:  dsaxena                          
               Type:  defect    |      Status:  new                              
           Priority:  high      |   Milestone:  Not Triaged                      
          Component:  kernel    |     Version:  Development build as of this date
         Resolution:            |    Keywords:  XO-1.5                           
        Next_action:  diagnose  |    Verified:  0                                
Deployment_affected:            |   Blockedby:                                   
           Blocking:            |  
--------------------------------+-------------------------------------------

Comment(by wmb at firmworks.com):

 0xff803b65 is in OFW - specifically it is the instruction in "@" that does
 the dereference.

 The virtual address that it is trying to access is 0xffee0f40, which is a
 bit outside the virtual address range that OFW normally uses.

 The kernel's vmalloc area is overlapping OFW's virtual address range:

 [    0.000000]     vmalloc : 0xe9781000 - 0xfffa2000   ( 360 MB)

 With one exception, OFW restricts its virtual address use to the 4M region
 from ff80.0000 to ffbf.ffff.  The exception is the frame buffer mapping, a
 16 MB mapping at fe80.0000, extending up to just below the main OFW
 mapping area at ff80.0000.

 I think we need to add either "reservetop=8M" or "reservetop=48M" to the
 kernel cmdline.  The former should prevent the kernel from re-allocating
 any virtual address space that OFW would use during device tree
 operations; the latter would also include the frame buffer, which might be
 helpful in the "sysrq-to-OFW" case.

 Note that the reservation is for virtual address space, not physical
 memory.

 I think the reservation is prudent, but I am not certain that the
 reservation will eliminate the problem as reported, since I don't have a
 good explanation for the specific fault address.  The details of how that
 address came to be used aren't obvious from the trace.

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