Beiträge von Mieze

apfel-baum Ja stimmt, Danke! In meinem alten System hatte ich einen i9-11900KF und habe beim Aktualisieren des Profils vergessen i9 gegen i7 auszutauschen.

apfel-baum Welcher Weg für dich der beste ist, hängt im Wesentlichen davon ab, wieviel Leistung Du brauchst/willst und wie hoch Deine Risikobereitschaft ist? Vor diesem Hintergrund bieten sich 3 Alternativen an:

1. Den i7-14700K behalten (maximale Leistung und Risiko): In diesem Fall solltest Du unbedingt das BIOS-Update durchführen und die CPU nur innerhalb der Spezifikationen betreiben (nicht Übertakten), um die Garantieansprüche nicht zu gefährden.
2. Tausch gegen einen i9-12900KF (hohe Leistung bei geringem Risiko): Die schnellste Intel-CPU, die nicht von dem Bug betroffen ist und inzwischen für ca. 285€ zu haben ist.
3. Tausch gegen einen i7-12700KF (bestes Preis/Leistungsverhältnis bei geringem Risiko): Der 12700KF ist zwar deutlich langsamer, bietet für ca. 190€ aber ein unschlagbares Preis/Leistungsverhältnis. In 2 Jahren werden wir außerdem wissen, ob das Problem endgültig gelöst wurde und dann dürfte ein i9-14900KF bzw. i7-14700KF für 200-250€ zu haben sein, so dass Du ggfs. günstig upgraden könntest. Mit dem gesparten Geld wäre das Upgrade dann fast finanziert.

PS: An meiner Signatur kannst Du ja sehen, dass ich mich bei meinem neuen System für Alternative 3 entschieden habe.

Aussetzer beim Audio deuten stark auf ein Problem mit dem Power Management hin. Handelt es sich bei dem betroffenen System um das aus deiner Signatur? Benutzt Du CPUFriend? Falls ja, dann schau mal, oben es hilft CPUFriend zu deaktivieren? Evtl. müssen auch nur die Frequenzvektoren im DataProvider angepasst werden?

Da das Angebot an neuen Mainboards mit Sockel 1200 inzwischen sehr überschaubar geworden ist und zum Teil Mondpreise Baufür aufgerufen werden, bleibt eigentlich nur noch die Wahl zwischen einem gebrauchten Mainboard und einer kompletten Neuanschaffung mit Sockel 1700, was dann aber bedeuten würde, dass Du eine neue CPU brauchen würdest.

Für einen Hackintosh mit Z490-Chipsatz sind Mainboards von Gigabyte erste Wahl und funktionieren mit MacOS bestens. Ich habe in einem meiner Systeme das Z490 Gaming X verbaut und bin seit 4 Jahren absolut zufrieden damit. In meinem Zweitsystem steckt ein MSI MPG Z490 Gaming Plus (BIOS 7C75vAC ist ok, 7C75vAD bootet nicht mit MacOS!), mit dem ich ebenfalls vollauf zufrieden bin. Beide haben mindestens 2 M.2-Slots. Falls Du eines dieser Boards günstig bekommen kannst, so kann ich sie nur wärmstens empfehlen.

bluebyte Wenn Du mir mit deinem Kommentar helfen wolltest, dann ist das nicht gut rübergekommen, denn es klang überhaupt nicht so. Egal, Schwamm drüber und noch ein schönes Restwochenende!

PS: Es klang nach meinem Empfinden eher so als wolltest Du damit ausdrücken, dass ich zu blöd wäre die Lüfterhalterung richtig zu installieren und noch nicht mal korrekt messen könnte. Daher meine heftige Reaktion.

Zitat von bluebyte

Die Anschlussbleche an den Karten sind immer länger als die Abdeckbleche.
Bei meinem bequiet Pure Base 500 und meinem bequiet Dark Base 900 sind die Abdeckbleche sogar 10mm kürzer.
Ich habe mal ein paar Anschlussbleche gemessen. Diese sind im Durchschnitt 121mm lang.

Nö! Gemäß der Norm beträgt die Länge des Brackets bis zur Unterkante der oberen Fixierung 120mm. Da die obere Fixierung im 90° Winkel gebogen ist ergibt sich bei einer Materialstärke von 0,8 mm eine Gesamtlänge von 120,8 mm. Die Slotabdeckungen von Fractal Design entsprechen ziemlich genau dieser Norm und man kann sie daher in jedem Gehäuse einsetzen. Ich weiß, dass manche Gehäusehersteller dünneres Material verwenden oder mit dem Design spielen. Dadurch haben die Slotabdeckungen manchmal andere Maße, aber das ist bei Fractal Design nicht der Fall. Kann man aber auch dem Foto entnehmen.

Zitat von bluebyte

Das mit dem Kästchen ist zwar gut gemeint, aber durch die Verzerrung des Blickwinkels wirklich suboptimal. Bei dieser Methode muss man unbedingt das Teil lotrecht fokussieren. Falls Du keinen Messschieber zur Hand hast, dann reicht auch ein Gliedermassstab oder Massband.

Schön, dass Du messen kannst und einen Messschieber hast. Jetzt solltest Du dich nur noch mal über die optischen Eigenschaften von Weitwinkelobjektiven, wie sie in Handykameras verwendet werden, informieren. Dann würde Dir schnell klar werden, dass eine verzerrungsfreie Abbildung damit unmöglich ist. Man kann dass aber auch auf dem Bild erkennen, wenn man mal schaut was an den Rändern mit den Karos passiert.

Zitat von bluebyte

Soweit dein Anschlussblech die 121 mm nicht weit überschreitet ist alles in Ordnung. Würde mal in deinem Gehäuse nachschauen, ob da etwas verbogen ist oder ein Kabel den Einbau behindert.

Unterhalb des Mainboards befindet sich der Mainboardträger. Vielviel Abstand zwischen diesem und dem Board bleiben, hängt von den Distanzhülsen ab. Hier gibt es gewisse Unterschiede, aber bei einem Bracket mit einer Länge von 120,8 mm treten da keine Probleme auf. Ich weiß auch nicht welche Kabel dort verlaufen sollten oder wie dort etwas verbogen sein sollte, vorausgesetzt man benutzt keinen Hammer zur PC-Montage? Die beanstandete Lüfterhalterung hat hingegen eine Länge von 124,8 mm und dass es dann Probleme mit dem Gehäuse geben kann, dürfte nicht verwunderlich sein, oder?

...weil die Lüfterhalterung die ich bestellt hatte um meine Intel X540 aktiv zu kühlen nicht in ein Fractal Design Define C passt, da die Slotblende der Halterung 4 mm zu lang ist. Dadurch kann man sie nicht mehr im Gehäuse festschrauben, weil sie gegen den Boden drückt. Auf dem Foto habe ich die originale Slotblende des Gehäuses auf die Halterung gelegt, um das Problem zu verdeutlichen.

Ich frage mich, was die sich dabei gedacht haben, denn die Maße der Slotblenden sind genormt?

Zitat von Bob-Schmu

Das kann man nur herausfinden, in dem man sich den CPU anschaut, wie weit er oxidiert ist.

Weiter oben habe ich es ja schon geschrieben, jeder Overclocker freut sich jetzt, weil Intel es nicht mehr auseinanderhalten kann.

Da alle Chips die komplexer als ein Logikgatter sind über auf dem Chip integrierte Funktionen zum Test und zur Diagnose verfügen, welche im normalen Betrieb nicht genutzt werden, könnte Intel sehr wohl herausfinden, ob ein Schaden durch den bekannten Bug oder aber durch Übertaktung entstanden ist. Möglicherweise hat Intel auf dem Die auch Funktionen integriert, die einen Betrieb jenseits der Spezifikation dauerhaft protokollieren (eFuse). Hierzu wirst Du auch im Datenblatt praktische keine Informationen finden, da sowas üblicherweise geheim gehalten wird.

Grundsätzlich wäre es für Intel kein Problem, ein Testprogramm zu veröffentlich, mit dem jeder Nutzer prüfen kann, ob der Microcode-Fix im UEFI bereits integriert ist und ob die CPU bereits geschädigt wurde, aber man kann sich wohl denken, warum sie das nicht machen.

Es wäre unglaublich naiv Intel gegenwärtig zu vertrauen und dafür gibt es sehr gute Gründe:

1. Es ist kaum vorstellbar, dass Intel nicht frühzeitig von dem Problem wußte. Trotzdem hat Intel versucht es auszusitzen.
2. Die Salami-Taktik immer nur das zuzugeben, was man nicht mehr verleugnen kann, zeigt, dass kein Willen zur Ehrlichkeit vorhanden ist.
3. Es gibt keinen reproduzierbaren Test, ob die CPU davon betroffen ist, falls Probleme auftreten, oder ob evtl. andere Ursachen für die Instabilität verantwortlich sein könnten.
4. Damals bei den Ausfällen der Serie 6 Chipsätze hat Intel einen Rückruf gestartet, was beim gegenwärtigen Problem auch mehr als angemessen wäre. Davon will Intel aber immer noch nichts wissen. Zumindest ein Verkaufsstop wäre überfällig, solange bis das Problem behoben ist.
5. Was das Garantieversprechen wirklich wert ist, kann man momentan nicht abschätzen. Es ist genauso gut möglich, dass Intel im Fall der Fälle den Austausch verweigert, weil z. B. die CPU übertaktet wurde, oder die Power Limits falsch gesetzt waren. Solche "Optimierungen" haben ja fast alle Mainboard-Hersteller in ihrem UEFI implementiert.

Ingesamt kann man aus diesen Gründen nur dringend davon abraten noch eine Core i-CPU der 13./14. Generation zu kaufen, weil man effektiv die Katze im Sack kauft und Gefahr läuft, auf einer Zeitbombe sitzen zu bleiben. Ich habe mich daher für einen 12700KF entschieden, insbesondere auch weil der zur Zeit ein unschlagbares Preis-/Leistungsverhältnis hat.

Im Prinzip hat Lorys89 lediglich die maximal unterstützte Kervel-version von Sonoma auf Sequoia angehoben (daher kein Bootarg mehr nötig), d.h. die Patches sind die gleichen geblieben. Das scheint zumindest bei Broadcom-Adaptern zu funktionieren.

BlueToolFixup - Lorys89

Es geht aber auch prinzipiell mit Bordmitteln. Du kannst auf der externe Festplatten ein neues MacOS installieren und dann mit dem Migrationsassitenten deine Daten auf die neue Platte übertragen.

Arkturus  MacGrummel Wenn das Bootarg '-bltfxbeta' zu einer KP führt, dann ist das der Beleg dafür, dass die Binary-Patches der BlueToolFixup.kext nicht mehr funktionieren und angepasst werden müssen, um Bluetooth wieder funktionstüchtig zu machen. Die Sache wird wohl aufwendiger als gedacht.

Hab mir gerade noch mal den Sourcecode von BlueToolFixup angesehen und kann bestätigen, dass die tatsächlich noch nicht für Sequoia angepasst ist und daher das Bootarg "-btlfxbeta" benötigt, damit die unter Sequoia funktioniert.

Die BCM94360NG hat die unangenehme Eigenschaft, dass sie nach dem Aufwachen aus dem Ruhezustand gelegentlich in den HID proxy Modus zurückfällt, so dass man die Maus zwar noch nutzen kann (Bewegen und Klicken), aber die Swipe-Gesten dann nicht mehr funktionieren. Dass habe ich als ziemlich nervig empfunden.

cobanramo Sorry, ich muss mich korrigieren. Ich habe BrcmPatchRAM3 im Herbst 2019, also für 10.14 und nicht für 10.15 geschrieben. Hatte gestern Abend schon zwei Gläser Rotwein getrunken und war daher nicht mehr so ganz fit.

Wenn die Karte unter Ventura ohne BrcmPatchRAM3 lief, dann braucht sie kein Firmwareupdate, sondern besitzt eine integrierte Firmware. Damit wäre BrcmPatchRAM3 überflüssig und wurde als Verursacher des Problem ausscheiden. In diesem Fall bliebe nur noch BluetoolFixup als mögliche Ursache übrig und müsste ggfs. für Sequioa überarbeitet werden.

cobanramo Ich habe mir deine Screenshots noch mal angesehen und dabei ist mir etwas seltsames aufgefallen: Wieso steht dort als Transport UART und nicht USB, so wie es sein sollte?

Das könnte erklären, warum es nicht funktioniert?

Bezüglich Anpassung von BrcmPatchRAM3 an Sequoia: BrcmPatchRAM3 lädt die Firmware in das Modul und veranlasst einen Reset, um die neue Firmware zu aktivieren. Ich habe die Kext damals geschrieben, weil Änderungen am BT-Stack von Catalina dazu geführt hatten, dass BrcmPatchRAM2 das Modul nicht mehr wie gewohnt registrieren konnte, da Apple das IO-System überarbeitet hatte. Anpassungen sollten eigentlich nur notwendig sein, falls Apple wieder mal alles umgekrempelt haben sollte? Das müsste dann ggfs. weiter untersucht werden...

Cudox Die stehen hier beschrieben:

BrcmPatchRAM

Die DW1560 unterstützt Handshake, so dass bpr_preresetdelay nicht benötigt wird. Welche Werte für dein System passen, musst Du durch probieren herausfinden, falls die Defaults nicht zum Erfolg führen.

Bootargs brauchst Du nur für BrcmPatchRAM3.kext, also wenn die Karte mit Firmware versorgt werden muss.

Welche Konfigurationswerte (Boot-Args) hast Du für BrcmPatchRAM3.kext angegeben?

Ab Catalina wird BrcmPatchRAM3.kext benötigt und für die Firmware zusätzlich BrcmFirmwareData.kext (Reihenfolge beachten, zuerst die Firmware). BrcmBluetoothInjector.kext ist seit MacOS 12 obsolete, dafür ist BlueToolFixup.kext seit 12.0 zwingend erforderlich, selbst bei Karten die keine Firmware benötigen und vorher OOB liefen.