Sleep/Wake Probleme debuggen

    Hallo Forum!


    Ich arbeite gerade an meinem Gigabyte X299X und scheitere leider am Sleep/Wake. Ich weiß, dass das ein schwieriges Thema ist und habe auch echt viel dazu gesucht und ausprobiert.

    USB soll ja häufig ein Grund sein. Die XHCIs habe ich mit SSDTs passend nach XHCI, XHC1 und XHC2 umbenannt, danach den Quirk "XhciPortLimit" auf true gesetzt und die USBInjectAll.kext geladen und dann mit dem Hackintool die passende USBPorts.kext erstellt. Danach den Quirk und InectAll wieder entfernt und die USBPortskext in die config.plist eingetragen. In ioregistryexplorer sieht auch alles gut aus. Die Ports funktionieren auch wunderbar.

    Leider will der Rechner dennoch nicht aus dem Sleep aufwachen. Er spring kurz an und erzeugt ein Kernel Panic bei schwarzen Bildschirm. Und hier weiß ich nicht weiter.


    Daher wollte ich fragen, wie ich das Problem am besten einenge, um eine Lösung zu finden. Der Kernel Panic habe ich mir durchgelesen, aber nicht das Keyword gefunden, dass mich auf den richtigen Weg gebracht hat. Wie kann ich am besten vorgehen? Gibt es noch Logs, in denen ich etwas finden kann? Nutzt es die Debug-Version von OpenCore zu verwenden?

    Gebt mir bitte einen kleinen Anstoss, um mich in die richtige Richtung zu bewegen :)


    Vielen Danke


    EDIT: Hier der Bericht vom Kernel Panic

    Moin, du machst da einige ACPI Kunststücke auf deiner EFI. Ist dir bewusst was die einzelnen Eingriffe im Detail tun? Besonders mit SSDT-THUNDERBOLT.aml sehe ich Probleme.


    An deiner Stelle würde ich mal ein paar ACPI Eingriffe deaktivieren und beobachten wie sich das auf den Sleep auswirkt.

    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.

    Hallo kuckkuck!


    Danke für den Hinweiß. Leider weiß ich das nicht im Detail. Ich versuche mich in das Thema einzulesen, finde da aber wenig Gutes. Das Video von al6042 kenne ich natürlich. Ich wünschte, jemand würde zum Beispiel die OC ACPI Exampels in einem Video Schritt für Schritt erklären. Ich glaube, dass da einigen Unwissenden mit geholfen wäre :)


    Die Thunderbolt werde ich morgen als erstes mal deaktivieren. Die Datei stammt von CaseySJ. Thunderbolt funktioniert dank modifizierter Firmware und der SSDT auch wunderbar. Sogar mit Hotplug und so weiter.


    Welche andere SSDT macht noch Kunststücken? Ich melde mich, nach meinem Test.


    Nochmals Danke!

    SSDT-RTC0 ist ein Ersatz für SSDT-AWAC, wenn STAS nicht existiert;

    SSDT XHC wird teilweise durch SSDT-Thunderbolt ausgehebelt, da sich Thunderbolt mit weit mehr als nur Thunderbolt beschäftigt und teilweise Werte für _UPC setzt;

    Rename zu XHC1 bewirkt dass Apples Mechanismen auf den Controller matchen, deswegen benennt man die Controller zu zB XHC um;

    SSDT DTGP ist kosmetisch, aber wird wohl von ANS (kosmetisch?) und Thunderbolt referenziert;

    Einige Renames sind etwas gewagt oder kosmetischer Natur.

    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.

    Einmal editiert, zuletzt von kuckkuck ()

    Hallo kuckkuck !


    Danke für deine Hilfe!

    STAS existiert bei mir, richtig?


    Ich habe auch einige SSDTs deaktiviert, aber der Wake funktioniert weiterhin nicht.

    • SSDT-ANS.aml
    • SSDT-AWAC.aml
    • SSDT-RTC0.aml
    • SSDT-PLUG.aml
    • SSDT-THUNDERBOLT.aml
    • SSDT-USBX.aml
    • SSDT-X299-DTGP.aml
    • SSDT-X299-XHC.aml


    Die RadeonVII habe ich auch mal gegen eine R9 280X ausgetauscht, um zu schauen ob es an ihr liegt. Kein Unterschied. Ich gehe jetzt noch mal die Darkwakes durch.


    Was könnte ich noch ausprobieren?


    Vielen Danke :)

    Zitat von Tirom

    STAS existiert bei mir, richtig?

    Sieht gut aus.


    Wie lautet denn der aktuelle Fehler bei Sleep?

    Wofür brauchst du SSDT-X299-XHC.aml?


    Mein Ziel war es nicht dich langfristig dazu zu bewegen alle diese ACPI Patches wegzulassen, jedoch kannst du probieren die verdächtigen SSDTs zeitweise zu deaktivieren, um herauszufinden welchen Einfluss sie auf den Sleep haben.


    Hier noch ein paar interessante Terminal Befehle zu Sleep: Problem mit Sleep/Wake- Update 2018: UI Lag nach Wake

    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.

    Hallo kuckkuck!

    Ich bin jetzt alle darkwakes 0, 8, 2, 1, 4, 3 durch und hab weiterhin keinen Erfolg. Ich entferne jetzt noch mal die XHC. Ich dachte, die XHCS müssen korrekt heißen, damit Sleep gut funktioniert. War wohl falsch ;)


    Hier der aktuelle Bericht:

    Häng mir mal bitte einen IORegistry-Explorer Dump an. Hast du alle BIOS Settings nochmal penibelst abgecheckt?

    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.

    Hey kuckkuck !

    Ich schaue gleich noch mal über die BIOS Settings drüber.

    Aktuell habe von MacPro7,1 (war irgendwo empfohlen) wieder auf iMacPro1,1 gewechselt. Mit darkwake=0 geht es nicht. Ich probiere da mal weiter mit rum.

    Die ioregistryexplorer Infos habe ich dir angehängt. Gebootet habe ich jetzt mit meinen ganzen Patches:

    • PC00 -> PCI0
    • LPC0 -> LPCB
    • FPU_ -> MATH
    • TMR_ -> TIMR
    • PIC_ -> IPIC
    • PMC1 -> PMCR
    • IOTR -> LDRC
    • SMBS._ADR -> XSBU.XADR
    • CPxx -> PRxx


    Hier die Infos aus dem Terminal:

    Code
    1. pmset -g
    3. System-wide power settings:
    4. Currently in use: hibernatemode 0 disksleep 10 powernap 1 sleep 1 Sleep On Power Button 1 ttyskeepawake 1 hibernatefile /var/vm/sleepimage tcpkeepalive 1 autorestart 0 displaysleep 10
    Code
    1. sudo pmset -g log | tail -n 20
    3. 2020-07-11 18:57:20 +0200 : Showing all currently held IOKit power assertions
    4. Assertion status system-wide: BackgroundTask 0 ApplePushServiceTask 0 UserIsActive 1 PreventUserIdleDisplaySleep 0 PreventSystemSleep 0 ExternalMedia 1 PreventUserIdleSystemSleep 0 NetworkClientActive 0
    5. Listed by owning process: pid 102(powerd): [0x0000001800088000] 00:12:48 ExternalMedia named: "com.apple.powermanagement.externalmediamounted" pid 145(hidd): [0x0000002f000980de] 00:00:00 UserIsActive named: "com.apple.iohideventsystem.queue.tickle serviceID:100000683 name:AppleHIDKeyboardEve product:Apple Keyboard eventType:3" Timeout will fire in 599 secs Action=TimeoutActionRelease
    6. Kernel Assertions: 0x4=USB id=502 level=255 0x4=USB mod=01.01.70, 01:00 description=com.apple.usb.externaldevice.14300000 owner=IOUSBHostDevice id=506 level=255 0x4=USB mod=01.01.70, 01:00 description=com.apple.usb.externaldevice.14700000 owner=Mass Storage Device id=507 level=255 0x4=USB mod=01.01.70, 01:00 description=com.apple.usb.externaldevice.14320000 owner=Gaming Mouse G502 id=508 level=255 0x4=USB mod=01.01.70, 01:00 description=com.apple.usb.externaldevice.14330000 owner=Keyboard Hub
    7. Idle sleep preventers: IODisplayWrangler
    Code
    1. sudo pmset -g assertions
    2. 2020-07-11 18:57:54 +0200 Assertion status system-wide: BackgroundTask 0 ApplePushServiceTask 0 UserIsActive 1 PreventUserIdleDisplaySleep 0 PreventSystemSleep 0 ExternalMedia 1 PreventUserIdleSystemSleep 0 NetworkClientActive 0
    3. Listed by owning process: pid 102(powerd): [0x0000001800088000] 00:13:22 ExternalMedia named: "com.apple.powermanagement.externalmediamounted" pid 145(hidd): [0x0000002f000980de] 00:00:00 UserIsActive named: "com.apple.iohideventsystem.queue.tickle serviceID:100000683 name:AppleHIDKeyboardEve product:Apple Keyboard eventType:3" Timeout will fire in 600 secs Action=TimeoutActionRelease
    4. Kernel Assertions: 0x4=USB id=502 level=255 0x4=USB mod=01.01.70, 01:00 description=com.apple.usb.externaldevice.14300000 owner=IOUSBHostDevice id=506 level=255 0x4=USB mod=01.01.70, 01:00 description=com.apple.usb.externaldevice.14700000 owner=Mass Storage Device id=507 level=255 0x4=USB mod=01.01.70, 01:00 description=com.apple.usb.externaldevice.14320000 owner=Gaming Mouse G502 id=508 level=255 0x4=USB mod=01.01.70, 01:00 description=com.apple.usb.externaldevice.14330000 owner=Keyboard Hub
    5. Idle sleep preventers: IODisplayWrangler

    Was genau meinst du mit CPxx -> PRxx? Da sollte doch zumindest eine Zahl stehen, aber auch den Grund des Renames verstehe ich nicht.

    Ist SMBS._ADR -> XSBU.XADR mit irgendeiner SSDT verbunden? Ansonsten macht das auch wenig Sinn auf den ersten Blick.

    XHCI oder XHC1 solltest du in XHC_ oder dergleichen umbenennen.

    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.

    Einmal editiert, zuletzt von kuckkuck ()

    Genau, xx steht für die ersten 56 Hexwerte CP00 bis CP37 und benennt diese nach PR00 bis PR55 um. Anscheinend ist das aber quatsch, wenn ich dich richtig verstehe.

    Welche Patches soll ich alle deaktivieren/rausschmeißen?


    EDIT: Hab jetzt noch folgenden Patch in die config.plist eingetragen:

    XHCI -> XHC_

    58484349 -> 5848435F


    Jetzt erstelle ich eine neue USBPorts.kext mit hackintool. Bis gleich :)


    EDIT2: Ich bin jetzt Darkwake 0 8 2 1 4 3 und ohne durchgegangen. Alle stürzen ab:

    Einmal editiert, zuletzt von Tirom ()

    Nicht einer davon ist wichtig. PC00 ist völlig in Ordnung, das ist uralt. Hatte ich mal als erster gemacht, weil damals sonst nicht Audio ging, weil AppleALC davon ausging, dass "HDEF" eben in "PCI0" zu finden ist und in den ersten ACPIs der iMacPro ebenfalls PCI0 wie bei allen vorherigen Plattformen vorlag.

    Den LPC0 umzubenennen ist ebenfalls völlig unwichtig. Auch PMC1 wird so wie es ist erkannt. FPU, TMR und PIC ebenso bzw spielen eh keine Rolle. Und SMBS auszublenden damit SBUS erscheint – ist eh nicht kompatibel und wird auf dieser Plattform auch nicht gebraucht. Die einzelnen Prozessor-Cores umzubenennen ist ebenfalls Tinnef und bringt rein gar nichts. Und wozu den XHCI umbenennen? Auch der läuft nativ, lediglich mittels eigener Kext etwas näher spezifizieren.

    Um dein Wake zu erreichen, brauchst du auch nicht mit "Darkwake" experimentieren. Die Holzhammer-Methode – der einzige Patch der ausreichend ist – die Methode "_PRW" in meinetwegen "XPRW" umzubenennen, schon greift die nicht mehr und lässt den Rechner schlafen wie er soll. Aufwachen dann über kurzes drücken auf den An/Ausschalter.

    ASUS PRIME X299-DELUXE i9-9940X • DDR4 64GB • SSD 960 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon RX Vega 64 • BMD Intensity Pro 4K

    ASUS WS X299 SAGE/10G i9-10980XE • DDR4 64GB • SSD 970 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon VII • BMD DeckLink 4K Extreme 12G


    Ordnung ist die primitivste Form von Chaos. (Hans-Jürgen Quadbeck-Seeger)

    Hallo apfelnico!


    Danke für die ausführliche Erklärung. Die nicht-Apple-ACPI scheint ja inzwischen echt gut aufgefangen zu werden. Das freut mich!


    Eine Frage zu der _PRW -> XPRW Umbenennung. Das macht man doch, wenn der Rechner unbeabsichtigt durch USB geweckt wird, richtig? Das ist ja nicht mein Problem: Mein Rechner schläft wie er soll, wenn ich ihn aufwecke stürzt er leider ab. Der Monitor bleibt schwarz und bei der Maus geht die LED nicht an. Die Lüfter laufen aber.


    Aber Danke für deine Hilfe, meine Config ist wieder etwas leerer geworden ;)

    Ah, falsch verstanden. Dachte er geht kurz in den Sleep, um danach gleich wieder aufzuwachen. Kenne leider nicht das Gigabyte, weiß nicht, was da anders läuft. Quirks dafür/dagegen?

    Zu den XHCx. Hier ist es schon interessant, die weiteren USB-Controller – nicht "Basis" auf PC00, sondern weitere an RPxx, welche dann einfach nur alle gleich "PXSX" heißen, umzubenennen. Das ist keinesfalls zwingend erforderlich, es läuft auch so. Es hilft nur ungemein, wenn man auch hier die Ports näher mittels Kext spezifizieren möchte, dann kann man diese sehr individuell eben mit XHC2 etc ansprechen. Auch lassen die sich dann in zum Beispiel "Hackintool" besser auseinander halten. Geht aber auch anders.

    ASUS PRIME X299-DELUXE i9-9940X • DDR4 64GB • SSD 960 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon RX Vega 64 • BMD Intensity Pro 4K

    ASUS WS X299 SAGE/10G i9-10980XE • DDR4 64GB • SSD 970 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon VII • BMD DeckLink 4K Extreme 12G


    Ordnung ist die primitivste Form von Chaos. (Hans-Jürgen Quadbeck-Seeger)

    X299 ist wirklich nicht meine Plattform, deswegen ist es sehr gut, dass hier jetzt jemand mit im Boot ist der sich da ein wenig besser auskennt :)

    Zitat von apfelnico

    Und wozu den XHCI umbenennen?

    Entweder XHCI oder XHC1 matcht auf manche Port Injectors von Apple SMBios, die in AppleUSBXHCIPCI hinterlegt sind, deswegen ist das der einzige Rename den ich noch nachvollziehen kann.

    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.

    apfelnico Kein Problem, ist ja leider auch etwas unübersichtlich geworden, bei meinem Problem... Kann ich die Umbenennung der anderen XHCs auch in der config.plist machen oder muss das in einer SSDT geschehen? Die hatte ich mal gehabt, aber inzwischen deaktiviert.


    kuckkuck Inzwischen ist nix anderes mehr drin, außer XHCI -> XHC_ mit neu erstellter USBPorts.kext. Dann bin ich noch mal alle darkwakes durchgegangen, aber keiner hat funktioniert. :/

    Zitat von Tirom

    Inzwischen ist nix anderes mehr drin, außer XHCI -> XHC_

    Es kann sein, dass ich mich hier getäuscht habe und es XHC1 statt XHCI heißen muss. Ich kann das morgen mal nachschauen. Du selber kannst einfach mal im IOReg nachschauen, ob irgendein Controller XHC1 heißt und wenn ja, ob die von dir eingestellten Ports trotzdem richtig übernommen wurden.

    Das Testen der darkwakes ist mMn. aktuell unnötige Arbeit, da wir mit einem viel tiefer greifenden Problem in der Panik zu kämpfen haben. Vielleicht ist das ja ein bekanntes Problem mit X299 und jemand hat einen Fix parat. Mir fallen auf das Fehlerbild leider keine konkreten Vorschläge ein, nur Dinge die man ausprobieren könnte.

    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.

    Hey kuckkuck!

    Danke für die Info bezüglich der darkwakes, das spart eine Menge Zeit :)


    Ich bin jetzt gerade nur etwas verwirrt, wie ich weiter manchen soll. In meinem System habe ich ohne Patches

    • PC00.XHCI (Intel USB3)
    • PC00.RP05.PXSX (Thunderbolt)
    • PC00.RP13.PXSX (ASMedia USB-C)

    apfelnico schreibt irgendwo, dass Umbenennungen XHCI -> XHC_ keinen Sinn ergeben, die PXSX -> XHC2/3 aber schon.

    Das geht aber nicht über Opencore, sondern nur über eine SSDT, richtig?

    Soll ich XHCI nach XHC_ oder XHC0 umbenennen oder als XHCI lassen?


    Kann ich sonst irgendwie helfen? Ich habe richtig Lust mich da rein zu knien, weiß aber nicht, was ich wirklich tun kann. Bringt es etwas, die DSDT und die IOReg von einem echten iMacPro zu suchen und mit meinen zu vergleichen? Gebt mir eine Aufgabe :top:


    Danke!

    Tirom

    XHCI bleibt. Die weiteren USB-Controller an den PCIe Root Ports (RPxx) sind nur allgemein als "PXSX" benannt. Diese würde ich umbenennen. Nicht aber mit XHC1 anfangen, dieser ist durch Apple anders definiert. Also weiter mit XHC2 und höher. Das geht nur mit einer SSDT. Nicht unbedingt eine neue SSDT dafür anlegen, sondern in der vorhandenen ACPI nach der USB-Deklaration suchen. Bei mir heisst diese "SSDT AMI" und hat eine "TableLength" von "3707". Steht im Header. Damit kannst du diese exakt aus der ACPI entfernen mittels OpenCore:



    Somit kannst du die modifizierte SSDT problemlos einbinden und bekommst keine Probleme. Der Vorteil dadurch ist, dass du später mittels Hackintool alle USB-Controller inklusive deren Ports individuell bestimmen kannst um eine perfekte USB-Kext zu generieren.


    Edit:

    Den Thunderbolt an RP05.PXSX würde ich erstmal davon unberührt lassen. Dessen USB-C Controller ist etwas tiefer versteckt. Dafür gibt es eine eigene SSDT:

    Dateien

    • SSDT-TBOLT3.aml

      (17,36 kB, 120 Mal heruntergeladen, zuletzt: )

    ASUS PRIME X299-DELUXE i9-9940X • DDR4 64GB • SSD 960 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon RX Vega 64 • BMD Intensity Pro 4K

    ASUS WS X299 SAGE/10G i9-10980XE • DDR4 64GB • SSD 970 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon VII • BMD DeckLink 4K Extreme 12G


    Ordnung ist die primitivste Form von Chaos. (Hans-Jürgen Quadbeck-Seeger)

    Hallo apfelnico !


    Danke für die gute Erklärung. Ich fasse noch mal kurz zusammen:

    Ich Suche in meiner DSDT den Abschnitt _SB.PC00.RP13 und kopiere den gesamten "Scope" in eine neue .aml. In dieser nenne ich das "Device (PXSX)" nach "Device (XHC2)" um. Das sieht bei mir so aus:

    Jetzt habe ich aber Fragen:

    Welchen Header muss ich noch hinzufügen? Nehme ich auch den aus meiner DSDT?


    Wenn dann diese SSDT hinzugefügt wird, muss man schauen, dass die Info nicht doppelt vorhanden ist, richtig? Also muss der Bereich in der original DSDT entfernt werden. Daher der ACPI Delete in der config.plist.

    Aber woher weiß ich, was gelöscht werden muss. 53534454 bedeutet SSDT, aber woher bekomme ich die TableLength. Und woher weiß OC, wann der Abschnitt beginnt.


    Sorry, da stehe ich etwas auf dem Schlauch. :think: Gibt es irgendwo eine Einführung: SSDTs für Dummies? :auslach: