Beiträge von segelfreak

Zitat von pstr

Es ging hier um Anomalien des z390 Gigabyte wo durch manuelles Einstellen der Taktrate anstelle Verwendung eines XMP Profils die Probleme "behoben" sind.

Was da genau die Ursache ist weiss bis dato scheinbar niemand.

Du hast offensichtlich ein ganz anderes Mainboard, das kannst Du somit nicht portieren.

Ich denke nicht, dass es sich "nur" auf z390 Chipsätze beschränkt. Ich habe hier in z370 und nach dem Upgrade auf Monterey lief meine T919 (CM_20702B0 v150 c9317) zunächst wie ein Bund Wurzeln. Ich hatte massives "Stuttering" bei der Magic Mouse, Sleep ging gar nicht mehr und die Wakes liefen auch in die falsche Richtung.

Nachdem ich das Stuttering und Sleep durch aktivieren von L0s+L1 ASPM für den USB Controller in den Griff bekommen habe, blieb noch das Problem mit dem Bluetooth-Absturz nach dem Wake. Zwar liess sich die Dose der Tastendruck und/oder Klick aufwecken, da aber dann der Daemon abstürzt, erfolgt danach keine weitere Eingabe (via Magic Mouse / Keyboard) und das System legt sich wieder schlafen und zwar bevor der Daemon vom OS wieder neu gestartet wird. Dieser Kreislauf lies sich eigentlich nur durch Nutzung einer USB Maus/Tastatur durchbrechen. Dann dauerte es ein paar Minuten und auch Bluetooth war wieder da.

Mein RAM lief bisher mit 3200 im XMP "Auto"-Mode. Nachdem ich jetzt versuchsweise ebenfalls manuell auf 2666 eingestellt habe, klappt das Aufwecken problemlos, inkl. Anmeldung durch die Apple Watch.

Was ich noch nicht probiert habe ist, ob manuell eingestellte höhere Taktzahlen (also nicht über XMP) dann wieder zu bluetooth Abstürzen führt. Ich werde das mal in kleine Schritten testen, also zunächst via 2700, u.s.w. Oder hat das schon jemand durchprobiert? (dann könnte ich mir die Mühe sparen)

Edit 1: Ich hab übrigens keine weiteren Bluetooth oder USB Kext's drin. Nur ein paar aml's (AWAC, EC-USBX, EC, HPET, PMC)

Aluveitie ja ich hab mich auch erstmal am Kopf gekratzt.... es macht eigentlich keinen Sinn. Ich muss das weiter testen, zumal es auch keine Fehlermeldung gibt, mit aktivierten Kexten. Ich kann die Funktion deaktivieren, aktivieren, nur beim Aufwecken erfolgt eben keine Anmeldung. Jetzt, mit deaktivierten Kexten, schon.

Vielleicht findet sich jemand, der das verifizieren kann?

Moin zusammen!

Ich bin noch dabei es einzugrenzen, aber kann es sein, dass die beiden Kexte (oder einer davon) die Entsperrung via Apple Watch killed?

Klingt weit her geholt, aber nachdem ich die beiden installiert hatte, ging mir die Entsperrung verloren. Ich habe das zuerst nicht miteinander in Zusammenhang gebracht, aber jetzt habe ich sie einfach mal deaktiviert und siehe da, die Anmeldung klappt wieder.

Hat jemand ähnliche Erfahrung gemacht?

Läuft mit iStat, iMacPro1,1 5700XT und der Reihenfolge wie von cmoers vorgeschlagen.

Danke erstmal für die Unterstützung!

Ich werde die beiden Darkmode bootargs durchspielen. Interessanterweise ist es so, dass bei einem kurzen sleep alles ok zu sein scheint. Erst wenn die Kiste die Nacht über Ruhe hatte, gibt's scheinbar die Probleme mit dem aufwachen.

Mglw. hat das damit zu tun, wie lange der Zustand anhält und ggf. ein anderer State aktiviert wurde?

Jedenfalls habe ich gerade "mal wieder" einen kurzen Sleep angestossen und der Hack ist sofort wieder aufgewacht. Ich dachte mir dann, warte mal ab, bis er wieder einschläft. Vielleicht bleibt er dann ruhig. aber leider wachte er auch danach sofort wieder auf.

Hier die Logdaten dazu:

Erste mal wake due to XDCI, dann gewartet bis der "Maintenance Sleep" aktiviert wurde. auch da instant Wake wegen XDCI.

Nachdem ich ihn dann ganz aufgeweckt habe und dann nochmals sleep angestossen habe, blieb's ruhig...

Wake Reason ist in beiden Fällen gleich, ich nehme also an, dass da evtl. doch die Maus zuckt...

Da muss ich also weiter suchen/probieren und den Übeltäter versuchen zu isolieren.

Edit 1:

Darkwake = 2 funktioniert leider nicht

Bluetooth war inaktiv, erst mit eingesteckter USB Maus lies sich das System richtig aufwecken. Denke Bluetooth war weg, kam erst nach einer gewissen Zeit wieder.

Log:

System Log: (im Anhang)

Probiere jetzt darkwake = 514...

Edit 2:

Leider erstmal Instant Wake bei ersten Sleep Versuch nach dem Neustart...

Beim zweiten Versuch klappt's dann wieder...

Edit 3:

5T33Z0 übrigens... Mit der ASPM L0s + L1 ist offenbar ein weiteres Problem "verschwunden". Ich hatte bisher immer ein kleines Ruckel-Probleme mit der Maus, führte das auf die unglückliche Positionierung des PC's unter dem Tisch zurück, weshalb dann das Bluetooth Signal womöglich sehr schwach sein könnte. Das hat sich jetzt erledigt. Läuft...

Und schließlich Edit 4: alles läuft, wie es aussieht.
Wake up nach einer durchgeschlafenen Nacht, klappt. L0s+L1 in Kombination mit darkwake=514. Perfekt.

Moin zusammen!

Tolles Projekt, danke dafür !!!

Kleiner Wasserstandsbericht nach meinem Test:

iMacPro1,1 mit 5700XT zeigt mir nur im Gadget die Temp an. Weder Macs Fan, HWMonitor oder iStat geben einen Wert aus, leider..

Bin aber auch mit der VirtualSMC unterwegs...

Mit L0s/L1 ist er über Nacht wohl aus geblieben, allerdings klappte das Aufwecken nicht so wie erhofft.

Ein Druck auf die Tastatur hat den Rechner aufgeweckt, aber der Bildschirm blieb schwarz. Da half auch mehrfaches Drücken und/oder Mausklicken nix. Der Hack schlief dann kurz danach wieder ein, was wohl normal ist, wenn man sich nicht anmeldet. (Auch das Entsperren via Apple Watch klappte an der Stelle nicht)
Erst als ich eine USB Tastatur angeschlossen hatte, verlief das Aufwachen vollständig und auch die Entsperrung via Apple Watch klappte sofort. Danach waren auch die Magic Mouse und Keyboard aktiv.

Für mich sieht es so aus, als ob zwar das Weck-Signal kommt, Bluetooth aber nicht aktiviert wird und somit auch keine Eingaben zur Anmeldung/Entsperrung durchkommen.

Ich habe jetzt mal auf L1 umgestellt und werden es weiter beobachten.

Kann man da in den Logs nach verdächtigen Einträgen suchen? (Wenn ja welche?)

p.s. lese gerade im Sammelthread, dass es wohl "a common Problem" ist... da will ich hier nicht unnötig den Thread verlängern. Scheinen die gleichen Symptome zu sein. Ggf. versuche ich es einmal mit einem clean install auf einer neuen SSD:

Vorhin ist er, direkt nach einem Neustart, allerdings zunächst wieder aufgewacht. Beim zweiten Versuch war dann Ruhe…

Werde weiter „testen“.

5T33Z0 Danke! Das ist seit "Jahren" der erste konkrete Hinweis, in welche Richtung ich laufen könnte!

Ich hab fix in Hackintool nachgeschaut und der Controller ist mit ASPM "disabled" gelistet.

Ab der Stelle begebe ich mich auf neues Terrain....

Wenn ich den Link richtig lese, dann muss ich den ASPM Mode sowohl für das PCIe Device (also en USB Controller) und auch für das Sub-Device per Device-Property Injektion aktivieren.

Der Controller liegt bei mir unter: PciRoot(0x0)/Pci(0x14,0x0)

Ich finde aber keinen Eintrag für den bluetooth Controller (vermutlich weil er über USB angebunden ist?)

Der (BCM4360) Wifi Adapter ist unter PciRoot(0x0)/Pci(0x1C,0x7)/Pci(0x0,0x0), sollte aber hierfür keine Rolle spielen?

Wenn ich es also richtig verstehe, muss ich

mit aufnehmen, wobei das dem L1 Modus entspricht.

Reicht es das über opencore einzuspielen, oder muss es über einen SSDT laufen?

Und: Ist L1 der korrekte Modus oder muss ich die brute-force "durchspielen"?

Ich habe einmal meine aktuellen Port mapping Dateien angehängt.

Edit:

So, das war schon mal ein Volltreffer!

Ich habe beide Modi ausprobiert, d.h. zuerst L1 und dann L0s/L1. Diese wurden auch jeweils im Hackintool korrekt für den USB Controller angezeigt.

Und was soll ich sagen... in beiden Fällen blieb die Kiste diesmal ruhig.

Ich hab's jetzt auf L0s/L1 belassen, scheint mir die bessere Option zu sein.

Tatsächlich scheint mir das Magic Keyboard in beiden Modi etwas "träger" aufzuwachen, aber das ist zu verschmerzen und vielleicht ist das auch nur "subjektiv", egal.

Ich werde das die kommenden Tage mal durchtesten, aber soweit sieht es sehr gut aus!

Danke nochmal für den Tipp!!!!

Ach je… ich will ehrlich sein: Nein, habe ich nicht!!! möglicherweise ist es zu klein. Oder zu groß. Oder ich bin Banner blind?

Mist.

Aber… zur Ehrenrettung: dass die Magic Mouse den Hack aufweckt ist kein spezifisches Monterey Problem, sondern war auch unter Big Sur und den vorherigen Versionen schon ein Problem. Nur konnte man da mit einem simplen Klick Abhilfe schaffen.
Mir geht’s insofern auch darum, das eigentliche Problem zu lösen.

Warum weckt eine Apple Magic Mouse die Kiste auf?

(Hoffe die Ausrede zählt!?)

Moin zusammen! Ich brauche einmal eure Hilfe, bitte. Ich habe hier folgendes Setup: Gigabyte z370 ultra gaming mit einer Fenvi T919 Karte drin. Die USB Ports sind gemappt und die Karte ist als "internal" eingestellt. Der Controller wird in bioreg auch als built-in angezeigt. Von der Seite aus sollte eigentlich alles i.O. sein, oder? ich habe nur eine Magic Mouse und ein Magic Keyboard dran hängen, sonst nichts.

Wenn ich das Teil in den Ruhezustand schicke, wacht der Hack direkt nach dem Sleep wieder auf.
Das Log gibt mir folgenden Grund an: "DarkWake to FullWake from Normal Sleep [CDNVA] : due to UserActivity Assertion Using AC"

Wenn ich Bluetooth deaktiviere, bleibt der Hack im Tiefschlaf. Das Verhalten ist reproduzierbar.

Unter Big Sur konnte ich mir damit helfen, in den erweiterten Einstellung für Bluetooth die Funktion zum Aufwecken zu deaktivieren. Das ist wohl auch der erste Griff, wenn es mit dem bluetooth nicht hinhaut.

Nun habe ich aber auf Monterey aktualisiert und leider ist diese (dritte) Option in den erweiterten Eigenschaften nicht mehr vorhanden. Auch der Defaults lässt sich nix drehen, die Einstellungen sind ebenfalls verschwunden.

Es bleibt lediglich

defaults -currentHost read com.apple.Bluetooth

{ BluetoothVersionNumber = 3;
IDSPairedDevices = ( "removed for privacy" );
RecentDevices = { "removed for privacy"; };
RemoteWakeEnabled = 0;
}

übrig. Andere Einträge, wie z.B. ControllerPowerState und BluetoothSystemWakeEnable sind weg.
Mir ist also die Lösung um Problem abhanden gekommen.

Wer hat eine Idee und kann helfen? Entweder, um das Aufwecken abzustellen oder die (vielleicht nur versteckte oder woanders zu findende) Option wieder zu deaktivieren?

p.s. wie es der Zufall will, habe ich auch den Übeltäter am Ende der Kette ausmachen können. Es ist die Magic Mouse.... ausgerechnet... Wenn ich sie ausschalte, bleibt der Hack ruhig schlafen.