CPUFriend Guide, HWP & Speedstep: X86PlatformPlugin vs ACPI_SMC_PlatformPlugin

Das ist jetzt in der Tat merkwürdig.

Bin leider für die nächsten Wochen unterwegs und kann daher nicht auf meinen Hackintosh zugreifen, der hat allerdings ne IvyBridge CPU, die eh nur mit Tricks XCPM-fähig ist.

Nach Umstieg auf MacPro1,1 Profil und CPUFriend habe ich nur mit AppleIntelInfo.kext überprüft, ob alle P-States auftauchen, aber nicht, welche CPU-PM kexte geladen werden.

Ich meine aber irgendwo gelesen zu haben, dass ACPI_SMC_PlatformPlugin als Fall-Back fungiert. Vielleicht passt irgendwas im iMac20 FrequencyVector nicht zum iMacPro1,1. Wie schon erwähnt hat Intel ja bei der 10ten Generation ganz schön in die Trickkistw gegriffen.

Was sagt denn IntelPowerGadget zum Frequenzverlauf, tut sich da überhaupt was ?

Habe mich inzwischen erinnert, wo ich das mit dem Fallback gelesen habe:

Pike‘s Blog on Wordpress

Am Ende beschreibt er auch, wie man im System nachschaut, was tatsächlich benutzt wird:

Tips:

1.) The X86PlatformPlugin.kext will only load with the plugin-type property is set on the first logical CPU. This however is not enough to enable XCPM mode. No. You may still use AppleIntelCPUPowerManagement.kext Even when X86PlatformShim.kext is loaded.

2.) The FrequencyVectors data in the plist is used to configure power management, and is not the same for all models/board-ids. Please use one that works for your setup.

3.) If sysctl -n machdep.xcpm.vectors_loaded_count returns 0 then the FrequencyVectors data is not being used. Backup the plist for your board-id and replace it with a different plist.

4.) If you use ssdtPRGen.sh to generate your ssdt_pr.aml then make sure to use the -turbo [top-turbo-frequency] argument for overclocked setups.

5.) Check for XCPM related errors at boot time. Like this: X86PlatformShim::start – Failed to send stepper. You got to fix errors or things may not work properly.

5T33Z0 : Auch wenn ich das selbst noch nicht ausprobiert habe, scheint der Weg mit CPUFriendFriend einfacher und weniger fehleranfällig zu sein. Ich bin mir auch nicht sicher, ob CPUFriend nur die FrequencyVectors injiziert oder nicht den gesamten Inhalt der ausgewählten plist, die ja noch andere Einstellungen wie AGPM beinhaltet. Das könnte ebenfalls Nebeneffekte hervorrufen.

Also irgendwie stimmt mit dem PW Management nichts mehr im Intel P. Gadget springt der der Min Core hin und her zwischen 0.7 und 3.5. Core AVG im Bereich über 3.6

Das war vorher nicht so.

Plugin Type steht auf 1

Edit: Evtl. einer von Euch noch Interesse zu helfen?

Mittlerweile tänzelt der CPU-Bereich nur noch zwischen 4 und 5 GHz , an sich wurde nichts verändert an den einstellungen, ausser das ich von OC 0.6 auf 0.6.1 umgestellt habe, aber dara wird wohl nicht liegen oder?

kuckkuck vielen Dank für deine ausführliche Antwort! Mit deiner Hilfe habe ich es geschafft, es zum laufen zu bringen. Also, ganz sicher bin ich mir noch nicht, ob alles gut so ist; ich hoffe, das kann noch jemand beurteilen der sich besser damit auskennt.

Was ich gemacht habe:
-Die Plist von iMac20,2 kopiert und entsprechend abgewandelt

-Mit dem Konverter-Script die SSDT erstellt

-aktuelle SSDT-PLUG deaktiviert, neu erstellte SSDT aktiviert, CPUFriend.kext aktiviert

--> Plugin Type 1 wird nicht eingestellt, die Powernap-Option ist wieder verschwunden und X86PlatformPlugin lädt nicht...menno!

Dann nochmal einen Schritt zurück: Mit der alten SSDT-PLUG wurde Plugin Type 1 geladen, mit der neuen SSDT nicht mehr...also habe ich angefangen zu vergleichen: Irgendwie sieht es in beiden SSDTs ähnlich aus an der Stelle, wo Plugin Type 1 geladen werden soll, aber nicht gleich...meine alte SSDT-PLUG band auch noch die SSDT-DTGP ein, die neue mit dem Konverter-Script generierte nicht mehr...also irgendwie unterscheiden sich die Methoden! Dann habe ich einfach mal ins Blaue hinein versucht, die bisherige SSDT-PLUG, die ja funktionierte, mit den Frequenz-Daten aus der neu erzeugten SSDT zu erweitern.

Und dann klappte es! Man sieht am Verlauf der Taktraten deutlich, dass die CPU nicht mehr grundlos hochaktet und der Verlauf ruhiger geworden ist (beide Screenshots wurden im IDLE aufgenommen). Ich sehe auch in IORegistryExplorer, dass X86PlatformPlugin wieder geladen ist und dort sehe ich auch, dass die Frequenzinfos geladen sind.

Jetzt aber meine große Frage:
Wieso funktioniert Plugin Type 1 nicht bei der SSDT, die das Konverter-Script erzeugt? Kann sich das jemand erklären, der sich mit diesen ACPI-Sachen besser auskennt als ich?

Und vor allem: Ist das in Ordnung so und "sauber" eingebaut?

Zitat von traeu

-Die Plist von iMac20,2 kopiert und entsprechend abgewandelt

traeu mit was und wie hast du diese abgewandelt, könntest du die entsprechende SSDT die nun läuft mal reinstellen?

Zitat von traeu

-Die Plist von iMac20,2 kopiert und entsprechend abgewandelt

Ist der iMac20,2 denn so viel besser?! Ich hab das gestern schonmal irgendwo gelesen das er besser wäre... Muss ich dann wohl auch mal ausprobieren.

kuckkuck Hast du dazu schon mal was derartiges gelesen?

Zitat von kuckkuck

Was dein Problem angeht, müsstest du nochmal erklären, was du bisher genau gemacht hast.

kuckkuck Prinzipiell nichts!

Ich habe die SSDT-PLUG mit dem ssdtime erstellt. Vorab habe ich über die Shell ein acpidump ausgeführt und die generierte DSDT.aml im Terminal mit der SSDTMASTER zur SSDT-PLUG gefertigt.

An sich waren die Freq.Werte immer gut, seit update auf 10.15.6 habe ich das Gefühl das sich dahin was geändert hat.

kuckkuck Danke, das heisst die die SMBIOS iMacPo 1.1 Mac-7BA5B2D9E42DDD94 mit der FrequencyVectors bearbeiten oder die für 19.1 wg. gleichem Prozessor? (Schnellinfo)

Zitat von kuckkuck

Der Grund ist, dass deine alte SSDT _SB.PR00 anspricht, während die generierte _PR.PR00 anspricht. Der Pfad zur CPU0 ist also in der generierten falsch, was häufig passiert.

oh Mann, ein bisschen peinlich....jetzt, wo du es gesagt hast, sehe ich es natürlich auch! Aber da wäre ich irgendwie nicht von alleine draufgekommen...probiere ich direkt aus wenn ich wieder bei der Kiste bin!

Danke für diesen Tipp

Zitat von schmalen

traeu mit was und wie hast du diese abgewandelt, könntest du die entsprechende SSDT die nun läuft mal reinstellen?

Ich habe nur in der Plist die Maximalfrequenz an meine CPU angepasst (bei iMac20,2 von 4500 auf 5000), dann noch (persönliche Preferenz) UnifiedSleepSlider auf NO gesetzt und dann die Zeichenkette bei Frequency Vector in einen Hex Editor kopiert und wie beschrieben die drei Werte Minimalfrequenz (auf 800), EPP (auf 0x40) und EPB (auf 4) angepasst.

Meine eigene Plist anhängen sollte jetzt nicht mehr nötig sein, ich erwarte dass es auch mit der generierten direkt geht, wenn ich den von Kuckkuck gefundenen Fehler behebe indem ich den CPU Namen anpasse. (EDIT: Ja, wie soll es anders sein: Mit geändertem CPU-Namen funktioniert es auch mit der generierten SSDT!)

Die einzige Frage die ich jetzt noch habe (die aber eigentlich gar nicht mehr relevant ist): Unterscheidet sich das Ergebnis des Ressource Converter Scripts, je nachdem ob man direkt die zur CPU passende Plist nimmt oder man erst FreqVectorsEdit verwendet?

Zitat von kuckkuck

Ja, du kannst ja mal beide Wege durchlaufen und dann vergleichen, das Ergebnis ist ein anderes.

Auch wenn ich keinen direkten Unterschied spüre, hat es dennoch geklappt, auch die iMacPro1,1-Plist als Basis zu nehmen. Werde jetzt einfach diese CPU-Daten nehmen! Sollte ja theoretisch am besten zu meiner CPU und meinem SMBIOS passen.

Zitat von traeu

Wenn ich dann der Anleitung weiter folge, trotz dass ich die Maximalfrequenz nicht anpassen kann, und am Ende CPUFriend und die erhaltene SSDT-data aktiviere, wird X86PlatformPlugin nicht mehr geladen, in den Energieeinstellungen sind zwei getrennte Slider und die Powernap-Funktion ist nicht mehr da.

Das hier war also völliger Unsinn, es hätte wunderbar funktioniert, wenn ich den CPU-Namen angepasst hätte...

Ich habe wohl zu recht den Fehler damals schon bei mir vermutet

Zitat von kuckkuck

Verstehe ich jetzt nicht, ich dachte, das Problem war, dass bei der Wahl des iMacPro als Basis das Frequencies Array nicht vorhanden war

Genau, ursprünglich dachte ich, dass es ein Hindernis wäre, wenn die Plist kein Array mit Maximalfrequenzen hat, sondern nur einen Vector-Eintrag (wie auf dem Screenshot von mir in Post 120).

Das dachte ich, weil es eben nicht geklappt hat, mit der aus dieser Plist erzeugten SSDT "Plugin Type 1" zu kriegen...

Hätte ich da schon gewusst, dass nur der CPU-Name falsch ist, hätte ich da schon bemerken können, dass es egal ist, ob da die Maximal-Frequenz-Einträge sind oder nicht, weil der Ressource Converter in beiden Fällen ordentliche Ergebnisse liefert (bis eben auf den falschen CPU Namen, der mir nicht aufgefallen ist)