Bug 2048819 - Resume from suspends hangs until a timeout reached (GDM/Gnome). removed fprintd = OK
Summary: Resume from suspends hangs until a timeout reached (GDM/Gnome). removed fprin...
Keywords:
Status: CLOSED DUPLICATE of bug 2019857
Alias: None
Product: Fedora
Classification: Fedora
Component: fprintd
Version: 35
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Benjamin Berg
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-01-31 22:20 UTC by Flo H.
Modified: 2022-10-28 16:48 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2022-02-01 09:09:38 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Flo H. 2022-01-31 22:20:34 UTC
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

Comment 1 Flo H. 2022-01-31 22:23:39 UTC
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.

````

Comment 2 Benjamin Berg 2022-02-01 09:09:38 UTC
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 ***

Comment 3 Benjamin Berg 2022-02-01 10:33:30 UTC
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.

Comment 4 Jan Burgmeier 2022-10-28 16:48:58 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.