Luke Browning wrote: > michaelellerman at gmail.com wrote: > > > 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. > > 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. > > Thanks, Luke
Thanks Mike for getting Luke on the right track with regards purgatory. Luke, you should know that to the best of my knowledge, the mpic code has never been shown to work. The kexec ppc64 code was developed on under BML for POWER5 and has been tested only on native xics and hypervisor versions (blades have a firmware emulation of xics). The mpic code was my best guess without reading any documentation, and has since been "cleaned up" without any testing. In addition, I received a report of kexec not working on a POWER3 box, and have only a failed attempt on my own POWER3 model 170 (I didn't try to debug it). You asked about debugging techniques: In addition to writing to a trace buffer, as you were suggesting, you should take advantage of RTAS. RTAS is preserved through both boots, and is easy to call both from the kernel (there are helper functions) and from real mode (just build the arguments on the stack and branch). My plan to debug the POWER3 was to call RTAS to write to the op panel, for cell I would suggest writing strings to the console stream. Also look at the early printk options in the kernel, they can turn on console printks very early into the new kernel (even before we look up the platform). The common purgatory code has a provision for debug print, but I don't think anyone has hooked it up for any platform on PowerPC. Partly because each platform would need different code. Regarding the 64K page issue, native has been tested quite a bit with 4K pages but not 64K pages. The issue is that a different tlbie is required for the large pages. The code walks the hash table, invalidating any entry that it finds. I haven't read up on the multiple page sizes to give you more details unfortunately. This would likely show up as faults in userspace due to tlbs left lying around. I would not expect the kernel to have many problems, because I would expect both the old and new kernels to create the same mappings at the same address, at least for the full kexec case. milton _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
