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?
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
