Re: Numaq in 2.4 and 2.6

[Mika Penttilä]

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








-
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/