Gigabyte GA-Z170-HD3P - Verbindung zu USB-Geräten bricht nach dem Aufwachen aus dem Ruhezustand ab

  • Vielen Dank! Kannst du da USB-Speichermedien mit einschließen? Wenn sich andere USB-Geräte (Maus, Tastatur...) verabschieden bekommt man das ja nur mit, wenn man sich die Logdateien anschaut. Bei Speichermedien gibt's die Fehlermeldung wie im ersten Beitrag zu sehen.


    Dein USB-Problem sollte aber in den Griff zu bekommen sein. Ich schlage vor, du eröffnest dazu ein neues Thema und hängst dort mal deine DSDT (falls im Einsatz), die config.plist und einen IOReg-Dump an.

  • Hat sich erledigt!


    Es war so einfach:


    "Comment: Change 15 port limit to 24 in XHCI kext 10.13 PB1Find: 837D8C10Name: AppleUSBXHCIPCIReplace: 837D8C1B"


    einfach mal direkt in der AppleUSBX geändert und es läuft! so vorne, als auch hinten :-))) Backplug, da steht die TimeMashine audoch drauf :-))))

  • Das habe ich mir schon fast gedacht, der Portlimitpatch ist aber keine Dauerlösung. Wenn du dir jetzt mal im IORegExplorer unter /_SB/PCI0@0/XHC die Ports anschaust, solltest du eine ziemlich lange Liste sehen. Knapp die Hälfte der dir dort angezeigten Ports werden aber nicht funktionieren. Lass es ruhig erstmal so und wenn du wieder Zeit hast: neues Thema eröffnen.


    Aja: Kannst du bitte testen, ob USB-Speichermedien nach dem Aufwachen aus dem Ruhezustand verfügbar sind?

  • Seltsam, dass USB3-Geschwindigkeit nicht erreicht wird.


    Die Ursache war: ich hatte ein USB-Verlängerungskabel benutzt. Das wohl nur USB2 übertragen kann.


    Ohne das Kabel wird volle USB3-Geschwindigkeit erreicht.

    Intel - diverse geniale Hardware bis einschließlich Skylake, damals...

    AMD X6 1035T Silentmaxx TwinBlock - ASRock N68-S -8GB RAM - XFX HD 6450 Passiv - Etasis EFN-300

    AMD 7 3700X - Noctua NH-P1 - B550 Aorus Pro V2 - RX460 Passiv - Silentmaxx Fanless II 500 Platinum

    - - - - - - - - HOWTO: RYZENTOSH - - - - - - - -

  • Ja, die Kabel... Das hatte ich doch heute auch schon :)


    Ich weiß gar nicht, in welche Richtung ich jetzt noch forschen soll. Doch mal F22a ausprobieren?

  • Mittlerweile gibt es die Version F22d (2017.12.01):


    Zitat

    Update Intel ME for security vulnerabilities


    Hat diese Version schon jemand ausprobiert?

  • Das habe ich mir schon fast gedacht, der Portlimitpatch ist aber keine Dauerlösung. Wenn du dir jetzt mal im IORegExplorer unter /_SB/PCI0@0/XHC die Ports anschaust, solltest du eine ziemlich lange Liste sehen. Knapp die Hälfte der dir dort angezeigten Ports werden aber nicht funktionieren. Lass es ruhig erstmal so und wenn du wieder Zeit hast: neues Thema eröffnen.


    Aja: Kannst du bitte testen, ob USB-Speichermedien nach dem Aufwachen aus dem Ruhezustand verfügbar sind?


    USB Speichermedien, egal ob SSD oder HDD, alle verfügbar.


  • Es geht nicht darum, dass USB Geräte nicht funktionieren, sondern dass unbenutzte/unbelegte/unfunktionelle Software Ports in der Liste angezeigt werden. Die Hälfte deiner XHC Liste ist durch virtuelle Schnittstellen belegt, nur an die andere Hälfte kann man wirklich was anschließen...

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.


  • USB Speichermedien, egal ob SSD oder HDD, alle verfügbar.


    Vielen Dank. Jetzt weiß ich schonmal, dass ein BIOS-Update helfen könnte. Mal schauen, ob ich das auch wirklich mache. Nicht, dass ich mir hinterher noch ganz andere Probleme einhandle.

  • also ich kann an alle USB-Schnittstellen was anschließen, ditt läuft allet, jetzt auch ohne den ganzen manuellen Port-Kram, lag scheinbar an der 10.13.1 Version, mit USBInjectAllKext ist alles wie früher

  • Da frage ich zur Sicherheit nochmal nach, so eine Meldung hast du tatsächlich noch nicht zu Gesicht bekommen?


  • Never ever! das sehe ich nur, wenn ich wie ein Wahnsinniger den USB Stick OHNE "auswerfen" rausziehe, quasi wie beim .... *lol*

  • Das Update auf f22d hat das Problem leider nicht behoben. Naja, jetzt sind wenigstens die nervigen, wiederkehrenden Booteinträge weg.

  • Jepp, deshalb war ich eigentlich froh, dass man mein Board bei Auslieferung schon auf F20 geupdated hat

  • Nach dem Update auf F22e hatte ich mit der extrahierten DSDT immer folgende Kernel Panic:



    In @Brumbaers großartigem Beitrag ist mir direkt das hier aufgefallen:



    Theorie ...
    Irgendwo im BIOS ist eine DSDT gespeichert und diese wird dann an Clover und von dort an macos übergeben. Ändert man was an den BIOS Einstellungen, wird eine neue DSDT erstellt. Speichert man eine eigene DSDT im patched Ordner, ersetzt Clover die BIOS-DSDT durch die eigene. Das ist kein Problem, solange die Änderung einer BIOS Einstellung nicht eine Änderung in der DSDT bewirkt. Denn diese Änderung wird nicht automatisch in die eigene DSDT übernommen. Dann passen verwendete DSDT und BIOS Einstellungen nicht mehr zueinander.


    Da war doch was... Die APCI-Tables hatte ich anscheinend direkt nach dem Update extrahiert und danach noch Einstellungen im UEFI vorgenommen. Also fix die ACPI-Tables nochmal mit Clover extrahiert und jetzt ist die Kernel Panic weg.


    Dann noch das hier, das ist für mich echt verdammt viel Gold wert:



    Die _LID Routine gibt es nur einmal. Was mache ich denn, wenn es eine Routine mehrmals gibt, wie _DSM oder _CRS ?
    Es gibt in der Clover DSDT Patches Tabelle eine Spalte TgtBridge. Dort kann man eine Kennung eines Gerätes eintragen auf das der Patch begrenzt werden soll. Auch wieder als Hexzahlen. TgtBridge ähnelt dem Scope-Befehl. Dummerweise ist die Funktionalität eingeschränkt, da das nur funktioniert, wenn das zu ersetzende Etwas innerhalb des Device-Befehls der TgtBridge steht. Leider werden Scope-Befehle ignoriert.


    Da ich die DSDT nicht patchen möchte und im Log öfter mal das hier gefunden habe:


    Zitat

    2018-02-06 19:26:02.227393+0100 localhost kernel[0]: (AppleACPIPlatform) Wake reason: GLAN XDCI


    ... musste ich das direkt mal ausprobieren. ACPI-Patches, mit denen ich die Methode _PRW in den Geräten XDCI und GLAN in XPRW umbenannt habe:



    Dabei kommt dann das hier raus:



    Und dazu diese SSDT:



    Sollte funktionieren... Wobei ich mich frage, ob ich noch eine Dummy-Methode namens "XPRW" anlegen sollte? Nee, Unsinn. XPRW wird ja eh nicht aufgerufen.

    5 Mal editiert, zuletzt von Harper Lewis ()

  • Ich zwar nur NIX verstanden, aber das war schon spannend. Die Erkenntnis: Ich weiß, dass ich nix weiß und Ahnung ist auch ausverkauft. Aber ich kenne nun einen, der einen kennt und der weiß, was ich nicht weiß."


    "Wissen ist Macht", sagte da mal einer. Aber nix Wissen macht auch nix – wenn man jemanden mit Macht kennt".


    Und diese Hacki-Forum ist eine echte "Machtzentrale". :thumbsup::dafuer:

    • FANLESS II 500/600 Watt Netzteil Platinum 0dB(A)!
    • ASRock Z370 Pro4
    • intel Core i5-8400
    • 32GB DDR4-2133 Crucial 4x8GB
    • SSD SATA3 1000GB Samsung 850 EVO
    • LG GH-24NS DVD-Brenner
    • SAPPHIRE PULSE Radeon™ RX 570 8GD5
    • onBoard HD-Sound 6/8Kanal
    • Card Reader intern
    • Dual BOOT mit WIN10 Pro
  • Den Fix brauche wohl doch nicht. Wake reason: GLAN XDCI sehe ich im Log immer nur kurz vor dem Einschlafen des Rechners, der aber zwischendurch nicht aus dem Ruhezustand aufwacht. Es ist aber gut zu wissen, dass das Umbennen mit TgtBridge so einfach funktioniert. Vielleicht kann ich das ja nochmal gebrauchen...


    @silenthunter: Das Board läuft bis auf das hier beschriebene USB-Problem sehr gut mit F22e.

  • Weil danach gefragt wurde: Anbei mal mein EFI-Verzeichnis für das Board + R9 280, 10.12.6

    Dateien

    • EFI.zip

      (10,69 MB, 48 Mal heruntergeladen, zuletzt: )
  • Ich bin zufällig heute in einem anderen Forum über die Lösung gestolpert: X.M.P.-Profile in den UEFI-Einstellungen deaktivieren, XMPDetection in der config.plist aktivieren. Die Systeminformation zeigt dann für alle RAM-Riegel eine Geschwindigkeit von 2998MHz statt 3000MHz an, USB-Geräte werden aber nach dem Aufwachen aus dem Ruhezustand nicht mehr ausgeworfen. Nach über einem Jahr kann ich endlich den grünen Haken an das Thema machen.