Beiträge von elmacci

@apfelnico : Interessant. Dass das keine Neuigkeit ist war mir nicht bewusst - auch weil überall immer die Methode über Pikers Skript propagiert wird. Zumindest muss es zwischen beiden Methoden ja gewisse Unterschiede geben, sonst wäre meine Sleep/Wake-Thematik ja nicht mit dieser Methode (hoffentlich) gelöst (muss noch ein wenig testen, aber bislang sieht es sehr gut aus).

Gibt es einen Grund warum die Plugin-Type=1 Geschichte nirgendwo in den Anleitungen (auch hier) nicht erwähnt wird?

Auch wenn es offensichtlich ein alter Hut ist kann es ja durchaus hilfreich sein für andere

Hi zusammen,

ich bin ja immer ein eifriger Leser auch anderer Foren und lese dort ab und zu über neue Möglichkeiten/Methoden für diverse Probleme die man so mit seinem Hacki haben kann (bspw. die Lösung für den iBooks Transparenzbug oder NvidiaGraphicsFixup). Wenn ich also etwas (meines Erachtens nach) spannendes habe teile ich das natürlich immer gerne mit den freundlichen Menschen hier im Forum

Auch jetzt gibt es wieder so ein nette Geschichte.
Und zwar hat der in der Szene vor allem für seine HDMI/Audio-Skripte bekannte toleda eine alternative Methode für natives Powermanagement auf Skylake/Kabylake Systemen entwickelt.

Das führt dazu, dass man für das Powermanagement der CPU nicht mehr auf Pikers ssdtPRGen-Skript angewiesen ist.

Ich persönlich habe besagte Piker-SSDT bislang im Einsatz gehabt (Skylake-CPU, iMac 17,1 SMBIOS-Definition, GTX 1080TI) und hatte auch eine einwandfrei "schaltende" CPU mit unterschiedlichen Speedsteps.

Allerdings habe ich es bislang nicht geschafft, diverse Sleep/Wake Probleme vollständig zu eliminieren auf meinem System.

Insbesondere das Aufwachen meiner 3 Monitore hat in bestimmten Anwendungsszenarien nicht stabil funktioniert. Gut, ich bin da vielleicht auch ein Sonderfall - 3 4K Monitore, Wake On Lan aktiviert, Per VNC/Remote einloggen etc.
Folgendes war bislang immer problematisch:
1) Aufwecken des Hackis über RemoteVNC
2) Steuerung des Hackis in der Remote-App
3) Remote App offen, aber keine Aktivität - am Hacki gehen die Displays aus / in den Ruhemodus
4) Beim wieder aufwecken (z.B. klicken auf den Desktop) crasht dann der Rechner

Jetzt könnte ich natürlich immer wieder die Remote-Verbindung trennen wenn ich gerade nichts mache - aber manchmal vergesse ich das eben und dann crasht das System.

Ihr seht - ein wirklicher Sonderfall und nicht wirklich realtitätsnah
Ich habe alles probiert - Grafikkarte mit SSDT-Injection, alle Darkwake Modes durch, IGPU aktiviert/deaktiviert, Primär und Sekundär, DSDT-Extraktion und Fixes, versch. BIOS Einstellungen und und und. Bis zu dem Punkt wo wirklich alle Devices die in meinem Rechner stecken bzw. nötig sind korrekt und mittels SSDT injected werden inkl. Slot-Nummer bei PCI-Devices (AppleLPC,MCHC, IMEI, LPCB, SATA Controller etc. pp)

Und jetzt zurück zum Kern des Ganzen:
Ich habe diese neue Methode einfach mal ausprobiert - und was soll ich sagen: Das oben genannte Anwendungsszenario teste ich gerade seit mehreren Stunden durch (immer wieder inaktiv per Remote, Verbindung aber steht dauerhaft. Einschlafen und Aufwecken per Remote etc.) und habe bislang noch keinen Crash gehabt

Vielleicht freue ich mich auch zu früh - aber interessant ist die Methode allemal.

Und hier kurz beschrieben die Vorgehensweise (den Originalen Thread bei den Tomaten verlinke ich hier jetzt mal nicht, falls jemand mehr Hintergrundinfos braucht einfach nach "macOS Native CPU/IGPU Power Management" suchen):

Voraussetzungen:
1) Diese Methode funktioniert bei Skylake/KabyLake-Systemen nur, wenn auch die dazu passende, originale SMBIOS-Definition eingesetzt wird. Sprich, bei meinem Skylake 6700K also iMac 17,1.

2) Der IOPlatformPlugin.Kext sollte nativ/Original Apple sein. Wenn ihr da nichts explizit gemacht habt sollte das auch grundsätzlich der Fall sein.

Vorgehensweise:
1) Es muss eine XPCM SSDT in den EFI/CLover/ACPI/patched Ordner hinzugefügt und beim Start geladen werden. Diese Datei bekommt ihr direkt von toledas github hier: https://github.com/toleda/audi…r/ssdt_xcpm/ssdt_xcpm.zip

2) Falls ihr eine über ssdtPRGen generierte SSDT.aml im patched-Ordner habt, muss diese gelöscht werden da nicht mehr notwendig.

Das wars. Natives Powermanagement mit entsprechenden Speedsteps und ggf. eine Lösung für Sleep/Wake-geplagte.
Vielleicht hilft es ja dem ein oder anderen bzw. führt zum Erfolg.

cheers

https://www.hackintosh-forum.d…?postID=338501#post338501

Der iBook Transparenz Bug wurde gefixt mittels einer Kext - sofern man eine Nvidia Grafikkarte und die Webdriver einsetzt.

Also die einzige die mir jetzt so spontan einfällt ist iStat Menus:
https://bjango.com/mac/istatmenus/

Auch selber im Einsatz

@blackcat: Bin da bei Dir - ich habe mich auch mühselig in die Themen hier eingelesen und muss sagen, es war die Mühe wert. Man bekommt einfach ein besseres Verständnis der Zusammenhänge. Aber anstrengend ist es trotzdem gewesen, die Multimonster-Verlockung war groß Ich gebe auch zu dass ich mich öfters mal auf der Tomate (allerdings mehr als Leser) rumtreibe, aber dann hauptsächlich nur weil nun einmal sehr viele Leute dort unterwegs sind und die Wahrscheinlichkeit höher, das ein bestimmter Fehler etc. dort besprochen wurde. Oder wie in dem Fall ein neuer Kext vorgestellt wird.

@Doctor Plagiat: Ah, interessant - HW Monitor nutze ich nicht (nur istat). Vielleicht teste ich den hellen Modus dann auch mal wieder bei Gelegenheit.

Funktioniert eigentlich bei den Leuten mit XCode jetzt auch alles wie es sein soll? Nur aus Interesse...:-)

Verstehe - kenne auch die Story warum Tony nicht beliebt ist und kann das absolut nachvollziehen.
Allerdings wäre ich ohne den Schmonz leider nie (oder nur spät) auf den Kext aufmerksam geworden. Tummeln sich halt doch viele Hackintoshler und auch Entwickler auf der Tomatenseite rum.

Zitat von Doctor Plagiat

Hat sich bei mir leider nicht geändert. Weiterhin sporadisch schwarze Fläche über dem Menü-Symbol.

ok, schade. dann bleibe ich halt weiterhin beim dark mode.. Danke für die Rückmeldung!

@Kadir91
Im dazugehörigen diskussionthread beim roten apfel (oder tomatenforum - warum auch immer tomate, das ist ja eigentlich ein apfel) wurde bezüglich xxode und instruments profiler erfolg vermeldet. kann es mangels xcode nicht selber testen, sollte aber funktionieren aufgrund der art wie der kext arbeitet. er sorgt dafür dass die nvidia treiber als apple eigene treiber erkannt werden. ich bin auch gespannt ob die in der vergangenheit sporadisch auftauchenden grafikfehler (teilweise schwarze flächen) in der menüleiste damit auch gelöst sind (workaround bisher ist der wechsel in den dark mode).

Na das freut mich aber Dann morgen gleich mal auch bei mir in die efi hauen *freu*

Hi zusammen,

bin gerade über diese neue Methode gestolpert, die offenbar das Problem umgeht dass die NVDIA Webdriver nicht von Apple gesigned sind und dadurch Grafikfehler (unter anderem transparente Fenster beim Öffnen von iBooks) entstehen.
Anscheinend sollen amit alle möglichen Fehler, die mit dieser Problematik zusammenhängen, gelöst werden.

Ich bin gerade noch unterwegs und kann das leider nicht testen.
Kennt das hier vielleicht schon jemand? Gibt es Freiwillige?

Ansonsten spiele ich das Versuchskaninchen wenn ich wieder an meinen Rechner komme (wahrscheinlich erst morgen).

--> https://github.com/mologie/NVW…Fix/blob/master/README.md

cheers

@Dr.Stein : Das ist mir klar das es um 10.13 geht - ich hatte mich nur gewundert was mit dem 10.12. Desaster genau gemeint war. Aber nach Deiner Erklärung hat es auch bei mir "geschnackelt" das es heisst: 10.12. Desaster = Verzögerung/Ewigkeiten keine Pascal Treiber. Hab die Verbindung zu 10.12. und der Pascal-Thematik nicht gemacht, da das "Desaster" ja schon bei 10.11 angefangen hat.

@kgp : Ah, noch jemand mit einer Aorus 1080TI Extreme.
Was meinst Du denn mit dem macOS 12 Webdriver Desaster in Kombination mit Pascal-Karten?
Bei mir funktioniert die Karte - wenn auch mit einigen kleineren Problemchen im Multi-Monitor-Setup, siehe hier:
Kompatibilität NVIDIA Pascal (Übersicht Hersteller und Modelle)

LG

Zitat von al6042

An meiner 1080 brummen zwei 4K-Monitore per DisplayPort angebunden.
Bei mir wird auch nur ein DisplayPort-Audio-Ausgang angezeigt, aber so richtig stören tut mich das nicht.

Noch jemand mit mehreren Monitoren - das ist beruhigend
Interessant mit den 2 4K Monitoren bei Dir. Bei mir ist es in der Tat nämlich auch so, dass wenn ich nur 2 von den 3 4K Monitoren direkt mit DP-Kabel anschließe - und zwar an Port DP2 und DP3 - dann habe ich keinerlei Probleme. Und sogar 2 HDMI Audio Outputs. Es scheint nur der Port DP1 problematisch zu sein.
Wenn ich die 2 Monitore nämlich an DP1 und DP2 (oder DP3) anschließe, dann habe ich nur noch 1 HDMI Audio Output.
Unter Windows im Dual Boot ist alles paletti...

@onlyWork: Gerne doch - die hat ja auch noch gefehlt in der Auflistung

Ja, ich denke auch dass die 1080ti alle die gleichen Phänomene aufweisen - ich bin gerade noch mit einem Leidensgenossen in einem anderen Forum im Austausch, der ein ähnliches Monitorsetup hat.
Genau die gleichen Symptome.

Vor allem das Sleep/Wake-Problem ist recht nervig. Manchmal wachen nur 2 Monitore auf, oder aber alle 3 wachen auf und ein Monitor hat auf einmal eine andere Auflösung. Es scheint auch immer der Monitor an einem bestimmten DP-Port zu sein...So als ob die Monitor-Infos nicht korrekt übergeben werden.
HDMI funktioniert übrigens gar nicht wenn mehrere Monitor benutzt werden. Nur wenn man einen einzigen Monitor per HDMI anschliesst geht es.

Ich teste gerade noch ein wenig rum und werde wohl - einfach um andere Faktoren auszuschliessen - macOS nochmal komplett frisch installieren.

Mich würde aber einmal wirklich interessieren ob es nur an meiner speziellen Version der 1080TI liegt oder ob es ein generelles 1080TI Thema ist. Leider ist die Kombi mit mehreren Monitoren und 1080Ti wohl nicht so häufig anzutreffen....
Ich lese jedenfalls nirgendwo von Pascal Karten und Multimonitor-Problemen - was mich wundert.

Cheers

Sodele, auch hier mal mein kleines Schmuckstück:

Ich kämpfe gerade noch mit ein paar kleineren Problemen, liegt wohl aber an meinem 3-Monitor-Setup. Das ist nicht so gängig, deshalb hab ich auch noch keine zufriedenstellende Lösung gefunden. Man beachte das ich von einem reibungslos funktionierendem System mit 2 GTX 970 komme und diese beiden nur gegen die 1080TI getauscht habe (Grafikkarten-SSDT natürlich entsprechend angepasst ;))

Problem 1 - Sleep/Wake:
Alle 3 Monitore über DP angeschlossen, beim ersten Boot alles in Ordnung. Nach Sleep kein Wake mehr bzw. es wachen nur noch 2 der 3 Monitore auf. Darkwake Settings alle durchprobiert. Einzige Lösung gerade: 2 Monitore über DP2HDMI-Adapter und HDMI Kabel am DP, 1 Monitor direkt mit DP-Kabel am DP. Jetzt wachen auch alle 3 Monitore nach Sleep auf. Allerdings nicht so wirklich stabil, habe immer noch ab und zu einen Freeze/Black Screen nach Wake. Bislang Darkwake 0 ausprobiert, ich teste aktuell noch die anderen Darkwake-Settings durch.
UPDATE 27.07.: Auch die Kombi mit 1x DP2HDMI Adapter und 2x DP funktioniert nicht wirklich. Bin jetzt wieder zurück auf 3xDP und Darkwake=8. Da wacht der Rechner auch nach längerem Sleep mit allen 3 Monitoren auf WENN ich über die Tastatur wecke. Wenn ich über Remote wecke klappt es ab und zu, aber nicht immer - dann wachen nur 2 der 3 Monitore auf.

Problem 2 - HDMI Audio:
In meiner vorherigen Konfiguration hatte ich auch 3 HDMI Audio-Outs. Logo, da auch 3 Monitore. Ab und zu hat er nur 1 angezeigt, nach einem Reboot aber wieder fein.
Jetzt sind es nur 2 HDMI Audio Geräte - zwar konstant bei jedem Boot. Aber bei 3 Monitoren etwas komisch...

Problem 3 - Kernel Panic mit GPUSensors.Kext:
Wenn man die neuesten FakeSMC+Sensors Kexte von Rehabman oder hwsensors.com benutzt, gibt es beim Boot eine KernelPanic in der GPUSensors.kext.
Lösung: Entweder GPUSensors.kext löschen/nicht verwenden oder die dort erhältliche Binary laden von kozlek. Da funktioniert die gpusensors.kext. Komischerweise ist das in der aktuellen hwsensors nicht gepatcht.

Ergo: Eigentlich fein, aber vielleicht für den ein oder anderen der auch ein Multimonitor-Setup betreibt gut zu wissen
Und die Leistung von dem Teil - alter Schwede...Mit meinem 970-SLI-Gespann so um die 70FPS in Overwatch bei 4K und Ultra Settings. Mit der hier jetzt knapp an 130 FPS dran und EPIC Settings in 4K...

Servus zusammen,

ich bins mal wieder - es hat sich ein wenig was getan. Und zwar bin ich von meiner GTX 970 SLI Kombi nun umgestiegen auf eine GTX 1080 TI

@apfelnico : Ich habe mich mal daran versucht, Deine damals für mich erstellte AML dahingehend anzupassen.
Sprich, Zweite Grafikkarte entfernt und device-id des HDAU-Geräts aus IOReg ausgelesen und angepasst.

Allerdings habe ich jetzt folgendes Thema:
Witzigerweise zeigt er mir in den Audioeinstellungen nur 2 HDMI-Audio-Geräte an.
Es müssten aber 3 sein. Ich habe 3 baugleiche Monitore mittels Displayport an der einen Grafikkarte angeschlossen.

Mit den 2 GTX 970 und Deiner AML hat er mir auch 3 angezeigt. Nur mit der einen GTX 1080TI sind es jetzt auf einmal nur 2 - bei 3 Monitoren?! Ich verstehs nich...

Wenn Du vielleicht mal Zeit/Lust/Gelegenheit hast, Dir das anzuschauen wäre ich Dir sehr dankbar!
Meine aktuelle IOReg sowie Deine von mir nun angepasste SSDT habe ich mal wieder hochgeladen unter diesem Link:
https://1drv.ms/u/s!AjsB2oNO_NXFofs4oOHm_UK6Fc-h5Q

Muchas Gracias!

Ich könnte mir vorstellen dass Du vielleicht Freedom Force meinst?

Mist - zu spät

Ja,, das Problem tritt offenbar auch nur auf wenn man manuell die Boot Entries eingetragen hat. Wenn es so wie bei dir eingerichtet ist funktioniert es.

UPDATE: Ich Horst - hätte auch einmal in ein paar anderen Foren suchen können, namentlich bei den "Verrückten". Dort hat jemand den Bug bereits gepostet. Offenbar hängt Clover in v4091 wenn man bei GUI "Custom Boot Entries" eingetragen hat. Wenn man diese löscht dann klappt es. Also für diejenigen die vielleicht das gleiche Problem haben - das ist der Workaround.
Den ich übrigens nicht einsetzen werde. Bleibe erst einmal weiterhin bei 4077. Ist mir sonst noch zu buggy.

Hi zusammen,

ich habe - wie eigentlich bei jedem Clover-Update - eine Aktualisierung von Clover v4077 auf v4091 über den Clover-Konfigurator durchgeführt. Mit allen notwendigen Einstellungen wie sonst auch.
Allerdings kommt nun beim Booten nicht mehr das Clover Auswahlmenü sondern nur noch "Welcome to Clover 4091 - scanning entries".
Und da bleibt er nun hängen.

Ich bin jetzt wieder auf v4077 zurück - und keine Probleme.

Hat das sonst noch jemand? Von 3000-irgendwas bis 4077 hat das immer geklappt. Nur jetzt mit 4091 will er plötzlich nimmer.

Cheers
elmacci

Schau mal hier in diesen Thread und die darin verlinkten Anleitungen:

Bluetooth Adapter beendet den Ruhezustand sofort

Kurz zusammengefasst: Du erstellst eine SSDT nur für USB die über Clover zusätzlich geladen wird (ein komplettes Patchen der DSDT wäre nicht notwendig).
Dazu ist aber ein bissl Zeit und Aufwand notwendig (Durchprobieren aller Ports an Deinem Rechner und notieren der aktiven Schnittstellen - feststellen des USB-Ports an dem die Karte hängt und Definition dieses Ports als "Intern"). Lohnt sich aber! Zum einen hast Du dann die USB-Ports alle sauber im System und Sleep funktioniert auch.

cheers