Posts by Mieze

    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?

    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. Im Terminal erhalte ich mit


    sudo powermetrics --hide-cpu-duty-cycle |grep interrupt


    ca. 4000 Interrupts/sec im Idle-Modus und es ist nicht das Trackpad, sondern der I2C-Controller, der diese Last erzeugt, da die Interrupt-Rate selbst im Polling-Modus ähnlich hoch bleibt.

    Code
    1. Vector 0x50(IGPU/B0D4/XHC/I2C0/IMEI/SATA/RP09/PXSX/HDEF/SBUS): 4080.90 interrupts/sec

    Wie sieht das bei Euch aus? Könnt ihr dieses Ergebnis reproduzieren? Die entscheidende Frage in diesem Zusammenhang ist, ob hier ein Fehler in VoodooI2C.kext vorliegt, oder ob Interrupt-Sharing hierfür verantwortlich ist?


    Hat wirklich niemand mal nachgeschaut? :bitte:

    Ich hatte mir noch mal eine BCM94350ZAE für Lenovo zum Preis von ca. 13€ bestellt. Leider zeigt sie das gleiche Verhalten wie die DW1820A. Wahrscheinlich trifft dies auf alle billigen WLAN-Module mit BCM94350ZAE zu, da so ein 32kHz Präzisions-Oszillator als Bauteil in Relation zum Gesamtpreis des Moduls ziemlich teuer ist (ein paar €) und es wundert mich nicht, dass die Hersteller dort den Rotstift ansetzen. Hier noch ein paar Fotos, um zu verdeutlichen, um welche Karte es sich handelt.

    Nachdem ich gestern 10.14.4 installiert habe, wacht das Notebook ständig aus dem Ruhezustand auf. Vorher gab es keine Probleme mit dem Ruhezustand. Auch auf meinem Desktop gibt es Probleme, da der Lüfter der RX570 alle paar Minuten kurz aufheult. Mir scheint Apple hat in 10.14.4 das Power Management vergeiget!

    Falls das Erneuern des Kext Caches nicht hilft, dann versuche auch mal den System-Cache zu löschen und anschließend den Kernel Cache zu erneuern. Das beseitigt Probleme, die daraus resultieren, dass Erweiterungen nicht richtig gelinkt wurden, weil der Linker mit veralteten Informationen arbeitet.

    Ich habe noch mal weiter recherchiert und kann jetzt bestätigen, dass es sich um ein Hardwareproblem handelt. Von Broadcom gibt es leider keine Datenblätter zu den WLAN-Chips, aber da einige der Chip-Designs an Cypress verkauft wurden, konnte ich dort ein Datenblatt vom BCM4356, welcher zur gleichen Familie gehört, finden. Auf Seite 17 steht dort:

    Quote

    3.3 External 32.768kHz Low-Power Oscillator

    The CYW4356/CG8674 uses a secondary low-frequency clock for Low-Power mode timing. Either the internal low- precision LPO or an external 32.768 kHz precision oscillator is required. The internal LPO frequency range is approximately 33 kHz (± 30%) over process, voltage, and temperature, which is adequate for some applications. However, one trade-off caused by this wide LPO tolerance is a small current consumption increase during power save mode that is incurred by the need to wake up earlier to avoid missing beacons.

    Offensichtlich wurde bei der DW1820A aus Kostengründen der 32kHz Oszillator eingespart und da AirportBrcmNIC.kext dafür ausgelegt ist, den Chip mit externem Oszillator zu betreiben, kann es nicht funktionieren, weil der Takt fehlt. Theoretisch könnte man versuchen, den Treiber zu patchen, damit er den internen Oszillator verwendet, aber dass dürfte sich in der Praxis als äußerst schwierig erweisen. :(


    Um AirportBrcmNIC.kext nutzen zu können, muss man eine Karte mit 32kHz-Oszillator finden.

    Im Normalbetrieb hatte ich auch keine Probleme, nur mit Blackmagic Diskspeed Test, aber da die Verbindung hierbei komplett ausgelastet wird, hat sich dieses Szenario in der Vergangenheit als guter Stabilitätsindikator für Treiber bewährt.


    PS: Ich werde mir wohl aus Neugier mal eine BCM94350ZAE für Lenovo bestellen und schauen, ob die OOB funktioniert. Leider dauert der Versand aus China mehrere Wochen.

    In der letzten Woche habe ich endlich Zeit gefunden, um mich intensiv mit der DW1820A zu beschäftigen. Da es einen quelloffenen Linux-Treiber für die Broadcom-Chips gibt, bin ich ähnlich vorgegangen, wie damals bei dem Radeon-Patch, d.h. ich habe mich zunächst mal in die Funktionsweise des Chips eingearbeitet, um dann einen Register-Dump durchzuführen. Auf AirportBrcmFixup.kext habe ich dabei bewußt verzichtet. Leider ist es mir bisher noch nicht gelungen, die DW1820A mit der AirPortBrcmNIC.kext zum Laufen zu bekommen. Hier eine kurze Zusammenfassung dessen, was ich bereits herausgefunden habe.

    • Die Kernel Panic beim Start resultiert daraus, dass ein bestimmter Takt nicht läuft und der Chip beim Messen der Taktfrequenz den Wert 0 ermittelt. Bei einer anschließenden Berechnung wird dann durch diesen Wert geteilt, was natürlich zu der besagten KP führt. Dieses Problem lässt sich durch Anschalten des Taktes mittels eines DSDT-Patches relativ leicht lösen.
    • Insgesamt scheint die Takterzeugung bei der DW1820A der Grund zu sein, warum die Karte nicht läuft und ich bin mit nicht sicher, ob es sich hierbei um ein Hardware- oder Softwareproblem handelt, d.h. ob es mit vertretbarem Aufwand lösbar ist oder nicht. Die Probleme mit dem Takt verursachen auch, dass der Treiber permanent hängt, weil der Chip nicht richtig arbeitet, so dass er den ganzen Rechner lahmlegt.
    • Für ein Hardwareproblem spricht auch die Tatsache, dass User mit Karten von Lenovo, so wie hier https://www.insanelymac.com/fo…ut-bluetooth-cannot-work/, offenbar keine Probleme haben und der Chip bei ihnen OOB arbeitet. Da Notebooks von Dell keine Whitelist für WLAN-Module haben, wäre es evtl. mal einen Versuch wert, eine BCM94350ZAE für Lenovo-Geräte zu testen?

    Ich habe die DW1820A gestern eingebaut und erste Tests durchgeführt. Die Karte ans Laufen zu bringen ist tatsächlich ziemlich frickelig. Mit dem AirPortBrcm4360.kext kann man die Karte betreiben, aber sie Kombination ist unter Last nicht stabil. Ich hatte bei einem Test mit Blackmagic Disk Speed Test über AFP plötzlich die WLAN-Verbindung verloren, so dass ich neu starten musste, um wieder WLAN zu bekommen. Was den Durchsatz betrifft, liegt die DW1820A auf jeden Fall vor der DW1560. Mit dem AirPortBrcmNIC.kext, welcher die Karte OOB unterstützt, hängt der Rechner beim Booten, da der Chip nicht richtig erkannt wird, aber dieses Problem lässt sich evtl. mit einem Clover-Patch beheben. Ich bleibe auf jeden Fall dran.

    Harper Lewis : Ich habe meine DSDT noch mal mit Deiner verglichen und bin auf folgende Methoden gestoßen, die in Deiner DSDT nicht vorhanden sind, und habe ausprobiert, was passiert, wenn ich sie entferne. Ich bin mir nicht ganz sicher, wozu diese Methoden dienen, aber sie haben definitiv mit PM zu tun und scheinen den Unterschied zu machen, denn ohne sie ist das Trackpad nach dem Aufwachen tot. Werde wohl mal genauer nachforschen müssen, was da passiert.

    PS: Ich habe heute überraschenderweise schon die DW1820A bekommen und werde sie nachher einbauen.

    Harper Lewis : Sorry wegen der verspäteten Antwort, aber ich musste erst dieses verflixte Seminar an der Uni hinter mich bringen. Wo hast Du die Kernel Extensions installiert? Bei mir hat es erst funktioniert, nachdem ich VoodooI2C.kext, VoodooI2CHID.kext und VoodooGPIO.kext in der EFI-Partition installiert hatte, VoodooPS2Controller. kext hingegen in /L/E. Mit VoodooPS2Controller. kext in der EFI funktionierte das Trackpad nach dem Aufwachen ebenfalls nicht mehr , außerdem gab es beim Boot regelmäßig KPs. Achte auch darauf, dass Du die PlugIns für Maus und Trackpad aus VoodooPS2Controller. kext entfernt hast.

    Ich habe den Dell Inspiron 5370. Beim Betrachten deiner DSDT fällt mir auf, dass sich bei mir macOS als die aktuelle Version von Windows 10 ausgibt. Welche Version hast Du denn gewählt?

    Code
    1. If (_OSI ("Windows 2017"))
    2. {
    3. Store (0x07E1, OSYS)
    4. }
    5. If (_OSI ("Darwin"))
    6. {
    7. Store (0x07E1, OSYS)
    8. }

    Das könnte evtl. auch ein möglicher Grund für den Unterschied sein.

    Harper Lewis Anbei meine DSDT. Vergleiche mal die Devices GPI0 und TPD0 in deiner und meiner DSDT. Evtl. findet sich dort ein Unterschied, denn ich habe die beiden Geräte bearbeitet.


    Auf jeden Fall gibt es hier einen klaren Unterschied zu meinen Logs, da dort 0xffffff anstatt 0xfffff7 angezeigt wird.

    Code
    1. 2019-02-15 18:32:11.561183+0100 0x22b1 Default 0x0 0 0 kernel: (kernel) VoodooGPIOSunrisePointLP:: Register 0x<private> = 0xfffff7

    So, sieht aus als habe ich die Lösung für beide Probleme gefunden, keine Kernel Panic beim Booten und das Trackpad funktioniert ebenfalls nach dem Aufwachen mit GPIO-Interrupt. Jedenfalls hat es bisher mehrere Sleep-/Wake-Zyklen überlebt. Hier eine kurze Zusammenfassung, was ich gemacht habe:

    1. In der grub-Shell mit "setup_var 0x272 0x0" auf GPIO-Interrupt umgeschaltet.
    2. VoodooPS2Controller.kext nach /L/E installiert.
    3. Bei VoodooGPIO.kext eine Zeile zur Ausgabe des Registers, welches den Modus des Pins enthält hinzugefügt. Eigentlich wollte ich damit nur ein paar Informationen sammeln und die Änderung dürfte keinen Einfluss haben, aber ja, manchmal erzeugen Compiler ja auch fehlerhaften Code. Ich würde mich jedenfalls nicht wundern, wenn es auch mit der normalen Version der Kext funktioniert. Zur Unterscheidung hat meine Kext die Version 1.1.5.
    4. VoodooGPIO.kext, VooddoI2C.kext und VooddoI2CHID.kext in die EFI-Partition installiert.
    5. Reboot

    Jetzt sollte das Trackpad auch nach dem Aufwachen noch funktionieren.

    Ich hatte mich gestern mal mit dem Problem von VoodooI2C nach dem Aufwachen im GPIO-Interrupt-Modus beschäftigt und bin der Ursache auf den Grund gegangen. Das Problem liegt offensichtlich in VoodooGPIO.kext begründet und hängt mit der Initialisierung zusammen. Beim Laden der Kext findet sie den GPIO-Controller bereits vollständig initialisiert vor, so dass die Initialisierung übersprungen wird. Das Trackpad funktioniert dann wie erwartet, aber nach dem Aufwachen aus dem Ruhezustand ist diese Konfiguration verloren, so dass der Treiber den GPIO-Controller neu initialisieren muss, was leider scheitert. Die Pins können in zwei unterschiedlichen Modi betrieben werden, dem ACPI-Modus, in welchem sie zum Erzeugen von GPE-Events benutzt werden, aber keine Interrupts generieren können, und dem GPIO-Modus, in dem der Treiber volle Kontrolle über die Pins hat, so dass sie als Interrupt Source genutzt werden können. Das Problem ist nun, dass VoodooGPIO.kext den Pin 0x1B nach dem Aufwachen im ACPI-Modus vorfindet und die Initialisierung scheitert. Theoretisch sollte es möglich sein, VoodooGPIO.kext so zu modifizieren, dass es es den Pin bei der Initialisierung nach dem Aufwachen wieder in den GPIO-Modus versetzt. Das Problem scheint also grundsätzlich lösbar zu sein, jedoch muss ich mich hier erst mal mit der Dokumentation des GPIO-Controllers befassen, um herauszufinden, wie es geht. Da ich mich zur Zeit aber mitten in der Klausurphase befinde und mit dem Studium ausgelastet bin, wird es wohl noch ein bisschen dauern, bis ich mich darum kümmern kann. Auf jeden Fall bleibe ich dran!


    Ein anderes Problem ist, dass VoodooPS2Controller beim Booten des Öfteren eine Kernel Panic verursacht, wenn VoodooI2C installiert ist, auch wenn sich nur VoodooPS2Keyboard.kext im Ordner Plugins befindet. Habt ihr dafür schon eine Lösung gefunden?


    PS: Sobald ich die DW1820A bekommen habe, werde ich hier einen Bericht schreiben, wie sich die Karte im Betrieb macht.

    Ich nutze ebenfalls die DW1560 (ca. 25€ incl. Versand per AliExpress) mit AirportBrcmFixup.kext, habe aber bereits eine DW1820A bestellt, da sie mechanisch besser passen sollte (Position der Antennenanschlüsse, beide rechts von der Schraube, so dass man den Metallbügel, welche die Antennenstecker sichert weiterverwenden kann, bei der DW1560 muss man darauf verzichten), darüber hinaus auch noch preiswerter (ca. 12€ incl. Versand per AliExpress) ist und schneller sein soll. Neben AirportBrcmFixup.kext wird unter Mojave lediglich ein DSDT-Patch benötigt, damit der passende Treiber geladen wird.


    Leider werde ich die DW1820A erst Ende März bekommen, da sich der Versand wegen dem chinesischen Neujahrsfest verzögert.

    Edit by al6042 -> Bitte keine Vollzitate von Beiträgen, welche direkt über deiner Antwort stehen...

    Das Problem hatte ich auch und musste letztendlich den Defender temporär deaktivieren, um das BIOS extrahieren zu können. Da mich die Warnung des Defenders misstrauisch gemacht hatte, habe ich sicherheitshalber mal das Universal BIOS Backup Toolkit 2.0 bei VirusTotal hochgeladen, um das Risiko abzuschätzen. Viele Scanner stufen es als potenziell gefährlich ein, was aber bei einem solchen Utility nicht ungewöhnlich ist, aber es gab auch zahlreiche Scanner, die nichts zu beanstanden hatten. Von daher erschien mir das Risiko vertretbar.