Messages in this thread | | | Date | Sat, 06 Dec 2003 15:09:10 +0200 | From | Mika Penttilä <> | Subject | Re: 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/
| |