hab nur mal eben Screenshots gemacht... die config.plist(s) mit den Einträgen sind ja hier vorhanden.
Hab leider noch zu viele Intel GPU Kexte drin - der DSDT fehlt es halt noch...
DSDT Patch (Broadcom WLAN/BT BCM4352) - Hilfe benötigt
-
- Erledigt
- suiciety2k
- Erledigt
-
-
wo Haste unten die error enträge her kexttopatch. Hast du High Sierra drauf ?
-
Nein, ich bin mit Sierra unterwegs...
und die PCI Error K2Ps sind von u.a. @al6042 aus diesem Thread.Nachtrag:
Leider geht der Sleep des Giada immer noch nicht (mehr) - seit dem Wechsel Atheros -> Broadcom...
dafür hab ich nun Airdrop - was ist jetzt besser?
... schöner wäre ja beides... gerade als Wohnzimmer MedienzentraleNachtrag 2:
Sleep geht etwas länger (5 Sek), allerdings muss ich bei der Broadcom BT ausschalten... damit ist natürlich mein Apple Trackpad aus...
Hmm... wo könnte ich den Fehler noch suchen -
-
Die FakePCIIDs loszuwerden ist mein übernächstes Ziel...
Derzeit verzweifele ich noch ein wenig am nur 5-8 Sekunden andauernden "Sleep".
Habe mal meine letzten beiden DSDTS angehängt.
- DSDT mit Broadcom Eintrag
- DSDT mit Broadcom und GLAN
Wäre schön, wenn nochmal jemand drüberschauen kann, ob irgendwo noch ein kleiner Fix im Punkto "Sleep" benötigt wird...... Und: Warum steht bei mir Google Chrome im IOReg in den USBHostResources drin?
Hab den Auszug mal angeängt -
Was wirft das Log denn direkt nach dem missglückten Sleepmode aus?
log show --style syslog --last "1h" | fgrep "Wake reason"
-
Jetzt bin ich gerade im Büro... und der Rechner ist runtergefahren *hätt ich den mal angelassen"
Ich schaue nach, wenn ich um 15:00 Uhr wieder zu Hause bin.Nachtrag:
so, das heißt im Klartext USB.
Das kann nur das "Pseudo-Aufwachen-lassen" von meinem Drahtlos Logitech Keyboard sein...ich lass ihn gleich nochmal etwas länger (nicht) schlafen
so kann ich die Zeit besser verifizieren...Nachtrag 2 (längerer "Sleep"):
Code- iMac-WZ:~ user$ log show --style syslog --last "1h" | fgrep "Wake reason"
- 2018-02-24 15:44:04.687077+0100 localhost kernel[0]: (AppleACPIPlatform) Wake reason: EH02
- 2018-02-24 15:44:04.687080+0100 localhost kernel[0]: (AppleACPIPlatform) Wake reason: EH02
- 2018-02-24 15:53:38.464622+0100 localhost kernel[0]: (AppleACPIPlatform) Wake reason: EH02
- 2018-02-24 15:53:38.464625+0100 localhost kernel[0]: (AppleACPIPlatform) Wake reason: EH02
- 2018-02-24 15:54:30.579259+0100 localhost kernel[0]: (AppleACPIPlatform) Wake reason: EH02
- 2018-02-24 15:54:30.579262+0100 localhost kernel[0]: (AppleACPIPlatform) Wake reason: EH02
- 2018-02-24 15:55:30.489354+0100 localhost kernel[0]: (AppleACPIPlatform) Wake reason: EH02
- 2018-02-24 15:55:30.489357+0100 localhost kernel[0]: (AppleACPIPlatform) Wake reason: EH02
- 2018-02-24 15:56:30.521302+0100 localhost kernel[0]: (AppleACPIPlatform) Wake reason: EH02
- 2018-02-24 15:56:30.521305+0100 localhost kernel[0]: (AppleACPIPlatform) Wake reason: EH02
- 2018-02-24 15:57:30.572077+0100 localhost kernel[0]: (AppleACPIPlatform) Wake reason: EH02
- 2018-02-24 15:57:30.572080+0100 localhost kernel[0]: (AppleACPIPlatform) Wake reason: EH02
- 2018-02-24 15:58:29.420065+0100 localhost kernel[0]: (AppleACPIPlatform) Wake reason: EH02
- 2018-02-24 15:58:29.420068+0100 localhost kernel[0]: (AppleACPIPlatform) Wake reason: EH02
- 2018-02-24 15:59:29.567760+0100 localhost kernel[0]: (AppleACPIPlatform) Wake reason: EH02
- 2018-02-24 15:59:29.567763+0100 localhost kernel[0]: (AppleACPIPlatform) Wake reason: EH02
- 2018-02-24 16:00:29.377655+0100 localhost kernel[0]: (AppleACPIPlatform) Wake reason: EH02
- 2018-02-24 16:00:29.377659+0100 localhost kernel[0]: (AppleACPIPlatform) Wake reason: EH02
- 2018-02-24 16:01:29.584240+0100 localhost kernel[0]: (AppleACPIPlatform) Wake reason: EH02
- 2018-02-24 16:01:29.584243+0100 localhost kernel[0]: (AppleACPIPlatform) Wake reason: EH02
Ja, wie vermutet USB weckt ihn gleich zu Beginn wieder auf...
kann nur der Logitech Keyboard Dongle sein (den hatte der Rechner immer schon, auch zu Atheros Karte Zeiten), oder BT von der neuen BCM4352... BT läuft doch bei der Broadcom via USB, oder?
Und BT schalte ich schon vor dem Schlafengehen händisch aus (BT deaktivieren).Nachtrag 3:
Nachdem alternativ ich in Google Chrome den Schuldigen vermutet hatte (was macht der in IOReg bei den USB Geräten???), klammere ich dies von meiner Seite aus wieder aus. Hardwarebeschleunigung in Chrome war aus, und der Browser komplett geschlossen vor dem nächsten Sleep-Test.
Hier noch ein Screenshot aus IOReg nach dem Google Chrome Test...Ist es die Broadcom-Karte?
Wie löse ich das Problem? Hat jemand Ideen?
@al6042 _pwr Methode via DSDT für die Broadcom? Oder reime ich mir hier etwas zusammen? -
Hallo zusammen,
Nach einer kleine Google Orgie und meiner Vermutung, dass sich das Problem mit einer _PRW Methode fixen lässt, bin ich auf folgende Lösung gestoßen.
insanelymac - a guide on fixing sleep issues
Ich habe mich mit der Terminal log Ausgabe der Wake Reasons durch die störenden Geräte durchgehangelt
_PRW in der DSDT
Jeder Grund für das Aufwachen bzw. Unterbrechung des Sleep Mode ist ein Device Eintrag in _SB.PCI0
In meinem Fall am Beispiel EHC2:
Vorher:
Nachher:
Laut Autor von dem InsanelyMac posting, scheint es in einer unbehandelten DSDT falsche Werte für GPRW zu geben, die korrigiert werten sollten:
GPRW sollte immer die Werte 0x09 und 0x04 zurückgeben.
Ist dies nicht der Fall bedarf es einer Korrektur.Ich habe nach und nach alle Devices im Hinblick auf _PWR gefixt - jeweils nach einem Fix die DSDT getauscht und das log via Terminal kontrolliert.
Das Ergebnis: Der Sleep Mode läuft ohne Unterbrechung
Der Nachteil:
Über meine kabellosen Endgeräte (BT Tastatur, Apple Trackpad und Logitech AIO Tastatur mit eigenem Dongle) lässt sich der Rechner nicht mehr mit der Leertaste wecken.
Ein kurzer Druck auf den Power Button führt aber zum Erfolg (OHNE Reboot).Damit könnte ich bis zu einer alternativen Lösung erstmal leben.
Was sagen die Experten? Ist dies eine probate Lösung oder gibt es bessere Alternativen?
-
Entspricht eigentlich genau dem, was ich unter folgendem Post kurz erklärt habe:
Ruhezustand will nicht -
Wenn es so funktioniert und dich nicht weiter stört, ist das doch prima. Ich kenne ähnliche Patches von Rehabman, bei denen aber immer nur der zweite Wert (hier 0x04) geändert wird, meist in 0.
-
Was muss man machen um einen 8942, 6084, Object does not exist (DTGP) fehler weg zu bekommen wenn man den Wifi patch eingefügt hat bei mir auf RP11 !?
-
Die DTGP-Method (Sourceforge) einfügen.
-
danke hat super geklappt und wie bekommt man dies warnings alle weg ?
4270, 3115, Not all control paths return a value (CGLS)
-
Die warnings kannst du ignorieren.
-
Ja ok das weiß ich aber wie würde man sie weg bekommen ?
-
Bei "Not all control paths return a value" musst du in der betreffenden Methode einen "Return (Zero)" vor der letzten, schließenden, geschweiften Klammer der Methode einsetzen.
-
Warum willst du sie denn weg haben, wenn du weißt dass man sie ignorieren kann. Du könntest jede Warnung kopieren und mit der Suchmaschine deiner Wahl nach Lösungen suchen. Da wirst du fündig, aber bestimmt nicht bei allen.
-
Wegen der Sauberkeit halt Ordnung eben ..... aber die BCM4352 wird nicht erkannt ohne extra Kexte ....
sie liegt auf RP11 habe dann den Patch eingefügt habe ich was falsch gemacht ?
-
Wird die Karte im DPCI Manager -> "PCI LIst" Fenster angezeigt?
Wenn ja, mit welcher Vendor-/Device-ID?Poste bitte einen Screenshot vom ioRegistryExplorer -> IODeviceTree des "RP"-Devices, an dem du die entsprechende Vendor-/Device-ID als "name"-Eintrag ("pci14e4,xxxx") gefunden hast.
-
Hier mal alle Bilder das ist nur mit PCI Fake Kexten und Clover Patches so läuft sie.