Messages in this thread |  | | Date | Wed, 26 Feb 2003 13:30:09 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [BUG] 2.5.63: ESR killed my box! |
| |
On Wed, 26 Feb 2003, Ion Badulescu wrote: > > diff -urpN -X /home/fletch/.diff.exclude virgin/arch/i386/kernel/smpboot.c > > nonzero_apicid/arch/i386/kernel/smpboot.c > > --- virgin/arch/i386/kernel/smpboot.c Sat Feb 15 16:11:40 2003 > > +++ nonzero_apicid/arch/i386/kernel/smpboot.c Wed Feb 26 13:02:10 2003 > > @@ -951,6 +951,7 @@ static void __init smp_boot_cpus(unsigne > > print_cpu_info(&cpu_data[0]); > > > > boot_cpu_logical_apicid = logical_smp_processor_id(); > > + boot_cpu_physical_apicid = hard_smp_processor_id(); > > > > current_thread_info()->cpu = 0; > > smp_tune_scheduling(); > > But this patch is for smpboot.c, which is not even compiled in for a UP > kernel... > > Both Rusty and I had problems with a UP+APIC kernel running on an SMP box.
What about detect_init_APIC()?
That one currently does an unconditional
boot_cpu_physical_apicid = 0;
and as far as I can see, this is the path taken by the UP case (because it doesn't even _try_ to find the SMP config tables).
What happens if you just remove that line (which means that the code further on will do
*/ if (boot_cpu_physical_apicid == -1U) boot_cpu_physical_apicid = GET_APIC_ID(apic_read(APIC_ID)); which might be correct.
Linus
- 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/
|  |