Re: [LinuxBIOS] x86_64: apic id lift patch

[Andi Kleen <ak@suse.de>]

> At the same time, we seem to be treading in territory where the fuctory 
> BIOSes have not yet been. We're in the weird position, at times, of 
> finding things out before the proprietary BIOSes get there.

You're saying that Arima machine only runs with LinuxBIOS so far?

> 
> Sometimes the ease of updating the BIOS can cause troubles you don't 
> expect. Fuctory BIOSes seem to count on infrequent updates, forked code 
> bases, and so on, so that you have to update each mainboard source base 
> individually -- they have the disadvantage of a forked code base, but 
> the one advantage is that a mod to fix one platform won't ever break 
> another.
> 
> At some point I had understood that linux was going to be able to 
> function without resorting to SRAT tables -- has that changed? Is this 

SRAT is definitely the wave of the future.  I'm going to keep
the old code working as long as it's relatively cleanly possible.
But this needs to make some assumptions, and in particular your
discontiguous APIC IDs broke that. I don't plan to try to handle
every weird case in this case - if your setup is really
weird use SRAT.

Regarding the BSP 0 - you probably just have a stupid bug
somewhere that breaks the timer interrupt. I don't know
of any hardware issue that would prevent the timer interrupt
going to a APIC ID != 0. There are some troubles with timer
interrupts, but they are different issues. IMHO the discontig
APIC IDs was just a workaround because you didn't want to fix
the interrupt routing properly, with the burden on the kernel.

You have two options now:

- Trace down why interrupt 0 doesn't work with BSP LAPIC != 0
and fix that. 
- Provide SRAT.

First is probably better, although the second also wouldn't hurt.


> patch really intrusive enough that it is not acceptable? The issue is 

Yes it complicates the logic enough and makes it more fragile,
which would be a long term maintenance issue. The only way 
to keep the fallback code alive at all is to keep it simple
and clean.


-Andi
-
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/