[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131106094848.GB2425@dhcp-16-105.nay.redhat.com>
Date: Wed, 6 Nov 2013 17:48:48 +0800
From: Baoquan He <bhe@...hat.com>
To: Vivek Goyal <vgoyal@...hat.com>
Cc: mwhitehe@...hat.com, x86@...nel.org, kexec@...ts.infradead.org,
linux-kernel@...r.kernel.org, davej@...oraproject.org,
mingo@...hat.com, holt@....com, hpa@...or.com,
rmk+kernel@....linux.org.uk, tglx@...utronix.de,
akpm@...ux-foundation.org, chaowang@...hat.com
Subject: Re: [PATCH] x86: make reboot task only run on the appropriate
processor
On 11/05/13 at 03:28pm, Vivek Goyal wrote:
> On Tue, Nov 05, 2013 at 05:16:07PM +0800, Baoquan He wrote:
> > Currently system always reboot after below message when execute "kexec -e".
> >
> > [ 0.572119] smpboot: Booting Node 0, Processors # 1 OK
> >
>
> So is it same problem were we reboot on non-boot cpu and sending INIT
> to boot cpu in second kernel brings down the machine?
They are different. Kdump hang when crash didn't happen on bsp, then
multiple CPUs are brought up, the bsp will go through the boot strap
code after INIT IPI message received. However in this case, executing
"kexec -e" will make system reboot and bring up only 1 CPU, then go back
to BIOS and reboot.
In kdump, nmi is sent to shutdown other CPUs. In this shutdown, cleanup
is done and finally processor is halt. And if crash didn't happen on
bsp, during system startup INIT sent to bsp will cause system hang.
However, in kexec reboot, a REBOOT_VECTOR interrupt is sent to all other
CPUs. In commit 4ef702c10b5df18ab04921fc252c26421d4d6c75, Andi imported
this IPI interrupt vector. Andi said it has been given the highest
priority.
It's still not very clear why this happened without that code block.
Seems interrupt disable is very doubtful.
>
> I think for x86, it makes sense to reboot on boot cpu.
>
> Thanks
> Vivek
>
> _______________________________________________
> kexec mailing list
> kexec@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
--
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