Messages in this thread | | | Date | Fri, 12 Aug 2005 15:32:48 +0200 | From | Andi Kleen <> | Subject | Re: APIC version and 8-bit APIC IDs |
| |
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/
| |