> 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.
That strikes me as the wrong way around. We *are* booting on this CPU,
so the MPS tables are wrong. Why reprogram reality to fit the MPS tables?
Also, you don't know what the other CPUs phys ID's really are if
everything is inconsistent anyway ... if the MPS tables say boot is phys 0,
and phys 1 also exists, and we find we're on phys 1, what now?
Also, if we kexec from a non-original boot cpu, we come back with that CPU
as the boot CPU, which is correct, but doesn't match the MPS tables .. the
one liner I sent before will fix that.
Wouldn't it be better to just leave the phys apicids as is, and just print
a warning of the MPS tables boot flags don't match up with reality? Seems
far less drastic to me.
> 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.
OK, that's bad. SMP does that currently too, but it's easy to fix without
going to the extent of reprogramming things that we don't really understand
the state of (because we have inconsistent info)
M.
-
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/
This archive was generated by hypermail 2b29 : Fri Feb 28 2003 - 22:00:39 EST