[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAE9FiQUW5tf5-Fbn0a_8s58P+7rXbG6iWPaDeHOuhxw4TZE+hQ@mail.gmail.com>
Date: Wed, 21 Dec 2011 10:24:53 -0800
From: Yinghai Lu <yinghai@...nel.org>
To: Don Zickus <dzickus@...hat.com>
Cc: mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org,
andi@...stfloor.org, torvalds@...ux-foundation.org,
peterz@...radead.org, robert.richter@....com, tglx@...utronix.de,
mingo@...e.hu, linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/debug] x86, reboot: Use NMI instead of REBOOT_VECTOR to
stop cpus
On Wed, Dec 21, 2011 at 6:59 AM, Don Zickus <dzickus@...hat.com> wrote:
> On Tue, Dec 20, 2011 at 02:38:39PM -0800, Yinghai Lu wrote:
>> > @@ -230,7 +285,7 @@ struct smp_ops smp_ops = {
>> > .smp_prepare_cpus = native_smp_prepare_cpus,
>> > .smp_cpus_done = native_smp_cpus_done,
>> >
>> > - .stop_other_cpus = native_stop_other_cpus,
>> > + .stop_other_cpus = native_nmi_stop_other_cpus,
>> > .smp_send_reschedule = native_smp_send_reschedule,
>> >
>> > .cpu_up = native_cpu_up,
>>
>> this broke kexec on our intel nehalem, westmere and sandbridge platforms.
>> system get reset while try to kexec second kernel.
>
>
> Hmm. Ok. Does the reboot path work correctly?
Yes.
> Vivek showed me that the
> kexec and reboot paths do the same shutdowns. Perhaps the second kernel
> has trouble dealing with cpus spinning in an NMI context and can't
> properly reset them.
not sure.
when use nonmi_ipi in first kernel, it will work well.
Thanks
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists