[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1206533864.10573.44.camel@pasglop>
Date: Wed, 26 Mar 2008 23:17:44 +1100
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Ivan Kokshaysky <ink@...assic.park.msu.ru>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Thomas Meyer <thomas@...3r.de>, Ingo Molnar <mingo@...e.hu>,
Stefan Richter <stefanr@...6.in-berlin.de>,
Thomas Gleixner <tglx@...utronix.de>,
"Rafael J. Wysocki" <rjw@...k.pl>,
LKML <linux-kernel@...r.kernel.org>,
Adrian Bunk <bunk@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Natalie Protasevich <protasnb@...il.com>,
Gary Hade <garyhade@...ibm.com>
Subject: Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: Reported
regressions from 2.6.24)
On Wed, 2008-03-26 at 13:14 +0300, Ivan Kokshaysky wrote:
>
> Yeah, it's resource issue for sure. The 00:1e.0 is a transparent
> bridge,
> so I blame commit 8fa5913d54f3b1e09948e6a0db34da887e05ff1f
> (PCI: remove transparent bridge sizing). It's wrong for two reasons:
> - we cannot ignore standard windows of a transparent bridge as they
> always positive decode, so they are potential source of address
> conflicts;
> - that patch just broke whole bridge setup logic in unpredictable way.
The root of the problem is again HW vendors getting wild I think...
Some bridges are fully transparent, some have explicit decode windows
but are also transparent for whatever else and we definitely don't deal
with it.
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists