lkml.org 
[lkml]   [2000]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] panic when booting Intel XXPRESS SMP boards
    On Fri, 8 Sep 2000, Linus Torvalds wrote:

    > I'm doing an alternative patch that just igores unknown buses, because
    > paniccing is definitely the wrong answer for anything but some early
    > debugging ("did I catch all the relevant cases?").

    I think we must panic() for an unknown bus that has an I/O APIC interrupt
    routed from that is marked as "conforming to the bus spec" in the MP
    table. Trying to assume any defaults is unsafe and is not any better --
    we may guess them upon the first interested user reports such a problem.
    This should trigger on a small amount of unusual system if any at all.

    For any other case we may try to handle interrupts according to
    information provided in the MP table.

    > It looks like the simplest solution is to just make bus number 0 be
    > "unknown", and leave it at that (and start ISA etc from 1). Wouldn't you
    > agree?

    We cannot asume any bus is of any type -- it may be ISA or PCI or
    whatever. Jean-Marc actually reported:

    Bus #0 is PCI
    Bus #1 is PCI
    Bus #18 is XPRESS
    Bus #19 is EISA

    a few days ago (I admit I should have replied by then but this week was
    completely crazy for me so I just marked it for later reference). So this
    will not help him either.

    We may add an "unknown" entry to our bus list and only choke upon I/O IRQ
    parsing under conditions I've outlined above. We may print the bus name
    to the log for user pleasure anyway, as it's stored as ASCII in the MP
    table.

    > I'd love to have somebody (yes, you) look at the actual MP table and see
    > if there is something special with the XXPRESS bus, but in the end even if
    > we don't know a bus we're better off always just mentioning the fact
    > ("Unknown bus XXXX") and going on with our life. Maybe the system won't
    > work simply becasue we won't find any critical devices off the bus, but if
    > we panic we _know_ that it won't work, so..

    The system may be unusable due to an IRQ flood for example (just like
    when I set my 8254 IRQ as level-triggered in the I/O APIC when simulating
    an MCA configuration).

    Jean-Marc: feel free to send me the output of `dmesg -s 32768' as I
    outlined in the previous mail -- I'll study it after the next week (or
    immediately, if you somehow manage it to be delivered in a few minutes ;-)
    ).

    Maciej

    --
    + Maciej W. Rozycki, Technical University of Gdansk, Poland +
    +--------------------------------------------------------------+
    + e-mail: macro@ds2.pg.gda.pl, PGP key available +


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

    \
     
     \ /
      Last update: 2005-03-22 12:38    [W:0.024 / U:0.032 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site