On Tue, 18 Dec 2007, Richard Henderson wrote:
>
> Another way to look at this is that the graphics BAR came in from
> the BIOS allocated at c0000000, and we ignored that.
We did?
> Perhaps there's a way to give weight to the BIOS settings when
> consdering where the PCI region is supposed to start?
Normally, we *always* keep the BIOS allocations, unless it explicitly
clashes with something and we have reason to believe that they cannot
work. And there's nothing it clashes with, so we definitely *should* have
kept it.
Why do you think it came pre-allocated at 0xc0000000? I'm seeing the
message
PCI: Cannot allocate resource region 1 of device 0000:01:00.0
and I can well imagine that that is it, but if it was a valid allocation,
then we really should have kept it there.
That question also brings up another issue: how come did we actually
choose address 0xc0000000 with the original patch you sent in? If we can't
find it in the parent resources, we shouldn't have accepted it even if it
had room for it!
Which brings up *another* potential fix for this thing: as mentioned,
Intel bridges often claim to be "Normal decode", but the core ones seem to
almost never actually be that, and they tend to be "Negative decode". So
what may be going on is:
- the kernel sees that BIOS allocation at 0xc0000000 (I'll take your word
for it, it doesn't actually say so without PCI debugging enabled)
- ...and notices that the PCI BAR is behind a PCI bridge that does
not claim to be able to actually bridge that resource (it's normal
decode, and the ranges it *does* decode are elsewhere!)
- so clearly that old allocation is pure crap and has to be re-done in a
range that is actually properly bridged.
but that decision bases itself on the Intel bridge not lying, and if it
turns out that the bridge at 0000:00:01.0 actually is transparent, then
the original allocation would have been ok.
That said, your bridge at 00:1e.0 is *also* transparent, and it's actually
against the PCI specs to have two transparent bridges on the same PCI bus,
so I'm a bit surprised about that. But it does bring up a new thing you
could *try*, namely this patch...
(You obviously have to replace "insert-your-device-here" with the proper
PCI device ID for the thing you have - your lspci output only gives the
name, not the numbers)
We seem to have a multitude of possible reasons for this insanity. It
would be interesting to hear which one(s) of the possibilities make a
difference, if any.
Linus
---
drivers/pci/quirks.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 26cc4dc..c3b52f5 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -820,6 +820,7 @@ static void __devinit quirk_transparent_bridge(struct pci_dev *dev)
{
dev->transparent = 1;
}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, insert-your-device-id-here, quirk_transparent_bridge );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82380FB, quirk_transparent_bridge );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TOSHIBA, 0x605, quirk_transparent_bridge );
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
