diff options
| author | Vivek Goyal <vgoyal@in.ibm.com> | 2006-03-31 02:30:05 -0800 |
|---|---|---|
| committer | Linus Torvalds <torvalds@g5.osdl.org> | 2006-03-31 12:18:50 -0800 |
| commit | 1a75a3f0680d9c4bc4761512658b6fd664032e18 (patch) | |
| tree | 8d3d7fe266740f58961b43ecf144503f36e88dc4 | |
| parent | 3ccfb81e871b45e4af6ebb3282f3cfa0f98f1b80 (diff) | |
| download | linux-3.10-1a75a3f0680d9c4bc4761512658b6fd664032e18.tar.gz linux-3.10-1a75a3f0680d9c4bc4761512658b6fd664032e18.tar.bz2 linux-3.10-1a75a3f0680d9c4bc4761512658b6fd664032e18.zip | |
[PATCH] i386 kdump timer vector lockup fix
Porting the patch I posted for x86_64 to i386.
http://marc.theaimsgroup.com/?l=linux-kernel&m=114178139610707&w=2
o While using kdump, after a system crash when second kernel boots, timer
vector gets (0x31) locked and CPU does not see timer interrupts
travelling from IOAPIC to APIC. Currently it does not lead to boot
failure in second kernel as timer interrupts continues to come as ExtInt
through LAPIC directly, but fixing it is good in case some boards do not
support the other mode.
o After a system crash, it is not safe to service interrupts any more,
hence interrupts are disabled. This leads to pending interrupts at
LAPIC. LAPIC sends these interrupts to the CPU during early boot of
second kernel. Other pending interrupts are discarded saying unexpected
trap but timer interrupt is serviced and CPU does not issue an LAPIC EOI
because it think this interrupt came from i8259 and sends ack to 8259.
This leads to vector 0x31 locking as LAPIC does not clear respective ISR
and keeps on waiting for EOI.
o This patch issues extra EOI for the pending interrupts who have ISR set.
o Though today only timer seems to be the special case because in early
boot it thinks interrupts are coming from i8259 and uses
mask_and_ack_8259A() as ack handler and does not issue LAPIC EOI. But
probably doing it in generic manner for all vectors makes sense.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Andi Kleen <ak@muc.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
| -rw-r--r-- | arch/i386/kernel/apic.c | 20 | ||||
| -rw-r--r-- | include/asm-i386/apicdef.h | 1 |
2 files changed, 21 insertions, 0 deletions
diff --git a/arch/i386/kernel/apic.c b/arch/i386/kernel/apic.c index eb5279d23b7..3fff3c62d57 100644 --- a/arch/i386/kernel/apic.c +++ b/arch/i386/kernel/apic.c @@ -415,6 +415,7 @@ void __init init_bsp_APIC(void) void __devinit setup_local_APIC(void) { unsigned long oldvalue, value, ver, maxlvt; + int i, j; /* Pound the ESR really hard over the head with a big hammer - mbligh */ if (esr_disable) { @@ -452,6 +453,25 @@ void __devinit setup_local_APIC(void) apic_write_around(APIC_TASKPRI, value); /* + * After a crash, we no longer service the interrupts and a pending + * interrupt from previous kernel might still have ISR bit set. + * + * Most probably by now CPU has serviced that pending interrupt and + * it might not have done the ack_APIC_irq() because it thought, + * interrupt came from i8259 as ExtInt. LAPIC did not get EOI so it + * does not clear the ISR bit and cpu thinks it has already serivced + * the interrupt. Hence a vector might get locked. It was noticed + * for timer irq (vector 0x31). Issue an extra EOI to clear ISR. + */ + for (i = APIC_ISR_NR - 1; i >= 0; i--) { + value = apic_read(APIC_ISR + i*0x10); + for (j = 31; j >= 0; j--) { + if (value & (1<<j)) + ack_APIC_irq(); + } + } + + /* * Now that we are all set up, enable the APIC */ value = apic_read(APIC_SPIV); diff --git a/include/asm-i386/apicdef.h b/include/asm-i386/apicdef.h index 03185cef8e0..5e4a35af292 100644 --- a/include/asm-i386/apicdef.h +++ b/include/asm-i386/apicdef.h @@ -37,6 +37,7 @@ #define APIC_SPIV_FOCUS_DISABLED (1<<9) #define APIC_SPIV_APIC_ENABLED (1<<8) #define APIC_ISR 0x100 +#define APIC_ISR_NR 0x8 /* Number of 32 bit ISR registers. */ #define APIC_TMR 0x180 #define APIC_IRR 0x200 #define APIC_ESR 0x280 |