Fedora 40 slow after updating packages, eventually hard resets; udev issues?

,

Hi. I recently updated packages for my Fedora 40 KDE machine, and while it worked fine after rebooting for the first time, it’s extremely slow ever since the next reboot. Also, it doesn’t show the usual Fedora plymouth screen, but rather a gray screen with three small squares in the upper left corner. Once the SDDM login screen appears, regardless of what I do, it does a hard reset after about 90 seconds. Even if I do manage to log in from SDDM, it’s very, very slow to load the desktop to the point that I can’t do anything useful before it hard resets.

I did manage to run glances from a TTY after pressing Ctrl+Alt+F3, and it says that (udev-worker) is using 100% of a CPU core. After disabling plymouth and removing quiet to see what’s going on behind it, I see that the machine is busy with this:

Job systemd-udevd.service/stop running (3s / 45s): Shutting down...

Eventually the SDDM login screen appears after it reaches the 45s timeout, but again, it hard resets about 90 seconds after the login screen appears.

I’ve tried disconnecting USB devices so that only the bare minimum (keyboard and mouse) is connected, but that didn’t help.

Kernel is 6.10.12-200.fc40.x86_64, but booting with an older kernel from the GRUB menu didn’t help.

System specs:

  • CPU: AMD Ryzen 9 7900X
  • GPU: AMD Radeon RX 5700 XT
  • RAM: 32GBx2 DDR5-5600 ECC (running at 5200 MT/s)
  • Motherboard: ASRock B650M PG Riptide WiFi
  • Storage: 1TB NVMe boot + 2TB NVMe data

No other operating systems are installed.

So yeah, how should I deal with this?

1 Like

Try booting with out the quiet and rhgb options (edit the grub boot line).
You may see kernel messages that help explain what is going on.

What do you mean by hard-reset? Does the machine go go back though the BIOS boot and grub etc? If so I would be suspecting a hardware issue.

“with out the quiet and rhgb options” is exactly what I already did to even find the “Job systemd-udevd.service/stop running” message. And by hard reset, yeah that’s what I mean, it just restarts as if I pressed the physical reset button.

I should add that using the “Shut Down” button on the SDDM login screen causes it to get stuck at

systemd-shutdown[1]: Waiting for process: 871 (systemd-udevd), 888 ((udev-worker))
systemd-udevd[871]: 0000:6f:00.0: Worker [888] processing SEQNUM=3978 is taking a long time
systemd-shutdown[1]: Sending SIGKILL to remaining processes...
systemd-shutdown[1]: Sending SIGKILL to PID 871 (systemd-udevd).
systemd-shutdown[1]: Sending SIGKILL to PID 888 ((udev-worker)).
systemd-shutdown[1]: Waiting for process: 888 ((udev-worker))
pcieport 0000:6c:06.0: Unable to change power state from D3hot to D0, device inaccessible
mt7921e 0000:6f:00.0: driver own failed
INFO: NMI handler (perf_event_nmi_handler) took too long to run: 188.413 msecs
perf: interrupt took too long (1472091 > 2500), lowering kernel.perf_event_max_sample_rate to 1000

and then instead of shutting down, it does the “hard reset” like I described earlier. “mt7921e” is likely related to the MT7921 Wi-Fi module on the motherboard, so I disabled it from UEFI settings and it seems to have stopped the biggest issues like the massive slowdown and the hard reset after a while. It shuts down normally when I click on the “Shut Down” button in SDDM or Plasma as well. However,

However, the “Job systemd-udevd.service/stop running” still makes boot take a long time, and plymouth still looks different, with the three squares on a gray background. Is there maybe some way I can look for details on what’s making systemd-udevd take so long?

Maybe check that the BIOS is up to date?

Did you check over the journal for a the boot to see what errors udevd reported?

Yeah, there was an update available, so I updated it, but unfortunately neither the resets with the Wi-Fi adapter enabled nor the udev issue on boot were helped by it.

Also, I should note that it seems to take a couple of seconds for the keyboard or mouse to become responsive on the SDDM login screen.

Yep, but I don’t know what to make of it:

$ journalctl -b | grep systemd-udevd
10月 12 00:11:41 gungnir2211 systemd[1]: Listening on systemd-udevd-control.socket - udev Control Socket.
10月 12 00:11:41 gungnir2211 systemd[1]: Listening on systemd-udevd-kernel.socket - udev Kernel Socket.
10月 12 00:11:42 gungnir2211 systemd[1]: Starting systemd-udevd.service - Rule-based Manager for Device Events and Files...
10月 12 00:11:42 gungnir2211 systemd-udevd[567]: Using default interface naming scheme 'v255'.
10月 12 00:11:42 gungnir2211 systemd-udevd[567]: Configuration file /etc/udev/rules.d/65-brother-brscan4-libsane-type1.rules is marked executable. Please remove executable permission bits. Proceeding anyway.
10月 12 00:11:42 gungnir2211 systemd-udevd[567]: /etc/udev/rules.d/65-brother-brscan4-libsane-type1.rules:9 Invalid key 'SYSFS'.
10月 12 00:11:42 gungnir2211 systemd[1]: Started systemd-udevd.service - Rule-based Manager for Device Events and Files.
10月 12 00:11:43 gungnir2211 systemd[1]: Stopping systemd-udevd.service - Rule-based Manager for Device Events and Files...
10月 12 00:12:28 gungnir2211 systemd[1]: systemd-udevd.service: State 'stop-sigterm' timed out. Killing.
10月 12 00:12:28 gungnir2211 systemd[1]: systemd-udevd.service: Killing process 567 (systemd-udevd) with signal SIGKILL.
10月 12 00:12:28 gungnir2211 systemd[1]: systemd-udevd.service: Main process exited, code=killed, status=9/KILL
10月 12 00:12:28 gungnir2211 systemd[1]: systemd-udevd.service: Failed with result 'timeout'.
10月 12 00:12:28 gungnir2211 systemd[1]: Stopped systemd-udevd.service - Rule-based Manager for Device Events and Files.
10月 12 00:12:28 gungnir2211 systemd[1]: systemd-udevd.service: Consumed 2.531s CPU time.
10月 12 00:12:28 gungnir2211 systemd[1]: systemd-udevd-control.socket: Deactivated successfully.
10月 12 00:12:28 gungnir2211 systemd[1]: Closed systemd-udevd-control.socket - udev Control Socket.
10月 12 00:12:28 gungnir2211 systemd[1]: systemd-udevd-kernel.socket: Deactivated successfully.
10月 12 00:12:28 gungnir2211 systemd[1]: Closed systemd-udevd-kernel.socket - udev Kernel Socket.
10月 12 00:12:29 gungnir2211 systemd[1]: Listening on systemd-udevd-control.socket - udev Control Socket.
10月 12 00:12:29 gungnir2211 systemd[1]: Listening on systemd-udevd-kernel.socket - udev Kernel Socket.
10月 12 00:12:29 gungnir2211 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-udevd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
10月 12 00:12:29 gungnir2211 systemd[1]: Starting systemd-udevd.service - Rule-based Manager for Device Events and Files...
10月 12 00:12:29 gungnir2211 systemd-udevd[882]: Using default interface naming scheme 'v255'.
10月 12 00:12:29 gungnir2211 systemd[1]: Started systemd-udevd.service - Rule-based Manager for Device Events and Files.

The errors concerning brscan4 are still there even after uninstalling the brscan4 package. /etc/udev/rules.d/65-brother-brscan4-libsane-type1.rules seems to have been removed with it, but the errors still happen.

You may need to rebuild the initrd to remove all traces of that file.

But I would first boot from a USB live image and see if that is responsive.

If the live image does not work I would suspect a hardware issue.

Looks like you were right that it’s a hardware issue, and it also looks like it was thankfully a temporary issue. I have on hand the Fedora and Debian installers on USB drives. In either case, they took a while with something to do with usb 1-8. I disconnected the machine from AC power for a few minutes, and then after that, it booted just fine. Both the Wi-Fi and Bluetooth parts of the Wi-Fi adapter work fine after enabling it again too.

As for what usb 1-8 is:

$ sudo dmesg | grep 1-8
[    4.167400] usb 1-8: new high-speed USB device number 4 using xhci_hcd
[    4.389202] usb 1-8: New USB device found, idVendor=0e8d, idProduct=0608, bcdDevice= 1.00
[    4.389205] usb 1-8: New USB device strings: Mfr=5, Product=6, SerialNumber=7
[    4.389207] usb 1-8: Product: Wireless_Device
[    4.389208] usb 1-8: Manufacturer: MediaTek Inc.
[    4.389209] usb 1-8: SerialNumber: 000000000

It’s the Bluetooth part of the Wi-Fi adapter. Why am I not surprised? I think something like this happened before on at least one laptop I had in the past, where the Bluetooth was suddenly misbehaving. That was fixed by doing the same thing as this case, which is to fully power cycle the system (disconnect AC adapter then remove battery, or if the battery isn’t removable, hold down the power button for a very long time).

Also, apparently the Bluetooth On/Off option in the UEFI settings doesn’t do anything. It stays on regardless of the setting. :roll_eyes:

Anyways, thanks for your help!

1 Like