VORSICHT Inkompatibilität MacOS 10.13 Thunderbolt 3/ UAD2 Satellite

    Leider nein!
    Es wird wohl auch keinen fix für geben, das Problem ist nämlich der Kext für die UAD Hardware selbst. Sobald die Thunderbolt Karte an einem anderem Slot als 16_3 installiert ist, verursacht dieser eine Reihe von folgenden Fehlern:




    Warum kann ich nicht verstehen, es macht auch keinen Unterschied welche Software Version ich installiere.


    Irgendwas lauft bei der initialisierung der Hardware anders ab, sobald die Thundrbolt Karte auf einem anderen Slot installiert ist.


    Theoretisch müsste ich mich hier an UAD wenden aber wie soll mir hier UAD helfen, wenn ich hier um Support für einen Hackintosh bitte.

    2 Mal editiert, zuletzt von DSM2 ()

    @DSM2 ich hatte massive Probleme mit meiner thunderboltex 3 und dem asus prime x299 deluxe.


    Mein System ist wie folgt :
    Intel i7 7800x
    Asus prime x299 deluxe
    32gb DDR 4
    Samsung EVO 960 m2 ssd
    Asus gtx 1080ti


    OSX 10.13.1 high sierra



    Ich hatte das Problem, das meine thunderbolt Karte einfach verschwand. Alles funktionierte wunderbar. Die Apollo twin wurde erkannt und das System war solid as a rock. Nur von jetzt auf nachher wurde auf einmal die apollo nicht mehr erkannt.
    Mehrmals Windows und Osx neu installiert, aber ohne Erfolg. Karte von pciex zu pciex gewechselt und auf einmal wurde die Apollo wieder erkannt...Aber dann irgendwann nicht mehr. Jetzt habe ich folgende Sache gemacht und es funktioniert seit drei Tagen ohne Probleme. Über Windows 10 die thunderboltex 3 firmware von Asus neu flashen und es sollte laufen.


    Traurig, das ein Elite Board mit einem Anschluss wirbt, der aber letztendlich den Kunden einfach nur Probleme mach.


    Viel Erfolg

    Nein, eigentlich nicht, danke deine Info könnte eventuell mein Problem lösen. Leider liegt mein X299 in Einzelteile zerlegt, weshalb es bei mir noch einige Wochen dauern wird, bis ich den wieder zusammengebaut habe und dies testen kann. Gegebenfalls melde ich mich nochmal bei dir per PN!

    Einmal editiert, zuletzt von DSM2 ()

    Interpretiere ich zuviel rein oder ist das hier die Zuweisung für die PCI Slots im Kext?
    Unter dem Punkt IONameMatch ?


    Nope...
    Die IONameMatches entsprechen den Vendor-/Device-IDs, welche von dem Kext unterstützt werden.


    Achte mal im DPCIManager unter "PCI List" ob dort das Gerät erkannt und mit einem der beiden Kombis dargestellt wird.
    Vendor = 1a00, Device = 0001
    oder
    Vendor = 1a00, Device = 0002

    Gruß
    Al6042

    Zeug mit dem ich so rum hantiere...

    Keine Unterstützung per PN oder Pinnwand... Eure Anfragen gehören ins Forum, nicht in mein Postfach!

    Ja sind drin und dann noch ein paar andere...



    Hast du vielleicht eine Idee was man probieren könnte um das ganze zum laufen zu kriegen ? @al6042

    Einmal editiert, zuletzt von DSM2 ()

    Sorry,
    dafür bin ich von den xX99er Boards zu weit weg.

    Gruß
    Al6042

    Zeug mit dem ich so rum hantiere...

    Keine Unterstützung per PN oder Pinnwand... Eure Anfragen gehören ins Forum, nicht in mein Postfach!

    Sehr schade, trotzdem danke!


    EDIT:


    Interessant ist wenn der Eintrag pci1a00,2 drin ist dann gibt es den Reboot...
    Mit pci1a00,1 bootet das ganze doch leider funktioniert Thunderbolt nicht, doch sind beide eintrage im DPCI aufgelistet.

    Einmal editiert, zuletzt von DSM2 ()

    Eine kleine Ernüchterung...
    Das Problem ist nur in Zusammenhang mit den UAD 2 Satellite Thunderbolt Karten, die Apollo tut Gott sei dank was sie soll.
    Hatte es vorher immer versucht im Daisy Chain Betrieb, heute einzeln versucht und dabei festgestellt das nur die Satellite Karten betroffen sind.
    Ich habe UAD bezüglich meines Problems kontaktiert und habe auch direkt mitgeteilt das es sich hierbei um einen Hackintosh handelt,
    bei welchem dieses Problem auftritt worauf mir der Support direkt eingestellt wurde.


    Ehrlich gesagt finde ich, dass dies einfach nur eine Schweinerei ist, da der Fehler seitens UAD verursacht wird und rein gar nichts mit dem Hackintosh zu tun hat.
    Die Apollo funktioniert ja auch auf einem anderen PCI Slot, hat daher auch nichts mit der Thunderbolt Geschichte an sich zu tun.


    Mein Plan sieht aktuell so aus, das ich mir die PCI-E Variante der Satellite zulegen werde, wobei ich aktuell irgendwie das Gefühl habe das diese auch von dem Problem betroffen sein könnten.


    Werde heute erneut versuchen den Support zu kontaktieren, vielleicht wird sich ja doch noch jemand meinem Problem annehmen, wobei ich mir übrigens nicht vorstellen kann, dass ich der einzige bin, der auf 10.13. unterwegs ist und Probleme damit hat.

    Ich habe zwei Uad 2 Pcie und eine apollo laufen ohne Probleme. Schön das du den Fehler gefunden hast. Vieleicht kommt die Lösung ja mit nem Firmware Update.


    Ich habe nach wie vor das Problem, das sich clover nicht automatisch durchstartet. Egal was in der configuration ändere, es will einfach nicht. Der Skin ändert sich auch sporadisch und ohne meinen Willen

    Ok, super dann kann ich ja beruhigt auf die PCI-E Umsteigen.
    Bezüglich deines Problems.
    Schick mir mal deine Config.plist über Private Nachrichten, ich schaue mir das mal an.

    Zitat von DSM2

    Ehrlich gesagt finde ich, dass dies einfach nur eine Schweinerei ist, da der Fehler seitens UAD verursacht wird und rein gar nichts mit dem Hackintosh zu tun hat.
    Die Apollo funktioniert ja auch auf einem anderen PCI Slot, hat daher auch nichts mit der Thunderbolt Geschichte an sich zu tun.


    Meinst du damit daisy-chain und UAD Sattelite funktioniert grundsätzlich nicht an TB3? Ich plane nämlich gerade meinen ersten Hacki, und das wären wirklich bad news...

    Wenn du 10.13 fahren willst vergiss es! Es hat an sich auch gar nichts mit dem Daisy Chain zu tun, sondern mit dem Treiber selbst für 10.13., ich habe die Satellite Thunderbolt auch versucht einzeln in Betrieb zu nehmen, bekam jedoch ebenfalls direkt die Kernel Panic beim Boot.


    Also entweder 10.12.6 nutzen und Upgrade auf High Sierra vergessen oder PCIE Variante zulegen.


    Ich kann leider aufgrund meiner Vegas nicht mehr auf 10.12.6 zurück.

    Hum das impliziert aber irgendwie das der Treiber für 10.13 so geschrieben ist das er den TB Controller auf bzw. an einem speziellen PCIe Slot haben möchte was ja auch untermauert wird durch die Tests die positiv verlaufen sind wenn die Karte auf einem bestimmten Slot steckt...


    Vielleicht ein wenig ins Blaue gedacht (hierzu fehlt mir halt echt der Background) aber könnte man nicht dem Slot auf dem die Karte steckt mittels DSM Methode in der DSDT die Infos unterschieben die der Treiber gerne hätte damit er glücklich ist? Es gibt doch das AAPL,slot-name Property wenn man die Slots in der DSDT jetzt mittels DSM Methoden so ordnet wie der Treiber das gerne hätte gäbe es da nicht vielleicht eine Chance das es funktioniert?

    Haswell, Notebook
    Zitat von DSM2

    Es hat an sich auch gar nichts mit dem Daisy Chain zu tun, sondern mit dem Treiber selbst für 10.13.


    Hm... also wenn das kein Hacky-Problem ist, müsste es ja eigentlich bei UAD schon Fehlerberichte hageln... Hab bisher noch nichts mitbekommen. Hoffe das wird gefixt! Ich kann/will nicht auf PCI umsteigen, der Krempel hat schon genug gekostet

    Zitat von griven

    Vielleicht ein wenig ins Blaue gedacht (hierzu fehlt mir halt echt der Background) aber könnte man nicht dem Slot auf dem die Karte steckt mittels DSM Methode in der DSDT die Infos unterschieben die der Treiber gerne hätte damit er glücklich ist? Es gibt doch das AAPL,slot-name Property wenn man die Slots in der DSDT jetzt mittels DSM Methoden so ordnet wie der Treiber das gerne hätte gäbe es da nicht vielleicht eine Chance das es funktioniert?


    Eine sehr gute Frage, ich selbst bin in der DSDT Materie alles andere als drin. @apfelnico : Ist das irgendwie möglich ? Können wir das irgendwie so setzen, das die Thunderbolt Karte meint sie würde in Slot 16_3 sitzen ?



    @44time : Ich frage mich auch warum es so still ist. Thunderbolt funktioniert ja an sich am hackintosh deshalb schließe ich den hacki aus, hab mittlerweile auch andere Geräte getestet und die laufen ebenfalls am hacki.
    Selbst die Apollo die ja ebenfalls per Thunderbolt verbunden ist, funktioniert einwandfrei!
    Das Problem tritt wie gesagt nur mit den DSP Karten auf aber auch nicht immer, das heißt wenn man auf 16_3 die Thunderbolt Karte auf dem X299 Deluxe hat funktioniert es.
    In meinem Fall ist dies nicht möglich da ich zwei GPU's habe und entsprechend 16_1 und 16_3 dafür verwendet wird,
    doch dennoch sollte es eigentlich keine Probleme damit geben wenn die Thunderbolt Karte auf 16_2 oder 16_4 liegen.
    Die Apollo funktioniert ja eben genauso auf dem 16_2 Slot und daher sollten auch die DSP Karten damit funktionieren.


    Mich kotzt es auch an das ich ein Haufen Kohle hier stehen hab, die ich nicht einmal nutzen kann.
    Ich versuche meine aktuell zu verkaufen, allein beim Gedanken daran, was ich da für einen Wertverlust haben werde, krieg ich die Krise.


    Die Leuten denken anscheinend man kriegt alles geschenkt im Leben.

    3 Mal editiert, zuletzt von DSM2 ()

    @DSM2
    Ich drück dir die Daumen, dass das eventuell durch Updates gefixt wird. Der ganze Thunderbolt-Quatsch hat mich auch mit Apple Hardware schon genug Ärger gekostet (max Kabellänge 3m, teuer, Latenzen schlechter als mein RME FF über USB 2.0).
    Ich überlege inzwischen ernsthaft, ob ich den UAD Kram einfach wieder rauswerfe....
    Good Luck auf jeden Fall!

    Naja klares Jein an der Stelle. Die Treiber werden eben für die Plattformen entwickelt auf denen sie laufen sollen und wenn bei macOS auf Apple Hardware der TB immer auf dem PCIe 16_3 Slot hängt dann ist es nachvollziehbar das man die Treiber eben genau daran bindet logistisch nachvollziehbar, logisch vielleicht nicht aber...


    Apple bietet nur einen sehr begrenzten Pool an Hardware und selbst der diversifiziert sich noch denn TB haben längst nicht alle Macs wird also eine Hardware entwickelt die nur eine bestimmte Range von Geräten wirklich unterstützen muss dann liegt doch der Schritt nahe die dazu gehörigen Treiber so simpel wie möglich zu halten (letztlich eine Kostenfrage). Nimmt man nun an, dass ein Gerät auf das der Treiber passen soll nur dann funktionieren muss wenn gewisse Vorraussetzungen geben sind die sich durch die eingesetzte Plattform ergeben kann man eine Menge Geld sparen indem man darauf verzichtet eine differenzierte Erkennung zu implementieren anders gesprochen auf einer Darwin Plattform hängen (natürlich exemplarisch gesprochen) TB Geräte immer auf einem bestimmten Slot und wenn dem nicht so ist gibt es entweder kein TB oder das Gerät ist nicht berechtigt den Treiber zu laden. Das es bei einem Hackintosh hier zu einem Crash kommt ist auch wieder dieser Engstirnigkeit geschuldet denn in der Apple Welt gibt es TB oder nicht und wenn es TB gibt dann auf dem entsprechenden Port anders gesprochen das Problem tritt im Mikrokosmos der Entwickler nicht auf weil das Gerät unter normalen (und das sind die Rahmenparameter in denen entwickelt wird) Umständen gar nicht erkannt werden dürfte. Am Hackintosh sieht das freilich anders aus denn da ist der TB Controller vorhanden wo immer er steckt und über die Device und VendorID wird auch der Treiber geladen allerdings erkennt dieser Treiber das da was nicht stimmen kann und anstatt einfach 1. den Dienst zu verweigern oder sich 2. an die Gegebenheiten anzupassen schmeißt er eine Panik und ist fertig damit.


    Seitens der Hersteller gibt es keinen wirklichen Druck daran was zu ändern denn schließlich ist die Mac Plattform ausreichend definiert und man stellt eben auch nur dafür her und damit sind die fertig...

    Haswell, Notebook