RE: [Fastboot] [PATCH] i386: move apic init in init_IRQs
From: Protasevich, Natalie (Natalie.Protasevich_at_UNISYS.com)
Date: 10/31/05
- Previous message: Patrizio Bassi: "Re: [BUG 2579] linux 2.6.* sound problems"
- Next in thread: Zwane Mwaikambo: "RE: [Fastboot] [PATCH] i386: move apic init in init_IRQs"
- Reply: Zwane Mwaikambo: "RE: [Fastboot] [PATCH] i386: move apic init in init_IRQs"
- Reply: Eric W. Biederman: "Re: [Fastboot] [PATCH] i386: move apic init in init_IRQs"
- Maybe reply: Protasevich, Natalie: "RE: [Fastboot] [PATCH] i386: move apic init in init_IRQs"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 31 Oct 2005 11:04:52 -0600 To: "Eric W. Biederman" <ebiederm@xmission.com>, <vgoyal@in.ibm.com>
> Vivek Goyal <vgoyal@in.ibm.com> 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 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/
- Previous message: Patrizio Bassi: "Re: [BUG 2579] linux 2.6.* sound problems"
- Next in thread: Zwane Mwaikambo: "RE: [Fastboot] [PATCH] i386: move apic init in init_IRQs"
- Reply: Zwane Mwaikambo: "RE: [Fastboot] [PATCH] i386: move apic init in init_IRQs"
- Reply: Eric W. Biederman: "Re: [Fastboot] [PATCH] i386: move apic init in init_IRQs"
- Maybe reply: Protasevich, Natalie: "RE: [Fastboot] [PATCH] i386: move apic init in init_IRQs"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
