(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.

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.

*********** 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.

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

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.

It works on SAMSUNG ELECTRONICS with the latest:

Linux version 4.18.16-100.fc27.x86_64 (mockbuild.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