Hint HB6 - kernel doesn't see chips behind it.

I moved a Kodicom card (http://linuxtv.org/wiki/index.php/Kodicom_4400R)
from an older machine to a new with a PCIe bridge. Bttv modprobe can no longer find the BT878 chips behind the PCI bridge, though the bridge is found.

The bridge is a PCI6140 AKA "Hint HB6".
I noticed a PCI quirk for it, tried manually adding the IO/memory spaces that were originally logged, but doesn't help.

This machine runs kernel 3.12.52 (x64), but it also fails on 3.0.76. The BT878 chips were recognised on the older machine also running 3.0.76 but with a vanilla PCI bus.

Relevant dmesg lines when not working (can post entire logs if helpful)

[    0.089046] pci 0000:00:1c.2: scanning [bus 03-05] behind bridge, pass 0
[    0.089105] pci_bus 0000:03: scanning bus
[    0.089136] pci 0000:03:00.0: [1283:8893] type 01 class 0x060401
[    0.089335] pci 0000:03:00.0: supports D1 D2
[    0.089336] pci 0000:03:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.089343] pci 0000:03:00.0: PME# disabled
[    0.089382] pci_bus 0000:03: fixups for bus
[    0.089383] pci 0000:00:1c.2: PCI bridge to [bus 03-05]
[    0.089397] pci 0000:03:00.0: scanning [bus 04-05] behind bridge, pass 0
[    0.089487] pci_bus 0000:04: scanning bus
[    0.089523] pci 0000:04:01.0: [3388:0021] type 01 class 0x060400
[    0.089729] pci 0000:04:01.0: supports D1 D2
[    0.089730] pci 0000:04:01.0: PME# supported from D1 D2 D3hot D3cold
[    0.089738] pci 0000:04:01.0: PME# disabled
[    0.089871] pci_bus 0000:04: fixups for bus
[    0.089872] pci 0000:03:00.0: PCI bridge to [bus 04-05] (subtractive decode)
[    0.089906] pci 0000:03:00.0:   bridge window [??? 0x00000000 flags 0x0] (subtractive decode)
[    0.089907] pci 0000:03:00.0:   bridge window [??? 0x00000000 flags 0x0] (subtractive decode)
[    0.089908] pci 0000:03:00.0:   bridge window [??? 0x00000000 flags 0x0] (subtractive decode)
[    0.089910] pci 0000:03:00.0:   bridge window [??? 0x00000000 flags 0x0] (subtractive decode)
[    0.089914] pci 0000:04:01.0: scanning [bus 05-05] behind bridge, pass 0
[    0.090011] pci_bus 0000:05: scanning bus
[    0.090116] pci_bus 0000:05: fixups for bus
[    0.090117] pci 0000:04:01.0: PCI bridge to [bus 05]
[    0.090139] pci_bus 0000:05: bus scan returning with max=05
[    0.090148] pci 0000:04:01.0: scanning [bus 05-05] behind bridge, pass 1
[    0.090159] pci_bus 0000:04: bus scan returning with max=05
[    0.090167] pci 0000:03:00.0: scanning [bus 04-05] behind bridge, pass 1
[    0.090177] pci_bus 0000:03: bus scan returning with max=05
[    0.090181] pci 0000:00:1c.0: scanning [bus 01-01] behind bridge, pass 1
[    0.090187] pci 0000:00:1c.1: scanning [bus 02-02] behind bridge, pass 1
[    0.090193] pci 0000:00:1c.2: scanning [bus 03-05] behind bridge, pass 1
[    0.090197] pci_bus 0000:00: bus scan returning with max=05

Working - in older machine

[    0.203039] pci 0000:04:00.0: [1409:7268] type 0 class 0x000701
[    0.203055] pci 0000:04:00.0: reg 10: [io  0xef00-0xef07]
[    0.203066] pci 0000:04:00.0: reg 14: [io  0xee00-0xee07]
[    0.203139] pci 0000:04:01.0: [3388:0021] type 1 class 0x000604
[    0.203219] pci 0000:04:01.0: supports D1 D2
[    0.203222] pci 0000:04:01.0: PME# supported from D1 D2 D3hot D3cold
[    0.203227] pci 0000:04:01.0: PME# disabled
[    0.203257] pci 0000:04:04.0: [1106:3044] type 0 class 0x000c00
[    0.203277] pci 0000:04:04.0: reg 10: [mem 0xfd8ff000-0xfd8ff7ff]
[    0.203289] pci 0000:04:04.0: reg 14: [io  0xed00-0xed7f]
[    0.203365] pci 0000:04:04.0: supports D2
[    0.203367] pci 0000:04:04.0: PME# supported from D2 D3hot D3cold
[    0.203372] pci 0000:04:04.0: PME# disabled
[    0.203416] pci 0000:00:1e.0: PCI bridge to [bus 04-05] (subtractive decode)
[    0.203423] pci 0000:00:1e.0:   bridge window [io  0xd000-0xefff]
[    0.203428] pci 0000:00:1e.0:   bridge window [mem 0xfd700000-0xfd8fffff]
[    0.203435] pci 0000:00:1e.0:   bridge window [mem 0xfd600000-0xfd6fffff 64bit pref]
[    0.203438] pci 0000:00:1e.0:   bridge window [io  0x0000-0xffff] (subtractive decode)
[    0.203441] pci 0000:00:1e.0:   bridge window [mem 0x00000000-0xfffffffff] (subtractive decode)
[    0.203520] pci 0000:05:0c.0: [109e:036e] type 0 class 0x000400
[    0.203546] pci 0000:05:0c.0: reg 10: [mem 0xfd6ff000-0xfd6fffff pref]
[    0.203690] pci 0000:05:0c.1: [109e:0878] type 0 class 0x000480
[    0.203717] pci 0000:05:0c.1: reg 10: [mem 0xfd6fe000-0xfd6fefff pref]
[    0.203871] pci 0000:05:0d.0: [109e:036e] type 0 class 0x000400
[    0.203898] pci 0000:05:0d.0: reg 10: [mem 0xfd6fd000-0xfd6fdfff pref]
[    0.204041] pci 0000:05:0d.1: [109e:0878] type 0 class 0x000480
[    0.204067] pci 0000:05:0d.1: reg 10: [mem 0xfd6fc000-0xfd6fcfff pref]
[    0.204222] pci 0000:05:0e.0: [109e:036e] type 0 class 0x000400
[    0.204249] pci 0000:05:0e.0: reg 10: [mem 0xfd6fb000-0xfd6fbfff pref]
[    0.204392] pci 0000:05:0e.1: [109e:0878] type 0 class 0x000480
[    0.204419] pci 0000:05:0e.1: reg 10: [mem 0xfd6fa000-0xfd6fafff pref]
[    0.204572] pci 0000:05:0f.0: [109e:036e] type 0 class 0x000400
[    0.204599] pci 0000:05:0f.0: reg 10: [mem 0xfd6f9000-0xfd6f9fff pref]
[    0.204741] pci 0000:05:0f.1: [109e:0878] type 0 class 0x000480
[    0.204768] pci 0000:05:0f.1: reg 10: [mem 0xfd6f8000-0xfd6f8fff pref]
[    0.204933] pci 0000:04:01.0: PCI bridge to [bus 05-05]
[    0.204939] pci 0000:04:01.0:   bridge window [io  0xd000-0xdfff]
[    0.204945] pci 0000:04:01.0:   bridge window [mem 0xfd700000-0xfd7fffff]
[    0.204950] pci 0000:04:01.0:   bridge window [mem 0xfd600000-0xfd6fffff pref]

lspci -vvv (NOT working)

04:01.0 PCI bridge: Hint Corp HB6 Universal PCI-PCI bridge (non-transparent mode) (rev 11) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32, Cache Line Size: 64 bytes
Bus: primary=04, secondary=05, subordinate=05, sec-latency=32
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: fff00000-000fffff
Prefetchable memory behind bridge: fff00000-000fffff
Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Bridge: PM- B3+
Capabilities: [90] CompactPCI hot-swap <?>

lspci -vvv (working)

04:01.0 PCI bridge: Hint Corp HB6 Universal PCI-PCI bridge (non-transparent mode) (rev 11) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 64 bytes
Bus: primary=04, secondary=05, subordinate=05, sec-latency=32
I/O behind bridge: 0000d000-0000dfff
Memory behind bridge: fd700000-fd7fffff
Prefetchable memory behind bridge: fd600000-fd6fffff
Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Bridge: PM- B3+
Capabilities: [90] CompactPCI hot-swap <?>
Kernel modules: shpchp

Thanks for any help / guidance on debugging

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi Richard,

Thanks for your report. I opened this bug report:

https://bugzilla.kernel.org/show_bug.cgi?id=110851

Can you please attach the complete dmesg logs from the old machine running 3.0.76 and the new machine running 3.0.76 to that bugzilla? Also please attach the complete "lspci -vvv" output for all the devices in the new machine.

Is there any chance you can try a current kernel, e.g., v4.4, on the new machine? Even if you can't install a new kernel permanently, the dmesg log of PCI enumeration is enough to show whether we detect the Kodicom devices or not.

Bjorn

Hi Richard,

Quoted 5 lines · Richard F

I moved a Kodicom card (http://linuxtv.org/wiki/index.php/Kodicom_4400R)
from an older machine to a new with a PCIe bridge. Bttv modprobe can no longer find the BT878 chips behind the PCI bridge, though the bridge is found.

Quoted 7 lines

The bridge is a PCI6140 AKA "Hint HB6".
I noticed a PCI quirk for it, tried manually adding the IO/memory spaces that were originally logged, but doesn't help.

This machine runs kernel 3.12.52 (x64), but it also fails on 3.0.76. The BT878 chips were recognised on the older machine also running 3.0.76 but with a vanilla PCI bus.

Thanks for your report. I opened this bug report:

https://bugzilla.kernel.org/show_bug.cgi?id=110851

Can you please attach the complete dmesg logs from the old machine running 3.0.76 and the new machine running 3.0.76 to that bugzilla? Also please attach the complete "lspci -vvv" output for all the devices in the new machine.

I posted a DMESG with 4.3.3 to Bugzilla now.
4.4.0 crashed on boot, not sure why yet.

Quoted 16 lines

Hi Richard,

Quoted 5 lines · Richard F

I moved a Kodicom card (http://linuxtv.org/wiki/index.php/Kodicom_4400R)
from an older machine to a new with a PCIe bridge. Bttv modprobe can no longer find the BT878 chips behind the PCI bridge, though the bridge is found.

Quoted 7 lines

The bridge is a PCI6140 AKA "Hint HB6".
I noticed a PCI quirk for it, tried manually adding the IO/memory spaces that were originally logged, but doesn't help.

This machine runs kernel 3.12.52 (x64), but it also fails on 3.0.76. The BT878 chips were recognised on the older machine also running 3.0.76 but with a vanilla PCI bus.

Quoted 9 lines

Thanks for your report. I opened this bug report:

https://bugzilla.kernel.org/show_bug.cgi?id=110851

Can you please attach the complete dmesg logs from the old machine running 3.0.76 and the new machine running 3.0.76 to that bugzilla? Also please attach the complete "lspci -vvv" output for all the devices in the new machine.

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 2 lines · Richard F

I posted a DMESG with 4.3.3 to Bugzilla now.
4.4.0 crashed on boot, not sure why yet.

Thanks for all the data you collected! I haven't had a chance to look at them yet, but maybe others will take a look also.

Crashing on boot is a much more serious problem than failure to find a card. Any information you can collect about the v4.4.0 problem would be extremely useful. A serial console log would be ideal, but even a photo or video of the boot might be helpful. Boot with "ignore_loglevel" to make sure we see all the messages.

Bjorn

Quoted 31 lines · Bjorn Helgaas

Quoted 16 lines

Hi Richard,

Quoted 5 lines · Richard F

I moved a Kodicom card (http://linuxtv.org/wiki/index.php/Kodicom_4400R)
from an older machine to a new with a PCIe bridge. Bttv modprobe can no longer find the BT878 chips behind the PCI bridge, though the bridge is found.

Quoted 7 lines

The bridge is a PCI6140 AKA "Hint HB6".
I noticed a PCI quirk for it, tried manually adding the IO/memory spaces that were originally logged, but doesn't help.

This machine runs kernel 3.12.52 (x64), but it also fails on 3.0.76. The BT878 chips were recognised on the older machine also running 3.0.76 but with a vanilla PCI bus.

Quoted 9 lines

Thanks for your report. I opened this bug report:

https://bugzilla.kernel.org/show_bug.cgi?id=110851

Can you please attach the complete dmesg logs from the old machine running 3.0.76 and the new machine running 3.0.76 to that bugzilla? Also please attach the complete "lspci -vvv" output for all the devices in the new machine.

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 2 lines · Richard F

I posted a DMESG with 4.3.3 to Bugzilla now.
4.4.0 crashed on boot, not sure why yet.

Quoted 2 lines · Richard F

I posted a DMESG with 4.3.3 to Bugzilla now.
4.4.0 crashed on boot, not sure why yet.

Thanks for all the data you collected! I haven't had a chance to look at them yet, but maybe others will take a look also.

Crashing on boot is a much more serious problem than failure to find a card. Any information you can collect about the v4.4.0 problem would be extremely useful. A serial console log would be ideal, but even a photo or video of the boot might be helpful. Boot with "ignore_loglevel" to make sure we see all the messages.

Bjorn

Would someone be able take a quick look at my logs and give me any kind of steer as to where to look? I'm happy to do some more debugging with a bit of guidance.

https://bugzilla.kernel.org/show_bug.cgi?id=110851

Quoted 7 lines · Richard F

Quoted 2 lines

I posted a DMESG with 4.3.3 to Bugzilla now.
4.4.0 crashed on boot, not sure why yet.

Thanks for all the data you collected! I haven't had a chance to look at them yet, but maybe others will take a look also.

Quoted 8 lines

Crashing on boot is a much more serious problem than failure to find a card. Any information you can collect about the v4.4.0 problem would be extremely useful. A serial console log would be ideal, but even a photo or video of the boot might be helpful. Boot with "ignore_loglevel" to make sure we see all the messages.

Bjorn

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi Richard,

Quoted 5 lines · Richard F

Would someone be able take a quick look at my logs and give me any kind of steer as to where to look? I'm happy to do some more debugging with a bit of guidance.

https://bugzilla.kernel.org/show_bug.cgi?id=110851

The kernel doesn't see the bt878 devices at all on your new machine, with the exception of the boot in comment #6, where you added another card in an adjacent slot. That makes me think there might be a hardware problem with the slot. Can you try a completely different kind of card in that slot? Do devices in that slot work with any other OS?

Bjorn,

Thanks for looking at it. Actually I've tried 3 different PCI cards in both slots and they all work fine. I have 2 different single channel BT878 based PCI cards in there now capturing CCTV 24 x 7, the machine stays up for months. That's why it's so odd. Any other pointers? Does the kernel need the BIOS to detect the card right?

Quoted 7 lines · Richard F

Bjorn,

Thanks for looking at it. Actually I've tried 3 different PCI cards in both slots and they all work fine. I have 2 different single channel BT878 based PCI cards in there now capturing CCTV 24 x 7, the machine stays up for months. That's why it's so odd. Any other pointers? Does the kernel need the BIOS to detect the card right?

The kernel should at least discover the card even if the BIOS doesn't do anything. But on x86, the BIOS usually *does* configure things, so it's very possible we could trip over a Linux defect if it doesn't.

Try booting with "pci=pcie_scan_all". That *shouldn't* make a difference because this isn't a PCIe device, but maybe our logic is broken.

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?

03:00.0 is an ITE 8893, and we do have a quirk related to a similar device:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/quirks.c?h=v4.4#n3662

Can you try the patch below, please?

drivers/pci/probe.c +4 -0

index 6d7ab9b..f6d8e85 100644
@@ -1530,6 +1530,7 @@ bool pci_bus_read_dev_vendor_id(struct pci_bus *bus, int devfn, u32 *l,
 	if (pci_bus_read_config_dword(bus, devfn, PCI_VENDOR_ID, l))
 		return false;
 
+	dev_info(&bus->dev, "%s %02x %#010x\n", __func__, devfn, *l);
 	/* some broken boards return 0 or ~0 if a slot is empty: */
 	if (*l == 0xffffffff || *l == 0x00000000 ||
 	    *l == 0x0000ffff || *l == 0xffff0000)

@@ -1571,6 +1572,7 @@ static struct pci_dev *pci_scan_device(struct pci_bus *bus, int devfn)
 	struct pci_dev *dev;
 	u32 l;
 
+	dev_info(&bus->dev, "%s %02x\n", __func__, devfn);
 	if (!pci_bus_read_dev_vendor_id(bus, devfn, &l, 60*1000))
 		return NULL;
 

@@ -1751,6 +1753,7 @@ struct pci_dev *pci_scan_single_device(struct pci_bus *bus, int devfn)
 {
 	struct pci_dev *dev;
 
+	dev_info(&bus->dev, "%s %02x\n", __func__, devfn);
 	dev = pci_get_slot(bus, devfn);
 	if (dev) {
 		pci_dev_put(dev);

@@ -1825,6 +1828,7 @@ int pci_scan_slot(struct pci_bus *bus, int devfn)
 	unsigned fn, nr = 0;
 	struct pci_dev *dev;
 
+	dev_info(&bus->dev, "%s %02x\n", __func__, devfn);
 	if (only_one_child(bus) && (devfn > 0))
 		return 0; /* Already scanned the entire slot */
 

Quoted 9 lines · Bjorn Helgaas

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)

Quoted 3 lines

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.

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.

Quoted 10 lines · Richard F

Quoted 9 lines · Bjorn Helgaas

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)

Quoted 6 lines

Quoted 3 lines

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.

Quoted 6 lines

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

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.

Quoted 61 lines · Richard F

Quoted 10 lines · Bjorn Helgaas

Quoted 9 lines · Richard F

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)

Quoted 6 lines

Quoted 3 lines

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.

Quoted 6 lines

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

Quoted 8 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

You should be able to tell whether Windows sees the BT878 even without drivers. I think there might be something in Device Manager, or you can use a tool like AIDA64 (there was a free trial version last I checked).

Quoted 2 lines

Is there's something needing configuring in that Hint HB6/PCI6140 bridge?

I can't think of anything, but that does seem like the most likely explanation.

Quoted 2 lines

When working, it loads the shpchp module, and it does advertise itself as "non transparent" mode.

I see "Hint Corp HB6 Universal PCI-PCI bridge (non-transparent mode)" in both lspci outputs. Is that what you mean, or do you see a difference somewhere else? It looks like that string is just looked up from the device ID; it's not influenced by anything the kernel does.

Quoted 3 lines

The other difference is a latency of
64 in the working scenario, 32 when not. Not configurable on the AMI BIOS unfortunately.

I did notice the shpchp and latency timer differences, but I couldn't figure out how they could possibly be related. But it certainly wouldn't hurt to enable shpchp in your kernel and see if it makes a difference.

I can't figure out how the latency timer could be involved either, but you can try fiddling with it, e.g., set it to 64:

  # setpci -s04:01.0 0x0d.b=0x40
  # echo 1 > /sys/bus/pci/rescan

On 1/02/2016 23:35, Bjorn Helgaas wrote:
---

Quoted 5 lines

You should be able to tell whether Windows sees the BT878 even without drivers. I think there might be something in Device Manager, or you can use a tool like AIDA64 (there was a free trial version last I checked).

I ran up AIDA64. The Hint device was recognised as something slightly different. It also didn't list anything behind the bridge - same issue. Not sure if the Subsystem ID of 0000 is an issue.

[ HiNT HB1-SE33 PCI-PCI Bridge ]

Device Properties:
Device Description HiNT HB1-SE33 PCI-PCI Bridge
Bus Type PCI
Bus / Device / Function 4 / 1 / 0
Device ID 3388-0021
Subsystem ID 0000-0000
Device Class 0604 (PCI/PCI Bridge)
Revision 11
Fast Back-to-Back Transactions
Supported, Disabled

Device Features:
66 MHz Operation Not Supported
Bus Mastering Enabled

The IT8893 similarly listed:

[ ITE IT8893 PCI Bridge ]

Device Properties:
Device Description ITE IT8893 PCI Bridge
Bus Type PCI
Bus / Device / Function 3 / 0 / 0
Device ID 1283-8893
Subsystem ID 0000-0000
Device Class 0604 (PCI/PCI Bridge)
Revision 10
Fast Back-to-Back Transactions Not Supported

Device Features:
66 MHz Operation Not Supported

Quoted 24 lines

Quoted 2 lines

Is there's something needing configuring in that Hint HB6/PCI6140 bridge?

I can't think of anything, but that does seem like the most likely explanation.

Quoted 2 lines

When working, it loads the shpchp module, and it does advertise itself as "non transparent" mode.

I see "Hint Corp HB6 Universal PCI-PCI bridge (non-transparent mode)" in both lspci outputs. Is that what you mean, or do you see a difference somewhere else? It looks like that string is just looked up from the device ID; it's not influenced by anything the kernel does.

Quoted 3 lines

The other difference is a latency of
64 in the working scenario, 32 when not. Not configurable on the AMI BIOS unfortunately.

I did notice the shpchp and latency timer differences, but I couldn't figure out how they could possibly be related. But it certainly wouldn't hurt to enable shpchp in your kernel and see if it makes a difference.

Quoted 5 lines

I can't figure out how the latency timer could be involved either, but you can try fiddling with it, e.g., set it to 64:

  # setpci -s04:01.0 0x0d.b=0x40
  # echo 1 > /sys/bus/pci/rescan

The shpchp module was already in the kernel config, but not used. rmmoding and modprobing again doesn't appear to help.

I tried the above setpci and rescan, but that didn't do anything new.

Must be a broken BIOS somehow masking the bridge - are we at a dead end?