Um schreiben oder kommentieren zu können, benötigst du ein Benutzerkonto.
Du hast schon ein Benutzerkonto? Melde dich hier hier an.
Jetzt anmeldenHier kannst du ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellen
Hat sich erledigt!
Es war so einfach:
"Comment: Change 15 port limit to 24 in XHCI kext 10.13 PB1Find: 837D8C10Name: AppleUSBXHCIPCIReplace: 837D8C1B"
einfach mal direkt in der AppleUSBX geändert und es läuft! so vorne, als auch hinten :-))) Backplug, da steht die TimeMashine audoch drauf :-))))
ok werde ich machen, derzeit läuft alles.
Seltsam, dass USB3-Geschwindigkeit nicht erreicht wird.
Die Ursache war: ich hatte ein USB-Verlängerungskabel benutzt. Das wohl nur USB2 übertragen kann.
Ohne das Kabel wird volle USB3-Geschwindigkeit erreicht.
Ja, die Kabel... Das hatte ich doch heute auch schon 
Ich weiß gar nicht, in welche Richtung ich jetzt noch forschen soll. Doch mal F22a ausprobieren?
Das habe ich mir schon fast gedacht, der Portlimitpatch ist aber keine Dauerlösung. Wenn du dir jetzt mal im IORegExplorer unter /_SB/PCI0@0/XHC die Ports anschaust, solltest du eine ziemlich lange Liste sehen. Knapp die Hälfte der dir dort angezeigten Ports werden aber nicht funktionieren. Lass es ruhig erstmal so und wenn du wieder Zeit hast: neues Thema eröffnen.
Aja: Kannst du bitte testen, ob USB-Speichermedien nach dem Aufwachen aus dem Ruhezustand verfügbar sind?
USB Speichermedien, egal ob SSD oder HDD, alle verfügbar.
Es geht nicht darum, dass USB Geräte nicht funktionieren, sondern dass unbenutzte/unbelegte/unfunktionelle Software Ports in der Liste angezeigt werden. Die Hälfte deiner XHC Liste ist durch virtuelle Schnittstellen belegt, nur an die andere Hälfte kann man wirklich was anschließen...
USB Speichermedien, egal ob SSD oder HDD, alle verfügbar.
Vielen Dank. Jetzt weiß ich schonmal, dass ein BIOS-Update helfen könnte. Mal schauen, ob ich das auch wirklich mache. Nicht, dass ich mir hinterher noch ganz andere Probleme einhandle.
also ich kann an alle USB-Schnittstellen was anschließen, ditt läuft allet, jetzt auch ohne den ganzen manuellen Port-Kram, lag scheinbar an der 10.13.1 Version, mit USBInjectAllKext ist alles wie früher
Da frage ich zur Sicherheit nochmal nach, so eine Meldung hast du tatsächlich noch nicht zu Gesicht bekommen?
Never ever! das sehe ich nur, wenn ich wie ein Wahnsinniger den USB Stick OHNE "auswerfen" rausziehe, quasi wie beim .... *lol*
Jepp, deshalb war ich eigentlich froh, dass man mein Board bei Auslieferung schon auf F20 geupdated hat
Nach dem Update auf F22e hatte ich mit der extrahierten DSDT immer folgende Kernel Panic:
In @Brumbaers großartigem Beitrag ist mir direkt das hier aufgefallen:
Theorie ...
Irgendwo im BIOS ist eine DSDT gespeichert und diese wird dann an Clover und von dort an macos übergeben. Ändert man was an den BIOS Einstellungen, wird eine neue DSDT erstellt. Speichert man eine eigene DSDT im patched Ordner, ersetzt Clover die BIOS-DSDT durch die eigene. Das ist kein Problem, solange die Änderung einer BIOS Einstellung nicht eine Änderung in der DSDT bewirkt. Denn diese Änderung wird nicht automatisch in die eigene DSDT übernommen. Dann passen verwendete DSDT und BIOS Einstellungen nicht mehr zueinander.
Da war doch was... Die APCI-Tables hatte ich anscheinend direkt nach dem Update extrahiert und danach noch Einstellungen im UEFI vorgenommen. Also fix die ACPI-Tables nochmal mit Clover extrahiert und jetzt ist die Kernel Panic weg.
Dann noch das hier, das ist für mich echt verdammt viel Gold wert:
Die _LID Routine gibt es nur einmal. Was mache ich denn, wenn es eine Routine mehrmals gibt, wie _DSM oder _CRS ?
Es gibt in der Clover DSDT Patches Tabelle eine Spalte TgtBridge. Dort kann man eine Kennung eines Gerätes eintragen auf das der Patch begrenzt werden soll. Auch wieder als Hexzahlen. TgtBridge ähnelt dem Scope-Befehl. Dummerweise ist die Funktionalität eingeschränkt, da das nur funktioniert, wenn das zu ersetzende Etwas innerhalb des Device-Befehls der TgtBridge steht. Leider werden Scope-Befehle ignoriert.
Da ich die DSDT nicht patchen möchte und im Log öfter mal das hier gefunden habe:
Zitat2018-02-06 19:26:02.227393+0100 localhost kernel[0]: (AppleACPIPlatform) Wake reason: GLAN XDCI
... musste ich das direkt mal ausprobieren. ACPI-Patches, mit denen ich die Methode _PRW in den Geräten XDCI und GLAN in XPRW umbenannt habe:
Dabei kommt dann das hier raus:
Und dazu diese SSDT:
Sollte funktionieren... Wobei ich mich frage, ob ich noch eine Dummy-Methode namens "XPRW" anlegen sollte? Nee, Unsinn. XPRW wird ja eh nicht aufgerufen.
Ich zwar nur NIX verstanden, aber das war schon spannend. Die Erkenntnis: Ich weiß, dass ich nix weiß und Ahnung ist auch ausverkauft. Aber ich kenne nun einen, der einen kennt und der weiß, was ich nicht weiß."
"Wissen ist Macht", sagte da mal einer. Aber nix Wissen macht auch nix – wenn man jemanden mit Macht kennt".
Und diese Hacki-Forum ist eine echte "Machtzentrale". 
