Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Subject: RE: [patch 1/1] Do not enforce unique IO_APIC_ID for Xeon processors in EM64T mode (x86_64)
Date: Sun, 8 May 2005 12:28:26 -0500
Message-ID: <19D0D50E9B1D0A40A9F0323DBFA04ACCE04B51@USRV-EXCH4.na.uis.unisys.com>
Thread-Topic: [patch 1/1] Do not enforce unique IO_APIC_ID for Xeon processors in EM64T mode (x86_64)
Thread-Index: AcVT1MfIJXn4FaURSrazSygboeoqzQAHfvOA
From: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
To: "Andi Kleen" <ak@suse.de>
Cc: <akpm@osdl.org>, <zwane@arm.linux.org.uk>, <len.brown@intel.com>,
       <venkatesh.pallipadi@intel.com>, <linux-kernel@vger.kernel.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1398
Lines: 41


> > Sure, I will remove the io_apic_get_unique_id() then. 
> Perhaps, it will 
> > be easy to put it back in if someone implements a chipset 
> that needs it.
> 
> I did it myself now.
>

Ok, great, I was about to put it together, but you beat me to it :) You
probably don't need the "#define IO_APIC_MAX_ID		0xFE: line
anymore?
 
> > 
> > Andi, I submitted the patch for i386 a little while ago 
> > 
> http://www.ussg.iu.edu/hypermail/linux/kernel/0505.0/0195.html
>  (I sent 
> > it to you also, but just noticed that it was not your usual email 
> > address - where did I get if from? have no idea...) Genapic in i386 
> > has a NO_IOAPIC_CHECK flag that is defined in every 
> subarch, so it was 
> > easy to fix the problem by making use of it in ACPI boot 
> path just as 
> > it was used in MP path.
> 
> That will not help on the other systems who don't have an own 
> subarchitecture but still run into problems with the check. 
> 
> I think the right strategy for i386 would be to remove this 
> check thing from the subarchitecture and implement the 
> heuristic described in the last mail.
> 
OK, I will do it next then. 
Thanks,
--Natalie
-
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/