On Sat, 19 Feb 2005, Steven Rostedt wrote:
>
> Here's the scoop:
>
> cat /proc/iomem:
Ok. This one does not show device 00:1e.0 _at_all_. It had:
I/O behind bridge: 00003000-00006fff
Memory behind bridge: c2000000-cfffffff
Prefetchable memory behind bridge: f0000000-f7ffffff
and it just doesn't show. It shows some of the devices that are behind
that bridge, though, and it should PCI Bus #01. Why not #02? Looks like we
must have decided that that PCI bus is transparent.
But we have the PCI device hierarchy right:
> /sys/devices/pci0000:00/0000:00:1e.0/0000:02:00.0:
> /sys/devices/pci0000:00/0000:00:1e.0/0000:02:01.0:
> /sys/devices/pci0000:00/0000:00:1e.0/0000:02:01.1:
> /sys/devices/pci0000:00/0000:00:1e.0/0000:02:02.0:
Oh, and your dmesg does show:
PCI: Transparent bridge - 0000:00:1e.0
so that explains it. We believe that 0:1e.0 is transparent.
Maybe we're even right. We do have a few quirky bridges that are marked
transparent. I didn't think yours was one of them, though.
I _think_ it's the code in arch/i386/pci/fixup.c that does this. See the
static void __devinit pci_fixup_transparent_bridge(struct pci_dev *dev)
thing, and try to disable it. Maybe that rule is wrong, and triggers much
too often?
Or maybe it really _is_ a transparent bridge after all, and the problem is
somewhere else. Disabling the pci_fixup_transparent_bridge logic is a good
thing to try first, though.
Linus
-
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/
