Beiträge von roqueeee

Den Guide für RTCMemoryfix könnte ich nicht besser schreiben. Entscheidend ist es, die Methode mit dem Halbieren der Offsets zu nutzen, sonst sitzt man noch ein Jahr später dran. Zum Glück bin ich da auch drauf gekommen.

Ein kleiner Zusatz unabhängig von RTCMemoryFix:

Wenn ich den AppleRTC-Patch (Kext Patch) nutze, habe ich keine Bios-Resets mehr, aber die OC Einstellungen werden auf Auto gestellt (0x58 und 0x59 werden nicht überschrieben, aber 0xB4-0xB7). Das spricht meiner Meinung dafür, dass die Schreibvorgänge in B4-B7 durch einen anderen Teil des Systems verursacht werden, nicht durch AppleRTC.

Man sollte also eher den FixRTC-Patch oder einen DSDT Patch nutzen, als den AppleRTC Kext Patch. Oder eben RTCMemoryFix. Zumindest bei mir löst AppleRTC das Problem nicht vollständig.

Wenn ich das Thema nativer NVRAM weiterverfolge, kann ich gerne einen neuen Beitrag schreiben. Allerdings habe ich noch keinen Ansatz, wie ich da weiter vorgehen kann.

Dieser Thread kann ja gerne RTCMemoryFix gewidmet bleiben!

Schöne Erklärung kuckkuck! Wollte gerade Anfangen, einen kleinen Guide zu schreiben, aber das muss ich nun nicht mehr. Wenn du früher geschrieben hättest, hätte ich mir ein paar graue Haare erspart.

Bei meinem P55 USB3 Board gibt es 2 kritische Bereiche: 0x58-0x59 und sowie 0xB4-0xB7.

Wenn das schreiben in 58 und 59 erlaubt ist, habe ich nach einem Neustart einen kompletten Bios-Reset.

Wenn das schreiben in B4-B7 erlaubt ist, werden meine OC-Einstellungen auf Auto zurückgesetzt, was, wie man sich vorstellen kann, für die Stabilität des Systems nicht gerade förderlich ist.

Dabei ist B4=CPU PLL, B5=System Memory Multiplier, B6=CPU Vcore, B7=VTT Voltage.

Kann natürlich sein, dass noch weitere Bereiche meiner RTC beschrieben werden, die eigentlich nicht verändert werden sollten. Das kann ich aber nicht weiter nachvollziehen. In der Hinsicht sind AppleRTC oder FixRTC wahrscheinlich die sichereren Lösungen.

Mit boot-arg "rtcfx_exclude=B4-B7,58-59" gibt es bei mir keine Probleme mehr. Dies sollte für viele Gigabyte H55- und P55-Boards gelten, da die sich in der Regel sehr ähneln. Aber man muss es natürlich selber testen!

-----

Mein ursprünglicher Plan war ja, doch noch einmal zu versuchen, ob ich Hibernate zum Laufen kriege.

Kurzer Hintergrund: IOHibernateRTCVariable speichert in der RTC in den Bereichen 0x80 bis 0xAB Infos zu Hibernate, am wichtigsten den Encryption key für das Hibernate-Image.

Wenn ich im BIOS S3 aktiviere und in macOS "pmset -a hibernatemode 25" aktiviere startet der Rechner nach dem Versuch in den Tiefschlaf zu gehen neu und ich habe einen kompletten Biosreset. Wenn ich nun mit RTCMemoryfixup die Bereiche 80-AB schreibschütze klappt Hibernate immer noch nicht, aber ich habe keinen Biosreset mehr. Der Rechner startet einfach ganz normal neu.

Also dachte ich, ich benutze die HibernationFixup.kext. Die versucht den Key in den NVRam anstatt in die RTC zu schreiben.

Leider gibt es einen Haken: Seit High Sierra kriege ich auf meinem Board keinen nativen NVRam mehr zum laufen, und HibernationFixup braucht nativen NVRam.

Lange Rede kurzer Sinn: Hibernate läuft immer noch nicht, aber zumindest zerschießt mir macOS nicht mehr das BIOS wenn es versucht zu schlafen.

Nächste Baustelle wäre, den nativen NVRAM wieder zum Laufen zu kriegen. Aber das verschiebe ich erstmal.

Okay, danke Chris für die Klarstellung! Nicht meine Baustelle

Also meine Problematik sind Cmos-Resets nach einem Neustart. AppleRTC und FixRTC sind auch darauf ausgelegt.

Grundsätzlich sind wakes aus dem Ruhezustand sehr häufig auf falsch konfiguriertes USB in Kombination mit dem Port Limit von macOS zurückzuführen. Hast du dich in die Richtung schon schlaugemacht?

Grüße

Naja, AppleRTC und FixRTC beheben eigtl. nur die Symptome und lösen das Problem nicht. Nämlich, dass die RTC nicht einwandfrei implementiert ist. Laut Entwickler: "..with RTCMemoryFixup it is possible to use all banks of cmos memory (256 bytes), and simulate writing into some critical bytes (you need to find which ones)". Theoretisch ziehe ich solche Lösungen vor. Da die Kext aber scheinbar relativ ungebräuchlich ist und es auch nur wenig Dokumentation gibt, hatte ich gehofft, dass hier jemand schon mal Erfahrungen damit gemacht hat.

Die Devise "never change a running system" ist ja auch langweilig, da lernt man nichts neues

Wenn ich die Kext einfach nur injiziere habe ich nach einem Neustart einen Biosreset (Habe vorher in Clover „FixRTC“ deaktiviert).

Ich werde evtl. am Wochenende, wenn etwas Zeit ist, mal mit den boot args rumspielen und gucken ob sich was ergibt.

Von 00 bis FF wird aber eine lange Testreihe werden (256) und wenn man ganze Bereiche abwählt wird es eine sehr lange Prozedur werden 🤣

RTCMemoryfixup - insanelymac.com

Daran werde ich mich auch noch orientieren.

RTCMemoryFixup - github.com

Habe gerade entdeckt, dass es mittlerweile eine Kext gibt, die RTC Fehler/Resets beheben soll. Steige noch nicht ganz durch, wie man die Kext nutzen kann. Scheinbar kann man per Boot-arg bestimmt kritische Abschnitte der RTC ausschließen.

Hat hier jemand schon Erfahrung mit der Kext gesammelt?

Mein Board (P55) benötigt bisher einen DSDT-Patch oder Clover-on-the-fly-Patching um Cmos resets nach einem Neustart zu verhindern. Wegen der RTC-Patches funktionierte leider Hibernation nie bei mir. Wäre natürlich super, wenn sich mit der Kext da was zurechtbiegen ließe. Daher mein Interesse.

Grüße

Hi Blacky,

hatte das gleiche Problem und es liegt wahrscheinlich daran, dass der ICH10 SATA-Chipsatz bei P55 ALPM (Agressive Link Power Managment) nicht richtig unterstützt und die AppleAHCIPort.kext dann eine Panic schiebt. Man kann ALPM per Kext-Patching deaktivieren.

Fündig geworden bin ich hier: AppleAHCIPort.kext - insanelymac.com

Seit dem keinerlei Panics mehr bei mir! Benutze übrigens nicht die AHCIPortInjector.kext, musst also gucken, ob es damit trotzdem geht!

Nur so aus Interesse: Speedstep hast du nicht mehr zum Laufen gebracht?

Grüße

Also Piker's Script unterstützt eigentlich erst Prozessoren ab der 2ten Generation. MaciAsl hat auch einen Generator eingebaut, der hat aber bei mir mal nicht funktioniert, seit dem nie mehr getestet.

Jo, eine eigene DSDT und evtl. auch SSDT erstellen ginge auch noch. Da kenne ich mich aber nicht so gut aus. Im Netz findest du zum Teil auch schon bearbeitete DSDTs, wäre vielleicht auch einen Versuch wert.

Du kannst auch nochmal Turbo Boost und C3/C6 ausschalten und gucken ob sich was ändert.

Mögliche SM-Bios Varianten, dien Du noch testen könntest: iMac 13.x oder 14.x. MacPro 5,1 geht auch, da gibt es aber manchmal Probleme, wenn man keinen ECC Ram hat.

Du kannst auch noch mit den Optionen in Clover rumspielen; Double First State, Use System IO , Plugin Type. Da kenn ich mich aber leider nicht aus, konnte da bei mir keinen Effekt feststellen.

Wenn das alles nichts klappt musst du wahrscheinlich beim NullCPUPowermanagement bleiben.

Im 2ten Bild wird deine SSDT nicht gedroppt, dann wäre da ein Häkchen vor. Du siehst, dass die Table "SSDT" heißt (klingt redundant, aber manche Mainboardhersteller benennen die Tables komplett falsch) und die Table ID "PPM RCM " hat. Kannst mal in der Config drop OEM ausschalten und dann im Drop Tables Bereich SSDT mit Table ID "PPM RCM " eintippen. Musst wahrscheinlich auch das Leerzeichen am Ende mit eingeben.

Vielleicht klappt dann evtl. das steppen, kann aber nichts versprechen.

Das Problem mit Clover Konfigurator ist, man weiß nicht immer, ob alles was man da einstellt auch wirklich umgesetzt wird. Wenn du z.B. Drop OEM anklickst, kannst du dich nicht blind darauf verlassen, dass deine OEM SSDT von Clover während des Bootvorgangs erkannt und anschließend gedroppt wird.

Also musst du wenn es ein Problem gibt sowas eigentlich kontrollieren. Ich bin mir jetzt aber anhand deiner Antwort nicht sicher, ob du das schon getan hast.

Dafür gibt es viele Herangehensweisen, ich hätte mal 2 zur Verfügung:

Du könntest im Clover Konfigurator auf den Reiter Boot.log gehen, anschließend generate boot.log klicken. Jetzt wird dir ein Text angezeigt wo Clover eigentlich alles protokolliert, was es macht. Relativ weit unten müsste der auch die dropped Tables auflisten.

Eine andere Möglichkeit hatte ich bereits erwähnt. Das wäre direkt während des Bootens in der Oberfläche von Clover zu gucken ob unter Optionen-> Acpi -> Tables dropping deine SSDT mit einem Haken gedroppt wird.

Denk dran, wenn Du irgendwas mit Speedstep konfigurieren willst, musst du wieder die NullCPUPowermanagement.kext rauszunehmen.

Mir fällt auch noch auf, dass in in deiner Config unter Drop Tables 2 mal SSDT eingegeben ist. Wenn deine SSDT auf deinem alten Board ähnlich heißt wie bei mir, wird Clover damit die SSDT nicht droppen können. Ich würde die beiden Einträge also rausnehmen.

Falls Du Generate P-,C-States benutzt, hast du in der Clover GUI geprüft, ob deine OEM SSDT wirklich gedroppt wird? Da muss dann ein Haken neben deiner SSDT im Drop Tables Bereich sein.

Die folgenden Fixes sind eigentlich für Kernel Panics, aber du kannst mal unter Kernel und Kext Patches entweder Kernel CPU probieren oder Fake CPU ID auf Lynnfield stellen.

Du könntest auch mal mit der NullCPUPowermanagment.kext booten. Vielleicht läuft er dann zumindest ungedrosselt. Dann hast du aber auch kein Powermanagement mehr.

Damit wäre ich dann aber tatsächlich mit meinem Latein am Ende.

Also wenn HWMonitor nur x9 anzeigt gehe ich davon aus, dass das nicht richtig taktet. Ohne Turbo Boost sollte der beim 1st gen i7 zwischen x9 und x18 wechseln. Wenn Du den Multiplikator wegen einem Overclock verändert hast, dann was anderes, z.B. x20. Mit Turbo Boost kommen noch ein paar Multiplikatoren mehr dazu.

Ich würde irgendwas rechenintesives starten, z.B. ein Video laufen lassen und gucken ob sich der Multiplikator und damit der Takt ändert.

Du hast im wesentlichen 2 Möglichkeiten bei i7 Prozessoren der 1. Generation. Zum einen kannst du die originale SSDT "droppen" und in Clover "Generate P- und C-states" aktivieren, dann erzeugt Clover eine eigene SSDT. Oder du kannst die eingebaute SSDT verwenden. Theoretisch kannst Du auch eine eigene SSDT schreiben oder erzeugen, denke aber mal, dass das nicht in deinem Fokus liegen wird. Für alle Möglichkeiten müssen jeweils auch die Bioseinstellungen stimmen.

Im Netz wird eigentlich durchgängig empfohlen, die "Generate P-,C-States"-Funktion zu nutzen. Persönlich habe ich aber auf meinem Gigabyte Board genauso gute Erfahrungen mit der eingebauten SSDT gemacht.

Ich versuche mal zusammenzufassen:

1. Eingebaute SSDT verwenden:

- Im Bios stellst Du Turbo Boost je nach Bedarf ein oder aus. Du stellst C1e aus, das hat bei mir mal Probleme gemacht. Du schaltest C3/C6 ein, dann kann der Prozessor zwischen vollem Takt und reduziertem Takt wechseln. Anschließend schaltest Du EIST (Enhanced Intel Speedstep) auf ein, damit aktivierst Du die eingebaute Speedstep-Funktion des Prozessors.

- In der Clover config.plist unter ACPI stellst Du sicher, dass Generate P- und C-States ausgeschaltet ist. Drop OEM ist ausgeschaltet. Im Bereich Drop Tables stellst Du sicher, dass keine Table mit dem Namen SSDT eingetragen ist.

2. SSDT mit Clover generieren:

- Im Bios stellst du Turbo Boost je nach Bedarf ein oder aus. Du stellst C1e aus. Du schaltest C3/C6 ein. Du schaltest EIST aus.

- In der Clover config.plist unter ACPI stellst Du sicher, dass Generate P- und C-States eingeschaltet ist. Du kannst die eingebaute SSDT entweder mit der Option Drop OEM droppen oder indem Du deine SSDT inkl. Type oder Length in dem Bereich Drop Tables eintippst. Den Namen deiner SSDT kannst Du z.B. herausfinden, indem Du nach dem Hochfahren in der Clover GUI zu den Optionen -> ACPI -> Drop Tables gehst (Mache das gerade aus dem Kopf, das wird leicht anders heißen).

Wie immer beim Hack, musst du durch probieren herausfinden, welche Option am besten für dich läuft!

Habe mir auch mal deine config angeguckt. Da sind viele Einträge, die für deine CPU irrelevant sein sollten (z.B. Einstellungen für integrated Graphics). Die könnte man auch nochmal aufräumen.

Hoffe dass das hilft, für die alten Boards wird es einfach schwer Infos zu finden!

Hatte vorher auf einem sehr ähnlichen System auch eine GTX 770 laufen. Hast du die eingebauten Treiber oder den Nvidia-Webdriver laufen?

Eine Zeit lang liefen Nvidia-Karten mit Rucklern unter High Sierra (die Treiber waren verbuggt, anschließend gab es eine Zeit lang einen Fix mit dem Whatevergrenn.kext). Irgendwann ab 10.13.6 oder so wurde das Problem auch von Nvidia gefixt, allerdings lief mein System nie wieder so flüssig, wie ich das noch aus Sierra Zeiten kannte. Egal ob eingebauter Treiber für die 770 oder Webdriver.

Im Grafikbereich von macOS hat sich seit Sierra sehr viel verändert, vor allem seit dem Umstieg auf Metal 2.

Allerdings lief bei mir der Webdriver besser, würde also vorschlagen diesen zu benutzen. Perfekt wird das aber leider nicht werden (zumindest bei mir).

Ich bin dann vor ein paar Monaten auf eine AMD-Karte umgestiegen. Jetzt läuft alles unglaublich flüssig, so wie ich es von früher kenne.

Gib mal im Terminal

ein. Dann werden dir alle Kexte angezeigt, die nicht von Apple stammen und geladen sind. Auf den System-Profiler ist in der Hinsicht kein verlass

Wird wahrscheinlich einfach Spulenfiepen sein.

Wenn die CPU/Mainboard fiept:

Wenn deine CPU unter last mehr Strom zieht kann das schon hörbar sein, auch außerhalb des Gehäuses. Bei meinem Rechner ist es besonders laut, wenn Load Line Calibration im Bios aktiviert ist, kannst ja mal gucken, ob das bei dir aktiviert ist. Wenn du overclockst, kann das aber den OC instabil machen, wenn du es abschaltest.

Graka fiept:

Die RX 580 hat den Ruf hörbares Spulenfiepen unter Last zu produzieren. Habe vor kurzem lernen müssen, dass das auch Stark vom Netzteil abhängt. Hatte vor kurzem ein billiges Netzteil von Cooler Master in meinem Rechner verbaut. In Spielen war damit meine Grafikkarte so laut, dass man es im nächsten Zimmer noch gehört hat. Mit einem guten Netzteil macht die Karte nur ein aus nächster Entfernung hörbares Geräusch.

Zitat von MacGrummel

Deinen Punkt 1 versteh ich nicht: Schon auf meinem alten Ga-P55m-UD4 lief IMMER eine ATI-Grafik, auf meinem Ga-EX58-UD5, der auch "nur" ein klassisches BIOS hat, steckt zZt. eine ATI-Radeon RX 580 mit 8192 MB, selbst meine Vega FE lief da schon testweise.

Das kann also eigentlich nicht das Problem sein.

Wo trägst Du denn den Boot-Rom-Wert im Configurator ein? Ich hab Bios-Version und -Release Date und die Firmware Features angepasst..

BootROM:

Du kannst nicht direkt das BootROM, nur die Bios Version in der Config eintragen. Anschließend erzeugt Clover aus dem ersten, dritten und vierten Abschnitt der Bios Version die Boot Rom.

Apple hat jetzt die Nomenklatur der Boot Roms geändert von "X.X.X" zu "X.X.X.X.X.". Clover kann aus MP51.88Z.F000.B00.1807300628 nicht 138.0.0.0.0 erzeugen.

Zum Glück funzt es aber, wenn man es direkt im BOOTSCREEN einträgt.

Ich benutze r4658, da die neue 4674 bei mir nicht funktioniert. Habe aber eben in den Commits gesehen, dass das schon behoben sein könnte. r4659: "cleanup and consider new format of Biosversion."

ATI/AMD unter Legacy Bios:

Wollte damit sagen, dass das offiziell von den Herstellern nicht unterstützt wird. Ich besitze auch eine RX 580. Nachdem ich deinen Kommentar gelesen habe, habe ich die Karte eben mal wieder eingebaut und es funktioniert unter MacOS sehr gut.
Allerdings hatte ich das letzte mal schlechte Performance in Spielen unter Windows und sie daraufhin wieder ausgebaut. Damals habe ich das auf die fehlende Unterstützung geschoben, ohne das weiter zu überprüfen. Ich werde das jetzt aber mal weiter prüfen und unter anderem Windows neu aufsetzen. Würde gerne bei der RX580 in meinem Hack bleiben.

Dann von mir auch mal der obligatorische Screengrab