lkml.org 
[lkml]   [2003]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [BUG] 2.5.63: ESR killed my box!
    > 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/

    \
     
     \ /
      Last update: 2005-03-22 13:33    [W:3.260 / U:0.840 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site