Welches SMBIOS passt besser ?

  • Dann als nächstes CPU Power Management:

    - CPUFriend nach Clover/Kexts/Other

    - Den angehängten DataProvider nach Clover/Kexts/Other

    - In deiner Config.plist den Haken bei "PluginType" setzen und beim Plugin Type Drop Down auf 1 setzen


    Nur mal als test. Vielleicht geht es ja so.

  • CPUFriend, CPUFriendDataProvider in Clover/Kexts/Other

    Config.plist ---> APCI ---> SSDT ---> PluginType on und PluginTypeTopDown = 1


    Hat keinen Effekt auf den CPU Energieverbrauch.


    Wie sieht es denn mit den Power UEFI Settings aus? Gibt es das ein "Standard"-Setting?


    Power Technology: Disabled ; Energy Efficient ; [Custom]

    HWPM Support: Disabled 1) ; HWPM Native Mode 2) ; [HWPM OOB Mode]

    Override OS Energy Performance: [Disabled] ; Enabled

    Energie Performance: [Performance] ; Balanced Performance, Balanced Energy, Energy Efficient

    CPU C1E Support: [Enabled] ; Disabled

    Autonomous C-state Support: [Enabled] ; Disabled

    CPU C3 Report: [Enabled] ; Disabled

    CPU C6 Report: [Enabled] ; Disabled

    Package C State limit: C0 ; C2 ; C6 ; [C6(Retention)]


    FETT = Fest in UEFI, fordert Umkonfiguration

    1) Kernel Crash

    2) CPU Clock 3,6 anstatt 3,8 GHz im Idle

  • Ok wenn es so nicht geht, mit dem MacPro SMBIOS aber schon, würde es vielleicht Sinn machen das MacPro SMBIOS zu nutzen. Das Patchen der AppleGVA für korrekte Video Beschleunigung mit der AMD Karte kann man auch mit Whatevergreen lösen.

    LG Chris


    Meine Hardware:

  • Ich habe heute Mittag etwas ketzerisches gemacht. In gewisser Weise deine Mühe untergraben. Der erste Anschein war bezüglich Power Management gut, aber ob dann auch der Codec auf der GPU geladen werden, habe ich erst jetzt nach zwei Stunden (hügeligen, fiesen) Rennradfahren jetzt ausprobiert.


    Ich muss aber noch weiter austesten bzw. eingrenzen, was genau der Grund für dieses Ergebnis (im Screenshot) hatte.


    Und es ist vermutlich etwas Arbeit meinerseits zu wiederholen ...

  • Dein Vorschlag, das SMBIOS von MacPro6,1 und dann die "AppleGVA-Lösung" umzusetzen, bin ich im ersten Schritt angegangen. Dachte mir, der überarbeitet Clover-EFI-Folder wäre als Ausgangspunkt gut geeignet.


    Habe das SMBIOS von iMacPro1,1 ---> MacPro6,1 geändert.

    • keinen Effekt auf das CPU Power Management.
    • kein Effekt auf den Sleep Mode

    Dann den alten MacPro6,1 Clover Ordner getestet. CPU-PM war ok.

    Die alte MacPro6,1-Config im neuen iMacPro1,1 Clover Folder. ACPI und UEFI CPU PM verändert. Keine zum Ziel führende Veränderungen.


    Dann den alten Kext Other Folder vom MacPro6,1 in den neuen Kext iMacPro1,1 Kext reinkopiern (ersetzten).

    Resultat:

    • Intel SpeedStep ging, von 60W ---> bis auf 9W CPU Power Consumption
    • kein zyklisches Aufwachen und Rückkehr in den Deep Sleep

    NullCPUPowerManagement.kext:!:(z.Z. in Verbindung mit CPUFriend):!:


    Mit dem unveränderten Kext iMacPro1,1 Ordner getestet. Gut.


    Allerdings gibt es auch negative Effekt von NullCPUPowerManagement

    • in CineBench 15 ca. 40 Punkte, von 1110++ ---> 1060++
    • in Geekbench ca. 1000 Punkte weniger, von 25000++ ---> 24000++
    • geschuldet der Reduktion von 3,8GHz (statisch) auf dynamisch bis 3,6GHz (laut Intel Power Gadget)

    USB - was mir noch ein Rätsel bleibt:

    Die Umbenennung XHC1 ---> XHC, EHC1 ---> EH1, EHC2 ---> EH2 bereiten mir scheinbar Probleme.


    Habe gestern ohne die Umbenennung die 15-Port limit die USB 2.0 und 3.0 Konfiguration aufgesetzt und den Rechner getestet.


    Heute mit der Umbenennung ---> Deep Sleep geht ohne Veränderung (alle Lüfter aus, keine LED auf dem Mainboard an), aber der USB-Bus, genauer Tastatur, war "verwirrt". Konnte nach dem Aufwachen das Password nicht eingeben, da einzelnen Zeichen nicht richtig übertragen wurden.


    Die Maus (am Tastatur-HUB des Apple Keyboards) gezogen und wieder eingesteckt. Dann ging die Eingabe über USB wieder. Ist jetzt zwar nur einmal aufgetreten, aber ...


    Muss dazu anmerken, dass die Tastatur-Funktion, d.h. Eingabe über die Tastatur (v.a. Repetition des letzten Zeichen, manchmal kein Reaktion oder Delay der Anschläge) mal mehr, mal weniger "Kopfschmerzen" bereitet.


    Ohne hohen I/O-Traffic lief der Rechner (MacPro6,1 config keine Umbenennung des USB Devices) über Wochen ohne Neustart problemlos.


    Mit hohem I/O-Traffic durch Festplatten udgl. kommen wohl die USB-Device-Driver ins "Stolpern". Die uptime spielt da keine/eine untergeordnete Rolle.


    Was dem USB Bus fehlt, ist eine Art "reset" des USB, sobald kein I/O-Traffic geschieht. Denn sobald die Tastatur gezogen und angesteckt wird, ist alles für einen absehbaren Zeitraum ok.


    Auffällig ist eben nur die Human Interface Devices (Apple HID Device Driver??) v.a. Tastatur, da ich bei Festplatten udgl. keine Effekte feststellen konnte. Hatte keine Effekte in der Art von Datenverlust oder schlechter I/O-Performance. Kann auch sein, dass der Device Driver hier die I/O-Fehler auffängt.

  • Community Bot

    Hat das Label von In Arbeit auf Erledigt geändert