2

I have installed a PCIe-to-PCI Reversible Bridge which uses a Pericom Semiconductor PI7C9X111SL chip into a Debian computer. This PCIe card hosts 2 new PCI card slots. The PCI ID for this bridge appears to be 12d8:e111. These are ("Pericom", "PI7C9X111SL", "12d8" & "e111") are all listed in the Linux PCI text-file:

/usr/share/misc/pci.ids 

As:

12d8  Pericom Semiconductor
e111  PI7C9X111SL PCIe-to-PCI Reversible Bridge

Regardless, I see the following line when I type "lspci -knn":

04:00.0 Non-VGA unclassified device [0000]: Pericom Semiconductor PI7C9X111SL PCIe-to-PCI Reversible Bridge [12d8:e111] (rev 02)

So it would appear that Debian does not know what to do with this PCIe card. I can not think of my next move. All the Debian package on this computer are are up to date. I'm running Debian 9.0 and "uname -a" gives:

Linux ##### 4.9.0-1-amd64 #1 SMP Debian 4.9.6-3 (2017-01-28) x86_64 GNU/Linux

Added later...

I found this related log in dmesg after booting up the Debian computer:

[    0.220250] pci 0000:03:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[    0.220256] pci 0000:00:0c.0: PCI bridge to [bus 03]
[    0.220258] pci 0000:00:0c.0:   bridge window [io  0xa000-0xafff]
[    0.220260] pci 0000:00:0c.0:   bridge window [mem 0xfde00000-0xfdefffff]
[    0.220262] pci 0000:00:0c.0:   bridge window [mem 0xfdd00000-0xfddfffff 64bit pref]
[    0.224007] pci 0000:04:00.0: [12d8:e111] type 01 class 0xffffff
[    0.224011] pci 0000:04:00.0: ignoring class 0xffffff (doesn't match header type 01)

Added later, using this command:

lspci -s 04:00.0 -xxx

I get this response:

04:00.0 Non-VGA unclassified device: Pericom Semiconductor PI7C9X111SL PCIe-to-PCI Reversible Bridge (rev ff)
00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

My assumption is that the board manufacture did not program the chip properly (as in "not programming it at all"). I am not sure if the "class" is found in the above data. And if it is where it is in the above data. But given the class and above data are all 0xff's it does look to be incriminating.

Odd unexpected behavior (once figured out, I will try to edit down this question).

If I repeat the command:

lspci -s 04:00.0 -xxx

I am getting back different results. Maybe the command (or the PCI bridge) is cycling through different pages of EEPROM memory each 256 bytes long? That seems unlikely. Or, perhaps, reading the EEPROM is not dependable. And the failure mode is to read back 0xff. That makes more sense. And if I read back the EEPROM enough I eventually hit upon a sizable response:

04:00.0 Non-VGA unclassified device: Pericom Semiconductor PI7C9X111SL PCIe-to-PCI Reversible Bridge (rev 02)
00: d8 12 11 e1 00 00 10 00 02 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 01 01 a0 02
20: 00 00 00 00 01 00 01 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 00 01 00 00
40: 20 00 20 09 00 00 00 00 1f 80 40 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 08 00 b8 00 00 00 00
70: 80 00 00 00 00 00 00 00 00 00 00 d0 00 00 00 00
80: 07 90 00 00 f8 ff 00 00 10 00 10 00 10 00 10 00
90: 01 a8 43 c8 00 00 00 00 00 00 00 00 00 00 00 00
a0: 04 b0 00 00 ff ff ff ff ff ff ff ff ff ff ff ff
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

If true, reading the EEPROM is undependable, other communications with the Pericom chip may be in question. To test this I am now wondering what might be done to mitigate the problem? Perhaps slowing down / changing the PCIe bus clocks, if that is even possible?

  • Do you have any cards connected to the PCI slots? Are they detected? – Stephen Kitt Feb 14 '17 at 7:26
  • BTW, your successful read has the correct class (position 08-0b). So it's definitely a failure in reading the config space that causes the problem, and not an uninitialized EEPROM. – dirkt Feb 14 '17 at 14:51
3

Partial answer: I can tell you what goes wrong, but I'm not sure how to fix it.

Grepping the error message in the Linux kernel source leads to drivers/pci/probe.c, which requires a PCI of card PCI_HEADER_TYPE_BRIDGE (1) to have class PCI_CLASS_BRIDGE_PCI (0x0604). But your PCI card has class 0xffff (i.e., the class was not set properly by the manufacturer/reseller), so the driver decides that something is fishy and it would rather not use this bridge. And if the bridge isn't initialized by a proper driver, of course you won't see any cards behind it.

Ways around that are either (1) patch the kernel to make an exception for your card, or (2) give the card its proper class.

Googling finds a datasheet of the chip here, so in principle we have all the information we need to fix it. The section about the configuration register map (6.1) says this data is stored in an EEPROM, with the following notes for I2C resp. SMBUS access:

Note 1: When masquerade is enabled, it is pre-loadable.
Note 2: The VPD data is read/write through I2C during VPD operation.

So in it must be possible to somehow overwrite these values. Section 10 has more details on that, but the question is if the I2C/SMBus is connected somewhere in the first place - as it's on a PCIe card, probably not. However, looking at section 6.3.91/92, it looks one can write the EEPROM via the VPD register. Figuring out how to do that exactly needs some more work, and possibly a self-written C program.

Edit: Looks like there's a file vpd in /sys/ which can be used for write access of this kind. Please have a look if /sys/bus/pci/devices/0000:04:00.0/ exists and has a file called vpd somewhere, or if this is also missing because of the wrong class. If such a file exist, please do an hexdump -C on it, and edit your question with the results.

Anyway, before doing that, one should look at the rest of the configuration space values. You can do that with lspci -s 04:00.0 -x, and lspci -s 04:00.0 -xxx for the full dump. (There's a cavet about using -xxx in the lspci man-page that it may crash on non-conformant cards, but give it a try). So edit your question with the results. In this way, one should see if the class is the only value that needs fixing, or if there are more.

  • There was no file /sys/bus/pci/devices/0000:04:00.0/vpd. I am left wondering if Windows will also fail to recognize this card. This is very interesting. However, I am disappointed in the manufacturer. Thank you for you help. – st2000 Feb 14 '17 at 13:25
  • I have no idea if Windows would recognize it as a bridge, even if the class is wrong. If the EEPROM/configuration space reading is buggy in the first place, it probably won't work on Windows. If you can verify that EEPROM/configuration space reading sometimes works and sometimes doesn't, I'd contact the manufacturer and ask for a replacement, because then the hardware is probably defective. – dirkt Feb 14 '17 at 14:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.