Bug 1149871 - usb usb10-port1: Cannot enable. Maybe the USB cable is bad?
usb usb10-port1: Cannot enable. Maybe the USB cable is bad?
Status: RESOLVED WORKSFORME
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
Current
x86-64 SUSE Other
: P5 - None : Normal (vote)
: ---
Assigned To: openSUSE Kernel Bugs
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-09-07 12:59 UTC by Michael Hirmke
Modified: 2020-11-21 18:03 UTC (History)
6 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
lsusb -v / -t (102.01 KB, text/plain)
2020-04-20 15:49 UTC, Michael Hirmke
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Hirmke 2019-09-07 12:59:29 UTC
Starting with one of the latest Tumbleweed snapshots/kernels up to the actual one I get the message

usb usb10-port1: Cannot enable. Maybe the USB cable is bad?

when connecting a device to the first (closer to the front) of the two
Thunderbolt/USB-C ports on the left side of my DELL XPS13 9370 notebook.
Most of the connected devices are working, nevertheless, but sometimes they stop working on certain access operations. Some devices refuse to work at all using this port. The same devices are working without any problems using one of the other two ports of this notebook.

I contacted DELL support and they wanted me to give it a test with Windows.
So I installed Windows 10 and tested with a few devices. Everything worked and I didn't get any error messages in the event log.

So maybe it is a kernel/module bug?
Comment 1 Michael Hirmke 2019-09-08 13:12:54 UTC
More thorough tests in Windows 10 gave the same or similar problems.
So despite my first assumption, it seems to be a hardware problem.
I'll contact DELL again.
Comment 2 Michael Hirmke 2019-09-08 13:13:10 UTC
More thorough tests in Windows 10 gave the same or similar problems.
So despite my first assumption, it seems to be a hardware problem.
I'll contact DELL again.
Comment 3 Michael Hirmke 2020-04-20 08:41:39 UTC
In the meantime I don't have problems with Windows 10 any longer, so some fix must have solved this. I suspect, for Linux I also would need some fix, because despite my last comment, it doesn't seem to be a hardware problem - otherwise it wouldn't work in windows.

So I'm going to reopen this bug with a new description:

My DELL XPS 13 9370 has the following ports:

- Two Thunderbolt 3 (USB Type-C) ports with Power Delivery
- One USB 3.1 Gen 1 (USB Type-C) port with Power Delivery/DisplayPort

Connecting devices to the first Thunderbolt 3 port or the USB 3.1 Gen 1 port works without any problems.
Connecting devices to the the second Thunderbolt 3 port also works in most cases, but the kernel is logging thousands of messages like

usb usb10-port1: Cannot enable. Maybe the USB cable is bad?

A bad cable can't be the reason for this, because it happens with USB sticks, head phones ...;  even with external disks connected with a real thunderbolt adapter are producing these messages when using this port.

Booting the system with Windows 10 doesn't show any problem or messages for this port for a while now.
I'm not sure, what debug information would be necessary to analyze this problem?

System has Tumbleweed 20200416 version now.
Comment 4 Takashi Iwai 2020-04-20 09:32:30 UTC
A deja vu...  Oliver, Nicolas, please take a look.
Comment 5 Oliver Neukum 2020-04-20 12:39:08 UTC
Please retest with usbcore.autosuspend=-1 on teh kernel command line.
Comment 6 Michael Hirmke 2020-04-20 14:19:23 UTC
(In reply to Oliver Neukum from comment #5)
> Please retest with usbcore.autosuspend=-1 on teh kernel command line.

Nope, didn't help.
The messages reocurred directly after rebooting.

Kernel command line: BOOT_IMAGE=/vmlinuz-5.6.4-1-default root=UUID=63022e5c-d927-4c7e-9825-28ae8d5d7d22 splash=silent quiet resume=/dev/disk/by-uuid/73a50dba-2914-4a68-8226-b5b972c921ad no_console_suspend consoleblank=0 systemd.log_target=kmsg log_buf_len=10M printk.devkmsg=on crashkernel=191M,high crashkernel=72M,low modprobe.blacklist=nvidia modprobe.blacklist=nvidia_uvm modprobe.blacklist=nvidia_drm modprobe.blacklist=nvidia_modeset modprobe.blacklist=nouveau modprobe.blacklist=nv usbcore.autosuspend=-1 mitigations=auto
Comment 7 Oliver Neukum 2020-04-20 15:09:32 UTC
OK, it was worth a shot. Please provide the outputs of "lsusb -v" and "lsusb -t".
Comment 8 Michael Hirmke 2020-04-20 15:49:36 UTC
Created attachment 836158 [details]
lsusb -v / -t
Comment 9 Michael Hirmke 2020-04-20 15:56:29 UTC
(In reply to Oliver Neukum from comment #7)
> OK, it was worth a shot. Please provide the outputs of "lsusb -v" and "lsusb
> -t".

Some additional information:

My XPS 13 is connected to a thunderbolt docking station, CalDigit TS3 Plus, which in turn has connected an external monitor via display port, mouse and keyboard, an external audio box, a printer and a scanner.
Comment 10 Michael Hirmke 2020-04-28 18:41:09 UTC
Problem vanished with today's Tumbleweed snapshot 20200425 an kernel 5.6.6.
Comment 11 Michael Hirmke 2020-04-29 12:18:38 UTC
Sorry, same problem reoccurred today after third reboot since yesterday.
Comment 12 Michael Hirmke 2020-05-11 10:42:49 UTC
Still exists with 5.6.11!
Comment 13 Oliver Neukum 2020-05-13 10:00:38 UTC
Please try

usbcore.quirks=05e3:0610:kog,05e3:0612:kog
Comment 14 Michael Hirmke 2020-05-13 13:17:23 UTC
(In reply to Oliver Neukum from comment #13)
> Please try
> 
> usbcore.quirks=05e3:0610:kog,05e3:0612:kog

Sorry, no difference 8-<
Same messages, same freuqency.
Comment 15 Michael Hirmke 2020-07-11 08:44:28 UTC
Problem seems to have been solved with one of the last three Tumbleweed snapshots/kernels.
Comment 16 Michael Hirmke 2020-07-11 08:57:55 UTC
And again I was to hasty - it worked for three reboots, now the problem is back 8-<
Sorry for reopening the bug again.
Comment 17 Michael Hirmke 2020-07-26 19:21:15 UTC
I'm not sure, if I can believe my own observations, but it seems, that the occurrence of the error message depends on the direction a device is plugged in!?!? What? I have a Thunderbolt plug and I have to obey the direction I plug in a device? Please tell me that I have a halluzination 8-<
Comment 18 Miroslav Beneš 2020-09-16 11:17:56 UTC
(In reply to Michael Hirmke from comment #17)
> I'm not sure, if I can believe my own observations, but it seems, that the
> occurrence of the error message depends on the direction a device is plugged
> in!?!? What? I have a Thunderbolt plug and I have to obey the direction I
> plug in a device? Please tell me that I have a halluzination 8-<

If that's the case, it sounds like a cable issue to me?
Comment 19 Michael Hirmke 2020-09-16 18:00:43 UTC
(In reply to Miroslav Beneš from comment #18)
> (In reply to Michael Hirmke from comment #17)
> > I'm not sure, if I can believe my own observations, but it seems, that the
> > occurrence of the error message depends on the direction a device is plugged
> > in!?!? What? I have a Thunderbolt plug and I have to obey the direction I
> > plug in a device? Please tell me that I have a halluzination 8-<
> 
> If that's the case, it sounds like a cable issue to me?

I would suspect that, too, but with an USB dongle without a cable? And with an LTE stick with a cable? And with any other device plugged into this port?
And only with Linux, not with Windows?
Comment 20 Miroslav Beneš 2020-09-17 07:56:37 UTC
Oliver, Nicolas, any idea here?
Comment 21 Alan Hughes 2020-11-04 12:18:17 UTC
I am also seeing this issue on OpenSUSE Leap 15.2 with kernel 5.3.18-lp152.47-default. The system has become highly unresponsive as a result of this bug; boot time has been extended by several minutes, KDE login now takes at least 2 minutes, Dolphin start-up takes at least 1 minute. The USB device in question is not being used - there is nothing plugged in to it. Not only that but I have tried to remove all USB devices plugged into the machine and the messages continue to appear.

This problem did not appear on OpenSUSE Leap 15.1.

Windows 10 installer does not report any faulty hardware.

Ubuntu has apparently had similar problems reported, and resolved them by reverting the following kernel patch: "https://patchwork.kernel.org/project/linux-usb/patch/1549025551-4306-1-git-send-email-glogow@fbihome.de/". It might be worth while having a good hard look at this.
Comment 22 Takashi Iwai 2020-11-04 13:03:43 UTC
(In reply to Alan Hughes from comment #21)
> Ubuntu has apparently had similar problems reported, and resolved them by
> reverting the following kernel patch:
> "https://patchwork.kernel.org/project/linux-usb/patch/1549025551-4306-1-git-
> send-email-glogow@fbihome.de/". It might be worth while having a good hard
> look at this.

Interesting.  I'm building a test kernel with the revert for Leap 15.2 in OBS home:tiwai:bsc1149871 repo.  It'll appear later at
  http://download.opensuse.org/repositories/home:/tiwai:/bsc1149871/standard/

For Tumbleweed, it's being built in OBS home:tiwai:bsc1149871-tw repo, will be available at
  http://download.opensuse.org/repositories/home:/tiwai:/bsc1149871-tw/standard/

Please give it a try.
Comment 23 Michael Hirmke 2020-11-04 19:33:26 UTC
[...]
> For Tumbleweed, it's being built in OBS home:tiwai:bsc1149871-tw repo, will
> be available at
>  
> http://download.opensuse.org/repositories/home:/tiwai:/bsc1149871-tw/
> standard/
> 
> Please give it a try.

Sorry to tell you, but this didn't help in my case 8-(
Comment 24 Takashi Iwai 2020-11-05 09:01:13 UTC
(In reply to Michael Hirmke from comment #23)
> [...]
> > For Tumbleweed, it's being built in OBS home:tiwai:bsc1149871-tw repo, will
> > be available at
> >  
> > http://download.opensuse.org/repositories/home:/tiwai:/bsc1149871-tw/
> > standard/
> > 
> > Please give it a try.
> 
> Sorry to tell you, but this didn't help in my case 8-(

Thanks.  How about other people?

I'm asking it because we might see the multiple issues showing a similar end effect.
Comment 25 Alan Hughes 2020-11-05 09:38:36 UTC
I am unlikely to be able to try the new kernel until the weekend.

Will the current NVIDIA graphics drivers continue to work with it?
Comment 26 Alan Hughes 2020-11-07 10:20:07 UTC
Installed the kernel this morning and rebooted my system into it; kept it running for about 20 minutes or so. No sign of the "Cannot enable. Maybe the USB cable is bad?" messages during this period (normally they appear once every 4 seconds or so). Also boot speed was back to normal, login to KDE was fast (currently it takes at least a minute for my desktop to appear), and start-up of Dolphin was snappy (currently takes a minute or so to start up).

I think that, at least in my case, reverting this patch has solved the problem.

Can I request that this patch is reverted in the OpenSUSE kernel, and a new kernel released PDQ.
Comment 27 Takashi Iwai 2020-11-09 08:52:31 UTC
(In reply to Alan Hughes from comment #26)
> Installed the kernel this morning and rebooted my system into it; kept it
> running for about 20 minutes or so. No sign of the "Cannot enable. Maybe the
> USB cable is bad?" messages during this period (normally they appear once
> every 4 seconds or so). Also boot speed was back to normal, login to KDE was
> fast (currently it takes at least a minute for my desktop to appear), and
> start-up of Dolphin was snappy (currently takes a minute or so to start up).
> 
> I think that, at least in my case, reverting this patch has solved the
> problem.
> 
> Can I request that this patch is reverted in the OpenSUSE kernel, and a new
> kernel released PDQ.

So, your problem looks different from the bug the original report hits.
Could you open another bug report for tracking yours, in order not to mess up thing?

About the revert: we'd need to report and discuss things with the upstream at first.  As a last resort, a device-based quirk or such might be implemented.  Let's see.
Comment 28 Michael Hirmke 2020-11-21 18:03:50 UTC
Not sure, if it was a new kernel or the new motherboard my notebood needed, but at the moment, the problem doesn't show up - neither the message nor non working usb devices.