Re: XHCI unplug of USB-C device is not detected

[Mathias Nyman <mathias.nyman@linux.intel.com>]

Hi

On 5.11.2021 12.58, Mark Hills wrote:
> My only USB-C device is a Logitech StreamCam, which seems to cause some 
> kind of lock on resources when unplugged.
> 
> The symptom is it works when first plugged in to a PC. But after 
> unplugging it can't be made to work again.
> 
> I don't have prior experience of these components. I enabled debug 
> messages:
> 
>   echo -n "module xhci_hcd =p" > /sys/kernel/debug/dynamic_debug/control
> 
> Plugging in the webcam produces the dmesg below.
> 
> But unplugging simply results in no activity -- zero output in dmesg. Same 
> when plugging in again.
> 
> After unplugging the device is still listed:
> 
>   $ lsusb
>   Bus 004 Device 002: ID 046d:0893  Logitech StreamCam
>   Bus 004 Device 001: ID 1d6b:0003 Linux 5.14.2-mh xhci-hcd xHCI Host Controller
>   Bus 003 Device 001: ID 1d6b:0002 Linux 5.14.2-mh xhci-hcd xHCI Host Controller
>   Bus 002 Device 001: ID 1d6b:0003 Linux 5.14.2-mh xhci-hcd xHCI Host Controller
>   Bus 001 Device 007: ID 046d:c52f Logitech USB Receiver
>   Bus 001 Device 006: ID 056a:037b Wacom Co.,Ltd. CTL-672
>   Bus 001 Device 005: ID 1a40:0101  USB 2.0 Hub
>   Bus 001 Device 004: ID 04d9:0340  USB-HID Keyboard
>   Bus 001 Device 003: ID 04d9:0339  USB-HID Keyboard
>   Bus 001 Device 002: ID 1a40:0101  USB 2.0 Hub
>   Bus 001 Device 001: ID 1d6b:0002 Linux 5.14.2-mh xhci-hcd xHCI Host Controller

how about "lsusb -v"?
It should try to read something from the device.

> 
> and the associated uvcvideo module is free and can be removed with rmmod:
> 
>   $ lsmod | grep uvcvideo
>   uvcvideo              110592  0
>   videobuf2_vmalloc      20480  1 uvcvideo
>   videobuf2_v4l2         28672  1 uvcvideo
>   videobuf2_common       45056  4 videobuf2_vmalloc,videobuf2_v4l2,uvcvideo,videobuf2_memops
>   videodev              200704  3 videobuf2_v4l2,uvcvideo,videobuf2_common
>   mc                     53248  5 videodev,snd_usb_audio,videobuf2_v4l2,uvcvideo,videobuf2_common
> 
> The USB subsystem isn't entirely locked up. A USB keyboard on a different 
> type A port is picked up as expected.
> 
> I have access to a Thinkpad X230 laptop (Alpine Linux; kernel 
> 5.10.61-0-lts), and everything works as expected.
> 
> So it seems to be specific to the PC hardware (Gigabyte H170-D3HP 
> motherboard -- a single USB-C port and several regular ones). Or perhaps 
> even the kernel config.
> 
> What debugging can I do next?

Normally xHC generates an interrupt at connect change, and the interrupt
handler reads the port status, and prints a debugging message.

We could manually read all the port registers before and after disconnecting.
Check link state, and that the wake flags look ok in case device is suspended

Example:
# cat /sys/kernel/debug/usb/xhci/0000\:00\:14.0/ports/port*/portsc
Powered Not-connected Disabled Link:RxDetect PortSpeed:0 Change: Wake: 
Powered Not-connected Disabled Link:RxDetect PortSpeed:0 Change: Wake: 
Powered Not-connected Disabled Link:RxDetect PortSpeed:0 Change: Wake: 
Powered Connected Enabled Link:U0 PortSpeed:3 Change: Wake: 
Powered Not-connected Disabled Link:RxDetect PortSpeed:0 Change: Wake: 
...

Also see if disabling runtime suspend for both roothubs helps:
# echo on > /sys/bus/usb/devices/usb1/power/control
# echo on > /sys/bus/usb/devices/usb2/power/control

(if you have more roothubs than usb1 and usb2 do echo "on" to those as well

Thanks
-Mathias




> 
> Thanks
>