From: Natalie.Protasevich@unisys.com
To: akpm@osdl.org
Cc: ak@suse.de, zwane@arm.linux.org.uk, len.brown@intel.com,
venkatesh.pallipadi@intel.com, linux-kernel@vger.kernel.org,
Natalie.Protasevich@unisys.com
Subject: [patch 1/1] Do not enforce unique IO_APIC_ID for Xeon processors in EM64T mode (x86_64)
Date: Fri, 06 May 2005 22:34:34 -0700 [thread overview]
Message-ID: <20050507053435.6DA214749E@linux.site> (raw)
I revised the patch and it came out simpler (and much smaller) this time :) Please consider the following version:
<-Snip->
This patch disables unique IO_APIC_ID check for xAPIC systems running in EM64T mode. Xeon-based ES7000s panic failing this unnecessary check. IO_APIC_IDs only need to be unique in case of serial APIC bus. xAPIC systems deliver interrupts over the system bus.
Signed-off by: Natalie Protasevich <Natalie.Protasevich@unisys.com>
---
diff -puN arch/x86_64/kernel/io_apic.c~no-ioapic-check-x86_64-2 arch/x86_64/kernel/io_apic.c
--- linux-2.6.13-rc3-mm3/arch/x86_64/kernel/io_apic.c~no-ioapic-check-x86_64-2 2005-05-06 21:58:55.149700760 -0700
+++ linux-2.6.13-rc3-mm3-root/arch/x86_64/kernel/io_apic.c 2005-05-06 22:00:41.361554104 -0700
@@ -1867,12 +1867,16 @@ int __init io_apic_get_unique_id (int io
int i = 0;
/*
+ * xAPIC systems take advantage of APIC system bus architecture.
+ */
+
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)
+ return apic_id;
+
+ /*
* The P4 platform supports up to 256 APIC IDs on two separate APIC
* buses (one for LAPICs, one for IOAPICs), where predecessors only
* supports up to 16 on one shared APIC bus.
- *
- * TBD: Expand LAPIC/IOAPIC support on P4-class systems to take full
- * advantage of new APIC bus architecture.
*/
if (physids_empty(apic_id_map))
_
next reply other threads:[~2005-05-08 0:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-07 5:34 Natalie.Protasevich [this message]
2005-05-08 1:00 ` [patch 1/1] Do not enforce unique IO_APIC_ID for Xeon processors in EM64T mode (x86_64) Zwane Mwaikambo
-- strict thread matches above, loose matches on Subject: below --
2005-05-12 2:22 Protasevich, Natalie
2005-05-11 16:21 Protasevich, Natalie
2005-05-11 19:22 ` Andi Kleen
2005-05-11 7:10 Protasevich, Natalie
2005-05-11 11:22 ` Andi Kleen
2005-05-08 17:28 Protasevich, Natalie
2005-05-08 23:53 ` Andi Kleen
2005-05-08 5:01 Protasevich, Natalie
2005-05-08 13:49 ` Andi Kleen
2005-05-09 19:15 ` James Cleverdon
2005-05-05 22:11 Natalie.Protasevich
2005-05-06 17:34 ` Len Brown
2005-05-06 17:57 ` Zwane Mwaikambo
2005-05-07 13:41 ` 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=20050507053435.6DA214749E@linux.site \
--to=natalie.protasevich@unisys.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=venkatesh.pallipadi@intel.com \
--cc=zwane@arm.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.