> -----Original Message----- > From: Jack Steiner [mailto:steiner@xxxxxxx] > Sent: 2006年10月7日 10:17 > To: Matthew Wilcox > Cc: Zou, Nanhai; Jay Lan; Luck, Tony; Linux-IA64; fastboot; Eric W. Biederman > Subject: Re: Sending cpu 0 back to SAL slave loop > > 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. > This can be done. Sent an IPI and wait CPU0 to kexec, if CPU0 not response for a certain period of time. Send an OS_INIT to force kexec on CPU0. However I wonder should we implement it with a kernel-parameter, or make it default behavior? > 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??? > Not sure, I can have a try on Tiger, but I guess it depends on the how SAL is implementing rendez on each platform. > > 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. > For none crashdumping kexec, I have sched_setaffinity code in kexec-tools->arch_process_options, so kexec -e will only run on CPU 0. Thanks Zou Nan hai - 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
|