Re: Numaq in 2.4 and 2.6

From: Mika Penttilä
Date: Sat Dec 06 2003 - 08:06:17 EST

William Lee Irwin III wrote:

On Sat, Dec 06, 2003 at 02:19:24PM +0200, Mika Penttil? wrote:

Ok...the only thing that still confuses is the apicid to actually used to start the cpu. In NUMA-Q case we don't program the LDRs in either 2.4 or 2.6, the bios does this. So the NMI IPI must have the same destinations in both 2.4 and 2.6 in order to lauch the same cpus.

On Sat, Dec 06, 2003 at 02:19:24PM +0200, Mika Penttil? wrote:

In 2.4, the mpc_apicids are used as such as NMI IPI destinations. In 2.6, the mangled ones (by generate_logical_apicid()) are used as NMI IPI destinations. If the mpc_apicid is already in sort of (cluster, cpu) format (and used in 2.4 NMI IPI), it can't be the same after mangling?

The mangled physical APIC ID used as an index into phys_cpu_present_map
happens to determine the clustered hierarchical logical APIC ID, and so
wakeup_secondary_cpu() (switched via #ifdef) gets the right number.
There is a correspondence between (node, physical APIC ID) pairs and
logical APIC ID's that's part of the BIOS's bootstrap protocol. The
calculations you're looking at are based on that, and the logical APIC
ID's are encoded in that paired format by the BIOS, and in the mangled
format as indices into phys_cpu_present_map.

Both 2.4 and 2.6 use cpu_present_to_apicid() to do that translation on
the fly given an index into phys_cpu_present_map().

-- wli

Thanks, I understand what's happening in 2.6. So I think there might be a problem with 2.4.23 then. In mpparse.c :

void __init MP_processor_info (struct mpc_config_processor *m)
int ver, quad, logical_apicid;

if (!(m->mpc_cpuflag & CPU_ENABLED))

logical_apicid = m->mpc_apicid;
if (clustered_apic_mode == CLUSTERED_APIC_NUMAQ) {
quad = translation_table[mpc_record]->trans_quad;
logical_apicid = (quad << 4) +
(m->mpc_apicid ? m->mpc_apicid << 1 : 1);
printk("Processor #%d %s APIC version %d (quad %d, apic %d)\n",
mpc_family((m->mpc_cpufeature & CPU_FAMILY_MASK)>>8 ,
(m->mpc_cpufeature & CPU_MODEL_MASK)>>4),
m->mpc_apicver, quad, logical_apicid);
and later in same function :

phys_cpu_present_map |= apicid_to_phys_cpu_present(m->mpc_apicid);

but _not_

phys_cpu_present_map |= apicid_to_phys_cpu_present(logical_apicid);

as one would expect (and would make it identical to 2.6 behaviour).... A bug?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at