Bjorn, Thanks so much for your investigation. Yes, MOBO has 2 PCI slots fed off the IT8893E. This guy - http://linux.derkeiler.com/Mailing-Lists/Debian/2005-08/3243.html had a similar problem 10yrs ago(!), fixed by disabling ACPI, I tried that without any success. I did extract the BIOS tables and disassemble/reassemble them to see if there was anything obvious broken there, and not much shows, a few warnings, AML is pretty indecipherable stuff... I also tried fooling it with some Windows acpi_os_name's matching those in the AML, without luck. For kicks I spun up an old Win XP image today, and it recognised the PCI bridge but may not have been able to see the BT878's behind, but then I didn't have a reliable source for drivers for it. Is there's something needing configuring in that Hint HB6/PCI6140 bridge? When working, it loads the shpchp module, and it does advertise itself as "non transparent" mode. The other difference is a latency of 64 in the working scenario, 32 when not. Not configurable on the AMI BIOS unfortunately. Thanks again Richard On 1/02/2016 19:06, Bjorn Helgaas wrote: > On Sat, Jan 30, 2016 at 05:54:28PM +0000, Richard F wrote: >> On 29/01/2016 16:24, Bjorn Helgaas wrote: >>> On Thu, Jan 28, 2016 at 10:23:03AM +0000, Richard F wrote: >>> Your topology looks a little strange: >>> >>> 00:1c.0 PCIe root port to [bus 01] slot 0 >>> 00:1c.1 PCIe root port to [bus 02] slot 1 >>> 00:1c.2 PCIe root port to [bus 03-05] slot 2 >>> 03:00.0 PCI bridge to [bus 04-05] (Integrated Technology Express) >>> 04:01.0 PCI bridge to [bus 05] (Hint Corp) >>> >>> 00:1c.2 is a normal PCIe Root Port, so the device it's connected to >>> *should* be a PCIe device, but 03:00.0 doesn't have a PCIe capability. >>> Is this an adapter card of some kind? >> >> It's a motherboard bridge to get from PCIe to legacy PCI slots, quite a >> few motherboards use it I think. It's not an adapter I plugged in. > > That makes sense. It sounds like there are two conventional PCI > slots? I think it's also a minor platform bug that the 00:1c.2 root > port advertises a slot. 1c.2 is connected to a system-integrated > device, i.e., 03:00.0, not a slot. This might cause pciehp to claim > 1c.2 when it shouldn't. But that's unrelated to the current issue, of > course. > >> I posted the output of DMESG with your patch (in 4.4.0) to the bugzilla >> https://bugzilla.kernel.org/show_bug.cgi?id=110851 >> >> It produced a fair bit of output but doesn't look like the card was >> recognised. At least modprobe'ing bttv with the right parameters didn't >> yield the right response. > > I only added printks, so I didn't expect it to change the behavior. I > just wanted to confirm that we are scanning the bus and device numbers > where we expect the bttv devices to be, and we are. I think your bttv > card includes these devices: > > 04:01.0 PCI-PCI bridge (Hint Corp) > 05:0c.0 bt878 > 05:0c.1 bt878 > 05:0d.0 bt878 > ... > 05:0f.1 bt878 > > For conventional PCI, I think the device number is determined by the > slot wiring. That affects the device number of the Hint Corp bridge, > so if you move it between slots, it should change from device 01 to > something else. > > The device and function numbers of the bt878 devices are determined by > wiring on the card, so those should be the same between machine A and > B. These are 5- and 3-bit fields, respectively, so 0c.0 means we have > 01100 000 encoded into an 8-bit devfn as 0110 0000 or 0x60. When we > tried to read the vendor & device ID from 0c.0, we got no response > from the device: > > pci_bus 0000:05: pci_scan_slot 60 > pci_bus 0000:05: pci_scan_single_device 60 > pci_bus 0000:05: pci_scan_device 60 > pci_bus 0000:05: pci_bus_read_dev_vendor_id 60 0xffffffff > > I'm out of ideas. Other cards work in this slot; it's only the bttv > card that doesn't work. So it seems like it must be something about > that card that's different. > > Maybe somebody on the list will have more ideas? > > Bjorn > -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
