Ich schaue (spätestens am Wochenende) mal nach, was mein Vostro 5370 dazu sagt.

Bei mir sind das so zwischen 400 und maximal 2200 Interrupts/s.

Hallo,

ich wollte mal in die Runde fragen, welche SSD Ihr in Eurem Inspiron/Vostro 5370 habt und ob es ein Modell mit NVMe- oder AHCI-Schnittstelle ist?

Mieze

zurzeit löppt in meinem Inspiron 5370 noch die originale SSD...!

Möchte die aber über kurz oder lang durch diese hier ersetzen:

Crucial P1 500GB 3D NAND NVMe PCIe M.2 SSD

Oder gibt es da etwas besseres?

Zitat von Mieze

Bei meinen Experimenten mit VoodooI2C ist mir aufgefallen, dass seit 10.14.4 das Trackpad auch mit dem APIC-Interrupt 0x33 genutzt werden kann. Offensichtlich hat Apple das Interrupt-Management überarbeitet. Das Umschalten auf den GPIO-Interrupt kann man sich also prinzipiell sparen.

Ich habe in der UEFI-Shell mal testweise auf APIC-Interrupt umgestellt. Wenn ich dann macOS starte, läuft VoodoI2C wieder im Pollingmodus. Habe ich etwas übersehen?

Nachtrag: Die verbaute SSD habe ich durch eine größere ersetzt, es handelt sich um eine mit AHCI-Schnittstelle.

Harper Lewis

Ich habe es heute noch mal mit 10.14.6 probiert und bekomme das Trackpad auch nicht mehr mit APIC-Interrupt zum Laufen. Leider kann ich die Log-Dateien von damals nicht mehr finden und da ich seit dem letzten Versuch mit VoodooI2C neben einer neuen System Definition und dem macOS-Update auch noch ein BIOS-Update durchgeführt und an der DSDT gearbeitet habe, kann ich nicht mehr nachvollziehen, wie ich zu diesem Ergebnis gekommen bin. Ich kann mich nur erinnern, dass plötzlich der Log-Eintrag, dass das Trackpad im Polling-Modus läuft, nicht mehr auftauchte, obwohl ich die Setup-Variable auf APIC-Interrupt zurückgestellt hatte. Da ich ziemlich verblüfft war, habe ich natürlich alles genau überprüft, trotzdem kann ich einen Irrtum auch nicht ausschließen, weil ich die Log-Dateien eben nicht mehr habe.

Letztendlich habe ich es versäumt Notizen zu machen, da das Ergebnis im Endeffekt wertlos ist. Wegen des shared Interrupts erzeugt VoodooI2C eine viel zu hohe Interruptrate und hat verheerende Auswirkungen auf das CPU-Powermanagement hat. Sorry!

Ich vermute, dass die NVMe-SSD die Ursache der Probleme ist, aber ich möchte sie auch nicht gegen ein SATA-Modell tauschen. Von daher werde ich wohl mit VooddoPS2 für das Trackpad Vorlieb nehmen müssen.

Hallo Mieze ,

besten Dank für die Rückmeldung. Ich hatte gar nicht mitbekommen, dass es ein BIOS-Update gibt. Hat sich im Vergleich zur Vorversion etwas geändert, oder lässt sich immer noch via 0x272 von APIC auf GPIO umschalten?

Harper Lewis

Soweit ich das beurteilen kann, hat sich an den Einstellungen nichts geändert, selbst die Änderungen bei den Setup-Variablen, die ich unter 1.10 vorgenommen hatte, sind erhalten geblieben, so dass ich nach dem Update nichts machen musste.

Zur Sicherheit habe ich trotzdem das BIOS extrahiert. Anbei die Datei mit den Setup-Variablen von 1.12.

Vielen Dank, das sieht gut aus.

Ich wollte mal fragen, wer mit BrcmPatchRAM2.kext auch noch Probleme beim Aufwachen aus dem Ruhezustand hat? Bei mir verabschiedete sich Bluetooth mit der DW1560 trotz einem Wert von 400 für bpr_preresetdelay des Öfteren beim Aufwachen und deshalb bin ich der Sache mal auf den Grund gegangen.

Nach dem Download der Firmware bestätigt der Bluetooth-Controller den Empfang der Firmware mit folgender Nachricht.

Kurz darauf sendet er eine weitere Nachricht, bei der es sich um einen "vendor specific event" handelt.

Einige Zeit später folgt dann eine weitere Nachricht.

BrcmPatchRAM2.kext wartet nach dem Download der Firmware noch einige Millisekunden (wie lange wird durch bpr_preresetdelay festgelegt) und löst dann einen Reset des Bluetooth-Controllers aus, um die Firmware zu starten. Der erfolgreiche Reset wird von Controller durch eine weitere Nachricht bestätigt.

Scheitert der Reset hingegen, erhält man folgende Nachricht und Bluetooth ist danach tot.

Mir ist dabei aufgefallen, dass Bluetooth immer dann stirbt, wenn der Reset vor dem "vendor specific event" ausgelöst wird, bzw. gelegentlich auch dann falls er nach der Nachricht "Number of completed packets" durchgeführt wird. Offensichtlich gibt es hier einen Handshake-Mechanismus und der "vendor specific event" signalisiert die Bereitschaft zum Reset.

Ich habe daher BrcmPatchRAM2.kext so modifiziert, dass es den Reset erst nach dem Event auslöst und seitdem auch keine Probleme mehr beim Aufwachen. bpr_preresetdelay wird in meiner modifizierten Version weiterhin verwendet (als Verzögerung nach dem "vendor specific event" bis zum Reset), aber ich konnte den Wert auf 20 reduzieren, ohne dass es Probleme gibt.

Habt Ihr ähnliche Log-Einträge bei Euch beobachtet, wenn Ihr die Debug-Version von BrcmPatchRAM2.kext verwendet?

PS: Den Sourcecode habe ich bereits auf GitHub bereitgestellt.

Hallo Mieze . Hattest du die Probeme mit BrcmPtachRAM2 auch mit dem Fork von headkaze?

Harper Lewis

Nein, ich hatte das Problem mit Rehabmans Fork, aber headkazes Fork habe ich mir auch angesehen (wegen der Anpassung an Catalina) und der ist auch nicht wesentlich anders.

Hier eine Übersicht meiner Änderungen auf GitHub: https://github.com/Mieze/OS-X-…31cb59737d128ff2870d8baa7

Ich habe jetzt auch mal headkaze's Fork überarbeitet und dazu einen Beitrag auf IM verfasst:

https://www.insanelymac.com/fo…=comments#comment-2692431

Falls jemand Interesse hat, kann er gerne auch schon mal Testen. Den Sourcecode gibt's wie üblich auf GitHub:

https://github.com/Mieze/OS-X-BrcmPatchRAM-Catalina

Binaries für Mojave und Catalina findet Ihr unten als Anhang. Zu beachten ist eigentlich nur, dass meine Version jetzt BrcmPatchRAM3.kext heißt, weil ich die ganze Architektur überarbeitet habe.

Also dann noch viel Erfolg beim Testen und "Miau" von der Mieze!

Hallo Mieze ,

unter Catalina funktioniert dein Kext super. Danke schon mal dafür.

Ist das so gedacht das dein Paket nur unter Catalina funktioniert? Weil unter Mojave möchte der Kext nicht laden, auch nicht wenn ich den BrcmPatchRAM2.kext verwende.

>> Oben steht auch für Mojave

anonymous_writer Wie im Beitrag auf IM beschrieben, habe ich meine Tests auf dem Inspiron unter Mojave (10.14.6) mit BrcmPatchRAM3.kext, BrcmFirmwareRepo.kext und BrcmBluetoothInjector.kext in /L/E durchgeführt. Compiliert habe ich sie mit Xcode 10.3, deployment target 10.14 und dem SDK 10.14.

Was bekommst Du denn, wenn Du versuchst, die kext im Terminal mit "kextuil -v 5 BrcmPatchRAM3.kext," zu laden?

Hallo Mieze ,

Bin gerade unterwegs und kann es daher nicht Testen. Mache ich aber sicher später und schreibe dann nochmal.

Hallo Mieze ,

Ich bin überhaupt kein Fan vom installieren von Kexten im System. Konnte ich bisher mit Clover als auch OC erfolgreich vermeiden.

Da kommt so einiges beim laden des Kext.

Bei mir lädt BrcmPatchRAM3.kext auch unter 10.14.6. Sieht so weit auch alles gut aus. Ist BrcmBluetoothInjector.kext noch ohne die anderen Kexts zu verwenden oder ist die Beschreibung da nicht (mehr) korrekt?

Zitat

BrcmBluetoothInjector.kext

To be used for OS X 10.11 or newer.

This kext is a simple injector... it does not contain a firmware uploader. Try this kext if you wish to see if your device will work without a firmware uploader.

Do not use any of the other kexts (BrcmPatchRAM, BrcmPatchRAM2, BrcmFirmwareRepo, or BrcmFirmwareData) with this kext.

Ich habe bisher immer BcmPatchRAM2, BrcmFirmwareData und eine Injector-Kext benutzt, die als Treiber BroadcomBluetooth20703USBTransport und nicht BroadcomBluetoothHostControllerUSBTransport lädt.

Zitat von Harper Lewis

Bei mir lädt BrcmPatchRAM3.kext auch unter 10.14.6. Sieht so weit auch alles gut aus. Ist BrcmBluetoothInjector.kext noch ohne die anderen Kexts zu verwenden oder ist die Beschreibung da nicht (mehr) korrekt?

Grundsätzlich lässt sich BrcmBluetoothInjector.kext weiterhin ohne die anderen Kexts verwenden. Der einzige Grund, warum diese Kext jetzt gebraucht wird, ist die Tatsache, dass Apple einige Funktionen aus dem Framework entfernt hat, welche BrcmPatchRAM2.kext benötigt, um den Bluetooth Controller in IORegistry einzutragen. Diese Aufgabe wird jetzt von BrcmBluetoothInjector.kext erledigt.

anonymous_writer Das deployment target für BrcmFirmwareData.kext war auf 10.9 gesetzt, das von BrcmPatchRAM3.kext hingegen auf 10.14. Daher der Fehler beim Laden.

Danke Mieze ,

ich teste das dann nochmal sobald Catalina auf dem Laptop installiert ist. Wird wohl eher Morgen da hier aktuell steht 2 Stunden 30 Minuten.

Ich würde deinen Kext dann hier aufnehmen wenn du nichts dagegen hast.

Broadcom Bluetooth Firmware Patcher