Re: [RFC PATCH] Bug during kexec...not all cpus are stopped

[Alok Kataria <akataria@vmware.com>]

On Mon, 2010-10-11 at 14:39 -0700, Vivek Goyal wrote:
> On Mon, Oct 11, 2010 at 12:41:23PM -0700, Alok Kataria wrote:

> > --
> > 
> > x86 smp_ops now has a new op, stop_other_cpus which takes a parameter "wait"
> > this allows the caller to specify if it wants to stop untill all the cpus
> > have processed the stop IPI. This is required specifically for the kexec case
> > where we should wait for all the cpus to be stopped before starting the new
> > kernel.
> 
> > We now wait for the cpus to stop in all cases except for panic/kdump where
> > we expect things to be broken and we are doing our best to make things
> > work anyway.
> 
> I don't think that kdump path uses smp_send_stop().

Right, this should be removed from the patch description.

Belows is the new patch description
----------------------------------------------
x86 smp_ops now has a new op, stop_other_cpus which takes a parameter "wait"
this allows the caller to specify if it wants to stop untill all the cpus
have processed the stop IPI. This is required specifically for the kexec case
where we should wait for all the cpus to be stopped before starting the new
kernel.
We now wait for the cpus to stop in all cases except for panic where
we expect things to be broken and we are doing our best to make things
work anyway.
----------------------------------------------

> 
> IIUC, on x86, we directly send NMI to other cpus.
> 
> native_machine_crash_shutdown()
>   kdump_nmi_shootdown_cpus()
>         nmi_shootdown_cpus()
>            smp_send_nmi_allbutself
>                 apic->send_IPI_allbutself(NMI_VECTOR);
> 
> So above description should be limited to only panic() path.
> 
> On a side note, I am wondering why panic() and kdump path can't share the
> shutdown routine.

The comment in native_stop_other_cpus (native_smp_send_stop earlier)
explains why

        /*
         * Use an own vector here because smp_call_function
         * does lots of things not suitable in a panic situation.
         * On most systems we could also use an NMI here,
         * but there are a few systems around where NMI
         * is problematic so stay with an non NMI for now
         * (this implies we cannot stop CPUs spinning with irq off
         * currently)
         */


Thanks,
Alok
> 
> Vivek