[PATCH] ARM: Temporary fix for broken arch reboot

Russell King - ARM Linux linux at arm.linux.org.uk
Mon Nov 15 10:25:34 EST 2010


On Fri, Nov 12, 2010 at 04:01:25PM +0530, Shilimkar, Santosh wrote:
> > -----Original Message-----
> > From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> > Sent: Wednesday, November 10, 2010 9:16 PM
> > To: Shilimkar, Santosh
> > Cc: Catalin Marinas; linux-arm-kernel at lists.infradead.org; Gadiyar, Anand
> > Subject: Re: [PATCH] ARM: Temporary fix for broken arch reboot
> > 
> > On Wed, Nov 10, 2010 at 09:13:21PM +0530, Shilimkar, Santosh wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Catalin Marinas [mailto:catalin.marinas at arm.com]
> > > > Sent: Wednesday, November 10, 2010 7:35 PM
> > > > To: Russell King - ARM Linux
> > > > Cc: Shilimkar, Santosh; linux-arm-kernel at lists.infradead.org; Gadiyar,
> > > > Anand
> > > > Subject: Re: [PATCH] ARM: Temporary fix for broken arch reboot
> > > >
> > > > The printing only happens for SYSTEM_BOOTING or SYSTEM_RUNNING. I
> > > > suspect in this case we have SYSTEM_RESTARTING and the condition in
> > > > ipi_cpu_stop() is false, therefore no printing. It may be worth
> > putting
> > > > some printks outside the 'if' to see whether the secondary CPUs get
> > > > there.
> > > >
> > > While doing some experiments on this issue, one interesting
> > > observation I made. Looks like there is race between two
> > > Cores which makes system behave badly in reboot path.
> > >
> > > Just adding a delay in the ipi_cpu_stop() makes the reboot work
> > > as well
> > 
> > That could just be that it's taking longer than 500us for the reboot CPU
> > to get through setup_mm_for_reboot().
> 
> It not seems to be the case otherwise below patch should have worked.
> Right ? Did I miss your point ?

Yes you did.  Maybe all this code completes before your 500us in the
secondary CPUs complete.  So the delay in the secondary CPU path proves
nothing.

A delay in the reboot CPU path ensures that the other CPUs have time to
react to the stop IPI, so we know what state the system is in.



More information about the linux-arm-kernel mailing list