Re: [BUG] 2.5.63: ESR killed my box!

[Mikael Pettersson <mikpe@user.it.uu.se>]

Linus Torvalds writes:
 > > 1) apic_write_around(APIC_ID, boot_cpu_physical_apicid) places the APIC 
 > > value in the lower 8 bits of APIC_ID, when it should be in the upper 8. As 
 > > as result, it effectively forces the APIC id to always be 0 for the boot 
 > > CPU, which is fatal on SMP AMD boxes.
 > 
 > Wouldn't it be nicer to just fix the write instead? I can see the 
 > potential to actually want to change the APIC ID - in particular, if the 
 > SMP MP tables say that the APIC ID for the BP should be X, maybe we should 
 > actually write X to it instead of just using what is there.
 > 
 > In particular, Mikaels patch will BUG() if the MP tables don't match the 
 > APIC ID. I think that's extremely rude: we should select one of the two 
 > and just run with it, instead of unconditionally failing.

Yes, but that was just a test patch to test my suspicions about why
a UP_APIC kernel failed on an SMP K7 box. (CPU #1 was BSP and was
programmed with CPU #0's local APIC ID.)

I assume that an SMP machine once booted by the BIOS will have
unique local APIC IDs. They're typically either hardwired or programmed
by the BIOS. If the MP table then disagrees with what's in the
CPUs' local APIC IDs, who do you trust: the MP table or the CPUs?
I personally would trust the CPUs and leave the local APIC IDs alone,
in particular since writing to them always risks collisions, especially
in the UP-kernel-on-SMP-HW case.

So I think the BUG should be a warning, but we shouldn't clobber APIC_ID.

/Mikael