Re: APIC version and 8-bit APIC IDs

[Andi Kleen <ak@suse.de>]

On Fri, Aug 12, 2005 at 03:21:00PM +0200, Martin Wilck wrote:
> >Yes, it's broken. In fact I removed it in my physflat32 patch
> >which is needed for 16 core AMD systems. I don't think there
> >is a generic way to fix it because the XAPIC check breaks
> >on AMD systems 
> 
> on the Intel Xeon MP systems, too,

How so? The XAPIC version check should work there.

The problem on AMD happens because it reports an old APIC version.

> 
> >and there is no good way to decide early 
> >on subarchitectures before doing this check. Also it's only
> >a sanity check for broken BIOS, and in this case it causes more problems
> >than it solves.
> 
> agreed.
> 
> >ftp://ftp.firstfloor.org/pub/ak/x86_64/x86_64-2.6.13rc3-1/patches/physflat32
> 
> That is a beautiful patch, thank you.

It'll probably be revamped somewhat before inclusion. In particular
it has been suggested to merge it with bigsmp because the setup
should work on Intel too.

> 
> Only one small point: I wonder whether it is correct to use the number 
> of CPUs as criterion for this architecture. AFAICS, the Specs allow
> having only 4 CPUS, but giving them APIC IDs e.g. 16,17,18,19. In this 
> case, physflat32 should be used as well (in particular, the APIC ID 
> broadcast and mask must be set to 0xff).

I fixed that in the 64bit version already, but not in 32bit yet.
Yes, the value of the APIC IDs must be used as indicator.

-Andi
-
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/