Re: APIC version and 8-bit APIC IDs
From: Andi Kleen
Date: Fri Aug 12 2005 - 08:33:11 EST
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.
> 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/