PCI Timeout Errors

The following information applies to PCI Express cards as well as to legacy PCI-X and PCI cards, and in principle also to Meinberg USB devices.

PCI cards are usually identified by a by a registered PCI vendor ID which is 1360h for Meinberg, and a PCI device ID which is specific to a particular Meinberg PCI card, and has been assigned by Meinberg. Similarly, USB devices are identified by a well-known Meinberg USB vendor ID which is 1938h, and USB device IDs that have been assigned by Meinberg.

The vendor and device IDs are built into the devices, and even without any specific driver for the device being installed, the operating system can read those IDs as soon as a PCI card is inserted into a PCI slot, or a USB device is connected to a USB port.

On Windows, when a driver package is installed, the included .inf file tells Windows which combinations of vendor and device ID the kernel driver should support.

On Linux there is no .inf file, but when the kernel driver is manually loaded for the first time, the driver reports to the OS which vendor / device ID combinations it supports, and the Linux system remembers those combinations.

So whenever these operating systems detected a supported device, the associated driver is usually loaded automatically.

On other operating systems, the driver may generally need to be loaded manually when the system boots. How this needs to be done depends on the particular operating system.

Further handling is the same on all operating systems.

When the driver is loaded, the driver's probe routine is called for the device, and only if the probe routine succeeds, the driver is ready to be used to access the hardware device. If the probe routine fails, the device is unusable and the driver is usually unloaded.

The probe routine of the kernel drivers included in Meinberg driver packages first try to read firmware ID, device features, etc. from the device to be probed.

This usually requires communications with the microcontroller on the PCI card or USB device, and if that fails for some reason, the probe routine returns an error.

On most systems, devices can be disabled and enabled manually.

On Windows this can be done in the device manager, by right-clicking on a device and selecting Disable or Enable from the context menu. This results in unloading or loading the kernel driver, respectively.

On Linux and other operating systems this can be done by running specific commands to unload or load the kernel driver module.

When the kernel driver is unloaded, the device becomes unusable to applications.

When the driver is loaded, the probe routine is called, and the device becomes usable (again) if the probe routine succeeds.

Whenever the kernel driver is loaded and the probe routine is called but the microcontroller doesn't respond, the probe routine returns a timeout error and the driver software fails to load for the device that timed out.

Since the driver has not been loaded, an application trying to detect and communicate with the device usually just says, “No device found”, or the device is simply not listed in a device list presented by the application.

Under certain conditions it can happen that the driver software has been loaded properly, and applications randomly report error -20 (timeout) during operation. In this case the microcontroller on-board the PCI card could be accessed properly when the driver was loaded and the probe routine was called, but suddenly or temporarily fails to respond to when the kernel driver tries to communicate with it.

On Windows, corresponding log entries are added to the Windows application event log, which can be reviewed with the Windows Event Viewer application.

On Unix-like systems, there are associated entries in the dmesg output, if this happens.

In the past there have been rare occasions where a PCI card could be pulled out of its slot a little bit when the card was fixed in its slot by a screw or similar. As a consequence, not all contact strips in the slot connector were met by the associated contact strips of the PCI card. This could even result in a loose connection, so access to the card could be inhibited totally or only temporarily.

So a first check could be to see if the PCI card sits in its slot properly, or not.

Very old driver software accessed the PCI card in a way that may not be appropriate for the latest CPUs and/or chip sets. This has been improved in current versions of the driver package, so updating the driver software package may help.

If the card is assembled properly and the current driver software is used, but the problem still persists, the reason is probably a hardware problem on the PCI card, i.e. one of the chips on the card is defective, the soldering is not or no more correct, etc. In this case the only chance is to send the card back to the factory for repair, or replace it.

— Martin Burnicki martin.burnicki@meinberg.de, last updated 2023-07-26