Beiträge von hackopti2

na das wär ja was - 4 Std. umsonst
ich teste..

negativ:

"panic(cpu 1 caller 0xffffff7fbfabb16b): \"virtual bool IOAccelLegacyDisplayMachine::display_mode_did_change(uint32_t): Uninitialized NVIDIA GPU driver returns false\"@\/AppleInternal\/BuildRoot\/Library\/Caches\/com.apple.xbs\/Sources\/IOAcceleratorFamily_kexts\/IOAcceleratorFamily-

sowohl mit einer Headless IGPU als auch deaktivierter GPU. Der Installer hängt, das laufende System startet beim Booten einfach neu.

Muss ich irgendwas reinitialisieren, NVRAM?

das heißt ich bau sie ein und mache garnichts, außer die IGPU im BIOS zu deaktivieren?

Die Karte sollte OOB funktionieren, aber nach dem Setzen von nvda_drv in OC und dem deaktivieren der IGPU im BIOS:

IOAccelLegacyDisplayMachine::display_mode_did_change(uint32_t): Uninitialized NVIDIA GPU driver returns false

(taucht auf als Crash Reason wenn ich danach wieder mit der IGPU boote)

Hat jemand ne Idee was ich falsch mache?

Eine Idee: Damit dass er den KextCache nutzt und den Nvidia-Treiber nicht findet könnte es doch was zu tun haben?

Zwei Wochen ohne Crash, sieht so aus als ob es das war

interessant wäre jetzt aber schon der Grund, denkt ihr C-States und TurboBoost sind verantwortlich?

Würde das EFI gerne online stellen, will aber sicher sein, dass es sinnvolle Settings sind.

Hi, ne, das hab ich schon. Ich kenn die UEFI-Variable, das interessante ist:

Enable PCI Slot", Help: " ", QuestionFlags: 0x10, QuestionId: 365, VarStoreId: 1, VarStoreOffset: 0x13ED, Flags: 0x0

Default DefaultId: 0 Value: Other

Enabling this feature provides additional UEFI SMM Security Mitigation protections. However, this feature may cause compatibility issues or loss of functionality with some legacy tools and applications.

", QuestionFlags: 0x10, QuestionId: 303, VarStoreId: 1, VarStoreOffset: 0x13DB

"", Help: "", QuestionFlags: 0x10, QuestionId: 173, VarStoreId: 1, VarStoreOffset: 0x13DF, Flags: 0x0

Default DefaultId: 0 Value: Other

SFF:264,265c

000013d4 00 02 01 00 00 00 00 00 01 00 00 00 00 00 02 01 |................|

000013e4 01 01 01 01 00 00 01 00 00 00 01 00 00 01 00 00 |................|

MFF:265,266c

000013d4 00 02 01 00 00 00 00 00 01 00 00 01 00 00 02 00 |................| 13de <- Serial is set to COM1 on the MFF, although there is no option

000013e4 01 01 01 01 00 00 01 00 00 00 01 00 00 01 00 00 |................| MFF has PCI-Slot enabled, although MFF has no PCIe Slot

Letztendlich stürzt der SFF ja momentan nicht mehr ab -> also Ziel erreicht!

Der Grund waren entweder die C-States, TurboBoost oder eben das Setzen von COM1 auf COM2

das wäre interessant @theCurseOfHackintosh

kuckkuck tatsächlich ist er nach 25 sleep wake cycles mit folgenden Einstellungen nicht mehr abgestürzt:

Serial: COM2 (COM1 stürzt manchmal ab, Deaktiviert: stürzt immer ab)

C-States und Turbo Boost im BIOS deaktiviert - geht trotzdem auf 4.1 bis 4.2 Ghz hoch, 4.3 seh ich nicht, aber die kommen auch nicht wenn die anderen Cores auch arbeiten).

Ich teste weiter, aber wenn es das war dann liegt es am Serial Port (also der Speicherbelegung dahinter tippe ich), der lässt sich nämlich auf dem MFF weder aktivieren noch deaktivieren.

Moin, also mein MFF schläft auch mit Big Sur perfekt und ist noch nicht einmal abgestürzt. Das Problem hab ich nur mit der größeren Variante, dem SFF.

Die Kisten sind bis auf das Mainboard identisch aufgebaut

ist jetzt etwas off topic: Wo stürzt dein MFF denn ab? und mit welchem Fehler?

bis 10.14. sind die Kisten alle stabil gelaufen, deswegen tippe ich auch auf ein Software-Problem, finde aber keinen Ansatzpunkt

ja der Post war gestern noch nicht fertig..

Ich hab gestern weitere Unterschiede zwischen den beiden Systemen und in den DSDTs diesen Unterschied gefunden. Ich tippe mal, dass das PCIE-Wiring (der MFF hat keine PCI-Slots) ein anderes ist. Hab mich jetzt gefragt ob es die Speicherbereiche/Adressen sind, die ein Problem verursachen. Aber ob man hier was ändern kann und sollte - keine Ahnung?

Zusätzlich hab ich mal die ioreg-Dumps verglichen, da zeigt sich aber kein großer Unterschied.

MFF:

Device (RP01)

{

Name (_ADR, 0x001C0007) // _ADR: Address

OperationRegion (PXCS, PCI_Config, Zero, 0x0480)

Field (PXCS, AnyAcc, NoLock, Preserve)

{

Device (RP08)

{

Name (_ADR, 0x001C0000) // _ADR: Address

OperationRegion (PXCS, PCI_Config, Zero, 0x0480)

Field (PXCS, AnyAcc, NoLock, Preserve)

{

SFF:

Device (RP01)

{

Name (_ADR, 0x001C0000) // _ADR: Address

OperationRegion (PXCS, PCI_Config, Zero, 0x0480)

Field (PXCS, AnyAcc, NoLock, Preserve)

{

Device (RP08)

{

Name (_ADR, 0x001C0007) // _ADR: Address

OperationRegion (PXCS, PCI_Config, Zero, 0x0480)

Field (PXCS, AnyAcc, NoLock, Preserve)

{

spannend, hab mal das gesamte RTC gesperrt und bekomme jetzt eine "nvme: "Fatal error occurred." meldung - trotz NVMEfix.kext

danke für die Tipps, aber ja, alles getestet - versuche schon etwas länger das in den Griff zu bekommen.

Was ich bräuchte wär eine Möglichkeit zum Debuggen - aber er wacht auf, hängt und liefert mir beim hochfahren nur den Sleep Wake Failure from EFI, sonst keine Logs

Daraus schließe ich, dass er gerade noch die RTC Vars schreibt und sich dabei aufhängt.

hab ich beides probiert, wieder abgestürzt..

was mich irritiert: ein Micro Form Factor-Modell (selbe CPU, selbe SSD, selber RAM, selbe Geräte angeschlossen) macht diese Zicken nicht.

Hab auch mal das BIOS auseinandergenommen, in den UEFI-Variablen nach Unterschieden gesucht: ALLES GLEICH!

Deswegen tipp ich ja auf eine auf dem Mainboard verbaute Komponente, die sich unterscheidet. Das Problem besteht erst seit 10.14.

Noch irgendwelche kreativen Ideen bevor ich den Standby-Modus wieder deaktiviere, was aber alleine schon für die Umwelt doof wäre?

Moment, ein Detail ist anders: Es kommt nicht mehr die Meldung "Sleep Wake Failure from EFI", sondern er bleibt einfach hängen.. ich tippe das liegt am deaktivierten Bereich B0-B3

mist, wieder abgestürzt. sowohl wenn ich die zweite Bank deaktiviere (per RTCMemoryFixup) als auch wenn ich nur 58 und 59 deaktiviere.

Sicher das ich es nicht doch mit der SSDT probieren soll - das Ding stürzt ja direkt nach dem Aufwachen ab - also eine Ebene tiefer als eine kext?

ich hab's doch mit dem RTCMemoryFixup gemacht und Folgendes hinzugefügt: rtcfx_exclude=80-FF

bisher kein Absturz, aber ich warte noch

ok, Neuigkeiten, ich habe noch nichts geändert und auf den nächsten Absturz gewartet, hier mal ein paar Interessante Logs dieses Events:

ich würde jetzt also die zweiten 128 Byte der RTC-Variablen deaktivieren. Mit dieser SSDT zum Beispiel?

ahhh, ok, dachte sowas wird in UEFI-Variablen gespeichert.

ah ok, dann würd ich das erstmal probieren. Ich hätte gedacht, dass das den Sleep-Mode kaputtmacht.

das hatte ich jetzt aus den Links so identifiziert, anscheinend war ich aber schon zu müde

was ist denn der richtige Weg - einfach nur per SSDT die Größe auf 0x1 limitieren? da sind mir die Zusammenhänge ehrlich gesagt nicht so klar.