Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Subject: RE: APIC error on CPUx
Date: Mon, 22 May 2006 10:47:30 -0400
Message-ID: <CFF307C98FEABE47A452B27C06B85BB681D44D@hdsmsx411.amr.corp.intel.com>
Thread-Topic: APIC error on CPUx
Thread-Index: AcZ9m7/Mqny9BjTBSKWKm33xsIge/QAEik+g
From: "Brown, Len" <len.brown@intel.com>
To: "Jan Engelhardt" <jengelh@linux01.gwdg.de>,
       "Vladimir Dvorak" <dvorakv@vdsoft.org>
Cc: "Andi Kleen" <ak@suse.de>, <linux-kernel@vger.kernel.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 887
Lines: 25

 
>The problem goes away with noapic or acpi=off, but of course that also 
>means you don't have IRQs > 15.

"acpi=off" is a superset of "noapic" here, presumably because the
board doesn't have MPS  tables that describe the IOAPIC when ACPI is
off.

"noapic" is a perfectly reasonable thing to use if you don't
have a lot of interrupt sources and there is no more sharing
in PIC mode than IOAPIC mode.

The advantage of using IOAPIC mode is that the system has more interrupt
pins
availalble and this allows sharing to be avoided.  It also allows
the system to target the interrupts to any processor when you
have more than one.

cheers,
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/