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 >
