lkml.org 
[lkml]   [2000]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: FIXED! Updated 2.4 TODO List -- new addition WAS(test9 PCI resource collisions (fwd)

    Cool.

    On Wed, 25 Oct 2000, jamal wrote:
    >
    > The problem is resolved. Mucho Gracias from me and a few (probably
    > hundreds of people in my workplace) who might want to boot 2.3/4 on these
    > Dell docking stations (actually we own a few thousand of them, i am just
    > trying to make sure Linux runs fine ;->)

    I bet this will affect just about every single docking machine out there:
    the bridge in question is apparently the bog-standard "Intel Corporation
    82380FB (rev 01)". Yeah, National and TI seem to have docking bridges of
    their own, but I bet the intel one is the most used by _far_.

    > The proper fix, which is i think what you meant to say is:
    >
    > - }
    > + } else {
    > + /* Transparent bridge */
    > + child->resource[0,1,2] = dev->bus->resource[0,1,2];
    > + }

    Yes. "child->bus->resource" doesn't exist. The above is what my
    drug-addled brain obviously _tried_ to say. It might be more readable in
    the form

    child->resource[0,1,2] = child->parent->resource[0,1,2];

    which should do the same thing. Can you test that alternative too?

    I'll go try to find the complete specs for that bridge from hell, but in
    the meantime I've convinced myself that this might actually be generic
    enough that I think it's ok.

    Basically the notion of "transparent bridging" cannot break anything that
    has been programmed to it's proper address range, so the _only_ thing the
    Linux use of transparent bridging does is allow these kind sof bridges.
    Any bridge that has been properly programmed and does _not_ behave this
    way won't ever see this case, so the change should be safe.

    Obviously we should be doing a better job of being able to actually set up
    bridges, and that will probably make all of this a complete non-issue, but
    for the 2.4.x kind of timeframe I think we'll just face the fact that
    transparent bridges apparently do exist even if the jury is still out on
    the exact details on when and whether it is legal from a spec standpoint.

    [ Some time passes. ]

    I just checked out the National "Nile II" bridge. It's documentation
    explicitly states that it can do subtractive decoding etc, and it has a
    lot more windows than the default PCI bridge thing is supposed to have. So
    it appears that out of my sample of two docking bridges I've looked at so
    far, both seem to have deep magic going on that we have no clue about.

    We should add that information to our knowledge of specific bridges, but
    the notion of "transparent bridging" would still be the fallback for any
    bridge that we don't know about (and new ones obviously come out all the
    time). We simply cannot require that we'd know all the details of all the
    bridges just to work.

    Linus

    -
    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:41    [W:2.885 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site