Beiträge von MacPeet

Es können auch Antennenprobleme sein, je nachdem wie die geführt sind, bzw. Abstand zum Router.

Vielleicht liegt's ja auch an dem 2er Kext, obwohl für BigSur eigentlich der 3er gebraucht wird.

Allerdings, wenn Du die NG bald da hast, die läuft dann nativ, ohne Kext's.

achte darauf, dass die Karte sich mit dem 5 GHz WLAN verbindet

Mit 2,4 GHz kann es Störungen beim BT geben.

Sprich, im Router getrennte SSID‘s für beide Netze.

Prima, der Rest sind dann sicher Feineinstellung.

Wundern tut mich nur die Geschichte betreffs PatchRam2. Ich meinte immer, dass ab Catalina der 3er gebraucht wird.

Aber gut, ist dann wohl so.

liegt hier nur rum, schicke ich Dir gern

Adresse via PN

alles gut, ja die war von mir und da ist ja pci-aspm-default bereits drin

stammt bei mir aus der Konfiguration vom Lenovo T450s

Ich habe meine 1820A hier übrigens noch rumliegen mit KF4 in der Seriennummer, falls von Interesse.

richtig, der pci-aspm-default = 0 war auch bei mir zwingend, da der entsprechende Pin hardwareseitig nicht angesprochen wird. Unter Win wird es softwareseitig geregelt.

Bei der BCM94360NG im gleichen Rechner ist dies allerdings nicht mehr nötig.

Der PCI-Pfad in meiner SSDT müsste natürlich auch auf seinen Rechner angepasst werden.

Hast Du den fehlenden Kext denn eingebunden?

Kann ich Dir auch nicht sagen. Im Hackintool in der PCI-List sollte das Device aber schon auftauchen, auch mit dem richtigen Pfad.

Als ich die 1820A in Verwendung hatte (war noch unter Catalina) hatte ich es bei mir in einer SSDT gemacht.

Die 1820A Karten waren damals nicht ganz so einfach. Nicht jede Karte lief in jedem Rechner. Da gab es Unterschiede der Seriennummern am Ende (KF4, 3T3, usw.), es sei denn, sie sitzt auf einem PCIe-Adapter.

Ich selbst hatte dann aber auch auf die BCM94360NG NGFF M.2 gewechselt, welche keinerlei Kext braucht und nativ läuft bis inkl. Monterey.

Kann ich Dir nur empfehlen.

Für den Anfang fehlt auf jeden Fall ein Kext für BigSur:

BrcmBluetoothInjector.kext, BrcmFirmwareData.kext, BrcmPatchRAM3.kext

Den AirportBrcmFixup.kext braucht man ggf. nur wenn man die Länderkennung ändern will/muss.

Nach dem bereits vor 2 Tagen mein Macmini M1 und auch der Lenovo T450s (noch OC 0.6.9) ohne Probleme die DP6 gefressen hatten, dachte ich heute nun, der real MacPro3,1 mit OCLP 0.7.1 fehlt ja noch.

Und siehe da, dort die gleichen Probleme, wie hier nun mehrfach beschrieben wurde, das Update wird nicht angezeigt.

DMGLoading hatte ich auf Any, also einfach mal Signed eingetragen.

SecureBootModel hatte ich auf Disabled und hier nun ganz frech wie ich bin mal diese j137 eingetragen, was ja für einen iMacPro1,1 sein soll, so wie Ihr schreibt.

Neustart und was soll ich sagen, Update wird angezeigt, auch ohne extra Stick, wie es hier schon beschrieben wurde.

Auch der Wert j137 ist scheinbar nicht relevant bezüglich des tatsächlichen SMBIOS, da er hier ja auch geht.

Naja, gesagt getan, Update angestossen und während der Download lief wieder auf die alten Werte DMGLoading Any und SecureBootModel auf Disabled zurück gestellt.

Nach Neustart lief der Install ziemlich schnell und es begrüßte mich die neue Beta Monterey.

Fazit:

Ich denke jeder mit dem Problem kann diese j137 eintragen, egal was für ein SMBIOS eingestellt ist.

100% bugfrei ist hier gar nix, denke ich

Die Prioritäten bei Apple liegen längst auf Monterey. Bug-Reports werden eh munter ignoriert, bzw. zumindest nicht beantwortet, bzw. intern nimmt man sich dann vielleicht der Sache doch an, wenn die Meldungen sich häufen, betrifft aber nicht nur BigSur.

Eine neue Hauptversion wird es nicht mehr geben für BigSur. Natürlich werden evtl. noch Supplemental Update's und Sicherheitsupdates nachgereicht, also wie immer bei den älteren macOS-Versionen, sowie DP-Beta's für Safari etc..

Gestern kam DP6 unter Monterey und Apple hat tatsächlich was bei der Monitorerkennung getan, was auf BigSur natürlich bislang noch nicht eingebunden ist. Schade.

Was in dem Fall ja kein "Zitat: Benutzerfehler oder seltenes" war, sondern bereits mit erster Beta BigSur bestand und nun erst unter Monterey geht der Weg mal in eine positive Richtung, wobei Apple schon oft mit weiterer Beta wieder alles verbogen hat.

Ich hoffe mal nicht.

Andere User haben sicher auch andere Beispiele mit Problemen., z.B. im Grafikbereich war es doch lange eine Katastrophe.

Somit kann man hier auch nicht von 100% bugfrei sprechen, auch wenn ich mit BigSur generell sehr zufrieden bin und es ja hier aktuell noch das Hauptsystem ist.

Ich persönlich finde, dass Monterey ein Jahr zu früh kam (mit all den Vorstellungen, die sie bislang nicht liefern konnten, in keiner Beta). Besser wäre es gewesen, BigSur mal richtig fertig zu machen und dann mit den Erkenntnissen die neue Version beginnen.

Ferner auch mal den Entwicklern etwas Zeit geben, sich auf die neue Version einzustellen. Haben wir ja alle erlebt, dass plötzlich unter BigSur die eine oder andere Software nicht mehr lief.

Kaum haben sie es gelöst, kam auch schon Monterey mit noch mehr Sicherheitsregeln.

Apple's M1 Geräte haben bislang unter BigSur und Monterey mehr Bug's, als jeder Hackintosh, was auch ich bestätigen kann.

Somit könnte man fast das Gefühl haben, es sei 100% bugfrei. Leider ist es nicht so.

Dies ist nur meine allgemeine Meinung, kein Fachwissen! Muss sich also keiner angegriffen fühlen!

Ghostbuster

Ich habe den Macmini3,1 2009, gleiche CPU, gleiche Grafik, etc., wie bei Deinem Macbook Pro. Natürlich darf hier auch irgendwann auch mal Ende sein.

Ich hatte auch schon über Verkauf des alten Gerätes nachgedacht, allerdings zeigte sich, lohnt nicht, also weiter verwenden.

Auch ich boote inzwischen mit OCLP 0.7.1 (was ja auch Direktupdates ermöglicht in allen Systemen) und ich habe damit auch BigSur und Monterey versucht, allerdings macht dies nicht mehr viel Sinn. Der OCLP-Postinstall-Grafikpatch taugt nicht wirklich was, unter BigSur und Monterey.

Somit bin ich auch wieder zu Catalina zurück, womit die Kiste super läuft, auch ohne Lüfterprobleme oder CPU-Hitze. Catalina war für mich wichtig, da es als erstes OS auch AppleTV kann, somit habe ich den Mini zusammen mit einem Cinema 23" im Schlafzimmer in einen Schrank eingebaut, ausfahrbar natürlich. Somit erfüllt der Mini noch seinen Zweck für AppleTV, Filme und selbst eMail, Browser ist natürlich auch möglich.

Ich beziehe mich nun mal auf Deinen Post#13, insbesondere die Bilder von Catalina.

Warum ist dort die Menüleiste und das Dock nicht transparent? Hast Du dies explizit in Systemeinstellungen ausgeschaltet?

Ich frage nur, weil unter Catalina der Grafikpatch ja noch super geht.

Vermutlich dann doch die gefakte Biosversion, welche suboptimal ist.

Was ist da denn gefakt worden? Gibt's Alternativen?

Für die Thinkpad's gab es ja immer verschiedene Modbios's, je nach Anwendungszweck und Bedarf.

In der Regel war es ja nur WLAN, abgesehen vom alten T61/p, welcher noch was für Grafik brauchte, oder?

griven

Ich denke auch, dass da dann irgendwas an der Konfiguration nicht mehr so passt.

Die Aussagen 1/3 Ladebalken bezieht sich auf nach Verbose oder komplett ohne Verbose?

Ferner, hast Du schon mal die OC-Debug-Versionen genommen und die Debug-Funktionen in der config.plist aktiviert?

Ich denke damit (debug.log) könnte mhaeuser sicher mehr anfangen.

So, nochmal:

rot: direkt angesprochen

mit grün: weitere Infos für alle

In keiner Weise habe ich Lantra16 dort geschrieben, also was soll dies jetzt hier.

Letztendlich ist es mir aber jetzt auch egal.

Fakt ist, dass die 2010er bereits ab Late 2009 gebaut wurden, ferner wurden über den ganzen Bauzeitraum auch unterschiedliche Platten verbaut, was auch bei Apple damals üblich war, technische Änderungen über den gesamten Bauzeitraum ohnehin keine Neuheit.

Aber jetzt noch einmal, ich habe Dich weder direkt angesprochen, noch gemeckert.

Ende jetzt, bin raus.

Lantra16

Ich wüsste nicht, wo ich gemeckert haben sollte, warum auch, es geht doch nicht um meine Probleme und ich habe nur über technische Details geschrieben, die mir soweit bekannt sind, auch durch den Umgang mit vielen alten realMac's.

Ferner habe ich nicht geschrieben, dass DU "Macs Administriert" hast, ferner hast Du hier wohl nicht richtig gelesen.

Wenn es den 4,1 nicht betrifft, ist dies ja für Dich nur gut, auch wenn der Fehler bleibt. Warum, findest Du dann ja allein.

Ok, in dem Fall bin ich raus, wenn's ohnehin nicht gewollt ist.

naja, prima, die Mac Fan Control 1.5.9 free kam ja als Beta raus, welche dann auch endlich mit BigSur/Monterey geht.

Deine GPU zeigt hier die Temp, aber keinen Lüfter, wenn die WX4100 überhaupt einen hat.

Aber immerhin feine Sache.

Mein MacPro zeigt damit zwar auch die 4 Lüfter an, auch einstellbar, aber bei der GPU NVIDIA Quadro K600 keine Temp. Lüfter hat die eh nicht, da passiv.

Zum Thema zurück, die alten Macmini's haben diese Sensoren für GPU ohnehin nicht, diese zeigen auch nur den einen Lüfter, welcher dann mittels Mac Fan Control auch änderbar ist.

Naja, in einer Firma wechselt auch niemand Festplatten, um einen uralt-Rechner am Laufen zu halten, ganz im Gegenteil.

Heutzutage, zumindest ist es bei uns so, werden die Dinger nur noch geleast, höchstens 2-3 Jahre, dann weg und neu.

Um aber beim Thema zu bleiben, bei den 2010er Modellen ist es mit den Festplattensensoren genau so wie von mir beschrieben.

LetsGo

Du beschreibst aber auch einen Hackintosh und keinen alten realMac, oder?

msart und für alle anderen hier

Einige Aussagen von Dir sind leider nicht richtig, bzw. gehen in eine falsche Richtung.

Wenn Du, wie Du schreibst "Macs Administriert" hast, dann solltest Du dies eigentlich besser wissen.

Selbst wenn ich auf dem alten Macmini3,1 BigSur oder Monterey installiere, die Lüfter gehen niemals auf volle Pulle, auch beim Boot nicht.

Natürlich ist die CPU erst einmal auf 100%, nach Install, aber nicht die Lüfter, bis das ganze Spotlight/iCloud-Gedöns durch ist.

CPU-Temperaturen von weit über 60 Grad sind hierbei normal bei den realMac's mit C2D. Davon geht kein realMac mit C2D kaputt.

Nur so nebenbei: Mac Fan Control in der Free-Version zeigt keine GPU-Temp's, sowie auch andere Tool's nicht. Es gibt einige Tool's, welche dies können, dann aber nur in Pro-Versionen und vorausgesetzt, dass die GPU über die entsprechende Sensoren verfügt.

Die hier beschriebene Sache hat ja ganz andere Ursachen.

Bis Late2009 war es kein Problem eine HDD im realMac gegen eine SSD zu tauschen, da der Sensor einfach an einem Kabel hing und mittels Klebestreifen aufgeklebt war.

Die sogenannten 2010er-Modelle (die letzten mit C2D), ab Late2009 produziert, hatten nicht mehr den aufgeklebten Sensor, sondern der Sensor steckte in der HDD selbst.

Dies hat dann zur Folge, dass kurz nach Einschalten die Lüfter beim Booten voll laufen und auch im System, sofern man dafür keine Abhilfe schafft.

Dafür gibt es die hier bereits angesprochenen Tools, welche man in den Autostart legen kann und dann ist ab dem System Ruhe bei den Lüftern.

Volle Pulle Lüfter beim Booten bleiben dann aber, da die Tools erst im System selbst geladen werden können.

Dies ist quasi nicht so schlimm, wenn man die Lautstärke aushält beim Booten, zumindest geht davon kein realMac 2010 kaputt.

Auch für dieses Problem, während dem Booten, gab es im Internet Lösungen, diverse Kabel-Brücken oder auch beschriebene Löt-Brücken.

Ob sich das noch lohnt ist fraglich.

Ich würde dann die Lüfter eher beim Booten ertragen und dann auf die Tool's im System bauen.

Ok, soviel mal zur technischen Ursache betreffs der hier gefragten Lüfterprobleme.

griven

Ist richtig, was Du über das SIP geschrieben hast. Es ist auch auf den alten realMac's so, welche Grafik-Patch brauchen.

Hierbei unterscheidet OCLP bei der Erstellung bereits bei dem ausgewählten SMBIOS.

Mache ich dies auf dem MacPro3,1 setzt OCLP das SIP auf 00000000, weil hier native Grafik vorausgesetzt wird.

Mache ich dies auf dem Macmini3,1 setzt OCLP das SIP auf deaktiviert, was auch so bleiben muss, da die Grafik-Patches ja nicht im OC-Kextordner liegen, sondern auf S/L/E zugreifen.

Auch bei den betreffenden Hackintosh muss dann SIP deaktiviert bleiben.

Bei Deinen Versuchen betreffs OC Versionen größer 0.6.5 äußern sich die Misserfolge wie folgt?

Wo bleibt OC denn damit genau hängen?

Ich hab den Dump mal gewandelt. Es ist alc1150 und auch layoutID 99 in der AppleALC ist von den grundlegenden Knoten für Speaker/LineOut, HP, Mic's gleich und sollte somit halbwegs gehen.

Wenn aber so gar kein Gerät damit angezeigt wird, dann ist da noch was anderes nicht richtig. Vielleicht wirklich mal den empfohlenen Bootflag alcid=99 verwenden/testen!

Evtl. stimmt im ACPI-Bereich (DSDT/SSDT) noch was nicht, weil es evtl. kein HDEF-Device dort gibt. Ob HDAS to HDEF als Patch noch nötig ist, kann ich von hier aus natürlich nicht sagen, wobei teurere AppleALC's wohl sogar schon HDAS erkennen.

Aber Stop, in deiner config vom OC wird sowohl Lilu/AppleALC geladen, als auch VoodooHDA steht auf Yes.

Ich denke so gehts sicher nicht.