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 Semiconductore111  PI7C9X111SL PCIe-to-PCI Reversible BridgeRegardless, 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/LinuxAdded 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 -xxxI 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 ff10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffa0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffb0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffc0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffd0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffe0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff fff0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffMy 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 -xxxI 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 0010: 00 00 00 00 00 00 00 00 00 00 00 00 01 01 a0 0220: 00 00 00 00 01 00 01 00 00 00 00 00 00 00 00 0030: 00 00 00 00 80 00 00 00 00 00 00 00 00 01 00 0040: 20 00 20 09 00 00 00 00 1f 80 40 00 00 00 00 0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0060: 00 00 00 00 00 00 00 00 00 08 00 b8 00 00 00 0070: 80 00 00 00 00 00 00 00 00 00 00 d0 00 00 00 0080: 07 90 00 00 f8 ff 00 00 10 00 10 00 10 00 10 0090: 01 a8 43 c8 00 00 00 00 00 00 00 00 00 00 00 00a0: 04 b0 00 00 ff ff ff ff ff ff ff ff ff ff ff ffb0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffc0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffd0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffe0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff fff0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffIf 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?
Installing a PCIe-to-PCI Reversible Bridge under Debian results in unclassified device
debian;pci