On 09 Jun 2006 06:47:59 +0800, Zou Nan hai wrote: > Thanks for testing and review. > > There is still a lot of work to do for ia64 Kdump to be a very useful >and robust feature. > > Major issues. > 1. Full percpu dumping on INIT. > You may notices I only send an IPI to user CPUs and dump part of >registers for crashing CPU.Just stop other CPUs, not dumping their >status. This is only a temp hack. > On other platforms they did this by an NMI, on IA64 we should use INIT >to acknowledge other CPUs. And I know on some platform there is a >trigger on panel can trigger INIT. We could use that to dump at the time >of deadlock. But currently INIT is used by MCA, we need to find a way to >coordinate with MAC on INIT. > > 2. unwind section is missing in vmcore. > When you do a readelf on vmcore, you may notice there is no unwind >sections. We should add this percpu stack unwind sections to help dump >filter tools to analize the core dump. > > 3. kdump path at crash time. > Currently I still have to do a irq->end on each level triggered irq, >without that the MPT fusion driver can not restart. We should fix this, >at least do that in a way of not touching any memory in previous kernel. > > 4. Other than this, we need port the dump filter to IA64. > >There are still some minor issues. >e.g > When I get a crash when X is active, the new kernel will startup in a >blank screen(network is still working). I have indeed do a brute force >VGA reset on in purgatory code. But that seems to only shutdown the VGA >but not reinit it if X is running. > > Current kexec can't not run on a kexec'd kernel, that is because the >memory region of EFI memmap is not reserverd in /proc/iomem, I will sent >a patch to reserve that region later. > >There should be other issues and gaps need to find out. > >Thanks >Zou Nan hai >- >To unsubscribe from this list: send the line "unsubscribe linux-ia64" in >the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, I tried to use kdump on ia64, and it seemed to work, but I was not able to execute back trace for the panic process using crash tool. I think the reason is that 1st kernel does not save switch stack before 2nd kernel boots. Do you have a plan to improve kdump to save switch stack? Or is there another method to trace panic process? Regards, Takao Indoh _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
