[lkml]   [2005]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: APIC version and 8-bit APIC IDs
Hi Andi, hi everyone,

>>The MP_valid_apicid() function [arch/i386/kernel/mpparse.c] checks
>>whether the APIC version field is >=20 in order to determine whether
>>the CPU supports 8-bit physical APIC ids.
> Yes, it's broken. ... . Also it's only
> a sanity check for broken BIOS, and in this case it causes more problems
> than it solves.

We have another issue with the APIC IDs: the GET_APIC_ID and
APIC_ID_MASK macros from the subarch code. In all subarchs except summit
and es7000, these macros use a hard-coded mask 0x0F for the APIC ID.
Thus, any APIC ID >15 will be truncated, leading to obscure errors.

We are wondering why these masks are there in the subarch code at all.
After all, whether or not 8-bit APIC IDs are supported depends mainly on
the CPU type used. Why wouldn't it possible to have a "default"
architecture with APIC IDs > 15, if the CPUs allow it?

In other words: What would be broken if we just used an APIC ID mask of
0xFF everywhere?

The current situation with MP_valid_apicid() on the one hand (masking
the APIC ID as a function of local APIC version) and APIC_ID_MASK
(masking the APIC as a function of subarch) on the other hand is
inconsistent. A correct approach must take both CPU and architecture
constraints into account, and use a CPU-type-dependent variable mask in
the subarch code.


Martin Wilck Phone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1
D-33106 Paderborn
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-08-31 15:16    [W:0.048 / U:6.120 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site