No usb 3 Arch linux 3.15.1

Question

Up until my last reboot, I had the ability to use my usb 3 port. I just got the system installed not that long ago, so up until then I'd been configuring and installing drivers, but that was the session that I had actually been doing work in. I did install the xf86-input-synaptics driver, but I just removed it and booted again to see if that was messing it up, since it didn't come back, it didn't. Now I'm stuck. I have seen on many forums that people are having problems with it, but the port usually shows up in lsusb, dmesg, or lspci.

lsusb:

Bus 002 Device 005: ID 047b:0011 Silitek Corp. SK-1688U Keyboard
Bus 002 Device 004: ID 045e:0040 Microsoft Corp. Wheel Mouse Optical
Bus 002 Device 003: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 0bda:0139 Realtek Semiconductor Corp. RTS5139 Card Reader Controller
Bus 001 Device 003: ID 13d3:5134 IMC Networks 
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

lspci | grep -i usb

00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05)

dmesg | grep -i usb

[    1.278138] ACPI: bus type USB registered
[    1.278159] usbcore: registered new interface driver usbfs
[    1.278167] usbcore: registered new interface driver hub
[    1.278268] usbcore: registered new device driver usb
[    1.278630] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.278904] ehci-pci 0000:00:1a.0: new USB bus registered, assigned bus number 1
[    1.291224] ehci-pci 0000:00:1a.0: USB 2.0 started, EHCI 1.00
[    1.291408] hub 1-0:1.0: USB hub found
[    1.291716] ehci-pci 0000:00:1d.0: new USB bus registered, assigned bus number 2
[    1.304530] ehci-pci 0000:00:1d.0: USB 2.0 started, EHCI 1.00
[    1.304982] hub 2-0:1.0: USB hub found
[    1.597732] usb 1-1: new high-speed USB device number 2 using ehci-pci
[    1.721971] hub 1-1:1.0: USB hub found
[    1.830738] usb 2-1: new high-speed USB device number 2 using ehci-pci
[    1.955115] hub 2-1:1.0: USB hub found
[    2.037276] usb 1-1.2: new high-speed USB device number 3 using ehci-pci
[    2.240377] usb 1-1.4: new high-speed USB device number 4 using ehci-pci
[    2.390210] usb 2-1.2: new high-speed USB device number 3 using ehci-pci
[    2.476044] hub 2-1.2:1.0: USB hub found
[    2.743395] usb 2-1.2.3: new low-speed USB device number 4 using ehci-pci
[    2.899768] usb 2-1.2.4: new low-speed USB device number 5 using ehci-pci
[    6.531535] scsi6 : SCSI emulation for RTS5139 USB card reader
[    6.531790] usbcore: registered new interface driver rts5139
[    6.632207] uvcvideo: Found UVC 1.00 device USB2.0 UVC 1M WebCam (13d3:5134)
[    6.636268] input: USB2.0 UVC 1M WebCam as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input15
[    6.636452] usbcore: registered new interface driver uvcvideo
[    6.636456] USB Video Class driver (1.1.1)
[    7.114946] usbcore: registered new interface driver usbhid
[    7.114954] usbhid: USB HID core driver
[    7.125179] input: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM) as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2.3/2-1.2.3:1.0/0003:045E:0040.0001/input/input18
[    7.125756    ] hid-generic 0003:045E:0040.0001: input,hidraw0: USB HID v1.10 Mouse [Microsoft Microsoft 3-Button Mouse with IntelliEye(TM)] on usb-0000:00:1d.0-1.2.3/input0
[    7.126179] input: Silitek Standard USB Keyboard  as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2.4/2-1.2.4:1.0/0003:047B:0011.0002/input/input19
[    7.126612] hid-generic 0003:047B:0011.0002: input,hidraw1: USB HID v1.00 Keyboard [Silitek Standard USB Keyboard ] on usb-0000:00:1d.0-1.2.4/input0

lshw -short -class bus

H/W path           Device  Class          Description
=====================================================
/0                         bus            G74Sx
/0/100/1a                  bus            6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2
/0/100/1a/1        usb1    bus            EHCI Host Controller
/0/100/1a/1/1              bus            Integrated Rate Matching Hub
/0/100/1d                  bus            6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1
/0/100/1d/1        usb2    bus            EHCI Host Controller
/0/100/1d/1/1              bus            Integrated Rate Matching Hub
/0/100/1d/1/1/2            bus            USB2.0 Hub
/0/100/1f.3                bus            6 Series/C200 Series Chipset Family SMBus Controller

Up until now, I've simply been told the device is broken, since it doesn't show up on any of these. Now that I've seen it work, I know that it isn't and that it is just a configuration issue.

When it was working the ouput of lsusb included a fesco driver (I think). I don't see fesco anywere when using grep.

The computer is an Asus G74sx laptop.

Any and all information is appreciated. Thank you.

Edit:
Okay, so I don't know how much this helps, but I have another machine (running linux) with a working usb3 port. I started checking for differences between the two in xhci_hcd and ehci_hcd (just in case) and found that in /sys/bus/pci/drivers/ the working system has a folder "xhci_hcd", whereas the non-working system does not. At first I thought to myself, "hey, maybe I can copy it over from the one system to the other. Even as root, I can't even copy those files. So clearly something somewhere else in the system is going haywire. Don't know if this helps or obfuscates, but it is a detail.

Edit 2: The error message
The issue seems to be related to putting the system into suspend mode. I'm booting from a live-disk so I can quickly erase any changes. When I pt the machine into suspend mode it usually goes down without an issue. When it comes back up the usb 3 works fine. Sometimes, rather out of the blue, there is an error. Once the error occurs, I have to pull the plug on the machine and reset my live disk to get the port back.

The message doesn't last very long, only a few milliseconds but I got it on my camera.

The error message:

xhci_hcd 0000:04:00.0: PCI post-resume error -110!
xhci_hcd 0000:04:00.0: HC died; cleaning up
xhci_hcd 0000:04:00.0: HC died; cleaning up
dpm_run_callback(): pci_pm_resume+0x0/0xb0 returns -110
PM: Device 0000:04:00.0 failed to resume async: error -110
dpm_run_callback(): usb_dev_resume+0x0/0x20 [usbcore] returns -5
PM: Device 4-1.4 failed to resume async: error -5

Edit 3: Possible answer? (needs testing) Reading this, I found that if I manually unbind the usb3 then call systemctl suspend, then when I wake it up and manually bind the usb3 device, it works. I ran this 150 times, which if you consider that it will usually fail between 2 and 10 times, that is enough standard deviations from the mean, so I'm going to assume that it works. I put the bind and unbind into into "/etc/pm/sleep.d/20_custom-xhci_hcd". Then checked to make sure that it was executable.

#!/bin/sh
#File: "/etc/pm/sleep.d/20_custom-xhci_hcd"

case "${1}" in
    hibernate|sleep)
        #unbind
        echo "Unbinding xhci device"
        echo -n "0000:04:00.0" > /sys/bus/pci/drivers/xhci_hcd/unbind
    ;;
    resume|thaw)
        # bind
        echo "Binding xhci device"
        ehco -n "0000:04:00.0" > /sys/bus/pci/drivers/xhci_hcd/bind
    ;;
esac

I don't think this file ever gets called because I never saw the echo outputs. And thinking about it, it makes sense since this machine doesn't have pm-utils, and uses systemd instead. So I moved it to /usr/lib/systemd/system-sleep/ as per this site and adjusted it to:

#!/bin/sh
#File: "/usr/lib/systemd/system-sleep/xhci_hcd.sleep"

case $1/$2 in
    pre/*)
        #unbind
        echo "Unbinding xhci device"
        echo -n "0000:04:00.0" > /sys/bus/pci/drivers/xhci_hcd/unbind
    ;;
    post/*)
        # bind
        echo "Binding xhci device"
        ehco -n "0000:04:00.0" > /sys/bus/pci/drivers/xhci_hcd/bind
    ;;
esac

as stated in the same site. Then set it to executable. I'm going to test this but I think I'm feeling the love. If it works I'll post this to the answers part.

Answer 1

Finding the device
First, we need to find out what the device number is. If the port is enabled and you can see it with the command lsusb then use ls /sys/bus/pci/drivers/xhci_hcd. The device will be a number in the format xxxx:xx:xx.x and will most likely be the first entries returned from the ls command.

Resetting the port
If the port is not visible, it means that the port is not working, but it can be reset by removing all power to the machine. Shutdown the computer, remove all batteries and power cords, and wait 10 seconds. Then plug your cord back in and boot the machine. Then look for the device number again.

My device number is 0000:04:00.0, but it may be different. An example I have seen is elsewhere 0000:00:14.0. Remember or write down your number(s). We will need it for binding and unbinding. There may be more than one if you have multiple usb 3 ports.

Determining power management framework
For apt/aptitude/dpkg (ubuntu/debian/mint):
dpkg --get-selections | grep pm-utils
If something is returned, you have pm.

For pacman package manager (arch)
pacman -Qe | grep pm-utils
If something is returned, you have pm.

For rpm package manager (fedora, centos, etc...):
rpm -qa | grep pm-utils
If something is returned, you have pm.

For others, you can try these, I don't know how they all work and don't have a system to test them on.

Note: just because the packages installed does not imply that you are using it, but there is a good chance you are. Another thing you can do is simply cd /etc/pm/ and if it exists you can put the script there. Technically, I don't think there is anything wrong with having an unbinding script in both places. If someone wants to leave a comment on whether or not this is true, or if there is a better way to determine if pm is used, that would be fantastic.

systemd suspend script (no pm utils)
If you are using systemd or systemctl without pm we need to put the script in /usr/lib/systemd/system-sleep/xhci_hcd.sleep. For my machine the script looks like:

#!/bin/sh
#File: /usr/lib/systemd/system-sleep/xhci_hcd.sleep

case $1/$2 in
        pre/*)
                # Unbind
                echo "Unbinding xhci Device"
                echo -n "0000:04:00.0" > /sys/bus/pci/drivers/xhci_hcd/unbind
        ;;
        post/*)
                # bind xhci_dev
                echo "Rebinding xhci Device"
                echo -n "0000:04:00.0" > /sys/bus/pci/drivers/xhci_hcd/bind
        ;;
esac

Replace the 0000:04:00.0 with your device number in both instances. If you have multiple device numbers, run the bind and unbind for each. i.e if you have ports xxxx:xx:xx.x and yyyy:yy:yy.y, you will need echo -n "xxxx:xx:xx.x" > /sys/bus/pci/drivers/xhci_hcd/unbind and echo -n "yyyy:yy:yy.y" > /sys/bus/pci/drivers/xhci_hcd/unbind to unbind the two devices, and echo -n "xxxx:xx:xx.x" > /sys/bus/pci/drivers/xhci_hcd/bind and echo -n "yyyy:yy:yy.y" > /sys/bus/pci/drivers/xhci_hcd/bind to bind the devices. I put the first echo command to let us see when the binding and unbinding happens when we look at the logs using journalctl -b -u systemd-suspend. More information on power management with systemd/systemctl. Save that file then run sudo chmod a+x /usr/lib/systemd/system-sleep/xhci_hcd.sleep to make it executable. Personally I would reboot the system to ensure that the new file takes effect, but I believe it may take effect immediately. If it doesn't and you put the system to sleep (or suspend/hibernate), look at how you reset the port above.

pm suspend script (pm utils are installed)
If you are using pm utils we need to put the script in /etc/pm/sleep.d/20_custom-xhci_hcd

#!/bin/sh
#File: "/etc/pm/sleep.d/20_custom-xhci_hcd"

case "${1}" in
    hibernate|sleep)
        #unbind
        echo "Unbinding xhci device"
        echo -n "0000:04:00.0" > /sys/bus/pci/drivers/xhci_hcd/unbind
    ;;
    resume|thaw)
        # bind
        echo "Binding xhci device"
        ehco -n "0000:04:00.0" > /sys/bus/pci/drivers/xhci_hcd/bind
    ;;
esac

Replace the 0000:04:00.0 with your device number in both instances. If you have multiple device numbers, run the bind and unbind for each device. See the instructions below the script for systemd suspend script, but instead use chmod a+x /etc/pm/sleep.d/20_custom-xhci_hcd to make the file executable. Then reboot and test it.

More helpful resources:

• man pages
• Arch linux power management
• Arch linux systemd
• Ubuntu suspend/hibernate bug fix