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

[Bjorn Helgaas <helgaas@kernel.org>]

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