[PATCH] APIC physical broadcast for i82489DX

[PATCH] APIC physical broadcast for i82489DX

[Maciej W. Rozycki]

Ingo,

 The physical broadcast ID is determined incorrectly for the i82489DX,
which uses 8-bit physical addressing (32-bit logical).  Please apply the
following patch.

  Maciej

Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>

patch-mips-2.6.9-rc2-20040920-apic-broadcast-0
diff -up --recursive --new-file linux-mips-2.6.9-rc2-20040920.macro/arch/i386/kernel/apic.c linux-mips-2.6.9-rc2-20040920/arch/i386/kernel/apic.c
--- linux-mips-2.6.9-rc2-20040920.macro/arch/i386/kernel/apic.c	2004-09-20 03:57:43.000000000 +0000
+++ linux-mips-2.6.9-rc2-20040920/arch/i386/kernel/apic.c	2004-10-07 01:10:37.000000000 +0000
@@ -91,7 +91,7 @@ int get_physical_broadcast(void)
 	unsigned int lvr, version;
 	lvr = apic_read(APIC_LVR);
 	version = GET_APIC_VERSION(lvr);
-	if (version >= 0x14)
+	if (!APIC_INTEGRATED(version) || version >= 0x14)
 		return 0xff;
 	else
 		return 0xf;

Re: [PATCH] APIC physical broadcast for i82489DX

[William Lee Irwin III]

On Thu, Oct 07, 2004 at 03:24:23PM +0000, Linux Kernel Mailing List wrote:
> ChangeSet 1.2133, 2004/10/07 08:24:23-07:00, macro@linux-mips.org
> 	[PATCH] APIC physical broadcast for i82489DX
> 	The physical broadcast ID is determined incorrectly for the i82489DX,
> 	which uses 8-bit physical addressing (32-bit logical).
>  apic.c |    2 +-
>  1 files changed, 1 insertion(+), 1 deletion(-)
> diff -Nru a/arch/i386/kernel/apic.c b/arch/i386/kernel/apic.c
> --- a/arch/i386/kernel/apic.c	2004-10-07 09:10:03 -07:00
> +++ b/arch/i386/kernel/apic.c	2004-10-07 09:10:03 -07:00
> @@ -91,7 +91,7 @@
>  	unsigned int lvr, version;
>  	lvr = apic_read(APIC_LVR);
>  	version = GET_APIC_VERSION(lvr);
> -	if (version >= 0x14)
> +	if (!APIC_INTEGRATED(version) || version >= 0x14)
>  		return 0xff;
>  	else
>  		return 0xf;

This is the same as version <= 0xf || version >= 0x14; I'm rather
suspicious, as the docs have long since been purged, making this
hopeless for anyone without archives (or a good memory) dating back to
that time to check. All that's really needed is citing the version that
comes out of the version register and checking other APIC
implementations to verify they don't have versions tripping this check,
the latter of which is feasible for those relying on still-extant
documentation. Better yet would be dredging up the docs... So, what is
the range of the version numbers reported by i82489DX's?


-- wli

Re: [PATCH] APIC physical broadcast for i82489DX

[Maciej W. Rozycki]

On Thu, 7 Oct 2004, William Lee Irwin III wrote:

> > @@ -91,7 +91,7 @@
> >  	unsigned int lvr, version;
> >  	lvr = apic_read(APIC_LVR);
> >  	version = GET_APIC_VERSION(lvr);
> > -	if (version >= 0x14)
> > +	if (!APIC_INTEGRATED(version) || version >= 0x14)
> >  		return 0xff;
> >  	else
> >  		return 0xf;
> 
> This is the same as version <= 0xf || version >= 0x14; I'm rather

 I suppose defining a macro called something like APIC_XAPIC(x) to (x >= 
0x14) might actually have some sense, although unlike with the i82489DX, 
there is no promise for this to be always true.

> suspicious, as the docs have long since been purged, making this

 AFAIK i82489DX documents were never available online and I suppose they
might have never existed in a PDF form.  You could have ordered hardcopies
in mid 90's.

> hopeless for anyone without archives (or a good memory) dating back to
> that time to check. All that's really needed is citing the version that
> comes out of the version register and checking other APIC
> implementations to verify they don't have versions tripping this check,

 The APIC_INTEGRATED() macro reflects the range reserved for the i82489DX.  
Both "Multiprocessor Specification" and "IA-32 Intel Architecture Software
Developer's Manual, Vol.3" which are available online specify it clearly
and explicitly.  AFAIK, there is no integrated APIC implementation that
would violate it (unlike with I/O APICs), so what's the problem?  If a 
buggy chip appears, we can revisit this assumption.

> the latter of which is feasible for those relying on still-extant
> documentation. Better yet would be dredging up the docs... So, what is
> the range of the version numbers reported by i82489DX's?

 The i82489DX datasheet documents 0x01 for the chip and the
implementations I've encountered so far agree.

  Maciej

Re: [PATCH] APIC physical broadcast for i82489DX

[William Lee Irwin III]

On Thu, 7 Oct 2004, William Lee Irwin III wrote:
>> This is the same as version <= 0xf || version >= 0x14; I'm rather

On Thu, Oct 07, 2004 at 11:12:55PM +0100, Maciej W. Rozycki wrote:
>  I suppose defining a macro called something like APIC_XAPIC(x) to (x >= 
> 0x14) might actually have some sense, although unlike with the i82489DX, 
> there is no promise for this to be always true.

There is a presumption there that higher APIC revisions will be
backward-compatible and will have comparable version numbers, yes.


On Thu, 7 Oct 2004, William Lee Irwin III wrote:
>> suspicious, as the docs have long since been purged, making this

On Thu, Oct 07, 2004 at 11:12:55PM +0100, Maciej W. Rozycki wrote:
>  AFAIK i82489DX documents were never available online and I suppose they
> might have never existed in a PDF form.  You could have ordered hardcopies
> in mid 90's.

Which probably either predated or coincided with my earliest use of
computers.


On Thu, 7 Oct 2004, William Lee Irwin III wrote:
>> hopeless for anyone without archives (or a good memory) dating back to
>> that time to check. All that's really needed is citing the version that
>> comes out of the version register and checking other APIC
>> implementations to verify they don't have versions tripping this check,

On Thu, Oct 07, 2004 at 11:12:55PM +0100, Maciej W. Rozycki wrote:
>  The APIC_INTEGRATED() macro reflects the range reserved for the i82489DX.  
> Both "Multiprocessor Specification" and "IA-32 Intel Architecture Software
> Developer's Manual, Vol.3" which are available online specify it clearly
> and explicitly.  AFAIK, there is no integrated APIC implementation that
> would violate it (unlike with I/O APICs), so what's the problem?  If a 
> buggy chip appears, we can revisit this assumption.

Only documentation; this is probably as good as it gets, so I'm happy
with this level of explanation, for instance, saying what the revision
numbers are.


On Thu, 7 Oct 2004, William Lee Irwin III wrote:
>> the latter of which is feasible for those relying on still-extant
>> documentation. Better yet would be dredging up the docs... So, what is
>> the range of the version numbers reported by i82489DX's?

On Thu, Oct 07, 2004 at 11:12:55PM +0100, Maciej W. Rozycki wrote:
>  The i82489DX datasheet documents 0x01 for the chip and the
> implementations I've encountered so far agree.

Since it's not available online this will have to do. I seem to have
turned up some vague evidence they were made into PDF's ca. 1993, but
don't really expect that to mean anything.


-- wli