Description of problem: Machine would hang after resuming from standby until a timeout reached and then resume normally allowing to login (GDM/Gnome). I initially thought Gnome Shell or GDM would crash (issue report [1]). After understanding the logs with help of Gnome Discourse ([2]), I figured fprintd is responsible for the hang. My Thinkpad T450s comes without a fingerprint reader. frpintd blocks and delaysthe login Once removed, the system would not hang a second after resuming from standby. Removed fprintd-1.94.1-1.fc35.x86_64 @@System Removed fprintd-pam-1.94.1-1.fc35.x86_64 @@System Removed libfprint-1.94.2-1.fc35.x86_64 @@System [1]: https://gitlab.gnome.org/GNOME/gdm/-/issues/730 [2]: https://discourse.gnome.org/t/looking-for-help-debugging-and-reporting-a-bug/8775/5 Version-Release number of selected component (if applicable): fprintd-1.94.1-1.fc35.x86_64 gnome-shell-41.3-1.fc35.x86_64 Steps to Reproduce: install f35 on 450s, update the system (or leave it), close the lid, open the lid, wakeup and then wait 30 secs before login or any tty is available. Actual results: Close lid, open lid, wake-up, wait, wait, login Expected results: Close lid sleep, Open lid, wakeup, login
Here is a snippet from the journal, please let me know if you need further logs. ```` Jan 28 10:27:46 fedora audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=fprintd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Jan 28 10:31:23 fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=fprintd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Jan 28 10:31:23 fedora fprintd[3419]: libusb: error [udev_hotplug_event] ignoring udev action change Jan 28 10:31:23 fedora fprintd[3419]: libusb: error [udev_hotplug_event] ignoring udev action change Jan 28 10:31:23 fedora fprintd[3419]: libusb: error [udev_hotplug_event] ignoring udev action change Jan 28 10:31:23 fedora fprintd[3419]: libusb: error [udev_hotplug_event] ignoring udev action unbind Jan 28 10:31:23 fedora fprintd[3419]: libusb: error [udev_hotplug_event] ignoring udev action change Jan 28 10:31:23 fedora fprintd[3419]: libusb: error [udev_hotplug_event] ignoring udev action unbind Jan 28 10:31:23 fedora fprintd[3419]: libusb: error [udev_hotplug_event] ignoring udev action change Jan 28 10:31:53 fedora systemd[1]: fprintd.service: Deactivated successfully. ````
This will be btusb hanging again during firmware load. Marking as duplicate, please reopen if you can rule out that cause. *** This bug has been marked as a duplicate of bug 2019857 ***
So, double checking the log file, I only see timeouts from USB 2-4, which seems to be the wwan modem (with a button, I guess, as there is a usbhid device for it). The timestamps are odd though, so not entirely sure. So, I would suggest blacklisting btusb for a start, to confirm/rule out bug 2019857. Then, you could try blacklisting cdc_wdm, cdc_acm, cdc_mbim to see if that helps (not sure which one is the relevant one here). You can do that by adding a file to /etc/modprobe.d/disabled.conf or similar and just adding a row for each reading "blacklist btusb" and similar. After that, it is a good idea to run "dracut -f" and reboot.
Hi, I ran into a similar problem with Fedora 37 and a Lenovo ThinkPad T14s Gen 1, model 20UJS00K00. After resuming the gnome-shell hangs because of fprintd and I was able to track this down to usb device enumeration hanging on reading the "descriptors" sysfs file. Calls to lsusb also hang on the same file. I'm using the latest kernel: > Linux jbu-laptop 5.19.16-301.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Oct 21 15:55:37 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux Here is the backtrace from the hanging usb read: > (gdb) bt > #0 0x00007ffff7e77fac in read () from /lib64/libc.so.6 > #1 0x00007ffff7f90885 in read (__nbytes=256, __buf=<optimized out>, __fd=8) at /usr/include/bits/unistd.h:38 > #2 initialize_device (dev=dev@entry=0x5555555a87c0, busnum=busnum@entry=4 '\004', devaddr=devaddr@entry=1 '\001', sysfs_dir=sysfs_dir@entry=0x5555555a87a0 "usb4", wrapped_fd=wrapped_fd@entry=-1) at os/linux_usbfs.c:967 > #3 0x00007ffff7f92989 in linux_enumerate_device (ctx=0x55555559f610, busnum=<optimized out>, devaddr=<optimized out>, sysfs_dir=0x5555555a87a0 "usb4") at os/linux_usbfs.c:1117 > #4 0x00007ffff7f93115 in linux_udev_scan_devices (ctx=0x55555559f610) at os/linux_udev.c:299 > #5 linux_scan_devices (ctx=0x55555559f610) at os/linux_usbfs.c:458 > #6 op_init (ctx=ctx@entry=0x55555559f610) at os/linux_usbfs.c:410 > #7 0x00007ffff7f93e79 in libusb_init (ctx=ctx@entry=0x7fffffffe138) at /usr/src/debug/libusb1-1.0.25-9.fc37.x86_64/libusb/core.c:2353 > #8 0x0000555555565e23 in main (argc=<optimized out>, argv=0x7fffffffe398) at /usr/src/debug/usbutils-014-3.fc37.x86_64/lsusb.c:3895 USB4 seems to be the integrated card reader: > [root@jbu-laptop ~]# lsusb > Bus 007 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub > Bus 006 Device 003: ID 8087:0029 Intel Corp. AX200 Bluetooth > Bus 006 Device 002: ID 06cb:00bd Synaptics, Inc. Prometheus MIS Touch Fingerprint Reader > Bus 006 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub > Bus 004 Device 002: ID 058f:9540 Alcor Micro Corp. AU9540 Smartcard Reader > Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub > Bus 002 Device 002: ID 13d3:5405 IMC Networks Integrated Camera > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub The repoduction is not that easy and I'm not able to reliably reproduce the issue mostly it works if I do the following: 1. Connect to docking station with Monitors, Headset and webcam attached 2. Suspend while connected to the docking station 3. Disconnect from the docking station 4. Resume while disconnected from the docking station Please let me know if you need any further logs I can gather them if the next hang occures.