* Hint HB6 - kernel doesn't see chips behind it.
@ 2016-01-14 21:54 Richard F
2016-01-15 17:26 ` Bjorn Helgaas
0 siblings, 1 reply; 17+ messages in thread
From: Richard F @ 2016-01-14 21:54 UTC (permalink / raw)
To: linux-pci
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
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: Hint HB6 - kernel doesn't see chips behind it. 2016-01-14 21:54 Hint HB6 - kernel doesn't see chips behind it Richard F @ 2016-01-15 17:26 ` Bjorn Helgaas 2016-01-17 21:04 ` Richard F 2016-01-18 14:48 ` Richard F 0 siblings, 2 replies; 17+ messages in thread From: Bjorn Helgaas @ 2016-01-15 17:26 UTC (permalink / raw) To: Richard F; +Cc: linux-pci 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Hint HB6 - kernel doesn't see chips behind it. 2016-01-15 17:26 ` Bjorn Helgaas @ 2016-01-17 21:04 ` Richard F 2016-01-18 14:48 ` Richard F 1 sibling, 0 replies; 17+ messages in thread From: Richard F @ 2016-01-17 21:04 UTC (permalink / raw) To: Bjorn Helgaas; +Cc: linux-pci 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Hint HB6 - kernel doesn't see chips behind it. 2016-01-15 17:26 ` Bjorn Helgaas 2016-01-17 21:04 ` Richard F @ 2016-01-18 14:48 ` Richard F 2016-01-19 3:38 ` Bjorn Helgaas 1 sibling, 1 reply; 17+ messages in thread From: Richard F @ 2016-01-18 14:48 UTC (permalink / raw) To: Bjorn Helgaas; +Cc: linux-pci 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. > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Hint HB6 - kernel doesn't see chips behind it. 2016-01-18 14:48 ` Richard F @ 2016-01-19 3:38 ` Bjorn Helgaas 2016-01-19 10:16 ` Richard F ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Bjorn Helgaas @ 2016-01-19 3:38 UTC (permalink / raw) To: Richard F; +Cc: linux-pci 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Hint HB6 - kernel doesn't see chips behind it. 2016-01-19 3:38 ` Bjorn Helgaas @ 2016-01-19 10:16 ` Richard F 2016-01-19 17:41 ` Richard F 2016-01-27 14:54 ` Richard F 2 siblings, 0 replies; 17+ messages in thread From: Richard F @ 2016-01-19 10:16 UTC (permalink / raw) To: Bjorn Helgaas; +Cc: linux-pci 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Hint HB6 - kernel doesn't see chips behind it. 2016-01-19 3:38 ` Bjorn Helgaas 2016-01-19 10:16 ` Richard F @ 2016-01-19 17:41 ` Richard F 2016-01-27 14:54 ` Richard F 2 siblings, 0 replies; 17+ messages in thread From: Richard F @ 2016-01-19 17:41 UTC (permalink / raw) To: Bjorn Helgaas; +Cc: linux-pci 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. > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Hint HB6 - kernel doesn't see chips behind it. 2016-01-19 3:38 ` Bjorn Helgaas 2016-01-19 10:16 ` Richard F 2016-01-19 17:41 ` Richard F @ 2016-01-27 14:54 ` Richard F 2016-01-27 21:55 ` Bjorn Helgaas 2 siblings, 1 reply; 17+ messages in thread From: Richard F @ 2016-01-27 14:54 UTC (permalink / raw) To: Bjorn Helgaas; +Cc: linux-pci 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 > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Hint HB6 - kernel doesn't see chips behind it. 2016-01-27 14:54 ` Richard F @ 2016-01-27 21:55 ` Bjorn Helgaas 2016-01-28 10:23 ` Richard F 0 siblings, 1 reply; 17+ messages in thread From: Bjorn Helgaas @ 2016-01-27 21:55 UTC (permalink / raw) To: Richard F; +Cc: linux-pci 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Hint HB6 - kernel doesn't see chips behind it. 2016-01-27 21:55 ` Bjorn Helgaas @ 2016-01-28 10:23 ` Richard F 2016-01-29 16:24 ` Bjorn Helgaas 0 siblings, 1 reply; 17+ messages in thread From: Richard F @ 2016-01-28 10:23 UTC (permalink / raw) To: Bjorn Helgaas; +Cc: linux-pci 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? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Hint HB6 - kernel doesn't see chips behind it. 2016-01-28 10:23 ` Richard F @ 2016-01-29 16:24 ` Bjorn Helgaas 2016-01-30 17:54 ` Richard F 0 siblings, 1 reply; 17+ messages in thread From: Bjorn Helgaas @ 2016-01-29 16:24 UTC (permalink / raw) To: Richard F; +Cc: linux-pci 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 */ ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: Hint HB6 - kernel doesn't see chips behind it. 2016-01-29 16:24 ` Bjorn Helgaas @ 2016-01-30 17:54 ` Richard F 2016-02-01 19:06 ` Bjorn Helgaas 0 siblings, 1 reply; 17+ messages in thread From: Richard F @ 2016-01-30 17:54 UTC (permalink / raw) To: Bjorn Helgaas; +Cc: linux-pci 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 */ > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Hint HB6 - kernel doesn't see chips behind it. 2016-01-30 17:54 ` Richard F @ 2016-02-01 19:06 ` Bjorn Helgaas 2016-02-01 20:06 ` Richard F 0 siblings, 1 reply; 17+ messages in thread From: Bjorn Helgaas @ 2016-02-01 19:06 UTC (permalink / raw) To: Richard F; +Cc: linux-pci 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Hint HB6 - kernel doesn't see chips behind it. 2016-02-01 19:06 ` Bjorn Helgaas @ 2016-02-01 20:06 ` Richard F 2016-02-01 23:35 ` Bjorn Helgaas 0 siblings, 1 reply; 17+ messages in thread From: Richard F @ 2016-02-01 20:06 UTC (permalink / raw) To: Bjorn Helgaas; +Cc: linux-pci 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 > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Hint HB6 - kernel doesn't see chips behind it. 2016-02-01 20:06 ` Richard F @ 2016-02-01 23:35 ` Bjorn Helgaas 2016-02-03 13:52 ` Richard F 0 siblings, 1 reply; 17+ messages in thread From: Bjorn Helgaas @ 2016-02-01 23:35 UTC (permalink / raw) To: Richard F; +Cc: linux-pci 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Hint HB6 - kernel doesn't see chips behind it. 2016-02-01 23:35 ` Bjorn Helgaas @ 2016-02-03 13:52 ` Richard F 2016-02-03 15:51 ` Bjorn Helgaas 0 siblings, 1 reply; 17+ messages in thread From: Richard F @ 2016-02-03 13:52 UTC (permalink / raw) To: Bjorn Helgaas; +Cc: linux-pci 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Hint HB6 - kernel doesn't see chips behind it. 2016-02-03 13:52 ` Richard F @ 2016-02-03 15:51 ` Bjorn Helgaas 0 siblings, 0 replies; 17+ messages in thread From: Bjorn Helgaas @ 2016-02-03 15:51 UTC (permalink / raw) To: Richard F; +Cc: linux-pci 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2016-02-03 15:51 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-01-14 21:54 Hint HB6 - kernel doesn't see chips behind it Richard F 2016-01-15 17:26 ` Bjorn Helgaas 2016-01-17 21:04 ` Richard F 2016-01-18 14:48 ` Richard F 2016-01-19 3:38 ` Bjorn Helgaas 2016-01-19 10:16 ` Richard F 2016-01-19 17:41 ` Richard F 2016-01-27 14:54 ` Richard F 2016-01-27 21:55 ` Bjorn Helgaas 2016-01-28 10:23 ` Richard F 2016-01-29 16:24 ` Bjorn Helgaas 2016-01-30 17:54 ` Richard F 2016-02-01 19:06 ` Bjorn Helgaas 2016-02-01 20:06 ` Richard F 2016-02-01 23:35 ` Bjorn Helgaas 2016-02-03 13:52 ` Richard F 2016-02-03 15:51 ` Bjorn Helgaas
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.