HowTo: Thunderbolt HotPlug/HotSwap Finetuning für euren Hackintosh

  • Mork vom Ork Was genau oder besser gesagt welche Version hast du den versucht zu patchen?


    Edit: Ich bin eine Blindschleiche...


    Aber auch bei mir verabschiedet sich AMIBCP

    MacBookPro15,1 - HP Envy X360 - Intel i5 10210U - 16GB RAM - 512 GB SSD - Intel UHD 630 - 10.15.2 (19C57)


    MacPro7,1 - Intel Xeon 3175X - Gigabyte C621 Xtreme - 192 GB RAM - 2x 960GB Corsair Force MP510 - 2x MSI Radeon VII - 10.15.2 (19C57)




    Keine Unterstützung per PN...

    Eure Fragen gehören ins Forum, nicht in mein Postfach!

    Edited 2 times, last by DSM2 ().

  • Die auf der Supportseite verlinkte aktuelle Version F20k:

    -


    öffnen kann ich Sie mit der AMIBCP v.5.02.0023, nur eben leider nicht sichern.

    ASRock Z370 Professional Gaming i7 • Intel Core i7-8086K 4.0GHz • 32GB RAM • ASRock Radeon VII Phantom Gaming • 2x Samsung 970EVO NVMe M.2 SSD 500GB
    Custom Wasserkühlung • Thermaltake TheTower 900 • 1x LG 38UC99-W @ 3840 x 1600 (60Hz) via DP • SAMSUNG TV UE46ES7090 @ 1920 x 1080 (60Hz) via HDMI
    WINDOWS 7 ENTERPRISE • WINDOWS 10 ENTERPRISE INSIDER (PRO950 NVMe) • macOS 10.14.x latest Build (on Samsung 960 EVO NVMe) • Clover always latest Rev.

    Edited 2 times, last by Mork vom Ork ().

  • Das Board ist heute tatsächlich gekommen (hatte die Hoffnung schon fast aufgegeben, DHL hat sich da echt was geleistet – aber egal) und ich muss sagen, sooooo einfach war es mit dem Hacky noch nie. :feuerwerk:


    Beim ersten Einschalten kam diese Nachricht:



    Dann habe ich im BIOS lediglich den Stick mit der EFI von meinem Gigabyte Z370N ausgewählt (nix an der EFI verändert, ich schwör!) und das Teil war dann blitzartig unter 10.12.6 einsatzbereit. Keine spezielle BIOS Einstellungen geladen, alles so gelassen wie das Board geliefert wurde. Hat mich sehr beeindruckt.


    Natürlich zeigt er in den Systeminformationen unter Thunderbolt nichts an. Das wäre jetzt wirklich die Härte gewesen, wenn das auf Anhieb geklappt hätte.


    Bin jetzt etwas unschlüssig, wie ich am sinnvollsten weitermache. Wahrscheinlich erst mal die USB Situation checken, da liegt einiges im Argen, nirgendwo USB3, der USB-C Port reagiert auch noch nicht.


  • Aber ich sagte es doch auch schon: die von mir hier besprochene Lösung zeigt nach wie vor KEINE Thunderbolt-Geräte in den Systeminformationen unter dem Punkt Thunderbolt!

    Das Tutorial sorgt lediglich für funktionierenden HotPlug/HotSwap - nicht mehr, aber auch nicht weniger.


    - - - - -


    Habe soeben das Gigabyte Z170X SOC FORCE reaktiviert: aufgespielt war BIOS rev. 20e

    Habe ich soeben aktualisiert auf rev. 20k


    GC Alpine Ridge Karte steckt in PCIe Slot 7 - ist der von hinten gesehen ganz rechte x16 Slot. TB-Header Kabel ist gesteckt: kein Thunderbolt erkannt.

    Werde jetzt die einzelnen Slots durchtesten.


    - - - - -


    Jetzt weiss ich wieder, warum ich das Gigabyte Board eingemottet habe:

    das Ding hat zwar einen Thunderbolt-Header, erkennt auch die USB-C Anschlüsse der GC Alpine Ridge Karte - macht aber um's verrecken kein Thunderbolt.

    Ich meine auch mich zu erinnern, schon damals den Gigabyte-Support angeschrieben zu haben, welcher mir dann mitgwtwilt hat, das dieses Board definitiv

    KEIN Thunderbolt macht, wegen des PLX PEX8747 chips, welcher dafür sorgt, dass 32 Lanes für die GPU zur Verfügung stehen. Irgendetwas war da, weswegen

    ich das Board wieder eingelagert habe.


    Und es gelingt mir derzeit auch nicht, Thunderbolt aktiviert zu bekommen. Es werden mir auch keine Thunderbolt-Settings im BIOS angeboten. Sch....!


    - - - - -


    Ok, rausgefunden, warum das Gigabyte Z170X SOC FORCE kein Thunderbolt nimmt: es hat keinen x4-Slot !

    Thunderbolt läuft aber nur auf X4-Slots.


    Aber: das Board hat ja 3 M.2 Slots. Also habe ich getrixt: im dritten M.2 Slot sitzt ein M.2-auf-PCIe-X4 Adapter: et voila: THUNDERBOLT am Z170X SOC FORCE


    -


    Zugegeben: noch nicht die eleganteste Art, aber machbar. Brauch ich nur ein passendes "Riser"-Kabel und schon kann ich die Karte sauber im Gehäuse verlegen.

    ASRock Z370 Professional Gaming i7 • Intel Core i7-8086K 4.0GHz • 32GB RAM • ASRock Radeon VII Phantom Gaming • 2x Samsung 970EVO NVMe M.2 SSD 500GB
    Custom Wasserkühlung • Thermaltake TheTower 900 • 1x LG 38UC99-W @ 3840 x 1600 (60Hz) via DP • SAMSUNG TV UE46ES7090 @ 1920 x 1080 (60Hz) via HDMI
    WINDOWS 7 ENTERPRISE • WINDOWS 10 ENTERPRISE INSIDER (PRO950 NVMe) • macOS 10.14.x latest Build (on Samsung 960 EVO NVMe) • Clover always latest Rev.

    Edited 5 times, last by Mork vom Ork ().

  • Oh – sorry, du hattest das womöglich als versteckte Kritik einsortiert. War keinesfalls so gemeint. Wenn ich TB3 nutzen will, ist die Anzeige in den Systeminformationen das letzte, was mir dabei wichtig erscheint. Alles ist gut.


    Bin derzeit noch bei der Konfiguration der USB Ports. Der USB-C Port wird nicht erkannt (angesteckte Geräte werden nicht angezeigt), könnte das was mit dem aktivierten TB3 im BIOS zu tun haben? Meine BIOS Version ist oben im Bild, soll ich upgraden? Hier die Situation mit den Ports:


    1. Geräte mit 480 Mbps:


    2. Geräte mit 1.5 Mbps:


    3. Geräte mit 5 Gbps:


    Wie gesagt, wenn ich was bei USB-C einstöpsle, passiert nix. BIOS?

  • Aktivier mal USB über Thunderbolt, das ist ein Standart-Blocker..


    :hackintosh:

  • ResEdit

    welches System fährst Du?

    Ich habe unter Mojave 10.14.6 angefangen mit meinen ganzen Tests - und dabei zunächst die "USB 15-Port Limit" patches gesetzt und in "kexts-Others" den "USBInjectAll.kext" aktiv.

    Darüber habe ich bei meinem 370er Board rausgefunden, das bei mir Port HS10 und SS10 aktiv sein muessen, damit USB-C der GC Titan Ridge funktionieren.


    Selbiges hat bei mir dann auch unter Catalina beta 7 funktioniert. USB Portlimit patch setzen und USBInjectAll.kext nutzen. Damit feststellen, welche Ports genutzt werden. Der HS-Port

    wird nur Nutzung von USB-C-auf-USBG3.0-A Adapter benötigt, um auch USB2.0 devices an der GC Alpine/Titan Ridge nutzen zu können. nutzen zu können

    ASRock Z370 Professional Gaming i7 • Intel Core i7-8086K 4.0GHz • 32GB RAM • ASRock Radeon VII Phantom Gaming • 2x Samsung 970EVO NVMe M.2 SSD 500GB
    Custom Wasserkühlung • Thermaltake TheTower 900 • 1x LG 38UC99-W @ 3840 x 1600 (60Hz) via DP • SAMSUNG TV UE46ES7090 @ 1920 x 1080 (60Hz) via HDMI
    WINDOWS 7 ENTERPRISE • WINDOWS 10 ENTERPRISE INSIDER (PRO950 NVMe) • macOS 10.14.x latest Build (on Samsung 960 EVO NVMe) • Clover always latest Rev.

  • Mork vom Ork

    Erst mal dicken Respekt, das zum Thema zu machen. Kann allerdings nicht so ganz nachvollziehen, was nun an der SSDT neu sein soll. HotPlug funktioniert schon lange, habe auch einigen Leuten hier geholfen, dort funktioniert es ebenso. In deiner (Basis-) SSDT ist einiges drin, was noch raus kann. Um mal bei deiner SSDT zu bleiben:


    In Zeile 23-27 wird auf externe Quellen verwiesen. Der Verweis auf XHC_ kann ersatzlos gestrichen werden, es gibt keinerlei weiteren Bezug in der SSDT darauf. Im Original werden hier in der Folge USB2 vom XHC geroutet, ist hier völlig unsinnig. Auch heißt je nach System dieses Device auch mal XHCI oder anders. Egal, es kommt auch gar nicht weiter vor in deiner SSDT. Der Aufruf einer externen Methode DTGP funktioniert natürlich auch nur, wenn sie denn wo anders schon enthalten ist, darauf sollte noch hingewiesen werden (inject per Clover in die DSDT, oder enthalten in einer weiteren SSDT). Der letzte Eintrag PXSX kann ebenso raus, ist dieser doch schon exakt mit Pfad weiter oben beschrieben worden.


    Die Methode NTFY (Zeile 34) kann ersatzlos gestrichen werden, völlige Nebelkerze. Denn mit "Name (STA, Zero" blendest du das vorhandene Device "PXSX" aus, um für ein eigenes Device "UPSB" auf Adresse 0x0 (Zero) Platz zu schaffen, "Notify" wird also niemals ausgeführt.


    Die _DSM Methoden habe ich mal um die unsinnige "if"-Schleife reduziert.


    Beschreibung Definitionsblock "TbtOnPCH" finde ich auch nicht so elegant, denn diese SSDT sollte doch allgemeingültig sein. Also nicht nur auf irgendwelche RPxx vom PCH, sondern auch direkte PCIe der CPU zugeordnet.


    Es bleibt also, wie in vielen anderen SSDTs zum Thema, zum einen der Pfad zum Device "NHI0" und einige wichtige Beschreibungen per _DSM-Methode eingefügt.


    Deine Erkenntnis, dass der komplette Baum wie in der originalen Apple SSDT zu Problemen führt, ist richtig. Besser ist es allerdings, die Stamm-Devices DSBx noch aufzunehmen, denn hier können noch jeweils _DSM-Methoden hinzugefügt werden, die sich in der Kette vererben ("AAPL,slot-name"). Der Vorteil, nun werden auch die angeschlossenen Geräte in der PCI-Sektion (Systembericht) angezeigt! Weiterhin kann so auch der XHCI-Controller beschrieben werden. Habe ich mal integriert und "XHC5" genannt, damit dieser nicht namentlich mit eventuell weiteren XHCx-Controllern kollidiert.


    Ich habe die überarbeitete SSDT mal im Anhang gesetzt (Pfade natürlich überarbeiten), teste es gern. Der Teil des Tutorials, welcher sich dem BIOS widmet, finde ich sehr spannend. Ich habe das Glück, ein BIOS zu haben welches alle relevanten Einstellungen zu Controller zulässt; dieses allen Boards zugänglich zu machen – noch mal dicken Respekt.

    Files

    • SSDT-TBOLT3.aml

      (1.13 kB, downloaded 24 times, last: )

    ASUS PRIME X299-DELUXE • i9-7900X • DDR4 64GB • SSD 960 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon RX Vega 64

    Edited once, last by apfelnico ().

  • Die Sache an dem ganzen Vorgehen ist aber das aus welchen Gründen auch immer, dass ganze bei Thunderbolt Onboard funktioniert und mit der reinen alten Methode eben nicht.


    Ich selbst habe das ganze nicht analysiert und habe persönlich eine andere Lösung für Onboard Chipsets die aber recht komplex ist.


    Fakt ist das es mit der oben beschriebenen Methode definitiv funktioniert und einfacher umsetzbar ist als mein Ansatz für Thunderbolt Onboard.

    MacBookPro15,1 - HP Envy X360 - Intel i5 10210U - 16GB RAM - 512 GB SSD - Intel UHD 630 - 10.15.2 (19C57)


    MacPro7,1 - Intel Xeon 3175X - Gigabyte C621 Xtreme - 192 GB RAM - 2x 960GB Corsair Force MP510 - 2x MSI Radeon VII - 10.15.2 (19C57)




    Keine Unterstützung per PN...

    Eure Fragen gehören ins Forum, nicht in mein Postfach!

    Edited once, last by DSM2 ().

  • ResEdit

    welches System fährst Du?

    10.12.6, wie schon gesagt. Habe deinen Hinweis mit USB HS10 und SS10 zu spät gelesen. Den USB2 Header und den USB3 Port auf dem MoBo habe ich im BIOS deaktiviert, dann die nicht genutzten Ports mit uia_exclude=HS01;HS02;HS07;HS10;HS11;HS12;HS13;HS14;SS05;SS06;SS09;SS10;USR1;USR2 ausgeklammert. Das sieht dann jetzt so aus:


    Mehr USB brauche ich auch nicht. Habe dann eine Plugable Docking Station UD-CAM (ASIN B078WXTYTW) mit TB3 Kabel (!) am TB3 Port angeschlossen und siehe da: Die dort integrierte Soundkarte wird als USB-Tonausgabegerät erkannt, das darin befindliche USB-Netzwerk-Interface (10/100/1000 RJ45) ebenfalls. Auch die HDMI Schnittstelle wird erkannt, habe jedoch (bisher) kein Dual-Monitor Setup erfolgreich testen können. Immerhin wird das USB-Protokoll über TB3 weitergereicht, obwohl ich HS10 und SS10 "unsichtbar" konfiguriert habe.


    Bin echt erstaunt, wie locker sich das bislang alles gemacht hat, im BIOS habe ich lediglich die nervigen LED-Lichtorgeln des MoBos deaktiviert und die iGPU als Standard gesetzt. Sonst wie gesagt NULL Konfiguration im BIOS vorgenommen.


    Edit: Sorry, hatte ich vergessen: Onboard BT und WLAN habe ich ebenfalls deaktiviert im BIOS. Brauche ich beides nicht.

  • apfelnico


    Danke für Dein Feedback. Und danke für den Hinweis mit dem XHC-Eintrag. Das war mir zwar bewusst, dass dieser eigentlich noch rausgelöscht gehört, aber ist im Eifer des Gefenchts dann doch noch übersehen worden.

    Bezüglich der alten Methode kann ich nur sagen:


    ich habe diverse TBT-SSDT Dateien bei mir ausprobiert und wirklich keine davon ermöglichte mir ein sauberes HotPlug auf meinen beiden ASRock Boards. Keine.

    Daher war ich ja so versessen darauf, eine nicht nur für mich, sondern allgemein funktionierende Lösung zu finden, nachdem ich Alex' Video gesehen hatte, da ich mir dachte: "...es muss ja irgendwie gehen."


    Letztlich habe ich nicht getestet, ob es nun nur Dank der neuen Einstellungen f. TB im BIOS funktioniert, oder ob auch die "NOTIFY"-Funktion ihren Teil dazu beiträgt. Ich habe für mich und bei meinen diversen Tests halt immer

    nur festgestellt: nimmt man eins der Elemente wieder weg, funktioniert HotPlug bei mir wieder nicht mehr. So habe ich z.B getestet, was passiert, wenn ich nur die BIOS-Einstellungen belasse und gänzlich auf eine TB-

    SSDT verzichte. Fazit: HotPlug funktioniert NULL, also gar nicht. Für USB-C devices nie ein Problem, aber wirkliche TB devices funktionieren eben nur dann, wenn sie zu Beginn des Rechnerstarts gesteckt sind und einmal

    abgezogen, lassen sie sich nicht erneut reaktivieren.


    Und mit dem ganzen UPSB/DSBx Wust hatte ich ja auch geschrieben, das ich es in der Tutorial-SSDT bewusst weggelassen habe, da ich dadurch in einem längeren, hintereinandergeschalteten Strang an TB-Devices das

    Problem hatte, das ich die Kette dann nicht an jeder x-beliebigen Stelle unterbrechen konnte, ohne das mein Rechner umgehend einen Neustart gemacht hat. Habe ich die selbe Kette aber unter Nutzung der im Tutorial

    besprochenen SSDT genutzt, konnte ich die Kette an jeder x-beliebigen Stelle trennen und ggf. neu stecken.


    Das dadurch die bequeme Möglichkeit der Benennung der Devices mittels der _DSM-Methode verloren geht, habe ich zu Gunsten der Funktionalität ersteinmal in Kauf genommen. Gerne gehe ich dazu aber nachträglich

    nochmal genauer darauf ein. Darum bat ich ja um Euer Feedback


    :danke2:

    ASRock Z370 Professional Gaming i7 • Intel Core i7-8086K 4.0GHz • 32GB RAM • ASRock Radeon VII Phantom Gaming • 2x Samsung 970EVO NVMe M.2 SSD 500GB
    Custom Wasserkühlung • Thermaltake TheTower 900 • 1x LG 38UC99-W @ 3840 x 1600 (60Hz) via DP • SAMSUNG TV UE46ES7090 @ 1920 x 1080 (60Hz) via HDMI
    WINDOWS 7 ENTERPRISE • WINDOWS 10 ENTERPRISE INSIDER (PRO950 NVMe) • macOS 10.14.x latest Build (on Samsung 960 EVO NVMe) • Clover always latest Rev.

  • Letztlich habe ich nicht getestet, ob es nun nur Dank der neuen BIOS Einstellungen funktioniert, oder ob auch die "NOTIFY"-Funktion ihren Teil dazu beiträgt.

    Im Original https://osy.gitbook.io/hac-min…details/thunderbolt-3-fix wurde beschrieben, welche "_Exx" Funktion (Edge Triggered GPE) ein "Notify" für genau den benutzten Slot beinhaltet. Bei mir ist es "_E4C". Eine Methode Namens "NTFY" wurde ermittelt, diese wird in der DSDT benutzt. Entweder man editiert diese direkt in der DSDT, oder man versucht diese über Clovers DSDT-Patches durch Rename unbrauchbar zu machen. So sieht diese bei mir zum Beispiel aus:

    Um dann in der Folge in einer eigenen SSDT die Funktion neu zu erschaffen, mit an geeigneter Stelle modifizierte Notify, die bis zum NHI0 reicht. Sinnvoll wäre es natürlich, auch die restlichen unbearbeiteten "Cases" wieder aufzunehmen. Das kann also je nach System ganz anders aussehen, hier war es ein NUC. Und wie gesagt, deine "NTFY" hängt an "PXSX", welches du gerade "unschädlich" gemacht hast. Wenn es wichtig wäre, wäre es besser im aktiven Strang "UPSB" aufgehoben. Noch besser jedoch das Original ausgetauscht unter "Scope (_GPE)".


    Und mit dem ganzen UPSB/DSBx Wust hatte ich ja auch geschrieben, das ich es in der Tutorial-SSDT bewusst weggelassen habe, da ich dadurch in einem längeren, hintereinandergeschalteten Strang an TB-Devices das

    Problem hatte, das ich die Kette dann nicht an jeder x-beliebigen Stelle unterbrechen konnte, ohne das mein Rechner umgehend einen Neustart gemacht hat. Habe ich die selbe Kette aber unter Nutzung der im Tutorial

    besprochenen SSDT genutzt, konnte ich die Kette an jeder x-beliebigen Stelle trennen und ggf. neu stecken.

    Das dadurch die bequeme Möglichkeit der Benennung der Devices mittels der _DSM-Methode verloren geht, habe ich zu Gunsten der Funktionalität ersteinmal in Kauf genommen.

    Das habe ich ja verstanden und auch als richtig geschlussfolgert kommentiert. Nur ist es sinnvoll, (nicht den kompletten Strang!), sondern die ursprünglichen "DSBx" (nicht nur "DSB0") ebenfalls mit aufzunehmen (schaue doch dazu in meine überarbeitete Version). Es ändert sich somit nichts mit dem "Kettenproblem"! Aber da hier bereits nun schon eine _DSM-Methode gesetzt wird (mit dem Parameter "AAPL,slot-name"), wird dieser in der sich später aufbauenden Kette "vererbt". Es geht also gar nicht darum, eine lange Kette zu bauen und ein Gerät direkt per _DSM-Methode zu benennen, sondern dass das Gerät, unabhängig davon wie es heißt und ob der Hersteller es auch benannt hat, dass dieses Gerät eben in der PCI-Sektion des Systemberichts/Systeminformationen auftaucht. Denn hier ist es für den Nutzer sehr einfach einzusehen, ob überhaupt ein Treiber für dieses Gerät geladen wurde. Ansonsten tappt man da im Dunkeln. Kannst du gern ausprobieren. _DSM-Methode von z.B. "DSB1" entfernen, schon sieht man an diesem Strang in der PCI-Sektion keine Geräte mehr (die natürlich dennoch funktionieren).


    Hast du meine überarbeitete SSDT mal ausprobiert? Ich möchte ja nur helfen, einerseits Dinge zu verschlanken, andererseits wichtige Dinge zu integrieren.

    ASUS PRIME X299-DELUXE • i9-7900X • DDR4 64GB • SSD 960 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon RX Vega 64

  • Kurze Frage, wieso eigentlich die ganzen _STA Funktionen? Tauchen die Geräte in den original Tables nicht auf oder sorgt im Original irgendeine _OSI Konstruktion für die Deaktivierung der Devices? Inwiefern sollten die Device bereitgestellt werden, wenn ein anderes OS als macOS bootet? Hier sollte man evtl. darüber nachdenken vorhandene _OSIs zu verändern oder die gesetzten _STAs mit _OSIs zu versehen um cross-platform Support zu gewährleisten, Treiber wie OpenCore nutzen ACPI Tabellen auch bei nicht-macOS boot. Sorry, besitze selber keinerlei betroffene Hardware, deswegen kann ich nicht selber reinschauen.


    persönlich eine andere Lösung für Onboard Chipsets die aber recht komplex ist.

    Würdest du die vielleicht mal hier kurz beschreiben? Dann können wir mal drüber schauen, ob sich das irgendwie vereinfachen/verallgemeinern lässt. Ich weiß nicht, ob du dabei mit ACPI arbeitest, aber wäre definitiv interessant. 4 (oder eher 32 :D ) Augen sehen mehr als 2 :)

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

  • Kurze Frage, wieso eigentlich die ganzen _STA Funktionen? Tauchen die Geräte in den original Tables nicht auf

    Nein, diese Devices gibt es nicht in der original ACPI. Siehst du schon allein daran, dass es als "Device" in der SSDT definiert ist, nicht "Scope" (also erweiterte Einträge eines vorhandenen Devices). Mit der Methode _STA wird der aktuelle Status abgefragt. Deaktivierung von z.B. PXSX erfolgt nicht direkt mit einer Methode, sondern ändern des Parameters "Name (_STA, Zero)". Somit wird der Weg frei für das neue Device "UPSB". Sonst würde alles an PXSX hängen, was grundsätzlich nun auch kein Problem wäre.

    ASUS PRIME X299-DELUXE • i9-7900X • DDR4 64GB • SSD 960 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon RX Vega 64

  • Jup, darauf hab ich nicht geachtet, mir war nicht bewusst inwiefern hier FW Settings die ACPI Tabellen beeinflussen und evtl. gesamte Devices streichen, wer weiß (obwohl, gibts sowas überhaupt?). Ich vermute mal die Devices stammen aus Apple-ACPI Dumps? Matcht der Treiber auf UPSB?


    Mir ist bewusst wie _STA funktioniert, was ich sage ist, um es noch sauberer zu machen würde ich in diesem Fall noch _OSI Abfragen einbauen. Sprich:

    Zumindest bei UPSB oder Untergeräten wie DSBx sollte das so möglich sein.

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

  • kuckkuck


    Das würde doch reichen:

    Wenn "Darwin", dann PXSX ausblenden und normal fortfahren. Bei allem anderen wird es nicht ausgeblendet, und der TB-Controller wird wie gehabt an PXSX angehängt. Der Rest der SSDT ist somit hinfällig …

    ASUS PRIME X299-DELUXE • i9-7900X • DDR4 64GB • SSD 960 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon RX Vega 64

  • Der Teil mit der offenen Else Funktion gefällt mir, dann kann die FW oder sonst ein OS hier noch komplett selbstständig walten solange Darwin nicht gecalled wird. Der wichtigste Teil ist damit getan.


    Ob man den ganzen Rest mit aktivem Status anhängen will, wenn nicht macOS gebotet wird, ist ansichtssache. Da würde ich einfach noch für UPSB eine entsprechende if Konstruktion in die _STA Methode einbauen, macht ja keinen Sinn in diesem Fall weitere Devices einzubinden, die absolut ins Leere laufen und unbedingt aktiv sein wollen.

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

  • kuckkuck

    Dann so :)


    ASUS PRIME X299-DELUXE • i9-7900X • DDR4 64GB • SSD 960 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon RX Vega 64

  • apfelnico


    Ok, das mit der ganzen NOTIFY Routine habe ich soeben bei mir getestet. Diese scheint echt irrelevant zu sein. Hier scheinen also eher die korrekten Thunderbolt-Einstellungen im BIOS echten Einfluss auf "HotPlug/HotSwap on the fly" zu nehmen.

    Den Teil kann ich also schonmal wieder aus dem Tutorial streichen. Tutorial entsprechend angepasst. Den Rest werde ich gerne ebenfalls auf beiden Boards testen.

    ASRock Z370 Professional Gaming i7 • Intel Core i7-8086K 4.0GHz • 32GB RAM • ASRock Radeon VII Phantom Gaming • 2x Samsung 970EVO NVMe M.2 SSD 500GB
    Custom Wasserkühlung • Thermaltake TheTower 900 • 1x LG 38UC99-W @ 3840 x 1600 (60Hz) via DP • SAMSUNG TV UE46ES7090 @ 1920 x 1080 (60Hz) via HDMI
    WINDOWS 7 ENTERPRISE • WINDOWS 10 ENTERPRISE INSIDER (PRO950 NVMe) • macOS 10.14.x latest Build (on Samsung 960 EVO NVMe) • Clover always latest Rev.

  • apfelnico Das klingt nach einer Idee!

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.