Problem mit Ruhezustand

    Ich habe ein für mich schwer nachvollziehbares Problem mit dem Ruhezustand:


    Wenn ich den hackintosh per Mausklick über das Apfelsymbol -> Ruhezustand in den Schlaf versetze funktioniert alles wie es soll. Er geht also in den Schlaf und wacht bei Tastatureingaben oder Mausklicks wieder auf.


    Wenn sich der Hackintosh aber über die Energiesparen-Funktion nach einer bestimmten Zeit in den Ruhezustand versetzt oder wenn ich ihn über die Tastenkombi alt+cmd+eject in den Schlaf versetze wacht er nicht mehr auf. Die Lüfter fangen zwar an zu drehen aber ansonsten passiert nichts sodass ich ihn am powerknopf ausschalten muss.

    Wieso funktioniert der erste Weg aber nicht die anderen beiden? Wo liegt der Unterschied? Ist dies ein bekanntes Problem?


    Ich habe bereits den fixing sleep guide von dortania durchgearbeitet. (https://dortania.github.io/Ope…tall/universal/sleep.html)

    Gibt dir dieser Befehl im Terminal einen Hinweis auf das Problem?

    Code
    1. pmset -g log | grep -i failure
    Quote from anonymous writer

    Gibt dir dieser Befehl im Terminal einen Hinweis auf das Problem?

    Code
    1. pmset -g log | grep -i failure

    er gibt mir hier:

    "Failure during sleep: 0xFFFFFFFF0000001F : EFI/Bootrom Failure after last point of entry to sleep"


    Habe über Google verschiedenes gefunden (Legacy im Bios aktivieren, Serial deaktivieren, ResetHwSig in der Config auf on..) hat bisher nichts geändert.


    VIelleicht helfen die Logs?:

    Habe die config.plist mal angefügt.


    Aber was ich noch immer seltsam finde ist, dass der Ruhezustand einwandfrei funktioniert wenn ich über das Apfel-Symbol oben links gehe und auf "Ruhezustand" klicke. Nur der automatische Ruhezustand und über die Shortcuts amt+cmd+eject funktionieren nicht, bzw. er wacht dann nicht mehr richtig auf.

    Sieht nach dem gleichen Problem aus.

    Fujitsu ESPRIMO C720 Sleep Problem mit OpenCore / Sleep Wake failure in EFI


    Dann könnte eventuell auch das hier helfen.

    Fujitsu ESPRIMO C720 Sleep Problem mit OpenCore / Sleep Wake failure in EFI

    Danke. Habe die Sachen ausprobiert und auch noch was ich sonst alles gefunden habe.

    Der Sleep-Mode geht nun zumindest manchmal so wie er soll, aber bei ca. jedem 4. mal aufwecken kommt wieder der Fehler, dass der Monitor auf Stand-by bleibt aber die Lüfter voll aufdrehen und nur Hard-Reset hilft.

    Ich probiere weiter.. :)

    aber es scheint so als würde er mehr Probleme haben aus dem Schlaf zu kommen je länger er schon drin ist

    Update:

    Habe mal auf Big Sur geupdatet.


    Das Problem, dass er nicht aus dem Schlaf kommt besteht aber immer noch.

    Wenn ich ihn innerhalb von 5 Sekunden nachdem er in den Schlafmodus versetzt habe aufwecke dann wacht er auch auf, aber wenn ich länger warte drehen die Lüfter durch und es tut sich sonst nix.


    Habe alle möglichen Bios-Einstellungen ausprobiert und auch die verschiedenen Power-Management-Terminal-Befehle ausprobiert, es scheint alles nichts zu bringen :/


    Hier mal die Fehlermeldung, kann jemand damit was anfangen?


    Sleep Wake failure in EFI


    Failure code:: 0x00000000 0x0000001f


    Please IGNORE the below stackshot


    ================================================================

    Date/Time: 2021-05-08 19:36:10.857 +0200

    OS Version: ??? ??? (Build ???)

    Architecture: x86_64

    Report Version: 32


    Data Source: Stackshots

    Shared Cache: 94BDF3EE-CD67-34B0-91E1-19D61487C096 slid base address 0x7fff202f0000, slide 0x2f0000


    Event: Sleep Wake Failure

    Duration: 0.00s

    Steps: 1


    Boot args: -v keepsyms=1 debug=0x100 alcid=1 chunklist-security-epoch=0 -chunklist-no-rev2-dev


    Time Awake Since Boot: 14s




    Process: swd [310]

    Architecture: x86_64

    Footprint: 396 KB

    Time Since Fork: 4s

    Num samples: 1 (1)


    Thread 0x8a3 1 sample (1) priority 4 (base 4)

    <thread QoS background (requested background), thread darwinbg, process darwinbg, IO tier 2>

    1 start + 1 (libdyld.dylib + 89917) [0x7fff20619f3d] 1

    1 ??? [0x10d0f4454] 1

    1 ??? [0x10d0f41e8] 1

    1 __stack_snapshot_with_config + 10 (libsystem_kernel.dylib + 146966) [0x7fff205ebe16] 1

    *1 ??? [0xffffff80002331f6] 1

    *1 ??? [0xffffff8000940dae] 1

    *1 ??? [0xffffff800084bf01] 1

    *1 ??? [0xffffff800025651f] 1

    *1 ??? [0xffffff800028d84d] (running) 1


    Binary Images:

    0x7fff205c8000 - 0x7fff205f7fff libsystem_kernel.dylib (7195.101.2) <62A19DE4-50C5-3866-B5B2-43220E379C3B> /usr/lib/system/libsystem_kernel.dylib

    0x7fff20604000 - 0x7fff2063ffff libdyld.dylib (851.27) <9F95C644-D1BD-38D9-9612-6188FE9EA53C> /usr/lib/system/libdyld.dylib

    Model: MacPro6,1, BootROM 428.0.0.0.0, 4 processors, Quad-Core Intel Xeon, 3,4 GHz, 16 GB, SMC 2.20f18

    Graphics: Radeon RX 560, Radeon RX 560, spdisplays_pcie_device, 2 GB

    Memory Module: BANK 1/ChannelA-DIMM1, 8 GB, DDR3, 1600 MHz, 1315, CT102464BA160B.C16

    Memory Module: BANK 3/ChannelB-DIMM1, 8 GB, DDR3, 1600 MHz, 1315, CT102464BA160B.C16

    Network Service: Ethernet, Ethernet, en0

    Serial ATA Device: SanDisk Ultra II 240GB, 240,06 GB

    Serial ATA Device: TOSHIBA DT01ACA100, 1 TB

    USB Device: USB 3.0 Bus

    USB Device: USB Receiver

    USB Device: eLicenser

    USB Device: USB 2.0 Hub

    USB Device: Wireless Mouse

    USB Device: Komplete Audio 6

    USB Device: USB 2.0 Bus

    USB Device: Hub

    USB Device: USB 2.0 Bus

    USB Device: Hub

    Thunderbolt Bus:

    Edited 2 times, last by phil48 ().

    Ist immer noch der gleiche Fehler. RTC Memory Problem.

    Gibt da auch diesen Kext dazu und bei uns im Forum einen Thread. Musst du mal suchen.

    https://github.com/acidanthera/RTCMemoryFixup


    Leider ist es nicht so einfach RTC Probleme zu lösen da man dazu den defekten Bereich finden muss. Der Kext soll helfen diesen Bereich zu finden.

    OpenCore bietet dazu auch was. > MmioWhitelist

    Habe mit die RTCMemoryFixup.kext geladen, mich an den Opencore Guide gehalten und in die Boot-Args zum testen "rtcfx_exclude=00-FF" geschrieben. <br>

    • (To start, you'll need to add rtcfx_exclude=00-FF in boot-args. If after a reboot the RTC errors seems solved, this will tell you whether your CMOS errors are RTC related)

    Der Wake/Sleep-Fehler besteht jedoch weiterhin, dann kann ich ausschließen, dass es sich um einen RTC-Fehler handelt oder?<br>

    <br>

    Habe auch nochmal die aktuelle Config angefügt.

    Files

    • config.plist

      (25.9 kB, downloaded 47 times, last: )

    Edited once, last by phil48 ().

    Das ist nur ein Memory Bereich. Der Fehler kann auch in einem anderen sein.


    Versuche mal

    Code
    1. sudo pmset -a standby 0

    Hat bei manchen auch geholfen.

    Quote from anonymous writer

    Das ist nur ein Memory Bereich. Der Fehler kann auch in einem anderen sein.


    Versuche mal

    Code
    1. sudo pmset -a standby 0

    Hat bei manchen auch geholfen.

    Wie komme ich dann an die anderen Memory Bereiche ran?


    Standby 0 habe ich schon ausprobiert, genau so wie Powernap 0, disksleep 0, autopoweroff 0.. eigentlich alle möglichen Einstellungen in der pmset -g. Auch alle Hibernatemodes (0,3,25)

    Schaue mal hier. Eventuell hilft das weiter.

    RTCMemoryFixup.kext

    Das meinte ich aber oben: Also ich habe mir RTCMemoryFixup.kext geladen, dann bei den BootArgs 00-FF ausgeschlossen, aber der Fehler tritt weiterhin auf, was ja laut dem Dortania-Guide nicht auf einen RTC-Fehler hinweisen sollte

    HM, für mich ist das eine Speicherproblem. Andere Lösung fällt mir da leider keine ein.

    Danke trotzdem, ich probier weiter rum


    Edit:


    Da der Hack zwar aufwacht, wenn ich ihn innerhalb einiger Sekunden nach dem Ruhezustand aufwecke, aber nur sehr selten bei längeren Ruhephasen könnte es auch der RAM sein oder?


    Zurzeit habe ich 2x8GB Crucial CT102464BA160B verbaut. Gibt es eine Möglichkeit den RAM zu testen? Ohne sich neuen zu kaufen? Ich werde jedenfalls mal jeweils ein Modul ausbauen und schauen ob sich was tut