On Fri, Oct 06, 2006 at 02:44:43PM -0600, Matthew Wilcox wrote: > On Fri, Oct 06, 2006 at 03:39:10PM -0500, Jack Steiner wrote: > > For kexec, it is ESSENTIAL that all cpus except for the one doing > > the kexec be returned to the SAL slave loop. If this is not done, our > > chipset will misdirect IO interrupts on the newly exec'ed kernel. > > Could you do an IPI call to have CPU 0 do the kexec and have the CPU > that sent the IPI fall into the SAL slave loop instead? Yes, that seems ok, too. One endcase that must be covered is the case where where 1) cpu >0 panics and, 2) cpu 0 is looping with interrupts disabled - perhaps waiting on a lock held by the panic'ing cpu. In this case, the panic'ing cpu must send an NMI interrupt to cpu 0 to cause it to do the kexec. Not sure but I think this can be made to work. Hmmmmm. Another case that is more difficult to handle is a failure where an MCA has occurred & cpu 0 is in the SAL rendez slave loop. Kexec will have to bring cpu out of the rendez slave loop & cause it to kexec the new kernel. Is this possible??? I like the NMI approach for the general case where you are kexec'ing a new kernel - not a crashdump kernel. We have some dependencies on the boot cpu not changing. -- jack - To unsubscribe from this list: 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
|