Re: Userspace enumeration hang while btusb tries to load firmware of removed device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Nov 03, 2021 at 03:55:31PM +0100, Benjamin Berg wrote:
> Hi,
> 
> a user is seeing a hang in fprintd while enumerating devices which
> appears to be caused by an interaction of:
> 
> * system is resuming from S3
> * btusb starts loading firmware
> * bluetooth device disappears (probably thinkpad_acpi rfkill)
> * libusb enumerates USB devices (fprintd in this case)
> 
> When this happens, the firmware load fails after a timeout of 10s. It
> appears that if userspace queries information about the root hub in
> question during this time, it will hang until the btusb firmware load
> has timed out.
> 
> Attaching the full kernel log, below an excerpt, you can see:
>  * At :12 device removal: "usb 5-4: USB disconnect, device number 33"
>  * libusb enumeration retrieves information about the usb5 root hub,
>    and blocks on this
>  * At :14 there is a tx timeout on hci0
>  * At :23 the firmware load finally fails
>  * Then usb_disable_device happens
>  * libusb/fprintd gets the usb5 HUB information and continues its
>    enumeration
> 
> As I see it, there may be two issues:
> 1. userspace should not block due to the firmware load hanging
> 2. btusb should give up more quickly when the device disappears
> 
> Does anyone have a good idea about the possible cause or how we can fix
> the problem?
> 
> Downstream issue: https://bugzilla.redhat.com/show_bug.cgi?id=2019857

I'm not familiar with the btusb driver, so someone on the 
linux-bluetooth mailing list would have a better idea about this. 
However, it does look as though btusb keeps the device locked during the 
entire 10-second period while it tries to send over the firmware, and it 
doesn't abort the procedure when it starts getting disconnection errors 
but instead persists until a timeout expires.  Keeping the device locked 
would certainly block lsusb.

In general, locking the device during a firmware upload seems like
the right thing to do -- you don't want extraneous transfers from
other processes messing up the firmware!  So overall, it appears that
the whole problem would be solved if the firmware transfer were
aborted as soon as the -ENODEV errors start appearing.

Alan Stern



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux