BT Modul Instant Wake trotz Definition als 255 (Internal)

Moin,

ich benötige hier einmal Hilfe.

Nachdem ich mich ja nun doch verjüngt habe...stoße ich auf das Problem, dass mein neuer Hack immer einen Instant Wake hat.

USB - Mapping ist sauber gemacht. Ich hatte zunächst den Verdacht, dass das Problem an der noch auf dem Board verbauten Realtek Wifi/BT Lösung liegen kann. Diese ist per M2 gesteckt, aber über HS13/14 im System integriert. Technisch verstehe ich da zwar nur die Hälfte, aber egal.

Nun habe ich Probe halber also auch diese beiden Ports mal intern deklariert, dennoch ist das Problem nicht gelöst. Wake Reason ist folgendes:

Mittels ssdt-gprw habe ich das Problem zwar letztendlich gelöst verliere aber dadurch die Möglichkeit per USB einen Wake auszulösen.

Das Erfreuliche ist, er schläft ruhig und fest, wie erwartet - ich habe auch keine Abstürze mehr nach Wake und PowerNap ist sogar funktional.

Habt Ihr Lösungsansätze trotz SSDT-GPRW Wake per Keypress zu aktivieren oder geht es nur bei den Power Button?

Danke für jeden Input.

Viele Grüße

g.com

KungfuMarek Also ich widerspreche nur ungerne. Sleep funktioniert astrein. Nur eben durch die SSDT GPRW halt keinen wake per Tastendruck.

Steht oben auch ganz klar geschrieben.

Ich suche einen Weg Wake per Keyboard/Mouse zu aktivieren trotz der SSDT.

KungfuMarek Moin, auch hier widerspreche ich Dir. Der Second Sleep Bug ist auch gelöst. Das geht mittels boot-arg npci=0x2000.

Bei meinem Board gibt es kein altes Bios ohne 13er Support, wäre ja auch sinnlos bei meinem System.

Ich schaue mir gerne mal deine EFI an und helfe Dir beim Sleep, aber hier würde ich jetzt gerne dabei bleiben meine Frage zu klären.

KungfuMarek Jein...ich habe den acpi-wakre-type mittels PI integriert. Leider hat das nichts gebracht. Ich schaue mir das aber noch einmal genauer an.

Fein dass es mit dem Sleep funktioniert.

Zu dem Boot Arg - ich kann nicht genau sagen, was es macht. Es umgeht irgendwelche PCI Routinen und ggf. eliminiert es das im Bios angeschaltete Above 4G - soweit habe ich das noch nicht verstanden. Dies nur zur Info.

Wenn einer genauere Kenntnis hat, was npci=0x2000 macht und ob 4G erhalten bleibt oder nicht - bitte gerne mal Info.

UPDATE: Auch der USBWakeupFix Kext bringt keine Möglichkeit das Gerät mittels Keyboard Mouse aufzuwecken.

al6042  griven Sorry, dass ich Euch direkt anticke, aber Ihr seid doch Spezialisten im Thema DSDT/SSDT und Patching. Habt Ihr da vielleicht einen Tip? Könnt Ihr mir sagen, was PR04/PR05 ist oder wie man die GRPW Methode weniger invasiv anwenden kann, damit Wake per Tastendruck funktioniert?

Danke Dir al6042. Ich bin nun sogar etwas weiter. Also, das Problem ist tatsächlich meine BT karte. Habe diese eben mal vom USB abgesteckt und siehe da ohne GPRW schläft er.

Nun ist das ganze aber insofern komplizierter, da der HS Port eigentlich als Internal definiert ist. Leider ist hier die Komplikation, daß beide USB Ports auf dem MB über einen Hub laufen und somit am selben HS Port liegen. Ob dieser Umstand den Fehler verursacht? Schicke gleich einmal Bilder.

Ich habe da zwei Ports F_USB1 und F_USB2.

Beide sind in einem HUB zusammengefasst.

Definiert, als Internal.

Dennoch habe ich den Instant Wake vom BT Modul. Dieses Problem bestand zu keinem Zeitpunkt unter meiner alten Maschine.

Was ist da los?

Diese Vermutung hatte ich auch griven, aber selbst das Abstöpseln des Front USB und das Umstecken des Empfängers hat leider keine Besserung gebracht.

Ich bin hier gerade mit dem Latein am Ende.

Versuche jetzt mal mit USB Reset - bezweifle aber, das es etwas bringt.

UPDATE: Wie vermutet, die Einbindung der RHUB bringt keine Verbesserung. Ich würde mir wünschen mit Eurer Hilfe hier eine Lösung zu finden, da mein Ziel ja eigentlich war ein sauberes Rapture Lake Tutorial nebst passender EFI hier zu posten. Probleme sind ja nur noch ganz wenige da. Aber, Ihr wisst ja, man will immer das Maximum.

Was hat nicht sauber läuft sind 4 Punkte. Dies ist einer davon. Das DRM Problem ist ein Kabel/HDCP Problem, funktioniert aber. BT Entsperren mit der Watch könnte an der Hardware oder an der SSDT-GPRW liegen und dann gibt es nur noch eine Lappalie.

Danke für die Unterstützung.

Eigentlich ja und auf der alten Kiste hat das BT auch bei intern definertem USB nicht den Sleep gestört.

Hier in dem neuen System hingegen will es ohne die Brechstange _PRW zu kappen nicht funktionieren.

Ich meine, Du siehst ja - die Ports sind sauber definiert. Im Bios habe ich ERP an/aus und ASPM an/aus probiert ändert nichts.

Ich kann gerne mal die Efi posten, vielleicht habe ich etwas übersehen.

So richtig schlau werde ich aber nicht daraus.

Wie im anderen Post erwähnt hatte ich ja das Realtek Modul in Verdacht, dies ist über Hs 13 und HS 14 eingebunden, aber selbst das als intern definiert macht keinen Unterschied. Letztendlich der Beweis, dass es der BT USB Anschluss ist, kam dann durch abziehen des Kabels. Bäm, er schläft. Kabel dran Instant Wake.

Jetzt könnte ich natürlich die Karte vom PCI Adapter abziehen und in den Socket vom MB packen. Verliere dann aber auch das AX Modul unter Windows. Letztlich ist der Rechner ja eh über LAN am 2,5gbit Switch. Aber ob das mein Problem löst? Und vor allem ob es dann mit den Antenne. Anschlüssen von der Realtek Karte harmoniert?

Alternativ könnte ich natürlich eine Fenvi ordern und testen, aber ich vermute das gleiche Problem in grün.

UPDATE:

Ich habe jetzt mit acpi-wake-types experimentiert, habe die pci-aspm-defaults für den HXCI Controller eingerichtet. mit einem XHCI-Z790-unsupported.kext experimentiert. Problem bleibt bestehen. Instant Wake solange der blöde Dengle am USB hängt.

Meine EFI anbei - ich bin wirklich offen für Unterstützung -BTW - die Serial ist frisch generiert.

griven Es wird spannend. Also, nach langer Recherche stieß ich auf die Wurzel des Übels.Per USB mapping definiert man zwar den übergeordneten HS Port (das Hub) aber nicht die darunter liegenden Subports. Diese werde einfach nicht als intern wahrgenommen ergo…instant Wake. Es wäre also ein Ansatz entweder dem/denen die Methode _PRW zu entziehen per SSDT oder per Property Injection Werte zuzuweisen, die sie als interne Ports definieren. Jetzt bin ich gerade fern vom Rechner sehe hier aber meine Möglichkeit. Wenn Ihr da einen Ansatz seht, bitte gerne mal hier hinterlassen.

Lese ich mir nun dei SSDT Methode von apfelnico durch werden die im genannten Wake Reson RP4&RP5 die beiden Hubs sein. Frage wäre also, wie ich diese dann sauber deklariere, damit es bis rief in die Subports greift.

Ok, wer lesen kann ist klar im Vorteil. Die SSDT Methode ist klar ein Ansatz, der RP und die dazugehörigen Unterports werden da sauber deklariert. Könnte gut sein, dass ich hier Hilfe benötige, da meine SSDT von den Methoden ganz anders aufbaut. Habe es deswegen zunächst verworfen.

Ich danke schon jetzt für jede Hilfe.

kaneske Ich habe bis gerade eben schon experimentiert, allerdings deine Anmerkungen noch nicht gesehen.

Hatte es aber genau so gemacht.

Zu der Feststellung von Dir kommt erschwerend hinzu, dass die PR Ports vom XHCI dann in der SSDT-9 definiert werden. Wiederum mit eine krassen Anzahl von Methoden.

Ich bin hier total lost. Meine bearbeiteten SSDT´s enden in einer Menge ACPI Fehlern, somit greifen die nicht. Das wäre aber sicher zu korrigieren.

Des Weiteren sehe ich im IOReg, dass die PR Ports aus der SSDT-9 gar nicht die ausschließlich die USB Ports zu bedienen scheinen. Ein Beispiel sei hier der PR09 oder PR25. Sieht dann so im IOReg aus.

Da hängt mal geschmeidig die NVME dran.

Und der hintere USB 2 Hub wiederum taucht im IOReg unter keinem RP auf, auch RP09 ist der Wifi Anteil der Broadcom Karte im PCI Steckplatz.

Warum die alle über RHUB bzw. XHCI eingebunden werde ist mir absolut unklar. Oder gleiche Namen für unterschiedliche Dinge...

Ich denke das wird ein steifes Projekt und ggf. kann ich das mit Eurer Hilfe schaffen.

Ich wäre Dir massiv dankbar, wenn Du mir hier weiter Support geben könntest.

Ich denke das Ergebnis könnte hier für das Forum auch für viele andere interessant sein, da es wohl möglicherweise etliche AMI Biosse mit ähnlichen Strukturen geben mag.

Jetzt fehlt mir allerdings leider erst einmal das richtige Kabel um die USB-C Ports mit Full Speed zu identifizieren. Da muss ich bis Montag warten.

Ich werde morgen schon einmal vorarbeiten und melde mich dann.

UPDATE 1:

Was mich stutzig macht. Wenn der Hauptport als 255 deklariert wird, dann schalten die Apple Treiber die Unterports auf Port-Type 2, Ist der Hauptort als USB2 deklariert, werden die Port-Typen der darunter liegenden Ports auf Port-Type 0 geschaltet.

Das Verhalten ist reproduzierbar. Ganz gleich, ob mit Kext oder per SSDT. Ist das Treiberverhalten.

UPDATE 2:

kaneske Ich bin jetzt soweit, dass ich zwar die OEM SSDT gedroht bekommen und auch die gepaschte Variante integrieren kann, dabei aber sogar völlig ungepatcht, die USB3 Ports nicht mehr initialisiert werden. Ich bin dann dennoch Port für Port vorgegangen und habe eigentlich alles so gelassen, wie in der Ursprungsdatei, nur mittel _STA ungewünschte Ports deaktiviert. Auch bei Unterschreiten der 15 Ports und mit XHCIPortLimit Quirk enabled, keine Chance - der USB 3 Anteil bleibt verschwunden.

Testhalber habe ich dann dennoch Port HS12 mal als intern deklariert und dabei festgestellt, dass das Verhalten analog zur Kext Variante dazu führt, Hauptport 255, Unterport Port-Type 2. Und schlafen tut er auch nicht.

Ohne jetzt jemanden zu finden, der ACPI besser versteht - bin ich hier nun wirklich am Ende, wenn Du noch eine Idee hast, wäre ich dankbar.

Für den Moment sehe ich 3 Möglichkeiten. Mit _GPRW und kein Wake on USB leben, Karte in das interne M2 Fach einbauen, über meine USB3 Controller PCI Karte und Adapter einbinden.

Ich erinnere mich, dass wir von 15 Ports pro Controller sprechen, also hätte das den Nebeneffekt, ich habe zusätzliche 3 USB3,1 Ports.

N0b0dy Ich werde noch einmal alles auflisten. Danke für das Hilfsangebot. Ich habe das USB Mapping mit USBToolbox unter Windows gemacht und danach dann noch einmal den Kext mit Hackintool erstellt.

In MacOS habe ich dazu die RHUB-reset und den XHCI Port Limit Quirk benutzt.

Ein IOReg Dump von dem Zustand, also alle Ports sichtbar habe ich mir erstellt.

Ganz klassisch dann mit USB 2 und USB 3 Gerät Port für Port geprüft und die Port Adresse vermerkt, um dann von Hex auf den Wert zu gehen.

Was mir neu ist, die HS Ports laufen unter 14x… die SS unter 15x… Zumindest ohne Patching.

Und ja, bei Gigabyte ist es leider nicht so, das HS03 mit SS03 verbunden ist. Aber das werde ich noch einmal eruieren. Bzw. schaue auch mal oben auf den Screenshot vom USBMap, da habe ich sehr saubere Comments erfasst. z. B der hintere USB-A 3.1 Port unten unten hat HS05 und SS04.

Ich nehme gerne Eure Hilfe an. Allerdings fehlt es mir an einem Kabel, um die SS Personality der USB-C festzustellen. Habe wohl nur USB2.0 Kabel hier. Ich erwarte da morgen die Amazon Lieferung, bin allerdings beruflich bis Mittwoch verreist. Somit macht es am meisten Sinn mich dann am Ende der Woche zu melden.

Danke noch einmal 🙏