From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752647AbdATOkt (ORCPT ); Fri, 20 Jan 2017 09:40:49 -0500 Received: from terminus.zytor.com ([65.50.211.136]:57804 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752152AbdATOkq (ORCPT ); Fri, 20 Jan 2017 09:40:46 -0500 Date: Fri, 20 Jan 2017 06:40:05 -0800 From: tip-bot for Jiri Slaby Message-ID: Cc: mingo@kernel.org, tglx@linutronix.de, hpa@zytor.com, andy.shevchenko@gmail.com, torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, peterz@infradead.org, jslaby@suse.cz Reply-To: peterz@infradead.org, jslaby@suse.cz, linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, mingo@kernel.org, tglx@linutronix.de, andy.shevchenko@gmail.com, hpa@zytor.com In-Reply-To: <20170119114730.2670-1-jslaby@suse.cz> References: <20170119114730.2670-1-jslaby@suse.cz> To: linux-tip-commits@vger.kernel.org Subject: [tip:timers/core] x86/timer: Make delay() during early bootup Git-Commit-ID: bf3304d996fbb993bad6be09cafde39cc2db72bb X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: bf3304d996fbb993bad6be09cafde39cc2db72bb Gitweb: http://git.kernel.org/tip/bf3304d996fbb993bad6be09cafde39cc2db72bb Author: Jiri Slaby AuthorDate: Thu, 19 Jan 2017 12:47:30 +0100 Committer: Ingo Molnar CommitDate: Fri, 20 Jan 2017 09:45:22 +0100 x86/timer: Make delay() during early bootup When a panic happens during bootup, "Rebooting in X seconds.." is shown, but reboot happens immediatelly. It is because panic() uses mdelay() and mdelay() calls __const_udelay() immediately, which is does not work while booting. The per_cpu cpu_info.loops_per_jiffy is not initialized yet, so __const_udelay() actually multiplies the number of loops by zero. This results in __const_udelay() to delay the execution only by a nanosecond or so. So check whether cpu_info.loops_per_jiffy is zero and use loops_per_jiffy in that case. mdelay() will not be so precise without proper calibration, but it works relatively well. Before: [ 0.170039] delaying 100ms [ 0.170828] done After [ 0.214042] delaying 100ms [ 0.313974] done I do not think the added check matters given we are about to spin the processor in the next few hundred cycles. Signed-off-by: Jiri Slaby Reviewed-by: Andy Shevchenko Acked-by: Thomas Gleixner Cc: Linus Torvalds Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20170119114730.2670-1-jslaby@suse.cz [ Minor edits. ] Signed-off-by: Ingo Molnar --- arch/x86/lib/delay.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/lib/delay.c b/arch/x86/lib/delay.c index 073d1f1..a8e91ae 100644 --- a/arch/x86/lib/delay.c +++ b/arch/x86/lib/delay.c @@ -156,13 +156,13 @@ EXPORT_SYMBOL(__delay); inline void __const_udelay(unsigned long xloops) { + unsigned long lpj = this_cpu_read(cpu_info.loops_per_jiffy) ? : loops_per_jiffy; int d0; xloops *= 4; asm("mull %%edx" :"=d" (xloops), "=&a" (d0) - :"1" (xloops), "0" - (this_cpu_read(cpu_info.loops_per_jiffy) * (HZ/4))); + :"1" (xloops), "0" (lpj * (HZ / 4))); __delay(++xloops); }