From mboxrd@z Thu Jan 1 00:00:00 1970 From: linux@arm.linux.org.uk (Russell King - ARM Linux) Date: Mon, 15 Nov 2010 15:25:34 +0000 Subject: [PATCH] ARM: Temporary fix for broken arch reboot In-Reply-To: References: <20101109131838.GF2869@n2100.arm.linux.org.uk> <1289320692.11461.21.camel@e102109-lin.cambridge.arm.com> <20101110100617.GA23244@n2100.arm.linux.org.uk> <1289397874.4513.54.camel@e102109-lin.cambridge.arm.com> <20101110154604.GA27571@n2100.arm.linux.org.uk> Message-ID: <20101115152534.GE24194@n2100.arm.linux.org.uk> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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.