On Tue, Feb 06, 2018 at 07:38:42PM +0200, Mathias Nyman wrote: > On 01.02.2018 02:43, Herbert Poetzl wrote: >> 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 ... > Does reverting > 37be6676 usb: hub: Fix auto-remount of safely removed or > ejected USB-3 devices > help? Hmm, I did find 37be66767e3cae4fd16e064d8bb7f9f72bf5c045 for 4.9 and earlier but nothing which would revert cleanly for 4.14.13 or later ... Could you provide a hint how I can revert it easily for 4.14.17 or 4.15.1? Thanks in advance, Herbert > After reverting it the port should be disabled and re-enabled > after a few unsuccessful port resets, and hopefully start > working again. > -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
