lkml.org 
[lkml]   [2003]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Numaq in 2.4 and 2.6


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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:59    [W:0.040 / U:1.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site