Beiträge von Inspector42

Werde auch wieder vorbeischauen

Plane auch vorbeizukommen. Anfahrt diesmal aus Hamburg und nicht aus Frankfurt.

Der Monitor ist inzwischen installiert und Audio über HDMI funktioniert wie erwartet.

ich hatte noch die Gelegenheit, Windows auf einer separaten Festplatte zu installieren und auch Windows erkennt den ALC887 nicht. Also ist nun relativ sicher, dass es ein Hardware Problem ist.

Damit kann ich das Kapitel nun schließen.

Nochmals vielen Dank an alle, die mich mit Ratschlägen bei der Fehlersuche unterstützt haben.

Dies war mein erster Stammtisch und ich kann ohne Einschränkung sagen, dass sich die Anreise aus Frankfurt gelohnt hat.

Neben dem Kernthema Hackintosh haben wir bestimmt noch ein Dutzend andere Themen gestreift und ich habe viele interessante Leute kennengelernt. Natürlich habe ich auch wertvolle Details fürs die Optimierung meiner H(M)ac-Flotte gelernt.

Das war sicherlich nicht mein letzter Stammtischbesuch.

griven  Coaster : Sorry für den etwas überhasteten Aufbruch, um mein Auto noch vor Schließung aus dem Parkhaus zu holen. Habe dabei völlig vergessen, meine Tasse und den Müll wegzuräumen 🙈

Update: Nach viel Rumexperimentieren bin ich zu dem Schluß gekommen, dass die HD-Audio Hardware ne Macke hat. Die Hardware wird zwar im Linux als device geführt, weshalb ich auch einen validen Codec-Dump erzeugen konnte. Allerdings wird sie von den Linux-Treibern nicht erkannt und funktioniert daher auch unter Linux nicht.

Ein Vergleich des selbst erstellen Layouts mit vorhandenen Einträge im AppleALC.kext hat weiterhin gezeigt, dass zumindest der Line-Out identische Parameter mit vorhandenen Layouts hat und somit Mirone´s Layout-ID 5 hätte funktionieren müssen.

Also habe ich die Brechstange ausgepackt und bei eBay für 40€ einen Monitor mit eingebauten Lautsprechern ersteigert, dann gibt es Audio halt über HDMI.

Gott sei Dank brauche ich kein HIFI und günstige USB Soundsticks waren gerade auch nicht für weniger Geld im Angebot.
Monitor wird nächste Woche erwartet, dann liefere ich noch ein finales Update.

Ich plane ohnehin einen Abstecher ins Ruhrgebiet und wenn das Wetter keine Kapriolen schlägt, schaue ich Samstag mal vorbei.

Hallo Sascha,

kann leider auch nicht mit einer kompletten Übersetzung dienen, da mein Japanisch ziemlich eingerostet ist.

Bin aber vor 30 Jahren mit Zug und Rucksack mehrere Monate durch Japan gereist und hatte dafür Japanisch gelernt.

Japanisch benutzt 3 Symbolklassen:

Kanji: Dass sind die komplexen Zeichen

Hiragana: Silbenalphabet, das alle Worte abbilden kann und in der Schule verwendet wird, bevor die Schüler die Kanji beherrschen oder als Ersatz, falls der Author das Kanji nicht kennt. In normalen Texten primär für Bindeworte und Konjugation der Verben verwendet. Die Smybole sind eher „rundlich“

Katakana: Silbenalphabet wie Hiragana aber deutlich „kantigere“ Symbole. Wird nur für ausländische Namen oder japanisierte, ausländische Worte verwendet. Leider gibt es keine 1:1 Beziehung zwischen unserem Alphabet und den verfügbaren Silben, da ist manchmal etwas Vorstellungskraft gefordert.

Die technischen Begriffe werden mit Kanji dargestellt, allerdings sind Kanji eigentlich Pictogramme, die aber einige Tausend Jahre alt sind. Bei modernen oder abstrakten Begriffen wird dann mit vorhandenen Kanji etwas „äquivalentes“ zusammengebaut. So ist z.B. das Wort für Spannung wörtlich übersetzt „elektrischer Druck“ (電圧). Ohne Wörterbuch ein manchmal lustiges Rätselraten.

Ich hab mal ein paar wiederkehrende Begriffe übersetzt, für die gesamte Datei müsste ich wohl mindestens einen trüben Tag investieren.

Eine weitere Schwierigkeit ist, dass die Eisenbahngesellschaften in Japan lokal sind und sich in den Text viele Namen von Präfekturen, Regionen oder Firmen einreihen. Wenn man da keine Liste mit diesen bereitliegen hat, landet man relativ häufig „im Wald“. Idealerweise bräuchtest Du einen japanischen Eisenbahn Fan zum Übersetzen.

高性能 : Hochleistung

電鉄: Elektische Eisenbahn

電車: Elektischer Zug

電気機器：Elektrisches Equipment / Maschine

熊本: Kumamoto : Name der Präfektur

形: Typ / Modell

東急電鉄: „Elektrischer Ost Schnellzug“

Ich versuche mich in Kürze mal an einem kompletten Textblock, daraus ergibt sich vielleicht ein größerer Fundus an wiederkehrenden Begriffen.

Dieses Übersetzungsprogramm / Wörterbuch für iOS hat mir immer gute Dienste geleistet:
https://apps.apple.com/us/app/japanese/id290664053

[EDIT]

Vielleicht kann man sich der Thematik auch noch anders nähern, in dem man im Internet nach Japanischen Zügen oder Eisenbahnen sucht und ggf. die Bilder vergleicht. Leider mindestens genauso mühsam wie die Übersetzung, wenn man nicht tief in der Materie steckt. Führt sicherlich auch nicht zu authentischen Übersetzungen☹️

https://de.m.wikipedia.org/wiki/Schienenverkehr_in_Japan

[EDIT2]: Das mit der Übersetzung hat sich doch als deutlich schwieriger herausgestellt, als ich erwartet hatte. Hier also die (recht freie) Übersetzung des ersten Blockes. Vermutlich stehen einem "native speaker" die Haare zu Berge, wenn er/sie das liesst. Geholfen hat die Recherche des Zugtyps und die Betrachtung des dabei gefundenen Bildes. Obwohl die Übung Spass gemacht hat, kann ich mit 2h pro Zugbeschreibung leider nicht alle 26 übersetzen☹️.

熊本電鉄5000形

東急電鉄で運用されていた５０００系電車(初代)がベース となり、正面は大きな２枚窓を採用した湘南スタイル、下ぶくれの愛嬌ある顔つき、緑一色のカラーリングから、「青ガエル」の愛称で親しまれている。当時はモノコックを採用した超軽量ボディとアメリカからの技術導入による、最新の電気機器を備えていた高性能電車。

Kumamoto Elektrische Bahn Modell 5000

Das Zugsystem 5000 (erste Generation) wurde bei der Tokyu Railways als Basis eingesetzt. An der Front wurden 2 große Fensterflächen im “Shoonan” Stil verwendet. Darunter befindet sich eine Fläche mit “bukure”(mein vielleicht Bukarest=Rumänisch?) Charme und das einheitliche “Kata ichi ringa” Grün brachte ihm den Spitznamen “Ao Gaeru” oder „Grüner Frosch“ ein. Zu der Zeit wurde “Tenoshita” adaptiert und “Bodei” und amerikanische Leichtbautechnology eingeführt. Der Einsatz der neuesten Technology führte zur hoch effizienten Zügen.

Eigentlich dachte ich alle ID‘s bereits durchprobiert zu haben, allerdings hatte ich das über die device properties gemacht.

MacPeet: Da werde ich dann nochmal genauer hinschauen müssen, wenn auch auf meinem Board die üblichen Knoten im Einsatz sind stimme ich Deiner Einschätzung zu, dass dann eine existierende ID funktionieren sollte.

Wahrscheinlich habe ich mal wieder irgendein Detail übersehen.

Final update:

Nachdem ich günstig an ein H77 Board gekommen bin, habe ich den harten Schnitt vollzogen und das System umgebaut. Mit dem UEFI-BIOS erledigen sich viele Komplikationen und gegenüber einer PCIe-SATA Karte war die Investition auch nicht wesentlich höher, wenn man mal den Aufwand für den Umbau außen vor läßt.

Nun funktioniert fast alles wie erwartet, nur Ton bekomme ich nicht aus dem ALC887 gezaubert.

Das ASUS-P8H77-V LE hat eine Konfiguration, die zu keinem vordefinierten Layout in AppleALC zu passen scheint. Einen IRQ Konflikt kann ich nach Erzeugung und Installation einer passenden SSDT inkl. der Patch-Einträge in der config.plist von OC ausschießen.

Wenn es mir wieder in den Fingern juckt, werde ich mal versuchen, die notwendigen Ergänzungen für ein eigenes Audio-Layout in AppleALC einzubringen, den notwendigen codec-dump habe ich bereits mit einem Linux-Live-System extrahiert und mit PinConfigurator angeschaut.

Nun muss ich nur noch herausfinden, wie ich die layout.xml and platform.xml Dateien anpassen muss.

MacPeet: Ich versuche mich gerade an Deiner Anleitung auf root86.com, allerdings scheint ja der PinConfigurator inzwischen auch die Bereinigung der Verbs zu ermöglichen. Irgendwie fehlt mir im Moment noch der Überblick und die Zeit, das mal in Ruhe anzugehen.

plutect: Blutooth braucht eigentlich nur zwei Leitungen D+ und D-. Die anderen beiden sind beim normalen USB Stecker mit GND und VCC (+5V) belegt. Die bekommt das Bluetooth Modul aber schon über den M.2 Adapter,

Es ist übrigens wichtig, D+ und D- nicht zu vertauschen, aber soweit ich das auf dem Foto sehen kann, ist die Verbindung zum Blutooth Modul richtig verbunden. Daher sollte es wie auf dem Bild in Post #16 zu sehen auch mit den zwei Leitungen funktionieren.

Ich hatte bei meinem Hackintosh Probleme mit "Allow Blutooth devices to wake this computer", was bei mir durch die AppleWatch getriggert wurde.

Die Einstellung ist in den Systemeinstellungen unter Bluetooth-Advanced. Allerdings kann man nach Deaktivierung den Computer dann auch nicht über BT-Tastatur oder BT-Maus aufwecken und muß dann auf den Power-Button ausweichen. Wäre einen Versuch wert, falls Du das noch nicht probiert hast.

Update:

Nachdem ich die EFI Partition der ebenfalls eingebauten Festplatte gelöscht habe und damit nur noch eine Boot-Partition (auf der SSD) im System vorhanden ist, wird plötzlich auch die Datei nvram.plist erzeugt und die scheint auch vom open core nach dem Neustart sauber geladen zu werden. Ich sollte ebenfalls noch erwähnen, dass ich das Home-Verzeichniss des primären Accounts noch aus Zeiten teurer SSDs auf die Festplatte umgelenkt hatte. Das hatte ich bei der Aktion wieder rückgängig gemacht. Basierend auf der nun folgenden Problembeschreibung ist es wahrscheinlich, dass das Home-Verzeichnis auf der ausgebremsten Festplatte die eigentliche Ursache war.

Im Zuge der Ursachenforschung hat sich aber nun noch ein anderes, mehr fundamentales Problem gezeigt: Die interne 2GB Festplatte am zweiten SATA Port ist furchtbar langsam, so dass selbst das Abspielen einer Audio-Datei nicht möglich ist. Dabei scheint die Datenübertragung immer für ein paar Sekunden einzuschlafen, um dann wieder mit normaler Geschwindigkeit für einen kurzen Boost zu funktionieren. Unterm Strich bleibt aber eine sehr, sehr magere Netto-Übertragungsrate übrig, die beim Kopieren von Dateien auch häufiger den Beachball in Erscheinung bringt. Dagegen wirken externe USB2 Platten wie mit Lichtgeschwindigkeit.

Folgende potentielle Ursachen habe ich bereits ausgeschlossen:

1. Defektes SATA-Kabel: Ich habe zwei andere ausprobiert, die nachweislich in einem anderen Rechner funktioniert haben - selbes Symptom
2. Defekter SATA Stecker auf dem Mainboard: Festplatte ist auf allen 4 SATA Ports gleich langsam, die System SSD funktioniert dagegen auf allen Ports mit voller Geschwindigkeit
3. Defekter SATA-Controller im H61 Chipset: Chipset ist Revision 5, welches den ursprünglichen Fehler bei den Ports 2-5 beim Serie 6 Chipsatz von intel nicht mehr haben sollte. Außerdem funktioniert die SSD an allen Ports ohne Probleme und die Festplatte ich auch den an nicht betroffenen Ports 0 und 1 langsam.
4. Defekte Festplatte: Egal welche andere Festplatte / SSD ich versuche, als Zweitlaufwerk in den PC einzubauen: Das BIOS erkennt sie alle ausnahhmslos, aber macOS meldet, dass das "eingelegte Laufwerk" nicht gelesen werden kann. Jeglicher Formatierungsversuch endet mit dem Fehler "Auf den letzten Block des Gerätes konnte nicht geschrieben werden: (-69760)". Alle getesteten Laufwerke lassen sich aber sowohl an meinem MacBookPro (Catalina) über USB-SATA Adapter als auch ein meinem anderen Hackintosh (BigSur) am internen SATA Port einwandfrei formatieren und mit normaler Geschwindigkeit nutzen.
5. Interrupt-Konflikte: Ich habe im IO-Registry-Explorer alle IOInterruptSpecifier aller Geräte durchgeschaut und keine Überlappung zwischen dem IDE/SATA Controller und anderen Geräten entdeckt. Das war nach der Verwendung der bereinigten DSDT eigentlich auch so zu erwarten.

Es scheint fast, als könnte ich am PCH nur ein SATA Gerät betreiben, wobei es schon merkwürdig ist, dass das Boot-Drive immer funktioniert und nur das "Zweitlaufwerk" ausgebremst wird, egal ob HDD oder SSD und egal ob als ExFat, HFS journaled oder APFS formatiert.

Im Moment tendiere ich dazu, einfach eine PCI SATA Karte nachzurüsten und hoffentlich damit das Problem zu umgehen.

Vielleicht hat ja jemand noch ´ne gute andere Idee, an die ich nicht gedacht habe.

bluebyte Super Hinweis, in der Tat funktioniert NVRAM nicht nativ.

Allerdings bekomme ich die Emulation nicht ans Laufen.

Eintrag für LogoutHook ist vorhanden, Ausführungsrechte für die Skripte sind ebenfalls vorhanden.

Open Core config.plist habe ich angepasst.

Trotzdem wird keine nvram.plist auf der Boot-EFI Partition bei Logout erzeugt. Ich konnte aber auch die von LogoutHook.command erzeugten Meldungen im System-Log nicht ausfindig machen und bin daher etwas ratlos.

Die anderen Probleme habe ich jetzt dadurch umschifft, dass ich anstelle der diversen SSDTs für Open Core einfach die mit F5 extrahierte, von Clover on-the-fly gepatchte DSDT nutze. Die enthält nämlich außer des EC devices schon alles Notwendige.

Jetzt funktioniert auch das Injizieren der device properties.

In Verbindung mit dem Löschen der richtigen CpuPM Tabelle flutscht jetzt auch das CPU Power Management.

Nach einiger intensiver Recherche und Ausprobieren habe ich nun zumindest ein lauffähiges System 10.15.7 mit OpenCore zu Stande gebracht.

Die Kern-Herausforderung sind die ziemlich vermurksten ACPI-Tabellen des Hybrid-BIOS.

1. Die DSDT enthält den Teil (C-States) vom Power Management, der eigentlich in Cpu0Ist stehen sollte.
2. Die P-States sind dafür in einer separaten SSDT definiert, allerdings mit der Table-IDPPM RCM
3. Der DSDT fehlt die Methode DTGP, ohne die das Injizieren von device properties nicht sauber funktioniert

Also läuft die Kiste im Moment mit Kernel>Emulate>DummyPowerManagement und alcid=1 als boot-arg, weil die layout-id als device property nicht von AppleALC gefunden wird. WhateverGreen beschwert sich über die falsche device ID des IMEI, die offenbar auch nicht injiziert wird obwohl sie in der config.plist steht.

Die Fehlermeldung vom ersten Eintrag war übrigens auf meine eigene Schusseligkeit zurückzuführen, da ich SSDTTime aus Versehen mit eine bereits gepatchten DSDT gefüttert hatte. Das Einfrieren des Systems ist auf das CPU Power Management zurückzuführen, da die System internen Tabellen auf Grund der anderen Table-IDs nicht gelöscht wurden. Offenbar passiert da in Clover einiges zusätzlich hinter den Kulissen, denn da funktioniert das PowerManagement mit derselben SSDT aus ssdtPRgen. Es heißt also weiter recherchieren.

Als kleines extra Ärgernis kann man im OpenCore BootPicker keinen Default-Eintrag definieren. Mit UEFI>Quirks>RequestBootVarRouting wird immer der ersten Eintrag mit dem Stern versehen, egal was man im macOS als Startvolumes anwählt. Ohne ist nichts als Default definiert und egal welchen Eintrag man mit crtl-enter anwählt, beim nächsten start ist der Cursor wieder auf dem ersten Eintrag der auf die EFI Partition der Festplatte and ersten SATA Anschluß zeigt.

Weiß jemand, wie man in Open Core die Methode DTGP über eine SSDT einfügt ? Die SSDT im Anhang scheint das nicht zu bewerkstelligen, oder die dysfunktionale Injektion der device properties hat andere Gründe.

Ich muss zugeben, dass dieser PC damals nur als Minimal-Lösung mit i3-2125 ohne dedizierte Graphikkarte an den Start gegangen ist. Im Laufe der Zeit hat es dann Upgrades aus übergebliebenen Komponenten erhalten und nun hat mich der Ehrgeiz gepackt, auch dieses System auf einen halbwegs aktuellen Stand zu bringen (sprich idealerweise BigSur).

Irgendwie hatte ich schon geahnt, dass Open Core auf dem Hybrid-BIOS nicht so flutschen wird, aber ich bin ja gefühlt schon auf der Zielgeraden.

Habe gerade noch ein bisschen rumprobiert und bis zum Freeze funktioniert auch Safari, Apple Maps und Photos ohne murren.

Auch im System Report sieht alles so aus wie es soll, auch wenn ich das nur in mehreren Etappen anschauen konnte.

Das System friert auch nicht beim Aufruf irgendeiner Funktion ein, sondern scheint sich eher in der Zeiten ohne Benutzeraktion zu verabschieden - als würde die Nutzeraktion irgendeinen Hintergrundprozess ausbremsen, der dann irgendwann genug CPU-Zeit vom System zugewiesen bekommt, um loszulegen und dann voll auf die Nase zu fallen.

Jetzt ist aber Schluß für dieses Jahr, auch wenn die Silvesterparty diese Jahr im kleinen Rahmen stattfindet, braucht es noch ein wenig Vorbereitung.

Ich wüsche Euch allen einen guten Rutsch und ein erfolgreiches Jahr 2022.

hallo apfel-baum, OSX-Einsteiger,

danke für die schnelle Antwort. Hatte allerdings BootInstall_X64.tool schon für die Installation von openduet auf der Boot-SSD verwendet.

Ohne das (openduet) findet das BIOS von System 2 gar nichts auf der SSD.

Das funktioniert ab Catalina nur noch mit ausgeschaltetem SIP und das hab ich nur auf dem laufenden System 1 hinbekommen, daher der beschriebene Umweg.

Wenn man -v als boot-arg weglässt, sieht der Boot-Vorgang auch ganz normal aus, und bis zum Einfrieren kann ich das System auch normal nutzen, ich kann "Über diese Mac" aufrufen, Aktivitätsmonitor funktioniert auch und ich konnte die Konsole starten. Leider beträgt die Zeit bis zum Einfrieren nur 1-2 Minuten.

Wenn ich das System 1 (UEFI) von dieser SSD boote, funktioniert alles ohne Einfrieren - gleicher Prozessor, nur der Z68 Chipsatz anstelle des H61.

Nachdem ich nun seit geraumer Zeit erfolgreich mit Open Core auf meinem Hauptsystem (1) und den beiden MacPros (3,4) gefahren bin, wollte ich nun noch das verbliebende System (2 in der Signatur) zunächst auf Catalina bringen, später dann vielleicht auf BigSur, wobei dass dann eine Änderung des SMBIOS erfordern würde.

Als Zwischenschritt lief das System mit Clover 5107 und 10.15.7 recht gut, allerdings hatte ich beim Neustart mit den CMOS reset zu kämpfen, was mich dann dazu bewogen hat, zwischen den Jahren die Umstellung auf Open Core in Angriff zu nehmen.

Ich hatte allerdings etwas mit der Installation des BootSektors zu kämpfen, den ich benötige, um OC auf dem alten H61 Board mit non-UEFI Bios booten zu können. Am Ende habe ich die SSD mit meinen anderen Hackintosh (System 1) gesteckt, SIP disabled, macOS und OC installiert und dann die SSD in System 2 eingebaut. So weit, so gut, OC Boot Picker erscheint und Catalina booted auch recht flott auf System 2.

Nun zum Kern des Problems:

Leider friert das System wenige Minuten nach dem Start ein, Maus und Tastatur sind tot. Das passiert unabhängig davon, ob man sich anmeldet oder nicht. Es ist mir zwar gelungen, die Console nach der Anmeldung und vor dem Freeze zu öffnen, es erscheint aber keine hilfreiche Fehlermeldung. Mehr konnte ich in der verfügbaren Zeit bis zum Freeze nicht testen.

Bei der Suche nach möglichen Ursachen sind mir folgende Zeilen im verbose log auf dem Bildschirm nach Anwahl des Laufwerkes im OC boot picker aufgefallen.

Ich habe die SSDT-EC mit Hilfe von SSDTTime auf Basis der extrahierten DSDT (in Anhang) erstellt.

Die DSDT ist ziemlich chaotisch strukturiert, aber soweit ich das verstehe, gibt es kein existierenden device vom Type PNP0C09 und der Pfad für das Fake-EC sollte nach der Anleitung von Dortania auch passen.

Aufgrund der ACPI Fehlermeldung vermute ich, dass das Einfrieren durch den fehlenden Fake-EC Eintrag verursacht wird.

Da ich da nicht weiterkam, hatte ich auch schon die Ergänzung von USBInjectAll und CpuTscSync ohne Erfolg probiert. Da meine Symptome aber nicht zu 100% auf die Beschreibung im Dortania Troubleshooting Guide passen, muss wohl unter "Akt der Verzweiflung abgehakt werden.

Hat irgendjemand 'ne Idee, wie ich dem Problem auf die Schliche komme ? ich stehen im Moment echt auf dem Schlauch.

Leider kennen ich kein simples S/PDIF — USB Interface 🙁, aber jedes Class-Compliant USB Audio-Interface sollte ohne Treiber funktionieren.

Habe bei mir noch 'nen alten G4 Mac Gigabyte Ethernet rumstehen mit 'ner Radeon 9800Pro und 128MB.

Soweit ich mich erinnern kann, braucht man nicht nur ein MacRom sondern muss ggf. auch noch ein paar Widerstände modifizieren. Ich habe die Anleitung von damals noch auf der Festplatte gefunden (als PDF hier angehängt). Ich hatte auch noch ein ROM-image, aber ich weiß nicht, ob das das korrekte ist. Ich glaube, ich hatte damals günstig eine MacEdition der Karte aufgetan und bin ums Flaschen rumgekommen.

Aber vielleicht hilf das ja als Startpunkt für die weitere Recherche.

Habe gerade mal einen Blick auf das GitHub Repository geworfen. Es sieht so aus, als ob Chris lediglich einen GUI Wrapper um das Original Skript aus dem Opencore Package gelegt hat, um die zu untersuchende Config-Datei per drag&drop dem Script mitzuteilen. Das geht übrigens mit Automator ganz einfach.

Ansonsten gilt in der Hackintosh Welt meiner Ansicht nach immer „auf eigene Gefahr“, also im Zweifel nicht alles gleich am „Produktiv-System“ ausprobieren und immer ein Backup des Systems (inkl. EFI) zur Hand haben.

Es ist schlicht unverhältnismäßig oder sogar unmöglich, alle möglichen Konfigurationen und Nebenwirkungen zu berücksichtigen.

Die Beiträge, die Chris1111 hier gepostet hat, zeugen aber von fundiertem Wissen.

Im Moment brauche ich mein System für wichtige Arbeiten, da muss das experimentieren zurückstehen. Allerdings bleibt von der Liste auch nur der EDID Patch übrig.

1. Habe schon seit geraumer Zeit 10.15.7 incl. der letzen Security Updates laufen. Hatte auch erst vor kurzem den Clean-Install ebenfalls mit 10.15.7 plus security updates gefahren. Das Problem präsentierte sich immer unverändert.
2. Hatte erst Anfang Januar auf OC 0.6.5 inkl. aller aktualisierten kext gewechselt und der Fehler hat alle bisherigen Updates über die letzten 3 Acidanthera releases inkl. der damit verbundenen kext updates überstanden.
3. Mein Monitor läuft schon im scaled mode und ich hatte auch schon andere Skalierungen und native resolution ausprobiert, ohne Effekt auf das DRM Problem.

Vermutlich ist es was ganz Simples und bin einfach "betriebsblind". Ich kann aber auch gut ohne DRM leben.