Re: Problem with xhci_hcd on Gigabyte Z170X Gaming 7-EK
Hi all, are there any news regarding this issue? I have a similar issue using a Lenovo ThinkPad T480s with Lenovo UltraDock CS18. If I undock the CS18 dock I will get the following messages (kernel 4.14.24): [ 64.127294] usb usb4-port1: Cannot enable. Maybe the USB cable is bad? [ 64.127306] xhci_hcd :3a:00.0: Cannot set link state. [ 64.127521] usb usb4-port1: cannot disable (err = -32) [ 64.127527] usb 4-1: USB disconnect, device number 2 [ 64.127532] usb 4-1.2: USB disconnect, device number 3 [ 64.137118] usb 4-1.4: USB disconnect, device number 4 After redocking no usb3 devices which are connected to the dock will be detected any more. Background: The CS18 ultra dock uses the integrated xhci controller of Intel thunderbolt3. So there is a second xhci controller inside the system. The port1 of the usb root hub (usb4) is physically inside the ThinkPad itself. That why it should always be possible to enable this hub port, even if the dock is not connected. For example a lsusb after booting (without undock and redock) looks like this: Bus 004 Device 003: ID 17ef:3070 Lenovo Bus 004 Device 002: ID 17ef:3070 Lenovo Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 004: ID 17ef:3075 Lenovo Bus 003 Device 005: ID 17ef:306f Lenovo Bus 003 Device 003: ID 17ef:3071 Lenovo Bus 003 Device 002: ID 17ef:3071 Lenovo Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 004: ID 0bda:0316 Realtek Semiconductor Corp. Bus 002 Device 005: ID 0781:5588 SanDisk Corp. Bus 002 Device 003: ID 2109:0812 VIA Labs, Inc. VL812 Hub Bus 002 Device 002: ID 1058:083a Western Digital Technologies, Inc. Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 011: ID 06cb:009a Synaptics, Inc. Bus 001 Device 010: ID 5986:2113 Acer, Inc Bus 001 Device 009: ID 8087:0a2b Intel Corp. Bus 001 Device 007: ID 2cb7:0210 Bus 001 Device 005: ID 17ef:3074 Lenovo Bus 001 Device 003: ID 058f:9540 Alcor Micro Corp. AU9540 Smartcard Reader Bus 001 Device 002: ID 2109:2812 VIA Labs, Inc. VL812 Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub There are 2 USB Hubs inside the dock connected to the usb 3 root hub (usb4). After undock and redock there is only the root hub available at the bus 4 (all other devices connected to bus 4 are gone even the 2 hubs). I made some debugging and found that [ 64.127294] usb usb4-port1: Cannot enable. Maybe the USB cable is bad? is because the rh port enable failed with EBUSY in hub.c hub_port_wait_reset. I increased the HUB_RESET_TIMEOUT from 800ms to 1600ms and it seems to work fine. I didn't get this message again and after redock the usb3 devices are available. But doing this more often (undock/redock) the hub enable still success but there are anyhow no usb3 devices available at the dock. A bit more debugging shows that after redock there is a usb4 port status change event missing at the xhci controller (xhci-ring.c handle_port_status). Working case: [ 127.632374] xhci_hcd :3c:00.0: Port Status Change Event for port 1 [ 127.632384] xhci_hcd :3c:00.0: handle_port_status: starting port polling. [ 127.632434] hub 3-0:1.0: state 7 ports 2 chg evt 0002 [ 127.632447] xhci_hcd :3c:00.0: get port status, actual port 0 status = 0x206e1 [ 127.632451] xhci_hcd :3c:00.0: Get port status returned 0x10101 [ 127.632478] xhci_hcd :3c:00.0: clear port connect change, actual port 0 status = 0x6e1 [ 127.632491] usb usb3-port1: status 0101, change 0001, 12 Mb/s [ 127.632499] xhci_hcd :3c:00.0: get port status, actual port 0 status = 0x6e1 [ 127.632502] xhci_hcd :3c:00.0: Get port status returned 0x101 [ 127.652047] xhci_hcd :3c:00.0: Port Status Change Event for port 3 [ 127.652049] xhci_hcd :3c:00.0: handle_port_status: starting port polling. [ 127.652133] hub 4-0:1.0: state 7 ports 2 chg evt 0002 [ 127.652138] xhci_hcd :3c:00.0: get port status, actual port 0 status = 0x21603 [ 127.652138] xhci_hcd :3c:00.0: Get port status returned 0x10203 [ 127.652146] xhci_hcd :3c:00.0: clear port connect change, actual port 0 status = 0x1603 [ 127.652149] usb usb4-port1: status 0203, change 0001, 10.0 Gb/s Not working case: [ 160.922848] xhci_hcd :3c:00.0: Port Status Change Event for port 1 [ 160.922860] xhci_hcd :3c:00.0: handle_port_status: starting port polling. [ 160.922956] hub 3-0:1.0: state 7 ports 2 chg evt 0002 [ 160.922972] xhci_hcd :3c:00.0: get port status, actual port 0 status = 0x206e1 [ 160.922976] xhci_hcd :3c:00.0: Get port status returned 0x10101 [ 160.923025] xhci_hcd :3c:00.0: clear port connect change, actual port 0 status = 0x6e1 [ 160.923046] usb usb3-port1: status 0101, change 0001, 12 Mb/s [ 160.923061] xhci_hcd :3c:00.0: get port status, actual port 0 status = 0x6e1 [ 160.923065] xhci_hcd :3c:00.0: Get port status returned 0x101 [ 160.950040]
Re: Problem with xhci_hcd on Gigabyte Z170X Gaming 7-EK
On Tue, Feb 06, 2018 at 07:54:53PM +0100, Herbert Poetzl wrote: > 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 :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. Following up on that, I did test with linux-4.9.0 without the patch and with the patch applied, but in both cases the result is the same: no error message and no second Hitachi HUB visible in lsusb. Rebooting to 4.14.13 brings back the error loop. Hope this helps, Herbert >> -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with xhci_hcd on Gigabyte Z170X Gaming 7-EK
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 :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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with xhci_hcd on Gigabyte Z170X Gaming 7-EK
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 :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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with xhci_hcd on Gigabyte Z170X Gaming 7-EK
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 :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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with xhci_hcd on Gigabyte Z170X Gaming 7-EK
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 :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) 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) -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with xhci_hcd on Gigabyte Z170X Gaming 7-EK
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 :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. Many thanks in advance, Herbert > -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with xhci_hcd on Gigabyte Z170X Gaming 7-EK
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 :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 -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
