Beiträge von Mieze

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.

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,

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 I²C-Controller, der diese Last erzeugt, da die Interrupt-Rate selbst im Polling-Modus ähnlich hoch bleibt.

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?

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.

fabz Es würde mich nicht wundern, wenn Du eine defekte Karte erwischt hättest, jedenfalls wärest Du nicht der erste Benutzer, der eine defekte Karte erhalten hat. Auf insanelymac.com finden sich schon einige Beschwerden über die Sonnet-Karte:

https://www.insanelymac.com/fo…ort-in-high-sierra-10132/

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:

Zitat

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.

Zitat von anonymous writer

Bei Verwendung des AirPort.Brcm4360 läuft WLAN 1A.

Ich hatte mit diesem Treiber bei meinem Standardtest für Netzwerktreiber (Blackmagic Diskspeed Test über AFP) einen Verbindungsabbruch, der sich nur durch einen Neustart beheben lies. Es scheint also nicht wirklich stabil zu funktionieren.

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?

Zitat von DSM2

Durchaus möglich das der Patch von Mieze auch hier ausreicht.

Leider nein, denn auch mit dem Patch muss die Karte vorher mit der Apple Firmware geflashed werden, damit sie vom Treiber akzeptiert wird.

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?

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.

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.