Age | Commit message (Collapse) | Author |
|
When we bring up a new CPU via INIT/startup IPI messages, the CPU that's
coming up sends a xTPR message to the chipset. Intel chipsets (at least)
don't provide any architectural guarantee on what the chipset will do with
this message. For example, the E850x chipsets uses this xTPR message to
interpret the interrupt operating mode of the platform. When the CPU
coming online sends this message, it always indicates that it is in logical
flat mode. For the CPU hotplug case, the platform may already be
functioning in cluster APIC mode at this time, the chipset can get confused
and mishandle I/O device and IPI interrupt routing.
The situation eventually gets corrected when the new CPU sends another xTPR
update when we switch it to cluster mode, but there's a window during which
the chipset may be in an inconsistent state. This patch avoids this
problem by using the flat physical interrupt delivery mode instead of
cluster mode for bigsmp (>8 cpu) support.
Signed-off-by: Ashok Raj <ashok.raj@intel.com>
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Cc: Andi Kleen <ak@muc.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
This patch is per Andi's request to remove NO_IOAPIC_CHECK from genapic and
use heuristics to prevent unique I/O APIC ID check for systems that don't
need it. The patch disables unique I/O APIC ID check for Xeon-based and
other platforms that don't use serial APIC bus for interrupt delivery.
Andi stated that AMD systems don't need unique IO_APIC_IDs either.
Signed-off-by: Natalie Protasevich <Natalie.Protasevich@unisys.com>
Cc: Andi Kleen <ak@muc.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
|