this commit addresses the same issue that as commit 1af45804 does. the following message is copying from that commit: If we find ourselves in the situation that the 'add' uevent has been fired earlier than the sysfs tree for a device was created, we should use the best-effort approach and give kernel some predetermined amount of time, thus waiting for the attributes to be ready rather than discarding the device from our device list forever. If those don't appear in the given time frame, we need to move on, since libvirt can't wait indefinitely. Signed-off-by: Guoyi Tu <tugy@chinatelecom.cn> --- src/node_device/node_device_udev.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 1d8486f623..4a1786c21c 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -427,10 +427,19 @@ udevProcessPCI(virNodeDeviceDriverState *driver_state, virPCIEDeviceInfo *pci_express = NULL; virPCIDevice *pciDev = NULL; virPCIDeviceAddress devAddr = { 0 }; + g_autofree char *linkpath = NULL; int ret = -1; char *p; bool privileged = false; + linkpath = g_strdup_printf("%s/config", udev_device_get_syspath(device)); + if (virFileWaitForExists(linkpath, 10, 100) < 0) { + virReportSystemError(errno, + _("failed to wait for file '%1$s' to appear"), + linkpath); + goto cleanup; + } + VIR_WITH_MUTEX_LOCK_GUARD(&driver_state->lock) { privileged = driver_state->privileged; } -- 2.27.0 -- Guoyi