How to force kernel to re-read/re-initialize PCI device IDs?

3
votes

My machine (running Linux kernel 3.2.38) on boot has wrong subsystem IDs (sub-device and sub-vendor IDs) of a PCI device. If I then physically unplug and re-plug the PCI device while the system is still up (i.e., hot-plug), it gets the correct IDs.

Note that the wrong sub-device and sub-vendor IDs it gets are same as the device's device and vendor IDs (see the first two lines in the lspci output below).

Following is the output of lspci -vvnn before and after hot-plugging the device:

Before hot-plugging:

0b:0f.0 Bridge [0680]: Device [1a88:4d45] (rev 05)
Subsystem: Device [1a88:4d45]
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 (250ns min, 63750ns max)
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at 2100 [size=256]
Region 1: I/O ports at 2000 [size=256]
Region 2: Memory at 92920000 (32-bit, non-prefetchable) [size=64]

After hot-plugging:

0b:0f.0 Bridge [0680]: Device [1a88:4d45] (rev 05)
Subsystem: Device [007d:5a14]
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-
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at 2100 [disabled] [size=256]
Region 1: I/O ports at 2000 [disabled] [size=256]
Region 2: [virtual] Memory at 92920000 (32-bit, non-prefetchable) [size=64]

My question: Is there a way to get the IDs fixed without hot-plugging the device? e.g. forcing kernel to re-read PCI device IDs e.g. by performing a PCI bus rescan/re-enumeration/re-configuration?

Any help would be highly appreciated. Thanks.

PS. Note that the problem isn't really related to kernel/software as it exists even if boot into UEFI internal shell.

PPS. The PCI device in this case is MEN F206N and "My machine" is MEN F22P

2
linuxpcipci-epci-bus
Do you know what happens when the system boots with the device plugged in? Does it have the correct vendor id at that point? – vivekian2
I would suggest that you look at the source code for the MEN F206N driver and see what it does in the _init (bootup) and _devinit (hotplug) hooks. It would be good to see if there is a difference in the implementation. – vivekian2
You should definitely try to get in touch with the MEN customer engineers or report this as a bug. Also, just on a side note, do try this out on 2 different x86 systems to make sure that the issue does indeed replicate. – vivekian2
I have tried it on three different systems. Same result :-) And yes I have already contacted MEN people too, they said they will look into it. But I am not expecting a fast response from them. – Jahanzeb Farooq
If the IDs are wrong at boot time, that points to a problem with the F206N card. I see it is an FPGA-based board. This smells like an FPGA loading/configuration issue. The hotplug/rescan would simply a bandaid on the "real" issue, and I would be hesitant to ship a production system with it. The vendor should be willing to work with you to fix it. – myron-semack

2 Answers

4
votes

You may forcefully rescan the PCI by :

# echo 1 > /sys/bus/pci/rescan

1
votes

A closer look at your lscpi output before and after hot plugging the device shows more delta than just the sub device/vendor ID. I'd be surprised if the device functions as expected after hot plugging.

Besides, forcing PCI reenumeration is not possible primarily because there may be other devices that have been enumerated correctly and functioning already. How do you expect reenumeration to deal with that? (and there are other reasons too.)

Prafulla