From: Andi Kleen <ak@suse.de>
To: fernando@oss.ntt.co.jp, patches@x86-64.org, linux-kernel@vger.kernel.org
Subject: [PATCH] [7/34] x86_64: safe_apic_wait_icr_idle - x86_64
Date: Mon, 30 Apr 2007 17:49:39 +0200 (CEST) [thread overview]
Message-ID: <20070430154939.26208151FC@wotan.suse.de> (raw)
In-Reply-To: <20070430549.617098000@suse.de>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3598 bytes --]
From: Fernando Luis VazquezCao <fernando@oss.ntt.co.jp>
apic_wait_icr_idle looks like this:
static __inline__ void apic_wait_icr_idle(void)
{
while (apic_read(APIC_ICR) & APIC_ICR_BUSY)
cpu_relax();
}
The busy loop in this function would not be problematic if the
corresponding status bit in the ICR were always updated, but that does
not seem to be the case under certain crash scenarios. Kdump uses an IPI
to stop the other CPUs in the event of a crash, but when any of the
other CPUs are locked-up inside the NMI handler the CPU that sends the
IPI will end up looping forever in the ICR check, effectively
hard-locking the whole system.
Quoting from Intel's "MultiProcessor Specification" (Version 1.4), B-3:
"A local APIC unit indicates successful dispatch of an IPI by
resetting the Delivery Status bit in the Interrupt Command
Register (ICR). The operating system polls the delivery status
bit after sending an INIT or STARTUP IPI until the command has
been dispatched.
A period of 20 microseconds should be sufficient for IPI dispatch
to complete under normal operating conditions. If the IPI is not
successfully dispatched, the operating system can abort the
command. Alternatively, the operating system can retry the IPI by
writing the lower 32-bit double word of the ICR. This “time-out”
mechanism can be implemented through an external interrupt, if
interrupts are enabled on the processor, or through execution of
an instruction or time-stamp counter spin loop."
Intel's documentation suggests the implementation of a time-out
mechanism, which, by the way, is already being open-coded in some parts
of the kernel that tinker with ICR.
Create a apic_wait_icr_idle replacement that implements the time-out
mechanism and that can be used to solve the aforementioned problem.
AK: moved both functions out of line
AK: Added improved loop from Keith Owens
Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: Andi Kleen <ak@suse.de>
---
---
arch/x86_64/kernel/apic.c | 22 ++++++++++++++++++++++
include/asm-x86_64/apic.h | 8 +++-----
2 files changed, 25 insertions(+), 5 deletions(-)
Index: linux/include/asm-x86_64/apic.h
===================================================================
--- linux.orig/include/asm-x86_64/apic.h
+++ linux/include/asm-x86_64/apic.h
@@ -2,6 +2,7 @@
#define __ASM_APIC_H
#include <linux/pm.h>
+#include <linux/delay.h>
#include <asm/fixmap.h>
#include <asm/apicdef.h>
#include <asm/system.h>
@@ -47,11 +48,8 @@ static __inline unsigned int apic_read(u
return *((volatile unsigned int *)(APIC_BASE+reg));
}
-static __inline__ void apic_wait_icr_idle(void)
-{
- while (apic_read( APIC_ICR ) & APIC_ICR_BUSY)
- cpu_relax();
-}
+extern void apic_wait_icr_idle(void);
+extern unsigned int safe_apic_wait_icr_idle(void);
static inline void ack_APIC_irq(void)
{
Index: linux/arch/x86_64/kernel/apic.c
===================================================================
--- linux.orig/arch/x86_64/kernel/apic.c
+++ linux/arch/x86_64/kernel/apic.c
@@ -68,6 +68,28 @@ int using_apic_timer __read_mostly = 0;
static void apic_pm_activate(void);
+void apic_wait_icr_idle(void)
+{
+ while (apic_read(APIC_ICR) & APIC_ICR_BUSY)
+ cpu_relax();
+}
+
+unsigned int safe_apic_wait_icr_idle(void)
+{
+ unsigned int send_status;
+ int timeout;
+
+ timeout = 0;
+ do {
+ send_status = apic_read(APIC_ICR) & APIC_ICR_BUSY;
+ if (!send_status)
+ break;
+ udelay(100);
+ } while (timeout++ < 1000);
+
+ return send_status;
+}
+
void enable_NMI_through_LVT0 (void * dummy)
{
unsigned int v;
next prev parent reply other threads:[~2007-04-30 15:56 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-30 15:49 [PATCH] [0/34] x86 candidate patches for review VI: MTRR, APIC, more paravirt, misc Andi Kleen
2007-04-30 15:49 ` [PATCH] [1/34] x86_64: Move mtrr prototypes from proto.h to mtrr.h Andi Kleen
2007-04-30 15:49 ` [PATCH] [2/34] x86: Adds mtrr_save_fixed_ranges() for use in two later patches Andi Kleen
2007-04-30 15:49 ` [PATCH] [3/34] x86: Save the MTRRs of the BSP before booting an AP Andi Kleen
2007-04-30 15:49 ` [PATCH] [4/34] x86: Save and restore the fixed-range MTRRs of the BSP when suspending Andi Kleen
2007-04-30 15:49 ` [PATCH] [5/34] i386: Enable support for fixed-range IORRs to keep RdMem & WrMem in sync Andi Kleen
2007-04-30 15:49 ` [PATCH] [6/34] i386: safe_apic_wait_icr_idle - i386 Andi Kleen
2007-04-30 15:49 ` Andi Kleen [this message]
2007-04-30 15:49 ` [PATCH] [8/34] i386: use " Andi Kleen
2007-04-30 15:49 ` [PATCH] [9/34] x86_64: use safe_apic_wait_icr_idle in smpboot.c - x86_64 Andi Kleen
2007-04-30 15:49 ` [PATCH] [10/34] i386: use safe_apic_wait_icr_idle in smpboot.c Andi Kleen
2007-04-30 15:49 ` [PATCH] [11/34] x86_64: use safe_apic_wait_icr_idle in smpboot.c - x86_64 Andi Kleen
2007-04-30 15:49 ` [PATCH] [12/34] i386: __send_IPI_dest_field - i386 Andi Kleen
2007-04-30 15:49 ` [PATCH] [13/34] x86_64: __send_IPI_dest_field - x86_64 Andi Kleen
2007-04-30 15:49 ` [PATCH] [14/34] i386: Use safe_apic_wait_icr_idle in safe_apic_wait_icr_idle - i386 Andi Kleen
2007-04-30 15:49 ` [PATCH] [15/34] x86_64: Use safe_apic_wait_icr_idle in __send_IPI_dest_field - x86_64 Andi Kleen
2007-04-30 15:49 ` [PATCH] [16/34] i386: fix mtrr sections Andi Kleen
2007-05-02 17:08 ` Bernhard Kaindl
2007-05-03 11:16 ` Bernhard Kaindl
2007-05-03 11:19 ` Andi Kleen
2007-05-03 15:12 ` Randy Dunlap
2007-04-30 15:49 ` [PATCH] [17/34] x86: PARAVIRT: Add a sched_clock paravirt_op Andi Kleen
2007-04-30 15:49 ` [PATCH] [18/34] i386: PARAVIRT: fix startup_ipi_hook config dependency Andi Kleen
2007-04-30 15:49 ` [PATCH] [19/34] x86_64: move __vgetcpu_mode & __jiffies to the vsyscall_2 zone Andi Kleen
2007-04-30 15:49 ` [PATCH] [20/34] i386: avoid checking for cpu gone when CONFIG_HOTPLUG_CPU not defined Andi Kleen
2007-04-30 15:49 ` [PATCH] [21/34] i386: replace spin_lock_irqsave with spin_lock Andi Kleen
2007-04-30 15:49 ` [PATCH] [22/34] i386: clean up flush_tlb_others fn Andi Kleen
2007-04-30 15:49 ` [PATCH] [23/34] i386: check capability Andi Kleen
2007-04-30 15:49 ` [PATCH] [24/34] x86_64: Auto compute __NR_syscall_max at compile time Andi Kleen
2007-04-30 15:49 ` [PATCH] [25/34] x86_64: skip cache_free_alien() on non NUMA Andi Kleen
2007-04-30 15:49 ` [PATCH] [26/34] i386: remove xtime_lock'ing around cpufreq notifier Andi Kleen
2007-04-30 15:50 ` [PATCH] [27/34] i386: pte clear optimization Andi Kleen
2007-04-30 15:50 ` [PATCH] [28/34] i386: pte xchg optimization Andi Kleen
2007-05-02 10:52 ` [patches] " Jan Beulich
2007-05-02 11:05 ` Andi Kleen
2007-05-02 19:19 ` Zachary Amsden
2007-04-30 15:50 ` [PATCH] [29/34] i386: pte simplify ops Andi Kleen
2007-04-30 15:50 ` [PATCH] [30/34] i386: convert the monitor thread to use the kthread API Andi Kleen
2007-04-30 16:55 ` James Bottomley
2007-04-30 17:56 ` Andi Kleen
2007-04-30 15:50 ` [PATCH] [31/34] i386: convert to " Andi Kleen
2007-04-30 15:50 ` [PATCH] [32/34] x86_64: unexport cpu_llc_id Andi Kleen
2007-04-30 15:50 ` [PATCH] [34/34] x86_64: ignore vgacon if hardware not present Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070430154939.26208151FC@wotan.suse.de \
--to=ak@suse.de \
--cc=fernando@oss.ntt.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@x86-64.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®