Re: [Fastboot] [PATCH] i386: move apic init in init_IRQs

[Eric W. Biederman]

"Protasevich, Natalie" <Natalie.Protasevich@xxxxxxxxxx> writes:

> 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.

The first cpu is brought online much earlier than the rest.  So
we just need to setup a table for boot cpu earlier.  From the looks
of it mach-es700 won't work if you compile a uniprocessor kernel 
for it right now.

We need to do this a little later than in mptable but this should be a fairly
simple one or two line change.

If people keep breaking the subarchitectures by accident we might even 
inspire someone to make a comprehensible sub architecture implentation
on x86 one of these days.


Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/