Re: Deadlock in usb subsystem on shutdown, 6.18.3+

[Oliver Neukum]

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