On Tue, 7 Aug 2007, Vivek Goyal wrote:
> On Mon, Aug 06, 2007 at 05:08:05PM +0200, Martin Wilck wrote:
>
> > 1. If, under SMP, the IO-APIC logical destination field is
> > set by the IRQ balancing code to one of the "other"
> > CPUs (i.e. not the crashing_cpu), and an IRQ arrives
> > on the respective pin after that CPU has shut down
> > its local APIC (but before the IO-APIC pin is masked)
> > the IRQ message can't be delivered.
>
> Point 1 and Point 2 seems to be same.
>
> >
> > 2. The crashing CPU itself disables its local APIC
> > before the IO-APIC, leaving a short time window
> > where the IOAPIC can receive IRQs, but not
> > deliver them.
> >
>
> I doubut that it would be the issue. Looking at intel IOAPIC (82093AA)
> documentation, it says that IRR bit of IOAPIC will be set only if
> destination CPU has accepted the interrupt.
I think you mean "destination Local APIC has accepted the interrupt"
above. The Intel documentation cited above contains this text on page
12:
For level triggered interrupts, this bit is set to 1 when local
APIC(s) accept the level interrupt sent by the IOAPIC. The Remote
IRR bit is set to 0 when an EOI message with a matching interrupt
vector is received from a local APIC.
The following text is from the IA-64 documentation ...
Any interrupt that is received by the processor is kept pending
and recorded in the Interrupt Request Register (IRR). If the
processor is not servicing an interrupt, then the contents of the
TPR determines whether the processor will accept a pending
interrupt depending on the priority of the interrupt compared to
the current TPR. If the interrupt has a higher priority, then the
processor is interrupted, otherwise the interrupt is kept pending.
So, I think if the CPU has interrupts disabled, but the Local APIC
does not, the IRR could get set. I guess we need to be sure to turn
off the Local APIC first before disabling interrupts in the CPU.
Chip
--
Charles M. "Chip" Coldwell
Senior Software Engineer
Red Hat, Inc
978-392-2426
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
