Beiträge von bobpedro

Ein anderes Thema was mich nun seit geraumer Zeit beschäftigt ist das Problem von ungewolltem wake-up aus dem Ruhezustand.

Zuerst hatte ich eine funktionierende Lösung mit einem ASUS PCE-AC55BT PCI-E adapter auf dem ich eine Broadcom BCM4352 Combo Karte montiert hatte, leider wurde der PC immer nach 5 Sekunden wieder aus dem Standby geweckt. Ohne die Karte passierte das nicht, weshalb ich andere Gründe ausschliessen kann. Da dasselbe Phänomen auch unter Windows auftrat, sogar mit der original Intel-Karte, musste es am Adapter liegen.

Nun habe ich die Nachfolge-Version des Adapters Asus PCE-AC55BT B1 im Einsatz und unter Windows funktioniert jetzt der Standby. Für Kompatibilität mit OS X habe ich die Intel-Wifi Karte mit einer BroadCom BCM4352 BCM94352Z Karte ausgetauscht. Damit funktioniert Standby unter Windows, in OS X allerdings nur wenn das mitgelieferte USB-Kabel (für Bluetooth notwendig) nicht mit dem Mainboard verbunden ist. Als Wake-Cause sieht man das USB-Device in den Power-Logs.

Zu genau diesem Thema gibt es auch einen Thread (Link), wo als Lösung beschrieben wird, dass die Broadcom-Karte als internes device mit einem USB-Connector-Wert von 255 (steht für intern) registriert werden muss, damit es den PC nicht mehr aus dem Standby aufweckt. Dafür wird eine korrekte Anwendung des USB-Port-Limit-Patches für OS X Mojave vorausgesetzt um dann den Entsprechenden Anschluss korrekt zu überschreiben.

Ich habe nun schon mehrere Anläufe hinter mir, aber es will nicht so recht klappen, die internen USB-Anschlüsse des P8P67 Pro tauchen nicht in der in allen Tutorials beschriebenen Form auf, bzw. verstehe ich nicht ganz was jetzt die beste Methode ist, um diesem USB-Anschluss den Wert 255 zuzuordnen. Hier bräuchte ich mal etwas Hilfe. Gibt es vielleicht einen einfachen Clover-Patch oder muss ich tatsächlich den Port-Limit-Patch machen und eine custom SSDT generieren?

Hier mal ein Screenshot wie das Gerät erkannt wird aus dem IORegistry-Tab des USB Prober Tools:

Hey al6042 natürlich hab ich die neuste Version des Kexts im Einsatz: 1215 auch wenn die von 2015 ist...

EDIT: ich habe ein issue in RehabMans Repository erstellt und bekam die Antwort, dass dieser kext von niemand gewartet wird: Link. Schade, denn er tut eigentlich was er soll!

Hey Sabo bist Du hier zu einer Lösung gekommen? Ich habe das selbe Problem und es liegt eindeutig am GenericUSBXHCI.kext. Ohne den Kext funktioniert der Shutdown, leider ist das die einzige Möglichkeit für mich mit meinem Mainboard USB3 zu aktivieren. Ich hatte das Problem vorher schonmal und konnte es durch Deaktivieren des "FixShutdown" ACPI Patches lösen. Jetzt allerdings habe ich das Problem wieder, weiß jemand Rat?

Das ist mir jetzt etwas peinlich, aber ich habe gerade gemerkt, dass die Stromversorgung vom USB-Hub nicht eingesteckt war. Jetzt scheint es mit dem GenericUSBXHCI.kext vollständig zu funktionieren. Dennoch Danke für die Tips!

Zitat von kuckkuck

Bei deinen USB handelt es sich anscheinend um einen AsMedia und keinen Intel USB Controller. Deshalb funktionieren sämtliche Methoden wie USBInjectAll, FakePCIID_XHCIMux oder PortLimitPatches nicht. Deine einzige Chance ist die GenericUSBXhci Kext, aber wenn die nicht hilft, kann ich dir leider nicht weiter helfen – sorry...

Also laut Spezifikation des Herstellers für das Asus P8P67 Pro REV3.0 ist es ein NEC® USB 3.0 controller.

Hallo zusammen, erstmal vielen Dank für die Anleitung und die vielen Beiträge, ich habe viele davon gelesen und muss mich leider dennoch mit einem Problem melden. Ich benutze den GenericUSBXHCI.kext von RehabMan, damit habe ich immerhin die USB3 Ports zum laufen bekommen, allerdings funktionieren diese nur mit USB3-Geräten, wenn vorher am selben Port ein USB2-Gerät eingesteckt war. An einem USB3-Hub funktionieren nur USB2-Geräte. In beiden Fällen sehe ich aber im IOReg oder USBProber, dass angeschlossene USB3-Devices erkannt werden (mit korrekter Bezeichnung), nur werden sie eben nicht gemountet.

Jetzt dachte ich vielleicht liegt es am Port-Limit, ich benutze den aktuellen Port-Limit-Patch für Mojave:

Die Filtermethode funktioniert leider nicht, da ich in IOReg nur 2 Einträge mit XHC1@0 sehe, also habe ich versucht eine Umbenennung mit Clover zu erreichen. Leider ohne Erfolg weder renaming von XHC1 noch XHCI zu XHC funktioniert. Ich habe auch noch renaming für EHC1 und EHC2 hinzugefügt ohne Effekt. Ich bin mir nicht sicher ob Clover die Patches überhaupt anwendet. Habe ich etwas wichtiges übersehen?

Anfangs hatte ich noch die Kexts USBInjectAll.kext und FakePCIID_XHCIMux.kext im Einsatz, mittlerweile nicht mehr.

Hier meine Kext-Liste (benutze außer Clover-Patches keine modifizierte DSDT oder SSDT):

Hat jemand eine Idee?

@djdevil1989 wie sieht es aus mit USB 3.0, hast Du das mittlerweile zum laufen bekommen?

Edit1: Auf dem Mainboard scheint ein NEC/RENESAS USB3 Controller (uPD720200 oder uPD720200a) verbaut zu sein. Ich habe viel herum probiert mit originalen Treibern von Dritt-Anbietern aus diesem Post, leider führte keiner davon zum gewünschten Erfolg.

Das beste Ergebnis konnte ich mit RehabMans Fork des GenericUSBXHCI USB 3.0 Driver erreichen. Damit werden auch die USB3 Ports erkannt, allerdings funktionieren nur USB2-Geräte problemlos. USB3-Geräte werden zwar erkannt (sieht man z.B. im IOReg oder mit dem USBProber) aber nicht gemountet. Erst wenn vorher ein USB2-Gerät am selben Port eingesteckt war, funktioniert danach auch das USB3-Gerät. Mit einem USB3-Hub funktionieren USB2-Geräte, USB3-Geräte werden erkannt aber nicht gemountet.

Meine Vermutung ist, dass es am Port-Limit liegen könnte, dafür habe ich den auch einen entsprechenden Patch in Clover. Die vielversprechende Lösung aus dieser Anleitung funktioniert bei mir leider nicht, da bei mir kein Eintrag mit XHC@14 im IOReg zu finden ist. Bei mir steht nur XHC1@0, ein rename-patch in Clover bringt leider keine Abhilfe (oder funktioniert nicht).

Edit2: Nach Einstecken der Stromversorgung für den USB3-Hub (wie dämlich) scheint alles zu funktionieren. Ich benutze den GenericUSBXHCI.kext, ohne USBInjectAll.kext oder FakePCIID_XHCIMux.kext, keine Port-Renamings und der Port-Limit-Patch scheint wohl auch überflüssig zu sein (Link) das werde ich aber noch testen.

Edit3: Es scheint als würde der GenericUSBXHCI.kext das Ausschalten verhindern. Mit dem Kext startet er einfach neu. Ohne Kext schaltet er ab. Hat jemand eine Idee?

Edit4: Da nach laut RehabMan der GenericUSBXHCI.kext nicht weiter maintained wird (Link), habe ich das Problem jetzt auch mithilfe einer FL1100 basierten PCI-E Karte gelöst und internes USB3 deaktiviert.

Hallo, ich bin wegen der nVidia Webdriver Situation auf eine Asus radeon RX 570 Strix Gaming umgestiegen für Hardwarebeschleunigung unter OS X Mojave. Ich habe extra diese Karte gewählt, da sie 2 DVI Anschlüsse besitzt und laut Apple Spezifikation sollte sie ja OOB laufen.

Ich musste allerdings die neuste Version von LiLu (1.2.8) und WEG (1.2.4) einsetzen damit ich sie zum laufen bekomme. Allerdings nur über DP und HDMI, die Monitore an den 2 DVI-Anschlüssen werden zwar korrekt erkannt, allerdings bleiben sie schwarz. Ich habe es versucht mit WEG bootflags -raddvi and -wegbeta sowie ein extrahiertes vBios rom mit clover zu injecten, leider ohne Erfolg.

Dann bin ich auf diesen Eintrag hier gestoßen und habe in meinem Bios nach legacy/efi settings gesucht. Es gibt dort nur eine Einstellung: Auswahl zwischen "EFI compatible rom" und "Legacy rom". Wenn ich das auf EFI umstelle, leuchtet beim booten die VGA-LED und das System bleibt hängen. Booten in diesem Zustand funktioniert mit der alten Geforce GPU, also scheint es Inkompatibilität mit der neuen GPU zu geben.

Daraufhin habe ich das Mainboard Bios von 3207 auf 3602 aktualisiert, aber ohne Verbesserung.

Die nächste Idee war das vBios der GPU zu aktualisieren. Installiert war Version 67DFHB.15.50.2.1.AS13 (welche auf techpowerup als unverified vermerkt ist), also habe ich die einzige dort als verified verfügbare version 67DFHB.15.50.2.1.AS10 drauf geflasht, ohne Verbesserung.

Der Versuch einen Framebuffer patch für clover zu erstellen scheitert daran, dass AMDFramebufferUtility die neue GPU nicht erkennt.

Jetzt bin ich langsam mit meinem Latein am Ende, würde aber in Zukunft die Monitore gerne wieder mit DVI betreiben und nicht über die Adapter-Lösung wie im Moment. Hat noch jemand eine Idee?

So neuer Anlauf: Mojave steht an und auch hier gibt es wieder ein paar Hürden. Hat jemand bereits Mojave erfolgreich auf einem P8P67 Pro installiert?

Da ich ja wie weiter oben beschrieben Probleme mit dem Start von Clover bekomme, sobald apfs.efi oder ApfsDriverLoader.efi im driver folder liegen, bin ich gezwungen weiter bei HFS+ zu bleiben.

Da Mojave hier noch strikter vorgeht als High Sierra, musste ich eine Neu-Installation mittels 14MBRinstallerMaker vornehmen.

Des Weiteren scheint Mojave meine Grafikkarte nicht mehr (richtig) zu unterstützen, zum erfolgreichen booten musste ich den bootflag -no_compat_check hinzufügen.

Jetzt fehlen mir noch nVidia Webdriver für multi-monitor-support, aber bislang gibt es noch keinen Treiber für Mojave: Link.

Ich habe mit nVidia Update zwar einen kompatiblen Treiber installieren können, aber beim Initialisieren der Grafik erfolgt leider ein Reboot.

Freue mich über Tips und Austausch, eventuell muss ich doch noch auf eine AMD Karte umsteigen...

Sorry ich war die letzten Tage etwas beschäftigt. Also Wake-on ist alles deaktiviert im BIOS. Das ist es also nicht.

EDIT: ich habe das Problem gelöst, durch Deaktivieren der Option "FixShutdown" unter "Acpi"->"DSDT"->"Fixes". Gefunden habe ich die Lösung hier: Link

Der Eintrag "FixShutdown" ist schon vorhanden, irgendwelche anderen Ideen, woran es liegen könnte?

Nachdem ich das Problem nicht lösen konnte, nutze ich meinen Hackintosh jetzt mit HFS+. Leider fährt er nach dem Ausschalten nach ein paar Sekunden wieder hoch. Das Problem kenne ich von Windows, da lies es sich allerdings durch Ausschalten von "fast-boot" beheben. Gibt es dafür irgendeinen Trick unter OS X?

Ich habe es gerade mit der neusten Version probiert: High Sierra 10.13.5 (17F77) - selbes Phänomen. Ich habe auch die neuste gepachte Version von hier probiert: https://www.insanelymac.com/fo…hout-verbose-boot/?page=5, leider ohne Erfolg. Bleibt mir also nichts anderes übrig als HFS+ zu verwenden?

Gibt es einen Grund weshalb Du kein APFS willst? Ich versuche High Sierra mit APFS zu installieren, aber sobald ich apfs.efi in EFI/CLOVER/drivers64UEFI kopiere, freezed der PC bevor Clover starten kann und zeigt nur " - " am unteren Bildschirmrand. Gibt es dafür eine Lösung?