> Vivek Goyal <[email protected]> writes:
> > I have attached a patch with the mail which is now using
> > boot_cpu_physical_apicid to hard set presence of boot cpu
> instead of
> > hard_smp_processor_id(). But the interesting questoin
> remains why BIOS
> > is not reporting the boot cpu.
>
>
> Ok. I don't know if we care but I do know why we were not
> seeing the report from the bios about your boot processor.
> We record information about cpus for up to NR_CPUS, and since
> you had a UP kernel NR_CPUS was one.
>
> From your earlier boot log.
>
> > ACPI: LAPIC (acpi_id[0x00] lapic_id[0x03] enabled)
> Processor #3 6:10
> > APIC version 17
> > ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> Processor #0 6:10
> > APIC version 17
> > WARNING: NR_CPUS limit of 1 reached. Processor ignored.
> > ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
> Processor #1 6:10
> > APIC version 17
> > WARNING: NR_CPUS limit of 1 reached. Processor ignored.
> > ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
> Processor #2 6:10
> > APIC version 17
> > WARNING: NR_CPUS limit of 1 reached. Processor ignored.
>
> So it looks like we have this problem completely fixed.
>
> I don't see a good way to ensure that we always record our
> boot apicid when we boot a multiple processor system and only
> use one processor.
Hi Eric,
There is another problem with that patch - it broke ES7000, I kept
getting timer panics. It turned out that check_timer() runs before the
actual APIC destination is set up. The IO-APIC uses
cpu_to_logical_apicid to find the destination - which needs
cpu_2_logical_apicid[] to be filled - which only happens after
processors are booted. At the time when check_timer() runs, it will
always be BAD_APICID (0xFF - broadcast) as the IO-APIC rte destination
for the timer, but ES7000 hardware happened not to support 0xFF so it
panics. I used bios_cpu_apicid[] to bring it up, but
cpu_to_logical_apicid is the only one that is kept up-to-date in the
hotplug case, so I cannot replace it in the cpu_mask_to_apicid().
There are probably some ways to fix this such as one below that I tried
(in mpparse.c):
if (m->mpc_cpuflag & CPU_BOOTPROCESSOR) {
Dprintk(" Bootup CPU\n");
boot_cpu_physical_apicid = m->mpc_apicid;
+ cpu_2_logical_apicid[num_processors] = m->mpc_apicid;
}
it worked, but looks more like a kludge of course. I think IO-APIC
setup has to happen after processors were brought online and so is
check_timer(), if timer is connected through the IO-APIC.
--Natalie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]