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

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

[Richard F]

Hello

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

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

[Bjorn Helgaas]

Hi Richard,

On Thu, Jan 14, 2016 at 09:54:35PM +0000, Richard F wrote:
> 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.

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

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

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

[Richard F]

Bjorn,

I have added the DMESG and lspci logs for different kernels and
motherbaords on that Bugzilla for you.

Not yet been able to build a 4.4 kernel yet - will try shortly.
Appreciate any pointers for further debug.

thanks
Richard

On 15/01/2016 17:26, Bjorn Helgaas wrote:
> 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

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

[Richard F]

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

On 15/01/2016 17:26, Bjorn Helgaas wrote:
> Hi Richard,
> 
> On Thu, Jan 14, 2016 at 09:54:35PM +0000, Richard F wrote:
>> 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.
> 
> 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.
> 

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

[Bjorn Helgaas]

On Mon, Jan 18, 2016 at 02:48:59PM +0000, Richard F wrote:
> 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

> On 15/01/2016 17:26, Bjorn Helgaas wrote:
> > Hi Richard,
> > 
> > On Thu, Jan 14, 2016 at 09:54:35PM +0000, Richard F wrote:
> >> 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.
> > 
> > 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Richard F]

I'll see what I can do to capture the 4.4 crash, and post.
It was quite early in the boot cycle as I recall.

thanks
Richard

On 19/01/2016 03:38, Bjorn Helgaas wrote:
> On Mon, Jan 18, 2016 at 02:48:59PM +0000, Richard F wrote:
>> 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
> 
>> On 15/01/2016 17:26, Bjorn Helgaas wrote:
>>> Hi Richard,
>>>
>>> On Thu, Jan 14, 2016 at 09:54:35PM +0000, Richard F wrote:
>>>> 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.
>>>
>>> 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 majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Richard F]

I rebuilt 4.4.0, as I noticed a warning about microcode in the .config
which I fixed (assumed changed function).  Another DMESG posted here
https://bugzilla.kernel.org/show_bug.cgi?id=110851

Still no joy unfortunately.

thanks
Richard

On 19/01/2016 03:38, Bjorn Helgaas wrote:
> On Mon, Jan 18, 2016 at 02:48:59PM +0000, Richard F wrote:
>> I posted a DMESG with 4.3.3 to Bugzilla now.
>> 4.4.0 crashed on boot, not sure why yet.
> 

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

[Richard F]

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

Thanks
Richard


On 19/01/2016 03:38, Bjorn Helgaas wrote:
> On Mon, Jan 18, 2016 at 02:48:59PM +0000, Richard F wrote:
>> 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
> 

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

[Bjorn Helgaas]

Hi Richard,

On Wed, Jan 27, 2016 at 02:54:25PM +0000, Richard F wrote:
> 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

> On 19/01/2016 03:38, Bjorn Helgaas wrote:
> > On Mon, Jan 18, 2016 at 02:48:59PM +0000, Richard F wrote:
> >> 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
> > 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[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?

Thanks again
Richard

On 27/01/2016 21:55, Bjorn Helgaas wrote:
> Hi Richard,
> 
> On Wed, Jan 27, 2016 at 02:54:25PM +0000, Richard F wrote:
>> 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?

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

[Bjorn Helgaas]

On Thu, Jan 28, 2016 at 10:23:03AM +0000, Richard F wrote:
> 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?

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 6d7ab9b..f6d8e85 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -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 */
 

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

[Richard F]

On 29/01/2016 16:24, Bjorn Helgaas wrote:
> On Thu, Jan 28, 2016 at 10:23:03AM +0000, Richard F wrote:
>> 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?

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.

pci=pcie_scan_all didn't yield anything new, as you expected.

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 also tried pci=reouteirq and posted the result, that also didn't help.

Please let me know if there's anything else I can try. The AMI BIOS
doesn't have any setup parameters for the PCI/e.

Thanks
Richard


> 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?
> 
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 6d7ab9b..f6d8e85 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -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 */
>  

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

[Bjorn Helgaas]

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

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

[Richard F]

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
> 

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

[Bjorn Helgaas]

On Mon, Feb 01, 2016 at 08:06:51PM +0000, Richard F wrote:
> 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.   

Interesting.  That makes you think there's some bridge init
difference.

> 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.

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).

> 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.

> 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.

> 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

You can also use "lspci -vvv -s04:01.0" and compare with the working
system and see if there are other differences.  I think AIDA64 will
also dump that config space, so you might be able to compare with
with what Windows XP does, too.

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

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

[Richard F]

On 1/02/2016 23:35, Bjorn Helgaas wrote:
---
> 
> 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


>> 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.
> 
>> 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.
> 
>> 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

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?

Thanks
Richard

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

[Bjorn Helgaas]

On Wed, Feb 03, 2016 at 01:52:42PM +0000, Richard F wrote:
> On 1/02/2016 23:35, Bjorn Helgaas wrote:
> ---
> > 
> > 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.

I don't think the Subsystem ID is relevant.

> [ 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
> 
> 
> >> 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.
> > 
> >> 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.
> > 
> >> 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
> 
> 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?

I mentioned "lspci -vvv" before, but I meant "lspci -xxx": that will
show you the whole config space.  You could compare them between the
working and non-working machines.  I think the Hint bridge is the
important device.

The BIOS isn't directly involved when we're enumerating devices.  It
may have done setup earlier that affects how the hardware works, but
it doesn't have a chance to intervene when we do config reads to find
devices.  So if the BIOS configured something in the bridge that
causes this problem, the "lspci -xxx" should show it.

Other than that, I don't have any other ideas.

Bjorn