Beiträge von CrazyHeinke

Ich habe meine Config jetzt noch einmal zurück gebaut.

Sprich AppleIGC deaktiviert und AppleIntel210Ethernet.kext inklusive BootArg ("e1000=0") wieder hinzugefügt.

Interessanterweise blieb jetzt mein Netzwerkadapter aktiv inkls. meiner gezogenen IP (via DHCP). Auch nach einem CleanNVRAM..

Allerdings friert mein PC immernoch ein sobald ich die USB Verbindung zu meinem QNAP herstelle. (unter Ventura lief das ohne Probleme)

Alle anderen USB Themen funktionieren super - die USB Config habe ich auch schon unter Ventura knapp 1 Jahr ohne Probleme verwendet.

Nachdem ich die Kexts wieder rückgängig gemacht habe wurde nach dem letzten Absturz auch der Netzwerkadapter QNAP QA (virtueller Port für die USB Quick Access Variante) unter MacOs angelegt. Leider stürtzt das komplette System trotzdem immer ab sobald ich den NAS via USB verbinde.

Hat hierzu vielleicht noch jemand eine Idee?

Zitat von cobanramo

Diesen Kext gab es zuletzt unter Monterey, danach wurde umgebaut und entfernt,

die Intel i225V v3 vom Z590 wird seit dem nur noch von Dext Driver "com.apple.DriverKit-AppleEthernetE1000" bedient.

Das funktioniert auch wunderbar unter Ventura und Sonoma.

Wenn du unter Ventura oder Sonoma den "AppleIntel210Ethernet.kext" vom Monterey einsetzen willst musst du auch den bootarg mitbenutzen damit die Dext Driver "com.apple.DriverKit-AppleEthernetE1000" von dem es normal startet unterdrückt wird.

dk.e1000=0 --> Bootarg für BigSur

e1000=0 --> Bootarg für Monterey, Ventura und Sonoma

Das problem hier unter Sonoma ist das die Intel i225V v3 mit dem standardmässigen Dext Driver "com.apple.DriverKit-AppleEthernetE1000"  IOSkywalkFamily.kext mitbenützt.

Ohne OCLP Modern Wifi patch startet das ganze auch normal und tut seine sache.

Mit OCLP Modern Wifi patch wird die IOSkywalkFamily.kext ersetzt und gepatscht, daher passt irgendwas nicht mehr.

Bei mir wirkt sich das so aus das Wifi funktioniert aber LAN Chip keine DHCP adressen beziehen kann usw.

Ergo müssten die OCLP Dev`s das weiter stricken damit das ganze Netzwerkstack die den Skywalk Kext mitbenutzt auch mitpatchen.

Da sie vermutlich nur den Wifi Teil anpassen ist es für Desktop Benutzer halbgar. bei Laptops ohne Lan Port mag das gut klappen.

Ich vermute hier sogar das all die Lan Chips die den Skywalk Kext mitbenötigen probleme haben.

Anders sieht es mit dem alten Intel Treibern wie vom Monterey "AppleIntel210Ethernet.kext" aus.

Hier wird die IOSkywalkFamily.kext nicht mitbenötigt und daher wirkt sich das eben nicht auf die Intel i225V v3 aus.

Wie schon oben erwähnt muss man daher die Dext Driver mit Bootarg unterdrücken damit die AppleIntel210Ethernet.kext" geladen wird.

Die AppleIGC.kext ist ein umgebauter Linux Driver der bei mir vom Catalina bis Sonoma durchgehend den Intel Chip startet.
Starten heisst eben noch lange nicht das es sauber funktioniert, die Kext bringt leider mehr probleme als nutzen.
Sie verursacht konfikte mit AHCI, bricht bei mir den Sleep und kann keine Recovery`s mehr starten.
Ansonsten wäre das die beste lösung gewesen.

Gruss Coban

Alles anzeigen

Das ist absolut korrekt bis Ventura habe ich auch den Kext mit dem bootargs "e1000=0" verwendet.

Nach der Neu Installation von Sonoma wurde mein I225 auch korrekt erkannt nur nach dem WiFi Patch nicht mehr...

Bei mir macht sich das allerdings so bemerkbar, dass der komplette Netzwerkadapter nach dem Patch nicht mehr sichtbar ist.

Wenn nur keine DHCP Adresse gezogen wäre, könnte man diese ja auch einfach manuell setzen..

Hallo zusammen,

ich habe ebenfalls auf Sonoma 14.0 aktualisiert (Neue Installation).

Im Anschluss an die Installation habe ich den WiFi Patch für meine BCM94360NG angewendet.

csr-active-config aktualisiert (03080000),

das boot-args "amfi=0x80" ergänzt,

Secure Boot Model aktualisiert "Disabled",

Folgenden Kext blockiert "com.apple.iokit.IOSkywalkFamily"

und die 2 Kexte eingebunden "IOSkywalk.kext", "IO80211FamilyLegacy.kext" (inklusive Plugin)

Anschließend habe ich den OCLP 1.0.1 Release zum patchen verwendet und siehe da WiFi, AirDrop etc funktioniert wunderbar.

Hierbei ist mir aufgefallen, dass der oben genannte WiFi Patch in Kombination mit dem "AppleIntel210Ethernet.kext" nicht funktioniert.

(Der I225-V Port von meinem Board wird nicht mehr erkannt)

Ohne den o.g. WiFi Patch funktionierte die Erkennung meiner ETH Karte problemlos mit dem Apple Kext.

Also habe ich den Kext entfernt und durch den "AppleIGC.kext" ersetzt. Jetzt funktioniert sowohl WiFi als auch Ethernet.

Leider funktioniert mit dem "AppleIGC.kext" mein QNAP USB Quick Access nicht mehr - hierbei wird ein Virtueller Netzwerkadapter erzeugt.

Sobald ich die USB Verbindung herstelle laufe ich in einen Kernel Panic. Wenn ich die USB Verbindung beim booten bereits hergestellt habe laufe ich nach der Anmeldung in eine Kernel Panic.

Daher meine Frage an euch wie habt ihr den I225-V unter Sonoma am laufen?

Vielen Dank schon einmal vorab!

Hallo zusammen,

ich habe gestern ebenfalls auf Sonoma 14.0 installiert (Neue Installation).

Im Anschluss an die Installation habe ich csr-active-config aktualisiert (03080000),

das boot-args "amfi=0x80" ergänzt,

Secure Boot Model aktualisiert "Disabled",

Folgenden Kext blockiert "com.apple.iokit.IOSkywalkFamily"

und die 2 Kexte eingebunden "IOSkywalk.kext", "IO80211FamilyLegacy.kext" (inklusive Plugin)

Anschließend habe ich den OCLP 0.6.8 Release zum patchen verwendet und siehe da WiFi, AirDrop etc funktioniert wunderbar.

Hierbei ist mir aufgefallen, dass der oben genannte WiFi Patch in Kombination mit dem "AppleIntel210Ethernet.kext" nicht funktioniert.

Also habe ich den Kext entfernt und durch den "AppleIGC.kext" ersetzt. Jetzt funktioniert sowohl WiFi als auch Ethernet.

Nach dem ich mich ein bisschen in die AMFI Thematik eingelesen habe würde ich nun ebenfalls gerne das boot-args "amfi=0x80" wieder entfernen und dafür den Amfipass.kext und das boot-args "--amfipassbeta" hinzufügen.
Wo habt ihr alle den Amfipass.kext her, also wo finde ich den ich nenne es mal Herkunftsdownload?

Des Weiteren würde mich interessieren, ob ich nach dem Patchen SecureBoot in MacOS wieder einschalten kann?

Als abschließenden Test habe ich die WiFi Karte noch einmal in den Build eines Freundes eingesetzt um zu testen, ob diese einwandfrei funktioniert.

Da meine WiFi Karte dort ohne Probleme lief und ich im Bios absolut nichts dies bzgl. finden konnte, denke ich dass die Karte wirklich nicht direkt im originalen Slot des Aorus Boards funktioniert.

Das ist natürlich nennen wir es mal suboptimal

Ich habe gerade mal auf der Gigabyte Seite für mein Board geschaut und dort wird der m2 Port für die WiFi Karte einfach gar nicht mehr erwähnt

Gerade habe ich aber noch einen Artikel gefunden indem jemand beim Aorus Ultra die originale Karte erfolgreich gegen eine BCM94360NG getauscht hat.

Link

Zitat von atl

Der CNVi-Slot hat ebenso wie der normale M.2 A+E Key slot eine Anbindung an USB, aber keine an PCIe. Somit gehen nur CNVi-Karten und der USB-Teil von normalen M.2-WiFi-Karten.

Wie kann ich denn erkennen, ob ein Slot diese Anbindung hat, oder nicht.
Im Forum gibt es mehrere Benutzer, welche das Gigabyte Z590i Vision D im Einsatz haben und dort funktionierte der Austausch scheinbar ohne Probleme.

Also habe ich überlegt mein MB gegen das Z590i Vision D zu tauschen, allerdings kann ich wenn ich die beiden Boards vergleiche keinen Unterschied fest stellen:

Link

Bei beiden Boards sind die folgenden "Erweiterungsslots" gelistet, wobei der letzte Eintrag der für die integrierte WiFi Karte ist: (Quelle Geizhals)

1x PCIe 4.0 x16, 1x M.2/M-Key (PCIe 4.0 x4, 2280/2260),

1x M.2/M-Key (PCIe 3.0 x4/SATA, 2280/2260, Rückseite),

1x M.2/E-Key (Intel CNVi, 2230, belegt mit WiFi+BT-Modul)

Auf GitHub hat bspw. SchmockLord ebenfalls eine EFI gepostet mit dem Gigabyte Z590i Vision D in der er die originale WiFi Karte ersetzt hat.

Zitat von GitHub

Wifi/BT: Intel AX201, replaced by a Broadcom BCM94360NG for macOS Compatibilty. Works out of the box. The BCM94360NG fits into the original WiFi-card housing and sits under the IO-shield. Original antennas fit.

Ich habe gesehen es gibt so Adpater Karten für einen normalen M2 Steckplatz wo ich dann die Wifi Karte installieren kann - das sollte bei meinem Board aber funktionieren, oder ?

kann mir hier ggf. jemand ein Adapter empfehlen, gerne mit Link

SchmockLord das Gigabyte Z590i Vision D hat bei Geizhals dieselbe Beschreibung des Steckplates wie das Aorus Ultra.

Du hast die WiFi Karte doch ebenfalls hinter der IO Blende direkt mit der originalen getauscht, oder?

Ich kann mir nicht richtig erklären warum unter Windows BT erkannt wird und WiFi nicht - also wenn der Steckplatz nicht kompatibel ist dürfte doch auch gar nichts erkannt werden?

Ich habe gerade mal die genaue m2 Beschreibung meines alten Boards und des neuen raus gesucht:

Gigabyte Z590 Vision D

1x M.2/ E-Key (PCIe/ Intel CNVi, 2230, belegt mit WiFi+BT-Modul

Gigabyte Z590i Aorus Ultra

1x M.2/ E-Key (Intel CNVi, 2230, belegt mit WiFi+BT-Modul

Hier scheint es doch einen Unterschied der Steckplätze zu geben - kann es daran liegen?

CNVi Slot steht bei beiden, aber der eine ist ein PCIe Slot gewesen.

Ich hatte zuvor ein Gigabyte Z590 Vision D Board im Einsatz und dort die BCM94360NG Karte direkt in dem M2 Slot angeschlossen das funktionierte sowohl für Windows als auch für Mac.

Jetzt bei dem neuen Board habe ich alles gleich angeschlossen - der Slot sitz hier wohl unter den Antennen und nicht unter einem m2 festplattenslot.

Hallo zusammen,

ich habe heute meinen neuen Build zusammen gestellt und dort auch wieder meine BCM94360NG in einem Gigabyte Z590i Aorus Ultra verbaut.

Nach der Windows 11 Installation ist mir aufgefallen, dass WiFi nicht erkannt wird - Bluetooth wird allerdings erkannt und funktioniert ohne Probleme.

hat einer von euch eine Idee wieso BT funktioniert und WiFi nicht mal bei den Netzwerkadaptern erkannt wird? Die neusten Treiber habe ich runter geladen und installiert.

kann es an Windows 11 liegen?

kann es sein das eine der beiden Antennen nicht richtig sitzt, oder würde BT dann auch nicht funktionieren

Vielleicht hatte jemand einmal eine ähnliche Situation und kann hier von seinen Erfahrungen berichten

Zitat von barrrrt

Oder Sound Control von Static Software. Nutze ich aber schon seit paar Tagen nicht mehr solche Tools.

Was nutzt du denn jetzt zur Lautstärkeanpassung, oder nutzt du wieder den normalen Kopfhörerausgang?

Hallo zusammen,

ich habe ein Gigabyte Z590 Vision D Motherboard im Einsatz - bei diesem Board konnte ich Audio via USB einbinden.

Die Audio Ausgabe funktioniert auch einwandfrei, das einzige Theme vor dem ich aktuell stehe ist, dass ich beim anschließen meiner Soundbar (via optical audio cable) keine Lautstärkesteuerung innerhalb von Mac Os zur Verfügung habe.

Hat hier jemand einen Tipp bzw. kann mir sagen wie ich die Lautstärkesteuerung für den optischen Ausgang aktivieren kann?

Anbei ein paar Infos zu meinem System:

Gigabyte Z590 Vision D

OC 0.7.9

AppleALC 1.7.0

Mac Os Monterey 12.2.1

SchmockLord - du hast einen ähnlichen Setup - funktioniert bei Dir die Lautstärkesteuerung in Mac Os des optischen Ausgangs?

Vielen Dank schon einmal vorab!

Hallo zusammen,

ich habe mittels OC0.7.8 meinen ersten Hackintosh inzwischen am laufen.

Alle von mir benutzen Funktionen laufen wie gewünscht (Audio, USB, Sleep & Wake, Wlan+BT, Handoff, usw.)

Mir ist allerdings im Boot Log aufgefallen, dass mehrere Kernel Errors erstellt werden zum Thema System Policy.

kernel: (Sandbox) System Policy: dirhelper(27) deny(1)

kernel: (Sandbox) 1 duplicate report for System Policy: dirhelper(27) deny(1)

Kann mir einer von euch hierzu vielleicht mehr sagen ?

Wie gesagt das System läuft wie gewünscht - ich kann keinerlei Einschränkungen mehr feststellen außer das der Bootvorgang recht lange dauert - ist das System aber einmal hoch gefahren läuft es sehr stabil und flüssig.

Zu den Specks:

- Gigabyte Z590 Vision D

- i9 11900k

- AMD Radeon RX 6900 XT

Eventuell kann mir hier einer von euch mehr zu sagen ?

Vielen Dank schon einmal vorab!

Die folgenden Geräte stehen auf Internal:

ITE

Bluetooth

Realtak Audio

Interner USB 2.0 Hub

An meinem Mainboard laufen 4 der Ports von der Rückseite ebenfalls über einen Hub.

Diesen Hub habe ich allerdings noch auf USB2 bzw USB3 stehen. RenStad - meinst du ich soll diese beiden Einträge auch auf Internal umstellen?

Ich habe jetzt einen ähnlichen Test durchgeführt und alle USB Geräte abgeklemmt, die angeschlossen sind.

Zum Test habe ich ein Magic Keyboard und eine Magic Mouse verwendet.

Leider blieb auch dieser Test ohne Erfolg und der PC erwacht direkt wieder aus dem Ruhezustand.

Einzige USB Geräte die noch angezeigt wurden, waren die internen USB Hubs, die BT Card und das ITE Device.

Hallo zusammen,

ich bin aktuell mit dem Thema Ruhezustand in meinem Open Core Build beschäftigt.

Nachdem ich Ruhezustand auswähle, versucht der Pc in den Ruhezustand zu gehen (ich denke das schafft er auch) erwacht dann aber direkt wieder aus dem Ruhezustand.

Infos zum System:

Intel i9 11900k

Gigabyte Z590 Vision D

Fenvi BCM94360NG

OpenCore 0.7.6

SMBIOS iMac Pro 1,1

Mac OS Monterey 12.0.1

Eigenes USB Port Mapping via USBMap.command

Ich habe folgende Settings in meiner config.plist angepasst:

Misc -> Boot -> HibernateMode -> None

NVRAM -> Add -> 7C436110-AB2A-4BBB-A880-FE41995C9F82 -> boot-args -> keepsyms=1

Anschließend habe ich die Settings Energie sparen in der Systemsteuerung wie folgt angepass:

"Wenn möglich Ruhezustand für Festplatte aktivieren" - Aktiviert

Alles andere deaktiviert

des Weiteren habe ich die 5 pmset Befehle (aus dem Dortania Guide) in Mac OS eingegeben:

sudo pmset autopoweroff 0

sudo pmset powernap 0

sudo pmset standby 0

sudo pmset proximitywake 0

sudo pmset tcpkeepalive 0

pmset -g assertions - wirft folgenden Output:

Im Log (log show | grep "Wake reason") finde ich immer wieder folgende Einträge:

2021-12-06 13:08:27.096280+0100 0x74 Default 0x0 0 0 kernel: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: XDCI CNVW USBW (User)

2021-12-06 13:08:27.096281+0100 0x74 Default 0x0 0 0 kernel: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: XDCI CNVW USBW (User)

Wenn ich die Einträge im Log richtig verstehe hängt dies mit der USBW.aml zusammen - diese habe ich von SchmockLordaktuellstem Build übernommen. (Selber CPU und fast identisches MB)

Ohne die USBW.aml und die USBWakeFixup.kext können meine USB Maus uns Tastatur nach einem Wake nicht verwendet werden.

Nun zu meiner Frage wie kann ich es erreichen, dass mein PC im Ruhezustand bleibt.

Anhand des Log kann ich jetzt nicht erkennen das es an einem bestimmten USB Device liegt, welcher den PC direkt wieder erwachen lässt.

Über Eure Anmerkungen bzw. Tipps wär ich sehr dankbar

Wie gesagt bin ich mir nicht sicher, ob es an der USBW Datei liegt - aber dann werde ich die Frage unter oben genannten Link noch einmal posten.

@5T33Z0 ich bin noch relativ neu im Hackintosh-Forum-forum - wie kann ich diesen Beitrag dann entfernen?

Hallo zusammen,

ich bin aktuell mit dem Thema Ruhezustand in meinem Open Core Build beschäftigt.

Nachdem ich Ruhezustand auswähle, versucht der Pc in den Ruhezustand zu gehen (ich denke das schafft er auch) erwacht dann aber direkt wieder aus dem Ruhezustand.

Infos zum System:

Intel i9 11900k

Gigabyte Z590 Vision D

Fenvi BCM94360NG

OpenCore 0.7.6

SMBIOS iMac Pro 1,1

Mac OS Monterey 12.0.1

Eigenes USB Port Mapping via USBMap.command

Ich habe folgende Settings in meiner config.plist angepasst:

Misc -> Boot -> HibernateMode -> None

NVRAM -> Add -> 7C436110-AB2A-4BBB-A880-FE41995C9F82 -> boot-args -> keepsyms=1

Anschließend habe ich die Settings Energie sparen in der Systemsteuerung wie folgt angepass:

"Wenn möglich Ruhezustand für Festplatte aktivieren" - Aktiviert

Alles andere deaktiviert

des Weiteren habe ich die 5 pmset Befehle (aus dem Dortania Guide) in Mac OS eingegeben:

sudo pmset autopoweroff 0

sudo pmset powernap 0

sudo pmset standby 0

sudo pmset proximitywake 0

sudo pmset tcpkeepalive 0

pmset -g assertions - wirft folgenden Output:

Im Log (log show | grep "Wake reason") finde ich immer wieder folgende Einträge:

2021-12-06 13:08:27.096280+0100 0x74 Default 0x0 0 0 kernel: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: XDCI CNVW USBW (User)

2021-12-06 13:08:27.096281+0100 0x74 Default 0x0 0 0 kernel: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: XDCI CNVW USBW (User)

Wenn ich die Einträge im Log richtig verstehe hängt dies mit der USBW.aml zusammen - diese habe ich von SchmockLord aktuellstem Build übernommen. (Selber CPU und fast identisches MB)

Ohne die USBW.aml und die USBWakeFixup.kext können meine USB Maus uns Tastatur nach einem Wake nicht verwendet werden.

Nun zu meiner Frage wie kann ich es erreichen, dass mein PC im Ruhezustand bleibt.

Anhand des Log kann ich jetzt nicht erkennen das es an einem bestimmten USB Device liegt, welcher den PC direkt wieder erwachen lässt.

Über Eure Anmerkungen bzw. Tipps wär ich sehr dankbar