lkml.org 
[lkml]   [2005]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: IBM Thinkpad G41 PCMCIA problems [Was: Yenta TI: ... no PCI interrupts. Fish. Please report.]


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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-11-18 23:46    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site