On Wed, 2007-02-14 at 12:47 -0300, Luke Browning wrote:
> 
> [EMAIL PROTECTED] wrote on 02/14/2007 08:11:11 AM:
> 
> > Anyway, I'm glad someone's looking at kexec on cell, I haven't had
> the
> > time to look closely at it. You said that your kexec was hanging in
> > the second region, how were you debugging it? Can you give us
> anymore
> > info?
> > 
> > Another problem with the existing kexec code is it doesn't cope
> > properly with 64k pages on non hypervisor machines, like the cell
> > blade. We need to fix the FIXME in native_hpte_clear()
> > (arch/powerpc/mm/hash_native_64.c).
> > 
> > cheers
> 
> Thanks for the tips.  I will start looking at kexec code now.   
> 
> Debugging is not easy, but you can do it using the cell simulator to
> examine  
> register and memory locations after a system crash.  I ended up
> writing assember  
> code to check point important values in global memory and on the
> stack.  I will  
> probably use the same techniques to debug kexec now that I have the
> source code.   
> 
> I don't know of another way without a kernel debugger.  How would you
> recommend  
> doing it?  Ultimately, I would like to set breakpoints, watchpoints,
> and step  
> through the code.  I heard that you could use gdb with the cell
> simulator to  
> debug the kernel, but it didn't work.  

Yeah the simulator is not a bad way to do it, as long as we keep in mind
that there may be issues on real hardware that the simulator doesn't
expose. A kernel debugger wouldn't be much use unfortunately, by the
time we're kexec'ing it wouldn't be able to help us. I haven't looked at
using gdb against the simulator.

> I will take a look at the 64K page issue also, but that is a little
> bit  
> outside my area of expertise.  How are 64K pages used on Cell?  Is it
> just the 
> kernel.  I thought that there were issues with the use of 64K pages
> and that  
> support was backed out. 

I'm not sure what the SDK kernels are using, but the upstream
cell_defconfig selects 64k as the base page size.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
fastboot mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/fastboot

Reply via email to