Re: Deadlock in usb subsystem on shutdown, 6.18.3+

[Oliver Neukum <oneukum@suse.com>]

On 14.01.26 20:26, Alan Stern wrote:
> On Wed, Jan 14, 2026 at 09:51:48AM -0800, Ben Greear wrote:
>> On 1/14/26 07:13, Alan Stern wrote:
> ...
>>>>>> task:kworker/4:2     state:D stack:0     pid:1520  tgid:1520  ppid:2      task_flags:0x4288060 flags:0x00080000
>>>>>> Workqueue: events __usb_queue_reset_device
>>>>>> Call Trace:
>>>>>>      <TASK>
>>>>>>      __schedule+0x46b/0x1140
>>>>>>      ? schedule_timeout+0x79/0xf0
>>>>>>      schedule+0x23/0xc0
>>>>>>      usb_kill_urb+0x7b/0xc0
>>>>>>      ? housekeeping_affine+0x30/0x30
>>>>>>      usb_start_wait_urb+0xd6/0x160
>>>>>>      usb_control_msg+0xe2/0x140
>>>>>>      hub_port_init+0x647/0xf70
>>>>>>      usb_reset_and_verify_device+0x191/0x4a0
>>>>>>      ? device_release_driver_internal+0x4a/0x200
>>>>>>      usb_reset_device+0x138/0x280
>>>>>>      __usb_queue_reset_device+0x35/0x50
>>>>>>      process_one_work+0x17e/0x390
>>>>>>      worker_thread+0x2c8/0x3e0
>>>>>>      ? process_one_work+0x390/0x390
>>>>>>      kthread+0xf7/0x1f0
> 
>>> Unfortunately, we have no to tell from the log you collected which host
>>> controller driver encountered this problem.  Nor, unless you can
>>> replicate the problem, any way to track down exactly where in that
>>> driver the bug is -- or even any way to tell whether a proposed fix
>>> actually solves the problem.
>>>
>>> Alan Stern
>>
>> The system was in the final stage of shutdown, so all we have in this case is serial
>> console output.  If we set console to more verbose mode, would that provide what
>> you need?
> 
> Maybe; it's hard to tell.  You'd have to enable dynamic debugging for
> the usbcore module and set the console to show debug-level messages.
> 
>> Or maybe 'dmesg' from when system boots?
> 
> I suspect that nothing from before the start of the shutdown would be
> useful.
> 
>> We can try to reproduce, but need some clues about what to provide to make progress.
> 
> The stack dump above shows that a kernel thread get stuck inside of
> usb_reset_device().  The first thing we would need to know is which
> device the thread is trying to reset.  Adding a dev_info() line near the
> start of usb_reset_device() would get us that information and you could
> capture it in the log.  (Along with that, we'd need to see the output
> from "lsusb -t".)
> 
> Knowing the device, we would know what host controller the device is
> attached to.  The trick will then be to figure what's going wrong with
> that host controller's driver.  It won't be easy, especially if the
> problem only occurs while the system is shutting down.

Something called usb_queue_reset_device()

Workqueue: events __usb_queue_reset_device
Call Trace:
    <TASK>
    __schedule+0x46b/0x1140
    ? schedule_timeout+0x79/0xf0
    schedule+0x23/0xc0
    usb_kill_urb+0x7b/0xc0
    ? housekeeping_affine+0x30/0x30
    usb_start_wait_urb+0xd6/0x160
    usb_control_msg+0xe2/0x140
    hub_port_init+0x647/0xf70
    usb_reset_and_verify_device+0x191/0x4a0
    ? device_release_driver_internal+0x4a/0x200
    usb_reset_device+0x138/0x280
    __usb_queue_reset_device+0x35/0x50
    process_one_work+0x17e/0x390

That is a fairly rare method.
We also know that
"the system was un-plugged from a KVM (usb mouse & keyboard)"
One of the few places usb_queue_reset_device() is used
is hid_io_error()

Do you still know which port that KVM had been plugged
into? I usually would not run a chain of logic with so
many assumptions, but if you cannot reproduce I see
no alternative.

	Regards
		Oliver