Dell inspiron 5370

  • 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?

    iMacPro1,1: Fractal Define R6 - ASUS SAGE X299 - i9 10900X 3,7Ghz - 32 GB - Sapphire RX 5700 XT Pulse 8GB - NVMe SSD 960 EVO 1 TB - BCM943602CS Combo Karte - Sonnet Solo 10G AQC-107 - Titan Ridge TB3 - macOS 11.7 - OpenCore 084

    Proxmox: G5-Casemod - GA Z270-HD3P - i7 7700k 4,2Ghz - 16 GB - iGPU - GT 730 - NVMe SSD 1TB - VM1: Monterey - VM2: Windows 10 - VM3: Mannaro VM4: Unraid

    Mac Mini Studio: 32 GB - 512 GB SSD - CalDigit TS3 Plus Station - Terramaster D2 TB3 Raid

  • 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.

    Einmal editiert, zuletzt von Harper Lewis ()

  • 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. :thumbup:

  • 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.

    Code
    1. BrcmPatchRAM2: [0a5c:216f]: END OF RECORD complete (status: 0x00, length: 4 bytes).

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

    Code
    1. BrcmPatchRAM2: [0a5c:216f]: Unknown event code (0xff).

    Einige Zeit später folgt dann eine weitere Nachricht.

    Code
    1. BrcmPatchRAM2: [0a5c:216f]: Number of completed packets.

    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.

    Code
    1. BrcmPatchRAM2: [0a5c:216f]: RESET complete (status: 0x00, length: 4 bytes).

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

    Code
    1. BrcmPatchRAM2: [0a5c:216f]: Not responding - Delaying next read.

    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. 8)

    2 Mal editiert, zuletzt von Mieze ()

  • 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. :thumbup::thumbup::thumbup:



    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 :wallbash:

  • 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.

  • 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