Re: Numaq in 2.4 and 2.6

["Mika Penttilä" <mika.penttila@kolumbus.fi>]

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))
return;

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",
m->mpc_apicid,
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?


--Mika