Beiträge von JoeHidden

Ja kann ich auch bestätigen. Alles fein mit FCPX und 980ti.

Wird bestimmt ein Riesenspaß... Schön das jetzt alles klappt.

Zitat von Paktosan

Ich probier mal, ob die Kext was verbessern

Schau mal im IORegistryExplorer ob unter dem XHC Knoten der FakePCIID_XHCIMux gebunden ist. Wenn nicht ist der Kext nicht geladen worden.

Zitat von kuckkuck

Wenn wir auf 0 wären, würde ich jetzt vorschlagen win 10 zu simulieren. Bei dir gibt es aber anscheinend ein generelles Problem mit EH01 und da ist mein Wissen wirklich zuende. Auch ich habe durch unsere Tests so einiges gelernt!

Die "höchstmögliche" seitens Asus in der DSDT enthalten Windows Version ist 2013. Die hatten wir bereits getestet. 2015 würde doch dann eh wie 2013 behandelt, oder? Ich frag mich Dia ganz Zeit warum der EH01 in der IOReg vorhanden ist aber der Treiber nicht geladen wird. Wenn er nicht da wäre ok, aber so - seltsam. Auf jeden Fall nochmals Danke bis hierhin @Kuckuck.

Zitat von Download-Fritz

"Fix Ownership" is quasi ein Clover-seitiges "EHCI/XHCI Handoff". Hatte nicht den Nerv, mir den ganzen Thread durchzulesen, werd' ich aber vielleicht heute Abend machen... mit ACPI kann ich wenig helfen, aber vielleicht fällt mir irgendwas auf. Mal RehabMan angeschrieben?

Ok, Danke auch Dir schonmal vorab. Mit Rehabman schreibe ich bei IM seit Freitag Abend. Die Kommunikation zieht sich aber wegen der Zeitverschiebung ein wenig... Letzter Stand war seine Vermutung, das irgendwas im Kernellog stehen müsste. Aber da finden ich nur den oben Zitieren Eintrag zu EH02 (der funktioniert). Zu EH01 schweigt sich der Kernel aus.

Unter Windows 10 ist alles wie es sein soll. Bisher fischen wir im trüben... Er meinte der Clover Parameter "Devices/USB/FixOwnership=true" wäre entscheidend. Ich hatte den Wert auf false, da im Clover Wiki dazu steht "This fix is not relevant for UEFI booting.". Er meinte dazu, die Angabe im Clover Wiki stimmt nicht. Einen Unterschied macht es leider trotzdem nicht. Die Logs helfen aber auch nur bedingt weiter. Interessant finde ich die folgenden Zeile aus dem Kernellog.

Die taucht bezüglich EH01 nicht auf. Ich habe aber auch google etc. schon mit allen sinnvollen Suchkombis durch. Es gab durchaus andere Fälle, denen auf dem X99 der EH01 fehlte - aber die waren dann immer damit fertig wenn sie USB3 am rennen hatten und dann spielt das Problem ja auch keine Rolle mehr... Naja, ich habe mit meinem Hacky soviel von der Community profitiert, da kann ich jetzt auch mal was erforschen. Und ich habe durch die systematische Testerei soviel mehr gelernt, als mit "mach mal den USBInjectALL Kext rein, dann gehts". Ist schon ein nettes Hobby.

Ein "KOMPLETE KONTROL S61" - Ich liebe das Ding jetzt schon...

Bringt der in dem Kontext denn noch etwas. Ich habe den schon seit einer weile raus, weil ich ja die passenden Port ausgewählt habe und exkludiere was nicht gebraucht ist auf dem XHCI?

Ich bin aber an anderer Front weiter. Rehabman meint, das Problem liegt an fehlenden Injects bei EHCI. Ich denke ich muss herausfinden, warum die EH01/EH02 Ports nicht korrekt vorhanden sind.

Genau kann ich auch nicht sagen, was da genau war. Aber die Rebootschleife hatte ich auch mit der 980ti vor ein paar Monaten. Ich hab mir damals nen Wolf gegoogled und keinen mit dem gleichen Problem gefunden. War aber genau wie bei ihm. Im laufenden Betrieb reinstecken ging, mit beiden Schirmen booten = RebootLoop. Das muss aber mit 12.0 gewesen sein - heute kann ich es auch nicht mehr nachstellen...

Test mal unterschiedliche Ports (1-2, 2-3,3-1 etc.). Ich hatte teilweise das Problem, dass es bei Initialisierung der Grafikkarte crashte. Umstecken hat dann geholfen und zurückstecken brachte reproduzierbar den Fehler.

Ok, dann gehe ich nachher mal XSEL an. Danke für die Erklärung!

Die DSDT umfasst derzeit, die XHCI/EHC1/EHC2 Änderung, die Anpassung der GFX für die PCIID meiner 980ti (MacPro6,1). Dazu die Basics aus dem Wiki, allerdings ohne HDMI und Audio Einträge. Ich nutze den internen ALC Audio Chip nicht. OS Check Fix und USB Power auch nicht.

Gruß Joe

@Kuckuck - Auch mit XSEL keine Änderung.

Moinsen...

Entscheidend ist, wie @kuckkuck schon geschrieben hat der Treiber. Deine USB Audio Devices, Mischer etc. laufen am besten über den älteren aber stabilen EHCI Treiber (AppleUSBEHCIPCI).
Ich hatte das gleiche Problem mit Audioglitches am Behringer U-Phoria und immer wieder mal Aussetzer am X-Touch. Durch FakePCIID und FakePCIIDXHCIMux.kext sorgst Du dafür das die USB2 Geräte vom EHCI Controller / Treiber bearbeitet werden. Bei mit kämpfen wir gerade noch etwas mit der Abwärtzkompatibilität von USB2 Geräten an USB3 Port - aber das wird. Und die USB2 Ports laufen mit allen Devices perfekt und ohne Glitches.

Gruß Joe

MacPro 6,1

Ich hab gestern Abend früh Schluss gemacht und teste heute Abend weiter.

@Kuckuck Codeword "Der ESEL ist offline" Leider auch keine signifikanten Änderungen erkennbar.

In der Info.plist der FakePCIID_XHCIMux finden sich die RM,pr- Einträge.

Wirklich viel habe ich dazu nicht gefunden aber Rehabman schreibt dazu folgendes:

Zitat

Configuration properties and their defaults: RM,pr2-force <00 00 00 00>. By default forces all XHCI ports to route USB2 devices to EHC1. RM,pr2-init <01>. Will write RM,pr2-force value at startup if non-zero. RM,pr2-block <01>. Will block writes to XUSB2PR if non-zero. RM,pr2m-block <01>. No evidence that OS X drivers attempt to write XUSB2PRM (offset 0xD4), but since this kext relies on a valid value here (as provided by the BIOS), writes to it are blocked if non-zero. RM,pr2-honor-pr2m <01>: Changes to XUSB2PR will be masked by XUSB2PRM if this is non-zero. RM,pr2-chipset-mask: Writes to XUSB2PR are masked by this value. This is defined by the chipset documentation. Default value depends on chipset. Refer to Intel 7/8/9-series chipset data sheet for more info.

So wie ich das verstehe wäre es doch damit möglich per RM,pr2-force nur die reinen USB 2.0 Ports an den EHCI zu leiten, oder? Das würde ja schon ausreichen. Ein USB 2.0 Device am USB 3.0 (Dongles etc.) dürfte gern auch XHC bearbeitet werden. Bisher erschließt sich mir die Maskierung aber überhaupt nicht - bzw. die Nummerierung auf deren Basis dann maskiert wird. Wirst Du da schlau draus?

--- Themensprung / Warnung ---

Auf die Gefahr Dir jetzt vollkommen auf die Nerven zu gehen... aber ich möchte das wirklich verstehen. Ich habe mir die DSDT nochmal sehr genau angesehen. Speziell das Thema korrekte _UPC Objekte. Beim XHC stimmen die Angaben von DSDT und IOReg überein, also Portbezeichnungen / Anzahl / Adressen. Bei EH01 und EH02 nicht.Bei EH01 (Adresse 8d26) fehlt der HUB und es fehlen alle Ports, selbst mit USBInjektAll ohne Filter. Bei EH02 werden die sechs Ports korrekt übernommen, aber die Nummern der Ports werden um zehn inkrementiert? Es taucht dem entsprechend auch nur ein USB2.0 Bus im USB Gerätebaum auf. Ich finde das nach wie vor sehr seltsam.

Zitat von kuckkuck

Das will ich sehen... Glaube ich nicht, aber vielleicht hast du recht...

Läuft... Jetzt wollte ich Dir gerade den Quote reinsetzen weil ich den Tab noch offen hatte, da seh ich das es die Antwort auf einen Post von der Seite davor war und der hatte natürlich doch die USBInjektAll. Mea Culpa

Aber ich bin auch bei Rehabman auf die Aussage gestolpert: "By default forces all XHCI ports to route USB2 devices to EHC1."

Ich probier noch mal eben was und dann Teste ich weiter...

Zitat von kuckkuck

Hmm... FakePCIID_XHCIMux killt nicht die Abwärtskompatibilität, er routet nur Ports zu einem EHC Controller.

Ok, dann ist die Frage ob er das in irgendwie mit den ACPI Namen korrespondiert. Vielleicht ist da EH01 hardcoded drin, oder sowas? Mich wundert nur das bei mir alles am EH02 hängt und der EH01 leer ist.

Zitat von kuckkuck

Das Boot Argument tut absulut garnichts ohne USBInjectAll.kext. Das wird nichts

Nein, das ist nicht korrekt. Ohne das Argument werden die HSxx Ports an den XHC gebunden - mit nicht. Ich nehme an das der FakePCIID_XHCIMux den Parameter auch auswertet. Der Hinweis zum Einsatz kam von Rehabman in einem anderen Thread den ich dazu gelesen hatte.

Zitat von kuckkuck

Kurze Frage, wie verhalten sich deine USB Ports bezüglich des Mikros wenn kein einziger Patch bezüglich USB realisiert ist?

Mikro beziehst Du auf das USB Audio Device? Wenn ja, ist die Antwort - läuft korrekt ohne jeden Kext als USB2 Device. Ohne Kexte fehlt dann aber der USB3 Support.

Zitat von kuckkuck

Radikalitäts-Steigerung + 1

Ich werde testen und berichten...

Verdammt Ja, hab ich auch. Gefühlt läuft nur Smart Auto wirklich gut. Bei Auto treten USB3 Disconnects auf.

Am besten scheint im Moment die folgenden Variante zu sein.
DSDT: Nur EHC1/EH01, EHC2/EH02, XHCI/XHC_
Kext: FakePCIID+FakePCIID_XHCIMux+USB_Injector x99
Clover Boot Argument -uia_exclude_hs

Bisher laufen alle Ports perfekt stabil. Und durch das Boot Argument sind auch nur die SSP Ports auf den XHCI gebunden.
Die Abwärtskompatibilität der USB3 Ports geht aber immer noch nicht.

Ich frage mich langsam ob ich nicht einen Denkfehler habe und da in der Konstellation überhaupt nicht möglich ist?
Kann es sein, das der FakePCIID_XHCIMux per Definition die Abwärtskompatibilität an den USB3 Ports kill?
Und wenn nicht, kann es daran liegen das bei meinem System EH01 in der IORegistry komplett leer sind und alle Ports am EH02 hängen? Vielleicht ein Zielkonflikt?

Gruß Joe

Entschuldige, hatte ich nicht explizit erwähnt. Identisch.

Radikaler getestet - ohne Befund

Ich sehe in der ausgelesen DSST den Eintrag

Und die Controller heißen wieder EHC1, EHC2 und XHCI - insofern wurde alles angewendet. Einen Unterschied im Verhalten kann ich nicht feststellen. Ich werde jetzt mal den Patch für Windows 8 Testen und ggf. mal Windows 10.

Nachtrag: Windows 8 bringt auch keine Veränderung. Windows 10 entfällt alt Test, da in der ausgelesenen DSDT kein Eintrag zu “Windows 2015”, was laut MS Doku Windows 10 wäre, existiert.

Hallo @Kuckuck

ich habe nochmal beide Varianten ohne jegliche Injektoren etc. getestet. Weder Windows 7 noch Windows 8 scheinen eine Veränderung zu ergeben. Über den Weg MaciASL/New from AHCI/SSDT kann man sehen, das die Änderungen jeweils übernommen wurden, mehr aber auch nicht. Vielleicht verhält sich das ASUS Bios in beiden (allen) Fällen gleich?

Ohne Injektor funktionieren alle USB2 Ports übrigens auch perfekt. Mit Rehabman's XHCI-x99-injector.kext wird alles gnadenlos über den AppleUSBXHCIPCI geroutet was logischerweise dazu führt das auch die USB3 Geräte laufen, aber damit auch die Audio Probleme vorhanden sind. Was mich wunder ist, das der XHCI-x99-injector eigentlich nur 0x8d318086 auf den AppleUSBXHCIPCI bindet. Warum wirkt sich das auf die USB2 Devices am Controller 0x8d2d8086 aus? Ich meine es wäre ja ok, wenn die USB2 Devices die in einem USB3 Port stecken auch vom xHCI verwurstelt werden, aber warum kassiert der auch alle USB2 Ports vom EHCI ein?

Gruß Joe

Zitat von kuckkuck

Wir müssen experimentieren.

Ok, ist ja auch mal spannend.

Zitat von kuckkuck

Wo hast du diese aml gespeichert? Wo ist die DSL Datei und unter welchem Namen hast du die beiden jeweils gespeichert?

EFI/CLOVER/ACPI/patched/SSDT-XOSI.aml
_OSI zu XOSI zunächst via Clover Patch (ACPI-->DSDT-->Patches)

Zitat von kuckkuck

Ist die SSDT.aml in der config.plist in der sorted order?

Ja

Zitat von kuckkuck

Benutzt du eine SSDT für Speedstep?

Nein

Zitat von kuckkuck

Wieso das so ist kann ich dir später erklären.

Ich denke das habe ich schon verstanden. Windows 8 weil sowohl für Windows 8 (_OSI string: "Windows 2012") und alle früheren Windows Versionen ein 0xFFFFFFFF als Return value liefern. Soll Windows7 gemeldet werden, müsste der Eintrag "Windows 2012" entfernt werden. Damit wäre "Windows 2009" respektive Windows 7 der höchstwertige valide Eintrag. Korrekt?

Klar immer nur mit Backup @kuckkuck...

Ich bin gerade mit der XOSI Variante dran. Ich kann sehen (wenn ich mit MaciASL die aktuelle Tabelle auslese, das die XOSI Methode in der DSST vorhanden ist. Bisher bemerke ich im System keine Veränderung. Gibt es eine Stelle wo ich validieren kann ob die Einstellungen überhaupt zu einer Veränderung führen? Fühlt sich gerade etwas "blind" an.

Ich nehme an, das die Umbenennungen XHCI->XHC, EHC1->EH01, etc. auf bei der Methode aktiv bleiben oder habe ich das missverstanden?

Nachtrag: Im MaciASL sehe ich auch die SSDT-XOSI im ACPI.