Beiträge von roqueeee
-
-
Habe die Kext so angepasst, dass die AGPM-Eigenschaften auch unter meinem SMBIOS injiziert werden. Das hatte aber wie gesagt keine unmittelbar merkbaren Effekte und wurde anschließend wieder rausgenommen.
Edit:
So, mit dem CFG_PTPL2_TBL Wert aus der RadeonBoost.kext taktet die Karte jetzt auch richtig. Für meine Karte sind zum Beheben des Problems also PP_EnableLoadFalconSmcFirmware und CFG_PTPL2_TBL notwendig. AGPM-Einstellungen sind nicht unbedingt notwendig.
CMMChris Die Einträge für RX4xx/5xx Karten scheinen ja aus dem Forrahue Framebuffer zu stammen und sind in meinem Fall die richtigen Werte um die Karte zum reibungslosen Funktionieren zu bewegen. Werde jetzt einfach alle Einstellungen aus deiner Kext fahren, wird schon nicht schaden. Danke für diese Kext!
Verrückt, scheinbar habe ich jetzt eine problemlos funktionierende XFX RX460 Fanless in meinem System. Bin eigtl nicht mehr davon ausgegangen, dass dieser Tag kommen wird.
-
HDRI Schöner Fund mit der RadeonBoost.kext!!
CMMChris Ich hab jetzt mal deine Kext angepasst, damit sie unter einem anderen SMBIOS lädt und die Eigenschaften für eine Rx580 bei meiner RX460 injiziert.
CFG_PTPL2_TBL habe ich ausgelassen, da ich die Werte nicht nachvollziehen kann. Wofür sind die gut?
Konnte dann feststellen, dass mit den injizierten Eigenschaften das Ruckeln nach dem Schlaf weg ist, allerdings liefert die Grafikkarte in Heaven nur noch etwa 50-60% der Leistung, im openGL Driver Monitor sieht man auch, dass die Karte nicht mehr ganz hochtaktet (kurioser Weise nur im Benchmark, auf dem Desktop taktet sie fröhlich bis ca. 1200 Mhz.)
Habe anschließend herausgefunden, dass eigtl. alle Werte außer PP_EnableLoadFalconSmcFirmware keinen merkbaren Effekt bei mir haben. Das heißt, wenn ich ohne AGPM-Eigenschaften und bei IOProviderMergeProperties nur PP_EnableLoadFalconSmcFirmware injiziere verschwindet das Ruckeln, aber die Leistung ist eingeschränkt.
Hast du evtl mehr Infos zur Falcon Smc Firmware und gibt es evtl. noch Eigenschaften, die mit der Taktproblematik helfen könnten?
Danke!
-
Freut mich sehr, dass du den Fehler finden konntest! Ein nicht perfekt funktionierender Hackintosh kann einem schon den Schlaf rauben!
Bei meiner XFX-Karte wird die Suche nach einem passenden Bios leider schwierig werden. Die Karten sind notorisch inkompatibel mit macOS und weichen in der Regel auch vom Referenzdesign ab. Musste damals glaube ich 5 verschieden Biose testen, bis ich eins gefunden hatte, mit dem man booten konnte und das stabil im Alltag läuft.
Die Karte ist aber die Version ohne Lüfter. Da ich ein Silentfreak bin bleibt die Karte wohl erstmal im Einsatz. Bei meiner Rx580 stört mich zum Beispiel dass die Lüfter manchmal im Dual Monitor Betrieb anspringen (Der Vram taktet hoch).
Mit viel Glück liefert Apple mit einem Update neue Treiber aus, die nicht so wählerisch sind, was das Kartenbios angeht. Man darf träumen.
-
Der Rechner auf dem das Problem auftritt wird von mir auch nur zum coden/ssh und für Medienkosum genutzt. Durch das Problem ist zum Glück nicht die Grafische Oberfläche oder die Videowiedergabe in ihrer Performance beeinträchtigt. Wenn man zocken will ist das Problem natürlich sehr ärgerlich.
Ich habe eben mal mit dem OpenGL-Monitor geguckt. Nach dem Sleep bricht während des Heaven Benchmarks zeitweise nur die Taktfrequenz ein (bei mir von ~1200Mhz auf ~200-300). Die Speicherfrequenz bleibt aber erhalten.
Außerdem bricht die Frequenz nur bei manchen Szenen des Benchmarks ein. Andere Szenen laufen mit voller FPS, ohne dass der Takt runter geht.
-
Bei mir tritt das gleiche Fehlerbild auf meinem Zweit-Hackintosh auf. In dem Rechner ist eine XFX RX 460 installiert, auf die ich ein MSI-Bios gespielt habe. Smbios iMacPro1,1, OpenCore 0.5.7, Z87 Mainboard.
Auf meinem Hauptrechner mit einer Sapphire RX 580 8GB Nitro+ tritt der Fehler nicht auf, der hat im Prinzip die identische OpenCore config.
Ursprünglich bin ich davon ausgegangen, dass es wahrscheinlich ein Treiberproblem sein wird, da die AMD Treiber ja in letzter Zeit relativ buggy sind.
Allerdings benutzt die RX460 einen anderen Treiber als eine RX480/580, Baffin vs EDIT:
PolarisEllesmere.Da ich auch schon mit Clover gegengetestet habe und auch ohne Whatevergreen der Fehler bei mir auftritt würde ich per Ausschlussverfahren am ehesten auf nicht ganz kompatibles Bios der Graka oder Mainboard/SSDT-Probleme tippen. Ich könnte die RX460 mal in meinem Hauptrechner installieren und gucken ob auf einem anderen Mainboard der Fehler auftritt, ist mir aber gerade zu aufwendig.
Wir wissen ja auch, dass der Fehler auf einem Z390 und auch auf einem Z87 Board passieren kann. Die sind vom Design komplett verschieden. Irgendwie gehe ich deswegen wohl am ehesten von einem Graka-Bios Problem aus. Vielleicht verträgt sich das nicht mit dem Treiber.
Ich vermute hier viel ohne definitive Antworten, hoffe es hilft aber, das Problem einzugrenzen.
-
Hast du auch die neueste Version von Whatevergreen?
-
Mit einer Vega 64 läufts, aber der Treiber für die RX 580 (oder besser alle Polaris Ellesmere Karten) ist seit Catalina verbuggt und lässt den Rechner einfrieren, wenn man z.B. Netflix gucken möchte.
Das steht in der aktuellen Shiki-FAQ:
ZitatNote, AMD Polaris Ellesmere is broken in 10.15 (e.g. RX 590), whereas AMD Polaris Baffin (e.g. RX 460) is fine.
// Easiest check is to run WebKitMediaKeys.isTypeSupported("com.apple.fps.2_1", "video/mp4") in Safari Web Console.
// Broken GPU driver will just freeze the system with .gpuRestart crash.
-
Leider kein Fix für das Netflix-Problem unter Safari bei der RX580, sonst alles problemlos durchgelaufen.
Als Übergangslösung funktioniert bei mir Netflix mit shikigva=256 bei einem iMacPro1,1 Smbios. DIe iGPU muss dafür deaktiviert sein. Läuft dann über den Software Decoder. Videoproc zeigt weiterhin alles Grün und Videoencoding in Davinci Resolve läuft immer noch über die RX580. WebKitMediaKeys.isTypeSupported("com.apple.fps.2_1", "video/mp4") spuckt dann in der Safari Web Console "true" aus.
Sidecar kann ich nicht testen.
Grüße
-
Freut mich zu hören, dass die Offsets funktionieren!
Wie in dem RTCMemoryfixup-Thread beschrieben, hatte ich mich letztendlich für rtcfx_exclude=58-59,80-FF entschieden.
Man kann nicht nachvollziehen, ob wirklich alle notwendigen Offsets der RTC schreibgeschützt werden. Mit dem sperren der 2ten Bank, so wie es kuckuck vorgeschlagen hatte, geht man einfach auf Nummer sicher. Dementsprechend würde ich Dir das auch empfehlen.
Mir ist übrigens letzten Monat der Prozessor angeraucht, nachdem ich den Arbeitsspeicher (völlig unnötiger Weise) von 1600MHz auf 1900Mhz übertaktet hatte. Gehe davon aus, dass der integrated memory controller der CPU das Zeitliche gesegnet hat.
Wie du aber schön beschreibst, kann man mit den alten Kisten immer noch einen richtig guten Hackintosh bauen. Habe den Eindruck, dass das Viele nicht auf dem Schirm haben. Mein P55 Hackintosh war auf jeden Fall von Yosemite bis Mojave ein treuer Begleiter!
Bin jetzt den Umständen entsprechend auf Z97+4790k umgestiegen.
-
Mit dem Nvram habe ich mich ehrlich gesagt nicht weiter beschäftigt!
Eigentlich läuft bis auf ein paar Kleinigkeiten (Nur S1, kein nativer Nvram, kein USB3 on board, Rotes Bild bei Netflix in Safari) alles Rund.Bei mir steht voraussichtlich eh bald ein Upgrade der Hardware an, deswegen hatte ich in letzter Zeit nicht mehr so viel Motivation, mit dem aktuellen Setup herumzuexperimentieren.
Mein Uralt-Rechner hat noch nicht einmal Uefi, dementsprechend konnte ich auch noch nicht Opencore testen.
Habe nach deinem Kommentar doch wieder Rtcmemoryfixup reingenommen, und mich für das komplette Sperren der 2ten Bank entschieden. Werde dann also mit rtcfx_exclude=58-59,80-FF fahren. Wenns da Langzeitschwierigkeiten gibt, werde ich mich hier melden.
Ich wollte nochmal die Gründe auflisten, die meiner Meinung nach gegen RTCMemoryfixup sprechen:
-Es ist nicht transparent nachvollziehbar, ob man wirklich alle Abschnitte der RTC ausschließt, die ausgeschlossen werden sollten.-Sollte es in Zukunft Probleme mit Lilu oder RTCMemoryfixup geben, könnte es passieren, dass die RTC nicht ordnungsgemäß schreibgeschützt wird. Dies würde im schlimmsten Fall dazu führen, dass der Rechner nicht hochfährt.
-Das Finden der kritischen Bereiche ist zeitintensiv und mühselig.
-
Leider kenne ich auch keine gute Methode. Habe die Veränderungen nach dem Neustart im Bios nachgeguckt. War dementsprechend auch ziemlich zeitaufwändig.
Wegen der mangelnden Überprüfbarkeit (evtl. Änderungen in einer Bank der RTC die nicht visuell im Bios repräsentiert sind) bin ich auch wieder zu FixRTC zurückgekehrt.
Habe eben mal ein bisschen gegoogelt wie ein Cmos aufgebaut ist. Typischerweise gibt es wohl Bänke die als Prüfsumme für einzelne Abschnitte der Rtc dienen. Wäre natürlich super wenn man die auslesen und überprüfen könnte. Die gesamte Rtc per Prüfsumme zu checken stell ich mir sinnlos vor, da zumindest die Echtzeituhr ja ständig weiter zählt, dementsprechend käme da immer was anderes raus.
-
Sieht grundsätzlich so aus, als ob der bei einer deiner injizierten Kexte abstürzt. Sind die alle aktuell?
Wobei, das 2te Bild kann ich nicht deuten. Da müssen die Pros mal ran 😉
-
Ist Clover oder Opencore auf der neusten Version? Wenn dein Rechner unter Mojave bootet und nicht unter Catalina könnte es auch einfach sein, dass da irgendwas verbuggt ist, z.B. der Bootloader, eine Kext oder evtl. sogar macOS.
Wenn du troubleshooten willst könntest du damit anfangen, mit „-v“ zu booten und zu gucken, wo es beim Booten hakt.
-
Lilu und andere Kexte, die auf Lilu angewiesen sind (z.B. Whatevergreen, Cpufriend, AppleAlc...), starten nicht unter 10.15 (Catalina), bis die dafür vom Entwickler aktualisiert werden.
Um den Versionscheck zu umgehen, kann man mit „-lilubetaall“ das Laden unter nicht unterstützten Betriebssystemversionen erzwingen.
-
Habe auf einer Testpartition gestern Abend die Public Beta ohne Schwierigkeiten installieren können. -lilubetaall sollte man natürlich nicht vergessen, durfte deswegen während der Installation auf einen schwarzen Bildschirm starren 😁. Hatte vorher natürlich Clover aktualisiert.
Wie nicht anders bei einer Beta zu erwarten, konnte ich auch direkt einige Bugs festsellen, das Error-Log füllte sich fleißig mit roten Pünktchen und beim Versuch die Netflixwebseite zu öffnen, hing sich der Rechner auf.
Bin ziemlich zuversichtlich, dass sich dieses mal unter der Haube nicht so viel geändert hat, wie zum Beispiel beim Umstieg auf Metal 2 letztes Jahr.
Freue mich schon auf ein weiteres Hackintoshjahr mit Catalina, aber fürs Erste zurück zum schön stabilen
High SierraEdit: Mojave 👍🏻.Spannend auch die Betriebssystem unabhängige Data Partition!
-
Bei S1 habe ich auch FixRTC aktiviert. Benutze zur Zeit nicht RTCMemoryfixup.kext.
Mit S1 schaltet sich die CPU nicht ab, sondern wird nur angehalten. Peripherie wird evtl. in einen low power modus versetzt. Sieht halt so aus, als ob der Monitor nur ausgeschaltet ist.
Bei S3 wird der Rechner fast komplett abgeschaltet, der Ram wird aber weiter mit Strom versorgt. Verbraucht dementsprechend weniger Strom.
FixRTC sollte eigentlich das kaputtschreiben des Cmos verhindern. Konnte bei mir aber im Ansatz nachvollziehen, dass das nicht immer funktioniert. Wenn S3 und FixRTC aktiviert sind und man meinen Rechner in den Ruhezustand versetzt führt das zu einem Biosreset bei mir (Nehme an, dass Teile der zweiten Bank der RTC trotzdem überschrieben werden (80-AB)).
In dem RTCMemoryfixup-Thread habe ich da noch etwas mehr zu geschrieben. Habe das bisher aber nicht weiterverfolgt und benutze einfach weiterhin S1.
Du könntest auch probieren, ob das Problem weggeht, wenn du
im Terminal eingibst. Damit schaltest du Hibernate im Betriebssystem aus und unterbindest eventuell die Schreibvorgänge in die RTC.
-
Zum nachhaken: Hast du FixRTC in Clover aktiviert?
Im Bios: Ist dein Ruhemodus unter Power Management auf S1 oder S3 gestellt? Bei mir zerschießt MacOs das Bios wenn ich S3 aktiviere, auch wenn FixRTC aktiviert ist. Deswegen benutze ich einfach S1, auch wenn das mehr Strom verbraucht.
Wenn du FixRTC aktiviert hast und das Biosproblem bestehen bleibt könntest du auch die RTCMemoryfixup.kext testen. Konfiguration und testen ist da aber aufwendig.
Anleitung: RTCMemoryFixup.kext
Wenn du bei Gigabyte Boards den Einschaltknopf lange gedrückt hälst, schmeißt der auch einen checksum error und fängt an das backup bios zurück zu spielen. Könnte also theoretisch auch User Error oder ein defekter Einschaltknopf sein. Nur so als Info, denke aber dass es nicht daran liegen wird.
Edit: Wenn du den Rechner über Nacht komplett vom Netz trennst könnte es auch einfach eine leere Cmos Batterie sein. Bei nem "10 Jahre alten" Board wäre das zumindest im Bereich des Möglichen.
-
Freut mich, dass der Patch funktioniert!
Also die AppleIntelCPUPowermanagement.kext sollte sich in /System/Library/Extensions befinden. Hast Du evtl. in /Library/Extensions geguckt? Wenn die Kext nirgendswo zu finden ist (was mich sehr wundern würde), könntest du auch über eine Neuinstallation nachdenken. Vielleicht ist ja deine Installation zerschossen.
Meine Theorie zu der Speedstep-Problematik ist, dass wenn Du die NullCPUPowermanagement.kext benutzt und CPU EIST im Bios aktivierst ist, dein Rechner mit dem Bios Powermanagment anstatt dem macOS Powermanagement läuft. Das läuft bei mir auch wenn ich es so einstelle (Bei mir aber auch ohne NullCPUPowermanagement.kext). Eigentlich kannst du testen, ob Du einfach mit dem Bios Powermanagment weiterlebst. Wenn du da langfristig keine Probleme hast, warum nicht.
Dass deine CPU nicht höher clockt als 3,06 sagt eigentlich nur aus, dass Turbo Boost nicht läuft. Grundsätzlich läuft Turbo Boost (bei Dir evtl. mit den Multipliaktoren x24, x25,x25, x26) eh nur auf einem der 4 Kerne zum jeweiligen Zeitpunkt. Alle 4 Kerne zur gleichen Zeit können bei Lynnfield Prozessoren nicht boosten. Dein Rechner sollte eigentlich auch ohne Turbo Bost gut funktionieren. Könntest also drüber nachdenken, es einfach abzuschalten.
Edit: Kann es sein, dass du einen i7 880 und nicht einen 870 hast? Die 3,06 Ghz sprechen dafür. Der 870 läuft eigtl. mit 2,93.
-
Einfach der Anleitung im Wiki folgen! Kurzgefasst trägst Du mit Clover Configurator unter Kernel und Kext Patches in deiner config.plist den Namen AppleAHCIPort, bei Find 40600200 und bei Replace 00000000 ein. Bei Comment könntest du zum Beispiel "ALPM IO Error AppleAHCIPort" eingeben, dann weißt du später mal, wofür der Patch gedacht ist. Nach dem Speichern und Neustarten sollten deine Abstürze hoffentlich der Vergangenheit angehören.