Kein USB 3 Arch Linux 3.15.1

Kein USB 3 Arch Linux 3.15.1

Bis zu meinem letzten Neustart konnte ich meinen USB-3-Port verwenden. Ich habe das System erst vor nicht allzu langer Zeit installiert, also hatte ich bis dahin Treiber konfiguriert und installiert, aber das war die Sitzung, in der ich tatsächlich gearbeitet hatte. Ich habe den xf86-input-synaptics-Treiber installiert, aber ich habe ihn einfach entfernt und erneut gebootet, um zu sehen, ob das das Problem verursachte, da er nicht zurückkam, tat er es nicht. Jetzt stecke ich fest. Ich habe in vielen Foren gesehen, dass Leute Probleme damit haben, aber der Port wird normalerweise in lsusb, dmesg oder lspci angezeigt.

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

LSPC | 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 -kurzer -Klasse-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

Bisher wurde mir lediglich gesagt, dass das Gerät defekt sei, da es auf keinem dieser Geräte angezeigt wird. Nachdem ich nun gesehen habe, dass es funktioniert, weiß ich, dass dies nicht der Fall ist und dass es sich lediglich um ein Konfigurationsproblem handelt.

Als es funktionierte, enthielt die Ausgabe von lsusb einen Fesco-Treiber (glaube ich). Ich sehe Fesco nirgendwo, wenn ich grep verwende.

Der Computer ist ein Asus G74sx-Laptop.

Wir sind für jede Information dankbar. Vielen Dank.

Edit:
Okay, ich weiß nicht, wie sehr das hilft, aber ich habe eine andere Maschine (mit Linux) mit einem funktionierenden USB3-Anschluss. Ich habe angefangen, nach Unterschieden zwischen den beiden in xhci_hcd und ehci_hcd zu suchen (nur für den Fall) und habe festgestellt, dass das funktionierende System in /sys/bus/pci/drivers/ einen Ordner „xhci_hcd“ hat, während das nicht funktionierende System keinen hat. Zuerst dachte ich mir: „Hey, vielleicht kann ich es von dem einen System auf das andere kopieren.“ Selbst als Root kann ich diese Dateien nicht einmal kopieren. Also läuft eindeutig irgendwo anders im System etwas schief. Ich weiß nicht, ob das hilft oder die Sache verschleiert, aber es ist ein Detail.

Bearbeitung 2: Die Fehlermeldung
Das Problem scheint damit zusammenzuhängen, dass das System in den Suspend-Modus versetzt wird. Ich boote von einer Live-Disk, damit ich alle Änderungen schnell löschen kann. Wenn ich die Maschine in den Suspend-Modus versetze, stürzt sie normalerweise ohne Probleme ab. Wenn sie wieder hochfährt, funktioniert USB 3 einwandfrei. Manchmal tritt aus heiterem Himmel ein Fehler auf. Sobald der Fehler auftritt, muss ich den Stecker der Maschine ziehen und meine Live-Disk zurücksetzen, um den Port wiederherzustellen.

Die Nachricht dauert nicht sehr lange, nur ein paar Millisekunden, aber ich habe sie auf meiner Kamera.

Die Fehlermeldung:

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: Mögliche Antwort? (muss getestet werden) LesenDas, ich habe festgestellt, dass es funktioniert, wenn ich das USB3-Gerät manuell entbinde und dann aufrufe systemctl suspend, und wenn ich es dann aufwecke und das USB3-Gerät manuell binde. Ich habe das 150 Mal ausgeführt, und wenn man bedenkt, dass es normalerweise zwischen 2 und 10 Mal fehlschlägt, sind das genug Standardabweichungen vom Mittelwert, also gehe ich davon aus, dass es funktioniert. Ich habe das Binden und Entbinden in "/etc/pm/sleep.d/20_custom-xhci_hcd" eingefügt. Dann habe ich überprüft, ob es ausführbar ist.

#!/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

Ich glaube nicht, dass diese Datei jemals aufgerufen wird, da ich die Echo-Ausgaben nie gesehen habe. Und wenn man darüber nachdenkt, macht es Sinn, da diese Maschine keine pm-utils hat und stattdessen systemd verwendet. Also habe ich sie gemäßDiese Seiteund angepasst an:

#!/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

wie auf derselben Site angegeben. Dann setzen Sie es auf ausführbar. Ich werde das testen, aber ich glaube, ich bin begeistert. Wenn es funktioniert, werde ich es im Antworten-Teil posten.

Antwort1

Suchen des Geräts
Zuerst müssen wir die Gerätenummer herausfinden. Wenn der Port aktiviert ist und Sie ihn mit dem Befehl sehen können, lsusbverwenden Sie ls /sys/bus/pci/drivers/xhci_hcd. Das Gerät hat eine Nummer im Format xxxx:xx:xx.x und ist höchstwahrscheinlich der erste Eintrag, der vom lsBefehl zurückgegeben wird.

Zurücksetzen des Ports
Wenn der Port nicht sichtbar ist, bedeutet dies, dass er nicht funktioniert. Er kann jedoch zurückgesetzt werden, indem Sie die Stromversorgung des Computers vollständig unterbrechen. Fahren Sie den Computer herunter, entfernen Sie alle Batterien und Netzkabel und warten Sie 10 Sekunden. Schließen Sie dann das Kabel wieder an und starten Sie den Computer neu. Suchen Sie dann erneut nach der Gerätenummer.

Meine Gerätenummer ist 0000:04:00.0, aber sie kann auch anders lauten. Ein Beispiel, das ich anderswo gesehen habe, ist 0000:00:14.0. Merken Sie sich Ihre Nummer(n) oder schreiben Sie sie auf. Wir benötigen sie zum Binden und Aufheben der Bindung. Es kann mehrere geben, wenn Sie mehrere USB-3-Anschlüsse haben.

Bestimmen des Energieverwaltungsrahmens
Fürapt/aptitude/dpkg(Ubuntu/Debian/Mint):
dpkg --get-selections | grep pm-utils
Wenn etwas zurückgegeben wird, erhalten Sie eine PN.

FürPacman-Paketmanager(arch)
pacman -Qe | grep pm-utils
Wenn etwas zurückkommt, hast Du eine PN.

FürRPM-Paketmanager(Fedora, CentOS usw.):
rpm -qa | grep pm-utils
Wenn etwas zurückgegeben wird, erhalten Sie eine PM.

FürAndere, Sie können diese ausprobieren. Ich weiß nicht, wie sie alle funktionieren, und habe kein System, auf dem ich sie testen könnte.

Notiz:nur weil die Pakete installiert sind, heißt das nicht, dass Sie sie auch verwenden, aber die Wahrscheinlichkeit ist groß, dass Sie es tun. Sie können auch einfach cd /etc/pm/das Skript dort ablegen, falls es existiert. Technisch gesehen ist es meiner Meinung nach nicht falsch, an beiden Stellen ein Skript zum Aufheben der Bindung zu haben. Wenn jemand einen Kommentar dazu hinterlassen möchte, ob dies zutrifft oder nicht, oder ob es eine bessere Möglichkeit gibt, festzustellen, ob pm verwendet wird, wäre das fantastisch.

systemd-Suspend-Skript (keine PM-Dienstprogramme)
Wenn Sie systemd oder systemctl ohne pm verwenden, müssen wir das Skript einfügen /usr/lib/systemd/system-sleep/xhci_hcd.sleep. Für meinen Rechner sieht das Skript so aus:

#!/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

Ersetzen Sie in beiden Fällen 0000:04:00.0 durch Ihre Gerätenummer. Wenn Sie mehrere Gerätenummern haben, führen Sie für jede das Binden und Aufheben der Bindung aus. Wenn Sie also die Ports xxxx:xx:xx.x und yyyy:yy:yy.y haben, müssen Sie echo -n "xxxx:xx:xx.x" > /sys/bus/pci/drivers/xhci_hcd/unbindund echo -n "yyyy:yy:yy.y" > /sys/bus/pci/drivers/xhci_hcd/unbindzum Aufheben der Bindung der beiden Geräte und echo -n "xxxx:xx:xx.x" > /sys/bus/pci/drivers/xhci_hcd/bindund echo -n "yyyy:yy:yy.y" > /sys/bus/pci/drivers/xhci_hcd/bindzum Binden der Geräte verwenden. Ich habe den ersten Echo-Befehl eingegeben, damit wir sehen können, wann die Bindung und Aufhebung der Bindung erfolgt, wenn wir die Protokolle mit betrachten journalctl -b -u systemd-suspend. Weitere Informationen zuEnergieverwaltungmit systemd/systemctl. Speichern Sie diese Datei und führen Sie sie dann aus, sudo chmod a+x /usr/lib/systemd/system-sleep/xhci_hcd.sleepum sie ausführbar zu machen. Ich persönlich würde das System neu starten, um sicherzustellen, dass die neue Datei wirksam wird, aber ich glaube, sie kann sofort wirksam werden. Wenn dies nicht der Fall ist und Sie das System in den Ruhezustand (oder Suspend/Ruhezustand) versetzen, sehen Sie sich an, wie Sie den Port oben zurücksetzen.

pm-Suspend-Skript (pm-Dienstprogramme sind installiert)
Wenn Sie PM-Utilities verwenden, müssen wir das Skript einfügen 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

Ersetzen Sie in beiden Fällen 0000:04:00.0 durch Ihre Gerätenummer. Wenn Sie mehrere Gerätenummern haben, führen Sie die Bindung und Unbindung für jedes Gerät aus. Lesen Sie die Anweisungen unter dem Skript für das Systemd-Suspend-Skript, verwenden Sie jedoch stattdessen, chmod a+x /etc/pm/sleep.d/20_custom-xhci_hcdum die Datei ausführbar zu machen. Starten Sie dann neu und testen Sie es.

Weitere hilfreiche Ressourcen:

verwandte Informationen