On Wed, Jan 31, 2018 at 04:58:58PM +0200, Mathias Nyman wrote: > On 30.01.2018 08:06, Herbert Poetzl wrote: >> On Mon, Jan 29, 2018 at 02:26:52PM +0200, Mathias Nyman wrote: >>> On 20.01.2018 06:20, Herbert Poetzl wrote: >>>> I've recently acquired a Gigabyte Z170X Gaming 7-EK motherboard >>>> with the Intel Z170 chipset and Sunrise Point-H USB 3.0 xHCI >>>> Controller for running Linux. >>>> Now most things seem to work fine (some problems with UEFI but >>>> that was kind of expected), but the xhci_hcd module is filling >>>> up my log files with a repeated message (ever 4 seconds): >>>> [ 2137.036187] usb usb2-port1: Cannot enable. Maybe the USB cable is >>>> bad? >>>> [ 2137.036981] xhci_hcd 0000:00:14.0: Cannot set link state. >>>> [ 2137.037767] usb usb2-port1: cannot disable (err = -32) >>>> Now I have no idea where usb2-port1 is or why it should have a >>>> bad cable, the only USB devices I know of are the USB drive >>>> I've booted the system from and the wireless keyboard/mouse >>>> combo I'm using. >>>> Both seem to work just fine and plugging those into different >>>> USB ports doesn't change the message. >>>> Bus 002 Device 002: ID 1b1c:1a00 Corsair >>>> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub >>>> Bus 001 Device 003: ID 046d:c534 Logitech, Inc. Unifying Receiver >>>> Bus 001 Device 002: ID 045b:0209 Hitachi, Ltd >>>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >>>> Note: I have no idea what the Hitachi device is. >>>> The current kernel is 4.14.13 (from Mageia 6). >>>> Any idea what the problem here is and how I can fix or work >>>> around it? >>>> Please let me know if you need any additional information on >>>> the system or environment. >>> lsusb -v could show more details about the misbehaving device. >>> Output of dmesg could tell something as well >> During testing I found out that there is a correlation between >> the BIOS and the observed error. >> When I unplug the power supply for a few seconds, the problem >> will completely disappear until the next time I enter the BIOS >> and change something there (doesn't matter what and doesn't >> affect the result). >> It also seems to be related to the 'mystical' Hitachi device >> I couldn't figure out what it is for or why it sits on each >> USB bus. >> You can find all the suggested output here ... >> http://vserver.13thfloor.at/Stuff/XHCI_HCD/ >> where 'failing' means that the problem is present and 'working' >> means that everything seems fine. > The Hitachi device is a built-in USB3 HUB, (USB3 so it supports > both USB2 and USB3 sides) I wasn't able to find the USB ID online and the Linux USB ID database only seems to know the vendor not the device IDs ... > In the failing case the USB3 side of the hub doesn't properly > finish reset, and gets stuck in a retry loop. > It's possible that we keep retrying a warm reset even if device > would require something else to reset it properly(normal reset, > or disable device in between) Well, I'm currently testing on that platform, so it would be easy for me to try some patches for that ... Thanks for looking into it, Herbert > -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
