Hi, I applied the patch to 2.6.18-rc2. However, compilation failed at machine_shutdown() of arch/ia64/kernel/machine_kexec.c on an sn2 machine. It was easy to figure out irq_descp() is gone and idesc->handle is replaced with idesc->chip. But this code in machine_shutdown() caused an error: ... if (cpu != smp_processor_id()) cpu_down(cpu); } } #elif defined(CONFIG_SMP) smp_call_function(kexec_stop_this_cpu, (void *)image->start, 0, 0); <=== #endif 'image' is undefined in the code. Was it a global? Where was it declared? Thanks, - jay Zou, Nanhai wrote: >>-----Original Message----- >>From: Horms [mailto:horms@xxxxxxxxxxxx] >>Sent: 2006年6月26日 15:47 >>To: Zou, Nanhai >>Cc: Linux-IA64; khalid_aziz@xxxxxx; fastboot@xxxxxxxxxxxxxx >>Subject: Re: [Fastboot] Ia64 kdump patch >> >>On Fri, Jun 09, 2006 at 06:47:59AM +0800, Zou Nan hai wrote: >> >>>On Thu, 2006-06-08 at 16:35, Horms wrote: >>> >>>>On Thu, Jun 08, 2006 at 06:48:23AM +0800, Zou Nan hai wrote: >>>> >>>>>The ia64 kdump patch is in 2 parts. >>>>> >>>>>the kexec-kdump-ia64-2.6.16.patch should apply on top of the previous >>>>>kexec patch by Khalid in Tony's test tree. >>>>> >>>>>the kexec-tools-kdump-ia64.patch should apply to kexec-tools-1.101 >>>>>with kexec-tools-1.101-kdump.patch >>>>> >>>>> >>>>>To test it. >>>>>Build first SMP kernel with KEXEC and KDUMP enabled. >>>>> >>>>>Boot it with kernel parameter "crashkernel=XXX@YYY" >>>>>means reserver XXX from YYY for crashdumping. >>>>>Build an UP kernel with KEXEC KDUMP VMCORE enabled. >>>>>load this kernel as a crashdumping kernel >>>>>kexec -p vmlinux.gz --initrd=initrd --append="...." >>>>> >>>>>trigger a crash, >>>>>maybe "echo c > /proc/sysrq-trigger" >>>>>after the crash kernel boots, >>>>>cp /proc/vmcore core >>>>> >>>>>gdb first_kernel_vmlinux core >>>>> >>>>>please test and review. >>>>> >>>>>Signed-off-by: Khalid Aziz <khalid_aziz@xxxxxx> >>>>>Signed-off-by: Zou Nan hai <nanhai.zou@xxxxxxxxx> >>>>> >>>>Hi, >>>> >>>>I'm very excited to be able to play with the new version of this patch, >>>>but the version you posted seems to included include all the kexec patch >>>>that went into Tony Luck's tree. Here is a rediff relative to the >>>>existing kexec patch (no other changes). >>>> >>>>The code does seem to be working for me. The main difficulty so far >>>>seems to have been finding an appropriate place and size and place for >>>>the reserved area. 128M@256M seems to work for me, offering enough >>>>memory and not lie on a resource boundry for me. >>>> >>>>Lastly, is it possible for you to comment on what areas of concern >>>>you have with regards to kdump/kexec on ia64. I am looking to port this >>>>code to xen, as my colleague Magnus Damm and I have already done so for >>>> >>i386 >> >>>>(complete) and x86_64 (almost complete). >>>> >>>> >>>> >>http://lists.xensource.com/archives/html/xen-devel/2006-05/msg01272.html >> >>>>Signed-Off-By: Horms <horms@xxxxxxxxxxxx> >>>> >>>> >>> 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 for that list, it is very useful to me. I hope that I can >>find some time to help with some of those problems. >> >>One thing that I am puzzling over is why you shutdown the PCI devices >>as part of machine_crash_shutdown(). As I am trying to port your code >>to xen this is quite a problem for me, as I'm not sure that Xen >>actually knows enough about PCI to do this. Its it a problem relating >>to bringing the devices back online after a reboot? Is it the MPT fusion >>problem you mention above? >> >> > The list is a bit wrong.., I notice that we don't need to dump unwind segment to core file for stack unwind to work... I am working on full register dumping and fixing the stack unwind issue. > > The PCI device shutdown code was to un-master all the PCI devices so that no DMA transaction will be issued by Device. However I think maybe we can remove this code because the new kernel memory space is invisible to first kernel. > >There is another problem that I call irq->end for each devices, it is not safe to touch any pointer belong to previous kernel at the crash time. >But without this code, MPT fusion driver is very likely unable to restart. It sometimes failed to restart even with the irq->end code. This is an open issue need to be fixed. > >Thanks >Zou Nan hai > > >>Horms >>H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ >> >- >: send the line "unsubscribe linux-ia64" in >the body of a message to majordomo@xxxxxxxxxxxxxxx >More majordomo info at http://vger.kernel.org/majordomo-info.html > - : send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|