Beiträge von oberstel

    Hallo Zusammen,


    mein Hackintosh mit OpenCore 0.8.5 und macOS 13.1 läuft eigentlich sehr stabil.

    Heute habe ich im Kernel Log einen Haufen Fehlermeldungen in Bezug auf meine Grafikkarte Radon RX 570 gefunden:

    Code
    1. [ 6612.318892]: [1:0:0]: AMD ERROR! Failed to allocate size:13631488. There is 23961536 free memory remaining, and 4200624064 fixed-free memory remaining.
    2. [ 6612.318916]: [1:0:0]: AMD ERROR! Failed to allocate size:13631488. There is 24027072 free memory remaining, and 4200624064 fixed-free memory remaining.
    3. [ 6612.318927]: [1:0:0]: AMD ERROR! Failed to allocate size:13631488. There is 24092608 free memory remaining, and 4200624064 fixed-free memory remaining.
    4. [ 6612.318952]: [1:0:0]: AMD ERROR! Failed to allocate size:13631488. There is 24158144 free memory remaining, and 4200624064 fixed-free memory remaining.

    Davon habe ich mehrere hundert Einträge im Kernel Log und es kommend auch laufend weitere dazu... :-(

    Ich weiß nicht, ob das vor dem Update auf Ventura auch schon so war oder ob das mit einer bestimmten OC Version kam.


    Hat jemand eine Idee wo ich mal hinschauen könnte um herauszufinden woran das liegt?


    Wie gesagt, der Rechner läuft erstmal einwandfrei aber irgendwas scheint ja mit der Speicherverwaltung der Grafikkarte nicht zu stimmen.

    Hier mal meine config.plist sowie mein kernel.log, falls jemand da reinschauen möchte:

    Dateien

    • config.plist

      (22,57 kB, 83 Mal heruntergeladen, zuletzt: )
    • kernel.log.txt

      (6 MB, 78 Mal heruntergeladen, zuletzt: )

    Nach ausführen des Befehls und den Einstellen vom pmset legt er sich nun wie gewünscht schlafen.

    Allerdings fahren nun meine Dockercontainer nicht mehr hoch.

    Verständnisfrage: Wenn Du auf Deinem System mit Docker Containern arbeitest... Ist ja die Idee von Containern, bestimmte Microservices bereitzustellen - Das ist doch die Natur von Docker. Demnach würde ich sogar erwarten das Docker den Standby seines Hosts verhindert. Oder?


    Guck doch mal warum Deine Container NFS brauchen und deswegen jetzt nicht mehr starten.

    Vor ein paar Tagen habe ich mir einen neuen Rechner zusammengebaut und OpenCore 0.6.4 und macOS Big Sur, Windows 10 und Ubuntu 20.04 installiert.

    Der Rechner hat ein MSI MPG z390M Mainboard mit i5-8600k CPU und 16 GB RAM. Storge ist eine NVMe SSD mit 500 GB im M.2 Slot.

    Soweit läuft eigentich alles super.


    Das Linux bootet in <9 Sekunden - Sehr geil!

    Windows startet in flotten 13 Sekunden - Was echt toll ist.

    Nur macOS braucht für den Start >26 Sekunden - das finde ich komisch.


    An der Hardware kann es also eigentlich nicht liegen... die rennt wie sau.

    Im Logfile erkenne ich auch nicht "den einen Delay", dass läuft eigentlich alles recht smooth durch, braucht halt nur mehr als 25 Sekunden :-(

    kernel_boot_log.txt


    Anbei lege ich auch mal meine config.plist, so viele Kexte und Driver lade ich eigentlich gar nicht...

    config.plist


    Hat einer von Euch eine Idee wo ich mal hinfassen sollte?

    Oder ist das eine normale Bootzeit und ich sollte mich damit begnügen?

    Das MacPro7,1 SMBios ist gänzlich falsch bei deinem System wie schon von badbrain angemerkt.


    Switchen und gut ist.

    Für meine Board/CPU Kombination wäre eigentlich der iMac15,1 die richtige SMBios Definition. Hierbei habe ich aber Probleme mit den USB Ports, Standby/Wakeup tut nicht richtig und auch die GPU Unterstützung bei H.264 und HVEC Videos funktioniert dann nicht.

    Seit dem ich MacPro7,1 nutze - geht das alles - Also, die Aussage „gänzlich falsch“ kann ich so nicht nachvollziehen.


    DSM2: Warum meinst Du das das so falsch ist? Was für eine SMBIOS Definition sollte ich Deiner Meinung nach nutzen?


    Danke al6042 für die Idee im VoodooHDA Kext mal nachzuschauen... Da bin ich tatsächlich fündig geworden.

    Auf Sourceforge liegt ja der Source Code von dem Kext und in der Datei VoodooHDAEngine.cpp erfolgt anscheinend genau die gesuchte definition:


    Werde am Wochenende das mal nach meinen Bedürfnissen anpassen und den Kext dann neu compilieren.


    Noch eine Frage an die Community bzgl. AppleHDA und VoodooHDA:

    Ich persönliche nutze den VoodooHDA schon seit vielen Jaren ohne Probleme... wie ich hier „zwischen den Zeilen“ lese, scheint es als hätte der VoodooHDA Kext nicht so viele Anhänger ;-) Oder täusche ich mich?


    Gibt es einen plausiblen Grund warum man lieber AppleHDA und nicht VoodooHDA nicht einsetzten sollte?

    Für meinen Rechner (i7-4790 auf MSI H97M-G43 mit AMD RX570) nutze ich die SM-BIOS Einstellungen für einen MacPro7,1.

    Bekanntermaßen gibt es bei bei Nutzung dieser SM-BIOS Einstellung das Problem mit der Meldung "Memory Modules Misconfigured".


    Seit Big Sur funktioniert leider der Kext MacProMemoryNotificationDisabler nicht mehr.

    Anstelle dessen, gibt es für OpenCore den Vorschlag eine Custom Memory Konfiguration in der config.plist vorzunehmen.

    Siehe auch: https://dortania.github.io/Ope…y.html#mapping-our-memory


    Das habe ich für mein Setup entsprechend umgesetzt, allerdings kommt die nervige Meldung immer noch nach jedem Start.

    Alle Einträge aus der config.plist werden bei "Über diesem Mac" > "Speicher" korrekt angezeigt, aber leider mit einem Ausrufezeichen versehen:


    Ich habe natürlich auch andere Kombinationen auf verschiedenen Bänken ausprobiert... Aber die Ausrufezeichen und die nervige Message Box kommen immer wieder.

    Im Anhang findet Ihr meine config.plist. Vielleicht kann ja jemand mal einen Blick drauf werfen und mir sagen was ich falsch machen.


    In der aktuellen config.plist habe ich 12 RAM Slots eingetragen, da der echte MacPro ja auch 12 hat. Mein Rechner hat eigentlich nur vier Slots, aber auch wenn ich in der config.plist die realen Gegebenheiten mit 4 Slots konfiguriere kommen die Ausrufezeichen und die Fehlermeldung :-(


    Update: Habe den Fehler selber gefunden. Bei den leeren Slots hatte ich bei Device > Size und Device > Speed jeweils eine 0 stehen (die Slots sind ja sich nicht belegt). Das findet Big Sur aber irgendwie doof. Wenn man dort eine 1 rein schreibt (so wie es in der Doku steht) dann bekomme ich bei jedem Slot einen grünen Haken und die Meldung kommt auch nicht mehr.

    Gelöst.

    Dateien

    • config.plist

      (30,03 kB, 221 Mal heruntergeladen, zuletzt: )

    Mein Rechner hat eine ganze Reihe von verschiedenen Audio Ports die mir durch die lokale Soundkarte und genutzte Grafikkarte angeboten werden:

    Gibt es eine Möglichkeit diese Bezeichnungen irgendwie / irgendwo zu ändern?

    So würde ich gerne aus "Headphone (Green Front)" ein "Intern" machen, da ich an diesem Port den internen Lautsprecher des Desktops angeschlossen habe.

    Oder die beiden "SPDIF-out (Black Rear Panel)" in "SPDIF Optical" und "SPDIF Coaxial" umbenennen da man an der aktuellen Bezeichnung nicht erkennen kann um welchen physikalischen Port es sich handelt...


    Hat jemand eine Idee?

    Wo steht das mit voodoohda? Außerdem kann (sollte man sogar) AppleALC statt voodoohda verwenden...

    Sorry, mein Fehler. Nicht VoodooHDA sondern AppleGFXHDA soll ja geblockt werden.


    Habe mal com.apple.driver.AppleGFXHDA wie in dem Beitrag beschrieben in der config.plist unterhalb von Kernel/Block eingetragen. Das klappt so aber nicht.


    Im Log steht dann:

    20:441 00:006 OCAK: Failed to pk find com.apple.driver.AppleGFXHDA - Not Found

    20:443 00:001 OC: Prelinked blocker result 1 for com.apple.driver.AppleGFXHDA (Disable GPU Audio Ports) - Not Found


    Den VoodooHDA.kext nutze ich, da mit AppleALC die VT2020 nicht laufen bekommen habe. Auch wenn Voodoo Teufelszeug ist - Bei mir läuft der Sound damit super ;-)

    Als Grafikkarte nutze ich in meinem Test-Rechner eine AMD RX560. Hierdurch werden mir 5x HDMI Ports als mögliches Audio Ports angezeigt.

    Auf dem Mainboard ist eine VIA VT2020 Soundkarte verbaut, welche ebenfalls einige Audio Ports anbietet (SPDIF, Kopfhörer etc.).

    Als Treiber nutze ich VoodooHDA und nicht AppleALC.


    Eigentlich nutze ich "nur" die Audio Ports der OnBoard Soundkarte. Die Audio Ports der Grafikkarte würde ich gerne irgendwie ausblenden.


    Um das zu erreichen, habe ich probiert in der config.plist den entsprechenden PCI Pfad bei DeviceProperties/Delete einzutragen, dass hat aber keinen Effekt:


    Im IORegitryExplorer werden die Ports der OnBoard Soundkarte unterhalb von HDEF@B1 aufgelistet, die der Grafikkarte unterhalb von PEG0@1:

    Gibt es eine Möglichkeit die Einträge unterhalb von PEG0 irgendwie zu droppen?


    Oder hat jemand eine Idee wie man die nicht benötigten Ports ausblenden kann?

    Habe meinem Rechner mal etwas "Beauty Treatment" gegönnt und OpenCanopy eingerichtet... Nicht weil ich's brauche sondern weil's geht ;-)


    GUI finde ich klasse und BootChime funktioniert eigentlich auch. Allerdings "hängt" der Rechner beim Booten für ca. 15 Sekunden bevor der bekannte Boot-Sound aus dem Lautsprecher ertönt. Im Log steht folgenden:

    Code
    1. 06:072 00:003 OC: Starting to play chime...
    2. 06:075 00:003 OC: Wave Resources\Audio\OCEFIAudio_VoiceOver_Boot.wav was requested
    3. 14:934 08:858 OCAU: File 59 for lang 7 is 32 2 2 (440576) - Success
    4. 15:038 00:104 OC: Play chime started - Success

    Success list sich ja toll, aber warum 8 Sekunden nach dem Request?

    Unterhalb von .../ressources/audio befindet sich nur diese eine .wav Datei und ich kann mir nicht erklären wofür das System sooo lange braucht.


    Was bedeutet File 59?

    Lang 7 ist vermutlich ein Language Code...

    Und was ist 32 2 2?


    Kann mir jemand einen Tipp geben wo ich mal hingucken sollte?

    48 Sekunden empfinde ich schon als lang. Verwendest Du eine mechanische Festplatte?

    Ja, das ist schon recht lang - Ich müsste die Kiste mal grundsätzlich neu aufsetzen... habe ich seit High Sierra nicht mehr gemacht. Immer nur Updates gefahren :-)


    Local Storage ist eine Samsung EVO 960 SSD mit M.2 Formfaktor. Dazu passend eine NVMe Raiser Karte.

    Laut Blackmagic Speed Test kommen da lesend wie schreibend rund 1.300 MB/s rüber. Die SSD könnte noch viel mehr, wenn ich die Raiser Karte mit 16 PCIe Lanes versorgen würde - Main MoBo hat aber nur einen x16 Slot und in dem steckt die Grafikkarte :-( Demnach habe ich die Raiser Karte in einen x4 Slot gesteckt und da kommt eben nicht viel mehr rüber.


    Vor geraumer Zeit hatte ich mal testweise den x16 Slot genutzt und bekam dann 2.900 MB/s read und 1.800 write. Das booten der Kiste ging dadurch aber auch nicht schneller.

    Irgendwie logisch, dass die Debug-Variante langsamer ist, oder? Denn es laufen parallel wahrscheinlich noch Monitoring-Prozesse und es werden Logs und Diuagnosebereichte zum Debuggen erzeugt.

    Naja, logisch schon - Aber es würde mich halt interessieren welche Erfahrung Ihr machen konntet (to guess is not to know).


    Mein Rechner (keine aktuelle Hardware, viel Software installiert) bootet in ca. 48 Sekunden (gemessen von Boot-Picker bis zum Erscheinen des Desktops.

    Diese 48 Sekunden braucht das System mit OC Release genauso wie mit OC Debug. Demnach macht es (zumindest bei mir) keinen Unterschied.

    Also könnte ich die Debug Binaries einfach immer nehmen, um bei Bedarf Debug einschalten zu können ohne die drei Files in der ESP austauschen zu müssen.

    OC gibt es ja in der Ausprägung "Release" und "Debug". Passend dazu kann man in der config.plist den Debug-Level setzen.


    Gibt es da Unterschiede in der System Performance? Also OC Release vs. OC Debug und Debug true/false...

    Gerade beim Booten habe ich oft das "Gefühl", dass mit aktiviertem Debug das System irgendwie langsamer bootet.


    Wie ist Eure Erfahrung?

    Ich weiß echt nicht mehr weiter... Nach einigem herumgebastel mit OC auf meinem Testrechner, habe ich OC 0.6.3 jetzt (im Zuge von Big Sur) auf meinem Desktop installiert (da war vorher Clover drauf).

    Der Rechner läuft soweit stabil (Audio, USB, WiFi, BT.... alles ok) und im Debug-Log tauchen keine groben Fehler auf.


    Nur schaffe ich es nicht das OC automatisch über das BIOS bootet :-(

    In dem Rechner hängt eine SSD (M.2 NVMe) auf der die EFI Partition sowie macOS, Ubuntu und Windows installiert sind.

    Alle drei Betriebssysteme kann ich über die UEFI-Shell einwandfrei starten (fs0: .... bootx64.efi bzw. grub64.efi)


    Mit Hilfe von Ubuntu und efibootmgr habe ich für OC entsprechende Einträge gemacht, die mir das BIOS des Mainboard aber leider nicht anzeigt. Anstelle von OpenCore, Windows und Ubuntu sehe ich nur vier leere Zeilen:


    Auf den Seiten von dortania habe ich irgendwo gelesen, dass es in der config.plist unterhalb von Misc > Security den Key "BootProtect" gibt. Da soll es wohl ein Problem mit dem Z97 Chipsatz geben (doch ich habe ja den H97).

    Der Key hat bei mir den Wert "Bootstrap" und wenn ich über die Shell die Bootstrep.efi starte, startet macOS einwandfrei. Aber ein entsprechender Eintrag im Boot Menü wird nicht angelegt.


    Hat jemand eine Idee?

    KMBeatz Sauberer wäre es die ACPI patches OS-aware zu schreiben oder nur MacOS mit OC zu starten.

    Ich habe mir dann auch gedacht, in den SSDTs noch ein If (_OSI ("Darwin")) einzubauen. Canopy nutze ich auch und eine Abfrage der OS Version in den SSDTs finde ich recht charmant. Das man hier nicht Linux (Ubuntu) handeln kann wusste ich nicht 🤔 mal gucken wie ich damit umgehe...


    Euch allen erstmal vielen Dank für die Diskussion!