Beiträge von JoeHidden

    @kuckkuck Ja, Auto geht auch. Macht zumindest äußerlich erst mal keinen Unterschied.


    Kurz zum aktuellen Stand. Ich habe gestern noch etwas geforscht.

    • Ich habe noch einmal validiert das die Adresse XHCI Controller im FakePCIID_XHCIMux 0x8d31/0x8086 korrekt vorhanden ist. Das trifft zu.
    • Von den zwei EHCI Controllern werden auch zwei erkannt, allerdings nur einer mit Anschlüssen. Da muss ich aber nochmal genau die Zuordnung vom Board studieren.
    • Nur mit der FakePCIID_XHCIMux & FakePCIID boote ist entweder USB2 oder USB3 vorhanden / je nach XHCI Bios Setting.


    Für den produktiven Betrieb habe ich deshalb zusätzlich nochmal die USBInjektAll (nur temporär Kuckuck - nicht schlagen) aktiviert. In Kombination der beiden Kexte habe ich einen USB2 Hub und einen USB3 Hub im System und mittels Hardware Hubs bekomme ich alle Geräte auf den korrekten Controllern ans rennen.


    Positiv ist, das in der Konstellation das USB Audio Interface nun perfekt via EHCI funktioniert- der Weg ist also der richtige... ;)
    Negativ ist, das die USB3 Ports nicht abwärtskompatibel sind, was für den Moment erstmal ok ist.


    Ich versuche nachher mal die einzelnen Adressen der Controller und das Hardwarelayout nachzusehen. Dann sehen wir weiter... ;)


    Gruß
    Joe

    Ok, hab ich angepasst.


    Wenn ich nur mit der FakePCIID_XHCIMux & FakePCIID boote ist USB2 ok. USB3 fehlt.


    Zu den BIOS Einstellungen. Die zwei Handover Values sind so wie verlinkt. Der XHCI steht aber auf Smart Auto, da bei Enabled das BIOS vom Board die EHCI Controller deaktiviert - was ja das Ziel untergaben würde... ;)


    Dementsprechende führt der Wechsel auf XHCI Enable im Bios zum umgekehrten Bild. USB3 ok - USB2 fehlt.


    Gruß Joe

    Ich freue mich wirklich das Du Dir die Zeit nimmst und versuchst zu helfen @rubenszy. Das meine ich absolut ernst!


    Aer ich muss die Frage stellen: hast Du mein Text gelesen? Auch wenn Du meinst, das USB2 immer geht, habe ich genau hier das Problem.
    Sowohl Deinen ersten Tipp uia_exclude, als auch den zweiten Hinweis DSDT-Patch XHC hatte ich doch bereits in meinem ersten Satz geschrieben.



    Zunächst zum IST Stand:
    Ich habe via DSDT die Anpassung von XHCI->XHC, EHC1->EH01 sowie ECH2-EH02 durchgeführt. Die neuste Version der USBInjectAll.kext kommt zum Einsatz und alle Devices werden von AppleUSBXHCIPCI bearbeitet. Die uia_exclude sind entsprechend gesetzt, es sind unter 15 Ports und es ist kein Patch der USB Treiber aktiv. Sowohl USB2 als auch USB3 Geräte werden korrekt erkannt und die Geschwindigkeit von USB3 ist korrekt. Im Prinzip entspricht alles der aktuellen Anleitung von @kuckkuck.


    Mittlerweile bin ich soweit, das ich mit dem FakePCIID_XHCIMux.kext zumindest 2 Ports als reine USB2 Ports am laufen habe und parallel zwei Ports als reine USB3 Ports. Das ist schon mal ein Schritt in die richtige Richtung aber das Handover von XHCI zu EHCI (also USB2 Device im USB3 Port) geht leider nicht. Mal sehen...

    Hey @rubenszy


    Vielleicht bin ich gerade ganz auf dem falschen Pfad, aber der Kext beschränkt sich doch auf den AppleUSBXHCI Driver und genau den möchte ich für die USB2 Ports eben nicht verwenden. Oder stehe ich gerade auf dem Schlauch?



    Gruß Joe

    Hallo in die Runde,


    ich habe ein spezielles Problem.


    Zunächst zum IST Stand:
    Ich habe via DSDT die Anpassung von XHCI->XHC, EHC1->EH01 sowie ECH2-EH02 durchgeführt. Die neuste Version der USBInjectAll.kext kommt zum Einsatz und alle Devices werden von AppleUSBXHCIPCI bearbeitet. Die uia_exclude sind entsprechend gesetzt, es sind unter 15 Ports und es ist kein Patch der USB Treiber aktiv. Sowohl USB2 als auch USB3 Geräte werden korrekt erkannt und die Geschwindigkeit von USB3 ist korrekt. Im Prinzip entspricht alles der aktuellen Anleitung von @kuckkuck.


    Jetzt zum Problem:
    Ich verwende ein externes USB Audio Device (ein UMC204HD von Behringer). Audio an sich ist ok, es kommt aber immer wieder zu Audioprobleme (Tonartefakte, Stottern, etc.). Das Problem ist dem Hersteller bekannt und liegt am Zusammenspiel mit dem XHCI Treibern bei Apple. Am MacBook via EHCI läuft das Interface ohne Probleme und die Gegenprobe - ein Focusrite Scarlett 2i2 von einem Freund zeigt das gleiche Verhalten am Hacki.


    Aus meiner Sicht müssten korrekterweise die USB2 Ports, bzw. USB2 Devices and USB3 Ports zum AppleUSBEHCI geroutet werden. Der Kext FakePCIID_XHCIMux.kext von RehabMan sollte nach der Beschreibung auf GitHub diese Funktion übernehmen. Er schreibt dazu folgendes:


    "... The effect is to route any USB2 devices attached to the USB2 pins on the XHC ports to EHC1. In other words, handle USB2 devices with the USB2 drivers instead of the USB3 drivers (AppleUSBEHCI vs. AppleUSBXHCI)."


    Aber es hakt im Zusammenspiel und die allgemeine Dokumentationslage ist doch recht dünn. Mit dem Kext sind bis auf einen plötzlich alle Ports weg (erstes Bild) aber der Treiber stimmt -> ohne den Kext sind alle Ports da, aber mit dem bekannten Standart, das alle Ports via AppleUSBXHCIPCI verwaltet werden (zweites Bild).


    Kennt sich jemand genauer damit aus und kann mit etwas Hilfestellung leisten?


    Gruß Joe


    @onlyWork


    War eigentlich ziemlich trivial. Die meiste Zeit habe ich gebraucht bis die SSD vom Bios erkannt wurde -> im Endeffekt musste ich das Bios resetten, erst danach wurde die SSD erkannt.


    Nachdem ich die Patche von Pikeralpha (Link) in die Clover Config gepackt habe war die SSD in OS X verfügbar. Dann habe ich von der alten Platte den Sierra Installer aufgerufen (wollte ja eh ne saubere Neuinstallation) und ab geht die Lucy :)


    Gruß Joe

    @onlyWork Ja, ich hab länger unerlaubt gefehlt. Zu viele andere Baustellen. Naja, perfekt würde ich meinen Hacky nicht nennen. Mit der Installation bin ich ja seinerzeit dem Pfad von @Brumbaer und @apfelnico gefolgt. Ich hatte primär das Ziel, das System erstmal perfekt stabil zu bekommen. Das ist erfüllt. Speedstepping nur rudimentär über die C-States, ich hab zwischenzeitlich aber auch noch keine Erfolgsmeldung von anderen dazu gelesen.


    Ich schleppe aber auch noch einige "Altlasten" mit mir rum, da ich das X99 System aus Zeitgründen damals auf Basis der installierten Platte des alten Hackys aufsetzen musste. Hardwaredefekt und es musste schnell weitergehen ;).


    Ich hab zum Beispiel das Problem, das bei jedem zwanzigsten (ungefähr) Boot die Spracheinstellungen auf englisch stehen, also die Setting aus dem "NVRAM" nicht korrekt gelesen werden. Nicht schlimm, aber jedesmal wenn es passiert nervt es doch.


    Der aktuelle Plan ist, in den nächsten Tagen Sierra mal komplett von Grund auf neu aufzusetzen. Dazu hab ich mir jetzt auch eine NVMe SSD bestellt (Samsung SM961, also die OEM Variante der 960 Pro). Dann kann ich mal ganz in Ruhe an den offenen Punkten arbeiten und muss dabei das Produktivsystem nicht anpacken.


    Wahrscheinlich kommt die SSD Morgen an, dann werde ich am Wochenende mal basteln und berichten.


    Gruß Joe

    Hey Ihrs,


    ja sehe ich genau wie Datec. Der originale 6,1 ist Kinderfashing gegen ein feines X99 System.


    @onlyWork
    Ich würde die eventuell nochmal über den 6900k nachdenken. Der Zehnkerner ist definitiv unverschämt im PL Verhältnis, aber der Okto ist ok und skaliert gut mit Resolve. Gerade beim transcodieren und bei der Arbeit mit RAW (bei mir Ursa 4.6k) merkst Du die 2 zusätzlichen Kerne.


    Gruß Joe

    Da ist der Key doch noch... ;)


    Code
    1. efi-boot-device-data %02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%02%1f%03%12%0a%00%00%00%00%00%00%00%04%01*%00%02%00%00%00(@%06%00%00%00%00%00@%e9%c6%e8%00%00%00%00{z%1f%a0Y%e1!I%a0%85%cef2%9a%08+%02%02%7f%ff%04%00


    Der sollte weg sein.

    Jo, ich bring eben den Junior ins Bett.


    Nachtrag1:
    @CrusadeGT
    Here we go...
    https://dl.dropboxusercontent.…608261/Posts/config.plist


    Nachtrag2:
    Ich vermute mal, hier versteckt sich das Problem.


    Nachtrag3:
    Ja, das war es. NVRAM eft-boot-device-data war das Problem. Jetzt ist der Clover auch wieder da.