Bug 1577483 - USB 3.0 fails to work after resume from suspend
Summary: USB 3.0 fails to work after resume from suspend
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 27
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-12 10:56 UTC by Uros Platise
Modified: 2018-10-29 11:02 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-29 11:02:27 UTC
Type: Bug


Attachments (Terms of Use)

Description Uros Platise 2018-05-12 10:56:01 UTC
Description of problem:

From some time ago I experience various problems with the latest kernel regarding the usb wake-up, which after resume from suspend, and re-pluging it ends with:

[ 2025.370876] usb usb2: root hub lost power or was reset
[ 2025.370882] usb usb3: root hub lost power or was reset

While the othe usb 2.0 port works flawlessly.


Version-Release number of selected component (if applicable):

Linux version 4.16.7-200.fc27.x86_64 (mockbuild@bkernel01.phx2.fedoraproject.org) (gcc version 7.3.1 20180303 (Red Hat 7.3.1-5) (G
CC)) #1 SMP Wed May 2 20:33:31 UTC 2018

running on:

DMI: SAMSUNG ELECTRONICS CO., LTD. 900X3C/900X3D/900X3E/900X4C/900X4D/NP900X4C-A09DE, BIOS P10ABK 11/01/2013

How reproducible:

Steps to Reproduce:
1. Start Linux
2. Put to suspend
3. Wake-up from suspend
4. Any USB device won't work and root hub lost power or was reset msg can be seen
5. Recovery is only possible via linux restart (haven't found other way yet)

Actual results:

USB port is not working.


Expected results:

USB port should and it was working normally.


Additional info:

$ lsusb
Bus 001 Device 004: ID 2232:1024 Silicon Motion 
Bus 001 Device 003: ID 8087:07da Intel Corp. 
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Comment 1 Raymond Wu Won 2018-06-16 15:25:16 UTC
(Please let me know if there's anything in this comment I could improve
upon - it's my first Red Hat Bugzilla comment.)

I'm getting the same issue in F28 with my USB 3.0 ports (motherboard: 
Gigabyte GA-H81M-HD3) - so can we add F28 to this?

My USB 3.0 ports lose power after I resume from suspend and the
dmesg|grep usb is very similar to the above. USB 2.0 is fine
(mouse/keyboard/front panel) - only the blue USB 3.0 ports are
affected.

I don't recall having this issue in F26 although I'm also not 100% sure
about that now (I'm trying to test this with a live USB but I tend to
not have a great track record with those). I didn't spend any time on
F27 as I did an incremental system-upgrade from F26 to F27 and then
immediately followed with a system-upgrade to F28.

I've dug around trying a few other workarounds, including the "unbind"
and "bind" one mentioned at
https://bbs.archlinux.org/viewtopic.php?pid=1758156#p1758156 via
https://zedt.eu/tech/linux/restarting-usb-subsystem-centos/ but that
didn't really help in my case.

However, what _does_ appear to be working for me right now to reset and
re-enable USB 3.0 post-suspend/resume, without rebooting is this guide:


http://hamwaves.com/usb.autosuspend/en/index.html


Current workaround steps in summary, to echo and confirm that page a 
little (with slight variations):

> sudo lsusb -v|less

(Look for the bcdUSB 3.00 entries)

~~~~~~~~~~~~
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
bcdUSB 3.00
...
  bcdUSB               3.00
  idVendor           0x1d6b Linux Foundation
  idProduct          0x0003 3.0 root hub
...
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
  bcdUSB               3.00
  idVendor           0x1d6b Linux Foundation
  idProduct          0x0003 3.0 root hub
~~~~~~~~~~~~

Now we want to look for the idVendor entries in one of the usb folders:

> cd /sys/bus/usb/devices/
> cat usb<tab><tab><tab>
(try and cat each usb#/idVendor and usb#/idProduct to find a match)
(etc etc.)
...

> cat usb4/idVendor /sys/bus/usb/devices/usb4/idVendor
1d6b
^ Here's one (compare with the above ls -v output)

> cat usb4/idProduct /sys/bus/usb/devices/usb4/idProduct
0003

Going into my usb5/ directory now (I've already looked through 1-4):

> cd /sys/bus/usb/devices/
> cat usb5/idVendor /sys/bus/usb/devices/usb5/idVendor
1d6b

> cat usb5/idProduct /sys/bus/usb/devices/usb5/idProduct
0002

See how this also matches some of lsusb -v (at least as far as idVendor
goes for bcdUSB 3.00 products).

At this point, plug in a test memory stick if you haven't done so
already - it helps to have a file browser like Nautilus open so you can
see the device pop up and be ready to mount as soon as this works.

From above, usb4 has 1d6b and 0003, so try:

> cd usb4/power/
> cat control auto
> echo 'on'|tee control
> dmesg|grep usb

Nothing - no change for me. So I set it back to how it was:

> echo 'auto'|tee control

Now try the other one:

> cd /sys/bus/usb/devices/usb5/power/

I've combined the next two commands just to play it safe for now:

> echo 'on'|tee control;echo 'auto'|tee control

I see my memory stick pop up in Nautilus and can mount, write files, and
unmount. Although if I eject/unmount again, I have to repeat the echo
'on'|tee control process.

This is the stage I'm at so far - I did leave it on 'on' yesterday but
that seemed to interfere with my system suspends (or maybe it was
because I didn't unmount before suspending), but with this, it's an
improvement on rebooting the whole system every time.

Next, I'll try leaving it on 'on' (autosuspend disabled) and see whether
it has any side-effects.

Uros, are you able to see whether this process gets you any closer?


Raymond.

Comment 2 Raymond Wu Won 2018-06-16 16:18:11 UTC
dmesg starting at the time of unmount/eject before suspending, with some annotations and no omissions:

https://paste.fedoraproject.org/paste/gdhuPQBhySenFm2fbsmvTQ/raw

I've also just given "echo 'on'|tee control" a go again without setting "auto" back afterwards and my system has managed to suspend correctly both with the memory stick plugged in and mounted, plugged in and 'ejected', as well as not plugged in.

I'm going to test mine like this for a while to see whether there are any negative effects before considering the "Permanent solution" at:

http://hamwaves.com/usb.autosuspend/en/index.html

In the meantime, uptime!


Raymond.

Comment 3 Justin M. Forbes 2018-07-23 15:16:04 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs.

Fedora 27 has now been rebased to 4.17.7-100.fc27.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 28, and are still experiencing this issue, please change the version to Fedora 28.

If you experience different issues, please open a new bug report for those.

Comment 4 Uros Platise 2018-07-23 17:34:41 UTC
The problem persist in 4.17.7-100.fc27 and yes Raymond Wu Won if I manually set it on power resumes and starts working. Thanks for hint.

--------------

[121133.216533] xhci_hcd 0000:03:00.0: Secondary root hub is not suspended
[121133.552409] usb 2-2: new full-speed USB device number 23 using xhci_hcd
[121133.740493] usb 2-2: New USB device found, idVendor=1ced, idProduct=4001, bcdDevice= 0.00
[121133.740502] usb 2-2: New USB device strings: Mfr=2, Product=1, SerialNumber=128
[121133.740507] usb 2-2: Product: MonoDAQ USB
[121133.740511] usb 2-2: Manufacturer: Isotel
[121133.740516] usb 2-2: SerialNumber: 7F000210081A1874
[121133.777858] usb 2-2: can't set config #1, error -71
[121133.778445] usb 2-2: USB disconnect, device number 23
[121136.008159] usb 2-2: new full-speed USB device number 24 using xhci_hcd
[121136.195647] usb 2-2: New USB device found, idVendor=1ced, idProduct=4001, bcdDevice= 0.00
[121136.195655] usb 2-2: New USB device strings: Mfr=2, Product=1, SerialNumber=128
[121136.195660] usb 2-2: Product: MonoDAQ USB
[121136.195664] usb 2-2: Manufacturer: Isotel
[121136.195668] usb 2-2: SerialNumber: 7F000210081A1874

Comment 5 Laura Abbott 2018-10-01 21:21:30 UTC
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs.
 
Fedora 27 has now been rebased to 4.18.10-100.fc27.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you have moved on to Fedora 28 or Fedora 29, and are still experiencing this issue, please change the version to Fedora 28 or 29.
 
If you experience different issues, please open a new bug report for those.

Comment 6 Uros Platise 2018-10-29 11:02:27 UTC
It works on SAMSUNG ELECTRONICS with the latest:

Linux version 4.18.16-100.fc27.x86_64 (mockbuild@bkernel04.phx2.fedoraproject.org) (gcc version 7.3.1 20180712 (Red Hat 7.3.1-6) (GCC)) #1 SMP Sun Oct 21 09:33:00 UTC 2018


Note You need to log in before you can comment on or make changes to this bug.