From: Mark Hills <mark@xwax.org>
To: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: linux-usb@vger.kernel.org
Subject: Re: XHCI unplug of USB-C device is not detected
Date: Sat, 6 Nov 2021 12:23:00 +0000 (GMT) [thread overview]
Message-ID: <2111061157310.2377@stax.localdomain> (raw)
In-Reply-To: <2a5d79d8-e12e-4e72-38f7-ab743b3a1efd@linux.intel.com>
On Fri, 5 Nov 2021, Mathias Nyman wrote:
> Hi
Hi, thanks for your help.
[...]
> > 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.
It seems to be populated with information from the webcam:
# lsusb -v
Couldn't open device, some information will be missing
Bus 004 Device 002: ID 046d:0893 Logitech StreamCam
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.20
bDeviceClass 239
[...]
but then on a second run, the webcam is removed from lsusb output.
Plugging it in again still has no effect.
[...]
> 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:
> ...
There's no difference in the output before or after disconnecting the
camera:
stax# cat /sys/kernel/debug/usb/xhci/*/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 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:
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 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 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 Not-connected Disabled Link:RxDetect PortSpeed:0 Change: Wake: WCE WOE
Powered Not-connected Disabled Link:RxDetect PortSpeed:0 Change: Wake: WCE WOE
Powered Not-connected Disabled Link:RxDetect PortSpeed:0 Change: Wake: WCE WOE
Powered Not-connected Disabled Link:RxDetect PortSpeed:0 Change: Wake: WCE WOE
Powered Not-connected Disabled Link:RxDetect PortSpeed:0 Change: Wake: WCE WOE
Powered Not-connected Disabled Link:RxDetect PortSpeed:0 Change: Wake: WCE WOE
Powered Not-connected Disabled Link:RxDetect PortSpeed:0 Change: Wake: WCE WOE
Powered Not-connected Disabled Link:RxDetect PortSpeed:0 Change: Wake: WCE WOE
Powered Connected Enabled Link:Resume PortSpeed:15 OverCurrent In-Reset Change: CSC PEC WRC OCC PRC PLC CEC CAS Wake: WCE WDE WOE
Powered Connected Enabled Link:Resume PortSpeed:15 OverCurrent In-Reset Change: CSC PEC WRC OCC PRC PLC CEC CAS Wake: WCE WDE WOE
Powered Connected Enabled Link:Resume PortSpeed:15 OverCurrent In-Reset Change: CSC PEC WRC OCC PRC PLC CEC CAS Wake: WCE WDE WOE
Powered Connected Enabled Link:Resume PortSpeed:15 OverCurrent In-Reset Change: CSC PEC WRC OCC PRC PLC CEC CAS Wake: WCE WDE WOE
> 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
Yes, it helps. I pinpointed it on usb3. The webcam can now be plugged and
re-plugged. It also survives a suspend/resume of the machine now and I can
see the change in portsc:
-Powered Connected Enabled Link:U3 PortSpeed:4 Change: Wake:
+Powered Not-connected Disabled Link:RxDetect PortSpeed:0 Change: Wake:
So it seems this is a workaround -- thank you.
Is it worth getting to the root of this problem (and can I capture any
data to help?) or is it just that some devices are buggy?
Many thanks,
--
Mark
next prev parent reply other threads:[~2021-11-06 12:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-05 10:58 XHCI unplug of USB-C device is not detected Mark Hills
2021-11-05 20:40 ` Mathias Nyman
2021-11-06 12:23 ` Mark Hills [this message]
2021-11-15 21:00 ` Mathias Nyman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2111061157310.2377@stax.localdomain \
--to=mark@xwax.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox