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:0.047 / U:3.548 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site