Bug 1720876

Created attachment 1581062 [details]
lspci verbose output

Description of problem:

On boot, the following message appears when trying to start a udev service that takes almost a minute and then finally gives up:

"A start job is running for udev Wait for complete device initialization"

This is even present when running the vanilla live-cd. Looking at the systemd logs of my installation I do see some hardware errors:


Jun 15 13:59:57 hadron-air kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.UBTC.RUCC], AE_NOT_FOUND (20190215/psargs-330)
Jun 15 13:59:57 hadron-air kernel: ACPI Error: Aborting method \_SB.PCI0.XHC.RHUB.HS01._PLD due to previous error (AE_NOT_FOUND) (20190215/psparse-529)


Jun 15 13:59:57 hadron-air kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.UBTC.RUCC], AE_NOT_FOUND (20190215/psargs-330)
Jun 15 13:59:57 hadron-air kernel: ACPI Error: Aborting method \_SB.PCI0.XHC.RHUB.SS01._PLD due to previous error (AE_NOT_FOUND) (20190215/psparse-529)
Jun 15 13:59:57 hadron-air kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.UBTC.RUCC], AE_NOT_FOUND (20190215/psargs-330)
Jun 15 13:59:57 hadron-air kernel: ACPI Error: Aborting method \_SB.PCI0.XHC.RHUB.SS02._PLD due to previous error (AE_NOT_FOUND) (20190215/psparse-529)

Jun 15 14:00:00 hadron-air systemd-udevd[743]: GOTO 'libsane_rules_end' has no matching label in: '/etc/udev/rules.d/S99-2000S1.rules

Jun 15 14:00:00 hadron-air kernel: iTCO_wdt iTCO_wdt: can't request region for resource [mem 0x00c5fffc-0x00c5ffff]

Jun 15 14:00:02 hadron-air kernel: iwlwifi 0000:00:14.3: BIOS contains WGDS but no WRDS

Jun 15 14:01:41 hadron-air kernel: ucsi_ccg 0-0008: failed to reset PPM!
Jun 15 14:01:41 hadron-air kernel: ucsi_ccg 0-0008: PPM init failed (-110)


However, after ruling out disks and wifi by disabling them through the BIOS I finally removed my GTX 1660 ti nvidia card and the system loaded up fast.

I ran the live-cd again since the problem is there too and found this:

Jun 16 05:40:49 localhost kernel: nouveau 0000:01:00.0: unknown chipset (168000a1)
Jun 16 05:40:49 localhost kernel: nouveau: probe of 0000:01:00.0 failed with error -12

So my guess is that the specific TU116 chip which is the one in my GPU is not yet detected by the bundled nouveau driver version. The resolution when running the livecd is actually very low, like 1024 and it cannot be changed so it fallbacks to the VESA driver.

I'm not sure but maybe the udev-settle service fires up before the proprietary nvidia driver is loaded? 

Version-Release number of selected component (if applicable):

Name         : systemd-udev
Version      : 241
Release      : 8.git9ef65cb.fc30
Architecture : x86_64


How reproducible:

Every time.


Steps to Reproduce:
1. Install any Turing based card
2. Turn on the computer

Actual results:
Long wait time for udev-settle-service to finish


Expected results:
Less time


Additional info:

My current hardware:

 - EVGA H370 motherboard
 - Intel i7-8700 CPU
 - Corsair 32GB RAM, 2666mhz
 - Kingson SATA-III SSD, 240GB (Fedora install)
 - Samsung 850 EVO - 500GB - M.2 SATA III (Windows 10 install)
 - EVGA GeForce GTX 1660ti, 6GB DDR6
 - And the usual usb keyboard, mice, etc.

I'm attaching the output of systemd-analyze blame, systemd-analyze critical-chain and the graphical plot, with /etc/udev/udev.conf flag udev_log=debug

Also attached the output of lspci -vv

This issue seems to be present on other distributions, I did googled before creating this ticket but the only fedora-related one was lost with the migration of askfedora it seems, here's a list of similar:

https://www.cipheronic.com/systemd-udev-settle-service-hangs-on-fedora-28/
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786942
https://bbs.archlinux.org/viewtopic.php?id=189106


What I did to double-check was to mask the systemd-udev-settle service and the boot time goes back to "normal" but I understand that is not a proper fix, especially if using LVM disk scheme (which I'm using) so I turned it back on. I did not notice any problems when disabling the service but I don't want to have any issues down the road.

Also, tried the latest Ubuntu 19.04 Live CD as well, and I did not experienced that issue.

Let me know if you need further information.