Nein, ganz anders. Du hast es nicht richtig gelesen. Es geht nicht um die DSDT. Lade mal deine komplette ACPI hoch, dann zeige ich dir was ich meine.
Sleep/Wake Probleme debuggen
- Tirom
- Erledigt
-
-
-
-
-
-
Hallo apfelnico !
Vielen Dank für die SSDTs!
Ich hab alle SSDTs auf disabled gestellt und nur deine aktiviert, den Patch hinzugefügt und per Hackintool (via USBInjectAll und XhciPortLimit) eine neue USBPorts.kext erstellt und eingebunden (sowie die beiden Helfer wieder entfernt).
Leider stürzt es weiterhin ab. Hier der Bericht:
Alles anzeigenCode- panic(cpu 0 caller 0xffffff801084aa3a): Kernel trap at 0xffffff8010866d57, type 13=general protection, registers:
- CR0: 0x0000000080010033, CR2: 0xffffff87360c9000, CR3: 0x000000001637a000, CR4: 0x00000000003626e0
- RAX: 0x000000007e008003, RBX: 0xffffff801105dc30, RCX: 0x00000000000000e2, RDX: 0x0000000000000000
- RSP: 0xffffff874b903bb0, RBP: 0xffffff874b903be0, RSI: 0x0000000000000003, RDI: 0xffffff801105dbd0
- R8: 0x0000000000000000, R9: 0xffffff8014dc4029, R10: 0x0000000000000003, R11: 0x0000000000000001
- R12: 0xffffff8010f30022, R13: 0x0000000000000001, R14: 0x0000000000000000, R15: 0xffffff8010f30008
- RFL: 0x0000000000010046, RIP: 0xffffff8010866d57, CS: 0x0000000000000008, SS: 0x0000000000000010
- Fault CR2: 0xffffff87360c9000, Error code: 0x0000000000000000, Fault CPU: 0x0, PL: 0, VF: 0
- Backtrace (CPU 0), Frame : Return Address
- 0xffffff8010551220 : 0xffffff801071f5cd mach_kernel : _handle_debugger_trap + 0x49d
- 0xffffff8010551270 : 0xffffff8010858b05 mach_kernel : _kdp_i386_trap + 0x155
- 0xffffff80105512b0 : 0xffffff801084a68e mach_kernel : _kernel_trap + 0x4ee
- 0xffffff8010551300 : 0xffffff80106c5a40 mach_kernel : _return_from_trap + 0xe0
- 0xffffff8010551320 : 0xffffff801071ec97 mach_kernel : _DebuggerTrapWithState + 0x17
- 0xffffff8010551420 : 0xffffff801071f087 mach_kernel : _panic_trap_to_debugger + 0x227
- 0xffffff8010551470 : 0xffffff8010ec27cc mach_kernel : _panic + 0x54
- 0xffffff80105514e0 : 0xffffff801084aa3a mach_kernel : _sync_iss_to_iks + 0x2aa
- 0xffffff8010551660 : 0xffffff801084a738 mach_kernel : _kernel_trap + 0x598
- 0xffffff80105516b0 : 0xffffff80106c5a40 mach_kernel : _return_from_trap + 0xe0
- 0xffffff80105516d0 : 0xffffff8010866d57 mach_kernel : _xcpm_perf_bias_set + 0x1c7
- 0xffffff874b903be0 : 0xffffff8010866feb mach_kernel : _xcpm_init + 0xab
- 0xffffff874b903c00 : 0xffffff8010857021 mach_kernel : _acpi_sleep_kernel + 0x441
- 0xffffff874b903c70 : 0xffffff7f926dfc2a com.apple.driver.AppleACPIPlatform : __ZN23AppleACPIPlatformExpert13sleepPlatformEv + 0x204
- 0xffffff874b903cc0 : 0xffffff7f926e3eab com.apple.driver.AppleACPIPlatform : __ZN12AppleACPICPU7haltCPUEv + 0x75
- 0xffffff874b903ce0 : 0xffffff8010e4cc30 mach_kernel : __Z16IOCPUSleepKernelv + 0x290
- 0xffffff874b903d40 : 0xffffff8010e85e25 mach_kernel : __ZN14IOPMrootDomain15powerChangeDoneEm + 0xac5
- 0xffffff874b903de0 : 0xffffff8010e173b7 mach_kernel : __ZN9IOService8all_doneEv + 0x767
- 0xffffff874b903e50 : 0xffffff8010e1414c mach_kernel : __ZN9IOService23actionPMWorkQueueInvokeEP11IOPMRequestP13IOPMWorkQueue + 0x86c
- 0xffffff874b903ea0 : 0xffffff8010e117e0 mach_kernel : __ZN13IOPMWorkQueue17checkRequestQueueEP11queue_entryPb + 0xa0
- 0xffffff874b903ef0 : 0xffffff8010e11679 mach_kernel : __ZN13IOPMWorkQueue12checkForWorkEv + 0xc9
- 0xffffff874b903f30 : 0xffffff8010e2cede mach_kernel : __ZN10IOWorkLoop15runEventSourcesEv + 0x11e
- 0xffffff874b903f70 : 0xffffff8010e2c4d6 mach_kernel : __ZN10IOWorkLoop10threadMainEv + 0x36
- 0xffffff874b903fa0 : 0xffffff80106c513e mach_kernel : _call_continuation + 0x2e
- Kernel Extensions in backtrace:
- com.apple.driver.AppleACPIPlatform(6.1)[3A6D8ECD-C39E-39C8-984A-2CC417488A56]@0xffffff7f926d4000->0xffffff7f9276efff
- dependency: com.apple.iokit.IOACPIFamily(1.4)[0A7D7382-66FE-391B-9F93-97A996256C25]@0xffffff7f91875000
- dependency: com.apple.iokit.IOPCIFamily(2.9)[BE052F4D-9B80-3FCD-B36D-BACB7DEE0DF2]@0xffffff7f910ee000
- dependency: com.apple.driver.AppleSMC(3.1.9)[4589419D-7CCC-39A9-9E2F-F73FE42DD902]@0xffffff7f91887000
- BSD process name corresponding to current thread: kernel_task
- Boot args: -v keepsyms=1 debug=0x100 alcid=7
- Mac OS version:
- 19F101
- Kernel version:
- Darwin Kernel Version 19.5.0: Tue May 26 20:41:44 PDT 2020; root:xnu-6153.121.2~2/RELEASE_X86_64
- Kernel UUID: 54F1A78D-6F41-32BD-BFED-4381F9F6E2EF
- Kernel slide: 0x0000000010400000
- Kernel text base: 0xffffff8010600000
- __HIB text base: 0xffffff8010500000
- System model name: iMacPro1,1 (Mac-7BA5B2D9E42DDD94)
- System shutdown begun: NO
- Panic diags file available: YES (0x0)
- System uptime in nanoseconds: 250872113825
-
Dann würde ich gern mal deinen EFI-Ordner sehen.
-
Hallo,
ich klinke mich mal hier rein, ich hoffe, das ist ok. Finde das Thema spannend und hänge an einem ähnlichen Punkt: Bei mir funktioniert zwar das Einschlafen, aber beim Aufwecken wirft Mojave alle USB-Geräte aus.
Hackintool zeigt für meine USB-Devices XHCI und SLT1 (für Asmedia) an. Im IoRegistry-Explorer gibt es unter PC00@0 direkt einen Eintrag mit XHCI und PC00@0 -> RP01@1c -> IOPP -> SLT1 -> SLT1 sind die Asmedia Ports.
Eigentlich läuft sonst alles - bis eben auf das Auswerfen der USB-Geräte.
In der Open-Core Anleitung heißt es ja, dass man bei einem ImacPro XHC1 zu SHCI per Patch in der config.plist umbenennen soll - ist das Quatsch? Oder gilt das nur für Mainboards, die ihre Intel-Ports eben XHC1 benennen? Entspricht dann XHC1 meinem SLT1 oder dem XHCI? Warum kann/darf man das nicht über einen Patch machen?
Gibt es irgendwo eine gute Anleitung zu diesem Komplex? Doktore da schon mehrere Wochen herum und bin ein wenig am verzweifeln...
Sorry, will den Thread nicht kapern, mich würde vor allem interessieren, wie du, apfelnico die AML mit den XHCI-renames "gebaut" hast (SSDT-BASIS.aml), damit ich das für mein System "nachbauen" kann...
