TheBloke

I found a solution/workaround: set AppleXcpmCfgLock to True. It fixes wake, and now I have perfect sleep & wake. I do not know why this worked, because GB motherboard is meant to have unlocked Cfg Lock, and VerifyMsr shows it is unlocked. But it has fixed wake!

No luck, still kernel panic on wake I noticed that the KP message has changed slightly - it now shows VirtualSMC in the backtrace. Note that this did not change because of CpuTscSync, it changed before I tried that. com.apple.driver.AppleACPIPlatform(6.1)[0EF10B66-B44B-32BB-9CE3-5434F4D40FE1]@0xffffff7f9d386000->0xffffff7f9d420fff dependency: com.apple.iokit.IOACPIFamily(1.4)[2956198D-24F2-3790-A9B2-1EAB9434B906]@0xffffff7f9cb09000 dependency: com.apple.iokit.IOPCIFamily(2.9)[44472E6F-8DA0-3B46-ADEF-AFF76EC6C6DB]@0xffffff7f9cb12000 dependency: com.apple.driver.AppleSMC(3.1.9)[D2F0B610-83F8-3B84-B0BD-D9D0CC95A697]@0xffffff7f9cba9000 as.vit9696.VirtualSMC(1.1.8)[813DCDAE-0225-34E9-8194-BCF9F3E72A56]@0xffffff7f9fd6a000->0xffffff7f9fd91fff dependency: as.vit9696.Lilu(1.4.9)[7C57166B-7B72-3290-B56C-17CE218385C2]@0xffffff7f9fce4000 dependency: com.apple.iokit.IOACPIFamily(1.4)[2956198D-24F2-3790-A9B2-1EAB9434B906]@0xffffff7f9cb09000 I have tried changing BIOS settings (eg C states, EIST), I have tried RtcMemoryFixup. I also tried going back to Mojave 10.14.6, and I got the same KP on wake in that OS, same as 10.15.7. Current full kernel panic log is below: panic(cpu 0 caller 0xffffff801c2469aa): Kernel trap at 0xffffff801c262d27, type 13=general protection, registers: CR0: 0x0000000080010033, CR2: 0xffffff8e1ed69000, CR3: 0x000000002204e000, CR4: 0x00000000003626e0 RAX: 0x000000007e008003, RBX: 0xffffff801ca5dc40, RCX: 0x00000000000000e2, RDX: 0x0000000000000000 RSP: 0xffffff8e3c7bbbb0, RBP: 0xffffff8e3c7bbbe0, RSI: 0x0000000000000003, RDI: 0xffffff801ca5dbe0 R8: 0x0000000000000000, R9: 0xffffff8020a7708d, R10: 0x0000000000000003, R11: 0x0000000000000000 R12: 0xffffff801c92f33d, R13: 0x0000000000000001, R14: 0x0000000000000000, R15: 0xffffff801c92f323 RFL: 0x0000000000010046, RIP: 0xffffff801c262d27, CS: 0x0000000000000008, SS: 0x0000000000000010 Fault CR2: 0xffffff8e1ed69000, Error code: 0x0000000000000000, Fault CPU: 0x0, PL: 0, VF: 0 Backtrace (CPU 0), Frame : Return Address 0xffffff801bf51120 : 0xffffff801c11a65d mach_kernel : _handle_debugger_trap + 0x49d 0xffffff801bf51170 : 0xffffff801c254a75 mach_kernel : _kdp_i386_trap + 0x155 0xffffff801bf511b0 : 0xffffff801c2465fe mach_kernel : _kernel_trap + 0x4ee 0xffffff801bf51200 : 0xffffff7f9fd7a6f4 as.vit9696.VirtualSMC : __ZN18VirtualSMCProvider10kernelTrapI22x86_saved_state_1010_tEEvPT_Pm + 0x454 0xffffff801bf51280 : 0xffffff801c0c0a40 mach_kernel : _return_from_trap + 0xe0 0xffffff801bf512a0 : 0xffffff801c119d27 mach_kernel : _DebuggerTrapWithState + 0x17 0xffffff801bf513a0 : 0xffffff801c11a117 mach_kernel : _panic_trap_to_debugger + 0x227 0xffffff801bf513f0 : 0xffffff801c8c1a6c mach_kernel : _panic + 0x54 0xffffff801bf51460 : 0xffffff801c2469aa mach_kernel : _sync_iss_to_iks + 0x2aa 0xffffff801bf515e0 : 0xffffff801c2466a8 mach_kernel : _kernel_trap + 0x598 0xffffff801bf51630 : 0xffffff7f9fd7a6f4 as.vit9696.VirtualSMC : __ZN18VirtualSMCProvider10kernelTrapI22x86_saved_state_1010_tEEvPT_Pm + 0x454 0xffffff801bf516b0 : 0xffffff801c0c0a40 mach_kernel : _return_from_trap + 0xe0 0xffffff801bf516d0 : 0xffffff801c262d27 mach_kernel : _xcpm_perf_bias_set + 0x1c7 0xffffff8e3c7bbbe0 : 0xffffff801c262fbb mach_kernel : _xcpm_init + 0xab 0xffffff8e3c7bbc00 : 0xffffff801c252f91 mach_kernel : _acpi_sleep_kernel + 0x441 0xffffff8e3c7bbc70 : 0xffffff7f9d391c2a com.apple.driver.AppleACPIPlatform : __ZN23AppleACPIPlatformExpert13sleepPlatformEv + 0x204 0xffffff8e3c7bbcc0 : 0xffffff7f9d395eab com.apple.driver.AppleACPIPlatform : __ZN12AppleACPICPU7haltCPUEv + 0x75 0xffffff8e3c7bbce0 : 0xffffff801c84bb20 mach_kernel : __Z16IOCPUSleepKernelv + 0x290 0xffffff8e3c7bbd40 : 0xffffff801c8850d5 mach_kernel : __ZN14IOPMrootDomain15powerChangeDoneEm + 0xac5 0xffffff8e3c7bbde0 : 0xffffff801c8162a7 mach_kernel : __ZN9IOService8all_doneEv + 0x767 0xffffff8e3c7bbe50 : 0xffffff801c81303c mach_kernel : __ZN9IOService23actionPMWorkQueueInvokeEP11IOPMRequestP13IOPMWorkQueue + 0x86c 0xffffff8e3c7bbea0 : 0xffffff801c8106d0 mach_kernel : __ZN13IOPMWorkQueue17checkRequestQueueEP11queue_entryPb + 0xa0 0xffffff8e3c7bbef0 : 0xffffff801c810569 mach_kernel : __ZN13IOPMWorkQueue12checkForWorkEv + 0xc9 0xffffff8e3c7bbf30 : 0xffffff801c82bdce mach_kernel : __ZN10IOWorkLoop15runEventSourcesEv + 0x11e 0xffffff8e3c7bbf70 : 0xffffff801c82b3c6 mach_kernel : __ZN10IOWorkLoop10threadMainEv + 0x36 0xffffff8e3c7bbfa0 : 0xffffff801c0c013e mach_kernel : _call_continuation + 0x2e Kernel Extensions in backtrace: com.apple.driver.AppleACPIPlatform(6.1)[0EF10B66-B44B-32BB-9CE3-5434F4D40FE1]@0xffffff7f9d386000->0xffffff7f9d420fff dependency: com.apple.iokit.IOACPIFamily(1.4)[2956198D-24F2-3790-A9B2-1EAB9434B906]@0xffffff7f9cb09000 dependency: com.apple.iokit.IOPCIFamily(2.9)[44472E6F-8DA0-3B46-ADEF-AFF76EC6C6DB]@0xffffff7f9cb12000 dependency: com.apple.driver.AppleSMC(3.1.9)[D2F0B610-83F8-3B84-B0BD-D9D0CC95A697]@0xffffff7f9cba9000 as.vit9696.VirtualSMC(1.1.8)[813DCDAE-0225-34E9-8194-BCF9F3E72A56]@0xffffff7f9fd6a000->0xffffff7f9fd91fff dependency: as.vit9696.Lilu(1.4.9)[7C57166B-7B72-3290-B56C-17CE218385C2]@0xffffff7f9fce4000 dependency: com.apple.iokit.IOACPIFamily(1.4)[2956198D-24F2-3790-A9B2-1EAB9434B906]@0xffffff7f9cb09000 BSD process name corresponding to current thread: kernel_task Boot args: -v keepsyms=1 swd_panic=1 alcid=7 chunklist-security-epoch=0 -chunklist-no-rev2-dev chunklist-security-epoch=0 -chunklist-no-rev2-dev Mac OS version: 19H2 Kernel version: Darwin Kernel Version 19.6.0: Mon Aug 31 22:12:52 PDT 2020; root:xnu-6153.141.2~1/RELEASE_X86_64 Kernel UUID: 05D51A3D-3A87-3FF0-98C3-9CF3827A3EDD Kernel slide: 0x000000001be00000 Kernel text base: 0xffffff801c000000 __HIB text base: 0xffffff801bf00000 System model name: MacPro7,1 (Mac-27AD2F918AE68F61) System shutdown begun: NO Panic diags file available: YES (0x0) System uptime in nanoseconds: 262354615090 last loaded kext at 143702877203: @filesystems.smbfs 3.4.4 (addr 0xffffff7fa3a89000, size 450560) loaded kexts: net.telestream.driver.TelestreamAudio 1.1.1 at.obdev.nke.LittleSnitch 5618 com.intel.driver.EnergyDriver 3.7.0 com.SmallTree.driver.SmallTree!I8259x 3.5.0 ru.joedm.SMCSuperIO 1.1.8 as.vit9696.SMCProcessor 1.1.8 as.vit9696.VirtualSMC 1.1.8 as.acidanthera.BrcmFirmwareStore 2.5.5 as.lvs1974.AirportBrcmFixup 2.1.1 com.rehabman.driver.USBInjectAll 0.7.5 meow.IOIIIO.MacProMemoryNotificationDisabler 1.0.0 org.lvs1974.driver.CpuTscSync 1.0.3 org.acidanthera.NVMeFix 1.0.4 as.vit9696.WhateverGreen 1.4.4 as.vit9696.!AALC 1.5.4 as.vit9696.Lilu 1.4.9 @filesystems.smbfs 3.4.4 @filesystems.msdosfs 1.10 >!AUpstreamUserClient 3.6.8 @kext.AMDFramebuffer 3.1.0 @fileutil 20.036.15 @kext.AMDRadeonX5000 3.1.0 @kext.AMDRadeonServiceManager 3.1.0 >AudioAUUC 1.70 >!AGraphicsDevicePolicy 5.2.6 @AGDCPluginDisplayMetrics 5.2.6 >!AHV 1 |IOUserEthernet 1.0.1 @filesystems.autofs 3.0 |IO!BSerialManager 7.0.6f7 >pmtelemetry 1 @Dont_Steal_Mac_OS_X 7.0.0 >AGPM 111.4.4 >X86PlatformShim 1.0.0 >!APlatformEnabler 2.7.0d0 >!AHDAHardwareConfigDriver 283.15 >AGDCBacklightControl 5.2.6 >!AHDA 283.15 @kext.AMD10000!C 3.1.0 >!ABacklight 180.3 >ACPI_SMC_PlatformPlugin 1.0.0 >!AGFXHDA 100.1.429 >!A!IPCHPMC 2.0.1 >!ASMCLMU 212 >!A!ISlowAdaptiveClocking 4.0.0 >!AMCCSControl 1.14 >!A!IMCEReporter 115 >!AFIVRDriver 4.1.0 @private.KextAudit 1.0 >!AFileSystemDriver 3.0.1 @filesystems.hfs.kext 522.100.5 @BootCache 40 @!AFSCompression.!AFSCompressionTypeDataless 1.0.0d1 @!AFSCompression.!AFSCompressionTypeZlib 1.0.0 >!AVirtIO 1.0 @filesystems.apfs 1412.141.1 >!AAHCIPort 341.140.1 >!ARTC 2.0 >!AHPET 1.8 >!AACPIButtons 6.1 >!ASMBIOS 2.1 >!AAPIC 1.7 $!AImage4 1 @nke.applicationfirewall 303 $TMSafetyNet 8 @!ASystemPolicy 2.0.0 |EndpointSecurity 1 |IOAVB!F 850.1 @plugin.IOgPTPPlugin 840.3 |IOEthernetAVB!C 1.1.0 @kext.AMDRadeonX5000HWLibs 1.0 |IOAccelerator!F2 438.7.3 @kext.AMDRadeonX5000HWServices 3.1.0 >!AGraphicsControl 5.2.6 @kext.triggers 1.0 @!AGPUWrangler 5.2.6 >DspFuncLib 283.15 @kext.OSvKernDSPLib 529 >!ABacklightExpert 1.1.0 >IOPlatformPluginLegacy 1.0.0 >!AHDA!C 283.15 |IOHDA!F 283.15 |IONDRVSupport 576.1 >!ASMBusPCI 1.0.14d1 @kext.AMDSupport 3.1.0 @!AGraphicsDeviceControl 5.2.6 |IOSlowAdaptiveClocking!F 1.0.0 >!ASMBus!C 1.0.18d1 |IOSMBus!F 1.1 |IOGraphics!F 576.1 >X86PlatformPlugin 1.0.0 >IOPlatformPlugin!F 6.0.0d8 |IOSkywalk!F 1 >usb.IOUSBHostHIDDevice 1.2 >usb.cdc 5.0.0 >usb.networking 5.0.0 >usb.!UHostCompositeDevice 1.2 |IO!BHost!CUSBTransport 7.0.6f7 |IO!BHost!CTransport 7.0.6f7 >usb.!UHub 1.2 |IOSurface 269.11 @filesystems.hfs.encodings.kext 1 |IOAudio!F 300.2 @vecLib.kext 1.2.0 |IOSerial!F 11 >usb.!UHostPacketFilter 1.0 |IOUSB!F 900.4.2 >!AXsanScheme 3 >!AThunderboltNHI 5.8.6 |IOThunderbolt!F 7.6.1 |IONVMe!F 2.1.0 |IOAHCI!F 290.0.1 >usb.!UXHCIPCI 1.2 >usb.!UXHCI 1.2 >!AEFINVRAM 2.1 >!ASMCRTC 1.0 >!AEFIRuntime 2.1 |IOHID!F 2.0.0 $quarantine 4 $sandbox 300.0 @kext.!AMatch 1.0.0d1 >!AKeyStore 2 >!UTDM 489.120.1 |IOSCSIBlockCommandsDevice 422.120.3 >!ACredentialManager 1.0 >!AFDEKeyStore 28.30 >!AEffaceable!S 1.0 >!AMobileFileIntegrity 1.0.5 @kext.CoreTrust 1 |CoreAnalytics!F 1 |IOTimeSync!F 840.3 |IONetworking!F 3.4 >DiskImages 493.0.0 |IO!B!F 7.0.6f7 |IO!BPacketLogger 7.0.6f7 >!ASSE 1.0 >KernelRelayHost 1 >!ASEPManager 1.0.1 >IOSlaveProcessor 1 |IOUSBMass!SDriver 157.140.1 |IOSCSIArchitectureModel!F 422.120.3 |IO!S!F 2.1 |IOUSBHost!F 1.2 >usb.!UCommon 1.0 >!UHostMergeProperties 1.2 >!ABusPower!C 1.0 |IOReport!F 47 >!AACPIPlatform 6.1 >!ASMC 3.1.9 >watchdog 1 |IOPCI!F 2.9 |IOACPI!F 1.4 @kec.pthread 1 @kec.corecrypto 1.0 @kec.Libm 1

Sleep works, but when waking the system up it will reboot and report the kernel panic listed above. This happens 100% of the time when I wake after sleep: reboot, because of that kernel panic. Therefore I must not use sleep, because it is not possible to wake the system without reboot. This is the same issue I first posted about, it is not new with your files. But unfortunately it's not yet fixed. I'd be grateful for any thoughts on what might be causing it - it does seem to be related to ACPI or SMC: Kernel Extensions in backtrace: com.apple.driver.AppleACPIPlatform(6.1)[0EF10B66-B44B-32BB-9CE3-5434F4D40FE1]@0xffffff7f8f586000->0xffffff7f8f620fff dependency: com.apple.iokit.IOACPIFamily(1.4)[2956198D-24F2-3790-A9B2-1EAB9434B906]@0xffffff7f8ed09000 dependency: com.apple.iokit.IOPCIFamily(2.9)[44472E6F-8DA0-3B46-ADEF-AFF76EC6C6DB]@0xffffff7f8ed12000 dependency: com.apple.driver.AppleSMC(3.1.9)[D2F0B610-83F8-3B84-B0BD-D9D0CC95A697]@0xffffff7f8eda9000

Thanks, I'll try it now. Do I still need RebaseRegions on? OK I tested (with RebaseRegions on). Unfortunately there is still kernel panic on wake, in AppleACPIPlatform. KP log is below. Thanks in advance. panic(cpu 0 caller 0xffffff800e4469aa): Kernel trap at 0xffffff800e462d27, type 13=general protection, registers: CR0: 0x0000000080010033, CR2: 0xffffff8e10a49000, CR3: 0x0000000013e96000, CR4: 0x00000000003626e0 RAX: 0x000000007e008003, RBX: 0xffffff800ec5dc40, RCX: 0x00000000000000e2, RDX: 0x0000000000000000 RSP: 0xffffffce3ff63bb0, RBP: 0xffffffce3ff63be0, RSI: 0x0000000000000003, RDI: 0xffffff800ec5dbe0 R8: 0x0000000000000000, R9: 0xffffff80128bf05b, R10: 0x0000000000000003, R11: 0x0000000000000000 R12: 0xffffff800eb2f33d, R13: 0x0000000000000001, R14: 0x0000000000000000, R15: 0xffffff800eb2f323 RFL: 0x0000000000010046, RIP: 0xffffff800e462d27, CS: 0x0000000000000008, SS: 0x0000000000000010 Fault CR2: 0xffffff8e10a49000, Error code: 0x0000000000000000, Fault CPU: 0x0, PL: 0, VF: 0 Backtrace (CPU 0), Frame : Return Address 0xffffff800e151220 : 0xffffff800e31a65d mach_kernel : _handle_debugger_trap + 0x49d 0xffffff800e151270 : 0xffffff800e454a75 mach_kernel : _kdp_i386_trap + 0x155 0xffffff800e1512b0 : 0xffffff800e4465fe mach_kernel : _kernel_trap + 0x4ee 0xffffff800e151300 : 0xffffff800e2c0a40 mach_kernel : _return_from_trap + 0xe0 0xffffff800e151320 : 0xffffff800e319d27 mach_kernel : _DebuggerTrapWithState + 0x17 0xffffff800e151420 : 0xffffff800e31a117 mach_kernel : _panic_trap_to_debugger + 0x227 0xffffff800e151470 : 0xffffff800eac1a6c mach_kernel : _panic + 0x54 0xffffff800e1514e0 : 0xffffff800e4469aa mach_kernel : _sync_iss_to_iks + 0x2aa 0xffffff800e151660 : 0xffffff800e4466a8 mach_kernel : _kernel_trap + 0x598 0xffffff800e1516b0 : 0xffffff800e2c0a40 mach_kernel : _return_from_trap + 0xe0 0xffffff800e1516d0 : 0xffffff800e462d27 mach_kernel : _xcpm_perf_bias_set + 0x1c7 0xffffffce3ff63be0 : 0xffffff800e462fbb mach_kernel : _xcpm_init + 0xab 0xffffffce3ff63c00 : 0xffffff800e452f91 mach_kernel : _acpi_sleep_kernel + 0x441 0xffffffce3ff63c70 : 0xffffff7f8f591c2a com.apple.driver.AppleACPIPlatform : __ZN23AppleACPIPlatformExpert13sleepPlatformEv + 0x204 0xffffffce3ff63cc0 : 0xffffff7f8f595eab com.apple.driver.AppleACPIPlatform : __ZN12AppleACPICPU7haltCPUEv + 0x75 0xffffffce3ff63ce0 : 0xffffff800ea4bb20 mach_kernel : __Z16IOCPUSleepKernelv + 0x290 0xffffffce3ff63d40 : 0xffffff800ea850d5 mach_kernel : __ZN14IOPMrootDomain15powerChangeDoneEm + 0xac5 0xffffffce3ff63de0 : 0xffffff800ea162a7 mach_kernel : __ZN9IOService8all_doneEv + 0x767 0xffffffce3ff63e50 : 0xffffff800ea1303c mach_kernel : __ZN9IOService23actionPMWorkQueueInvokeEP11IOPMRequestP13IOPMWorkQueue + 0x86c 0xffffffce3ff63ea0 : 0xffffff800ea106d0 mach_kernel : __ZN13IOPMWorkQueue17checkRequestQueueEP11queue_entryPb + 0xa0 0xffffffce3ff63ef0 : 0xffffff800ea10569 mach_kernel : __ZN13IOPMWorkQueue12checkForWorkEv + 0xc9 0xffffffce3ff63f30 : 0xffffff800ea2bdce mach_kernel : __ZN10IOWorkLoop15runEventSourcesEv + 0x11e 0xffffffce3ff63f70 : 0xffffff800ea2b3c6 mach_kernel : __ZN10IOWorkLoop10threadMainEv + 0x36 0xffffffce3ff63fa0 : 0xffffff800e2c013e mach_kernel : _call_continuation + 0x2e Kernel Extensions in backtrace: com.apple.driver.AppleACPIPlatform(6.1)[0EF10B66-B44B-32BB-9CE3-5434F4D40FE1]@0xffffff7f8f586000->0xffffff7f8f620fff dependency: com.apple.iokit.IOACPIFamily(1.4)[2956198D-24F2-3790-A9B2-1EAB9434B906]@0xffffff7f8ed09000 dependency: com.apple.iokit.IOPCIFamily(2.9)[44472E6F-8DA0-3B46-ADEF-AFF76EC6C6DB]@0xffffff7f8ed12000 dependency: com.apple.driver.AppleSMC(3.1.9)[D2F0B610-83F8-3B84-B0BD-D9D0CC95A697]@0xffffff7f8eda9000 BSD process name corresponding to current thread: kernel_task Boot args: -v keepsyms=1 swd_panic=1 alcid=7 chunklist-security-epoch=0 -chunklist-no-rev2-dev Mac OS version: 19H2 Kernel version: Darwin Kernel Version 19.6.0: Mon Aug 31 22:12:52 PDT 2020; root:xnu-6153.141.2~1/RELEASE_X86_64 Kernel UUID: 05D51A3D-3A87-3FF0-98C3-9CF3827A3EDD Kernel slide: 0x000000000e000000 Kernel text base: 0xffffff800e200000 __HIB text base: 0xffffff800e100000 System model name: MacPro7,1 (Mac-27AD2F918AE68F61) System shutdown begun: NO Panic diags file available: YES (0x0) System uptime in nanoseconds: 163225257981 last loaded kext at 40753858761: |IOAVB!F 850.1 (addr 0xffffff7f958bd000, size 139264) loaded kexts: com.disc-soft.DAEMONTools.VirtualSCSIBus 1.0.2 net.telestream.driver.TelestreamAudio 1.1.1 at.obdev.nke.LittleSnitch 5618 com.intel.driver.EnergyDriver 3.7.0 com.SmallTree.driver.SmallTree!I8259x 3.5.0 ru.joedm.SMCSuperIO 1.1.8 hu.interferenc.TSCAdjustReset 1.1 as.vit9696.SMCProcessor 1.1.8 as.vit9696.VirtualSMC 1.1.8 com.rehabman.driver.USBInjectAll 0.7.5 meow.IOIIIO.MacProMemoryNotificationDisabler 1.0.0 org.acidanthera.NVMeFix 1.0.4 as.vit9696.WhateverGreen 1.4.4 as.vit9696.!AALC 1.5.4 as.vit9696.Lilu 1.4.9 >!AUpstreamUserClient 3.6.8 @fileutil 20.036.15 @kext.AMDFramebuffer 3.1.0 @filesystems.autofs 3.0 @kext.AMDRadeonX5000 3.1.0 @kext.AMDRadeonServiceManager 3.1.0 >AudioAUUC 1.70 >!AGraphicsDevicePolicy 5.2.6 @AGDCPluginDisplayMetrics 5.2.6 >!AHV 1 |IOUserEthernet 1.0.1 |IO!BSerialManager 7.0.6f7 >pmtelemetry 1 @Dont_Steal_Mac_OS_X 7.0.0 >AGPM 111.4.4 >!APlatformEnabler 2.7.0d0 >X86PlatformShim 1.0.0 >!AHDAHardwareConfigDriver 283.15 >AGDCBacklightControl 5.2.6 >!AHDA 283.15 @kext.AMD10000!C 3.1.0 >!ABacklight 180.3 >ACPI_SMC_PlatformPlugin 1.0.0 >!AGFXHDA 100.1.429 >!ASMCLMU 212 >!AMCCSControl 1.14 >!A!ISlowAdaptiveClocking 4.0.0 >!A!IMCEReporter 115 >!A!IPCHPMC 2.0.1 >!AFIVRDriver 4.1.0 @private.KextAudit 1.0 >!AFileSystemDriver 3.0.1 @filesystems.hfs.kext 522.100.5 @BootCache 40 @!AFSCompression.!AFSCompressionTypeDataless 1.0.0d1 @!AFSCompression.!AFSCompressionTypeZlib 1.0.0 >!AVirtIO 1.0 @filesystems.apfs 1412.141.1 >!AAHCIPort 341.140.1 >!ARTC 2.0 >!AHPET 1.8 >!AACPIButtons 6.1 >!ASMBIOS 2.1 >!AAPIC 1.7 $!AImage4 1 @nke.applicationfirewall 303 $TMSafetyNet 8 @!ASystemPolicy 2.0.0 |EndpointSecurity 1 |IOAVB!F 850.1 @plugin.IOgPTPPlugin 840.3 |IOEthernetAVB!C 1.1.0 @kext.triggers 1.0 @kext.AMDRadeonX5000HWLibs 1.0 |IOAccelerator!F2 438.7.3 @kext.AMDRadeonX5000HWServices 3.1.0 >!AGraphicsControl 5.2.6 @!AGPUWrangler 5.2.6 >DspFuncLib 283.15 @kext.OSvKernDSPLib 529 >!ABacklightExpert 1.1.0 >IOPlatformPluginLegacy 1.0.0 >!AHDA!C 283.15 |IOHDA!F 283.15 >!ASMBusPCI 1.0.14d1 @kext.AMDSupport 3.1.0 @!AGraphicsDeviceControl 5.2.6 |IONDRVSupport 576.1 >!ASMBus!C 1.0.18d1 |IOSMBus!F 1.1 |IOGraphics!F 576.1 |IOSlowAdaptiveClocking!F 1.0.0 >X86PlatformPlugin 1.0.0 >IOPlatformPlugin!F 6.0.0d8 |IOSkywalk!F 1 >usb.IOUSBHostHIDDevice 1.2 >usb.cdc 5.0.0 >usb.networking 5.0.0 >usb.!UHostCompositeDevice 1.2 |IO!BHost!CUSBTransport 7.0.6f7 |IO!BHost!CTransport 7.0.6f7 >usb.!UHub 1.2 |IOSurface 269.11 @filesystems.hfs.encodings.kext 1 |IOAudio!F 300.2 @vecLib.kext 1.2.0 |IOSerial!F 11 >usb.!UHostPacketFilter 1.0 |IOUSB!F 900.4.2 >!AXsanScheme 3 >!AThunderboltNHI 5.8.6 |IOThunderbolt!F 7.6.1 |IONVMe!F 2.1.0 >usb.!UXHCIPCI 1.2 >usb.!UXHCI 1.2 |IOAHCI!F 290.0.1 >!AEFINVRAM 2.1 >!ASMCRTC 1.0 >!AEFIRuntime 2.1 |IOHID!F 2.0.0 $quarantine 4 $sandbox 300.0 @kext.!AMatch 1.0.0d1 >!AKeyStore 2 >!UTDM 489.120.1 |IOSCSIBlockCommandsDevice 422.120.3 >!ACredentialManager 1.0 >!AFDEKeyStore 28.30 >!AEffaceable!S 1.0 >!AMobileFileIntegrity 1.0.5 @kext.CoreTrust 1 |CoreAnalytics!F 1 |IOTimeSync!F 840.3 |IONetworking!F 3.4 >DiskImages 493.0.0 |IO!B!F 7.0.6f7 |IO!BPacketLogger 7.0.6f7 >!ASSE 1.0 >KernelRelayHost 1 >!ASEPManager 1.0.1 >IOSlaveProcessor 1 |IOUSBMass!SDriver 157.140.1 |IOSCSIArchitectureModel!F 422.120.3 |IO!S!F 2.1 |IOUSBHost!F 1.2 >usb.!UCommon 1.0 >!UHostMergeProperties 1.2 >!ABusPower!C 1.0 |IOReport!F 47 >!AACPIPlatform 6.1 >!ASMC 3.1.9 >watchdog 1 |IOPCI!F 2.9 |IOACPI!F 1.4 @kec.pthread 1 @kec.corecrypto 1.0 @kec.Libm 1

Thanks for the fast reply! Link to new SendMe.zip, using your provided DSDT + RebaseRegions: https://drive.google.com/file/d/1qgQpgmpY2ONNPsq-LNpnjhPD0TT7SObM/view?usp=sharing

Hi mald0n, I finally got a new PC and it is mostly working on Catalina 10.15.7, but not completely. I have SSDTs prepared by a user on another forum and I have modified them a bit myself, but it is not yet perfect. Link to download Run Me ZIP: https://drive.google.com/file/d/1en1xmHHus8YW175JrDV-vkeHFbbPqrpn/view?usp=sharing System: Bootloader: OpenCore 0.6.3 SMBIOS: Mac Pro 7,1 macOS: 10.15.7 Motherboard: Gigabyte X299X Designare 10G CPU: Intel i9-10980XE 18-core RAM: 128GB DDR4 3600 Mhz GPU: Gigabyte Vega 64 OC 8GB NVMe 1: 2TB, macOS NVMe 2: 512GB, Windows 10 Problems Two SSDTs won't load because they have errors "AE_ALREADY_EXISTS", which you can see in the kernel.log SSDT-X299X-DESIGNARE10G-PC00-XHC.aml SSDT-X299X-DESIGNARE10G-PC00-SBUS.aml Sleep / wake problems: KP on Wake: I get a Kernel Panic on wake every time. Panic log is included in the ZIP in file: "panicOnWake-2020-11-07-181354.txt" Can't sleep with SBUS SSDT: If the SBUS SSDT loads OK (I have had it working in the past), then the system won't sleep - logs show "System sleep prevented by SBUS" I do not know if my Vega64 SSDT is correct, as I based it on a X5700 XT SSDT. And it is not correctly applying properties to the HDAU device (About This Mac -> PCI does not show the correct name for the GPU audio device) History A lot of the initial config.plist was created by a user on the Tonyx86 forum. He added a bunch of ACPI patches to config.plist, eg renaming PC00 to PCI0. I am not 100% sure why he did this, but I think it was so the system more closely resembled a real Mac Pro. You can see these renames in my config.plist But I have disabled them all because they prevent dual-booting Windows He also provided all the SSDTs I am using, but I had to edit most of them to get them to work without the ACPI patches. I'd be very grateful for some of your DSDT/SSDT magic! I'd be glad to make an additional donation if you're able to get things working a bit better for me. Many thanks for your time and your help in the past.

Yes, on my two systems I get more info from FakeSMC than with VirtualSMC, which is why I have never moved on from FakeSMC even though it is now 1+ years since last update.

I finally solved it Issue still happened with VirtualSMC, and when using the CLOVER.SERIES.CHIPSET. I took some more videos of the kernel panic log, and saw there were references to AHCI, and to the version number 999.1.1, which I vaguely remembered from a while ago. Answer: It was the AppleAHCIPort.kext from InsanelyMac, that I had installed 1-2 years ago! It was still in /Library/Extensions. I don't even remember why I installed it in 2018, but I don't need it any more on either of my Hacks, so I have removed it. I had to re-clone a 10.14.6 install onto the SSD and then re-install Catalina, because just deleting the .kext from the Catalina /Library/Extensions did not solve the problem. I guess it was still cached somewhere. But once I removed it from 10.14.6 then cloned and did the Catalina upgrade, it installed and rebooted fine. Lesson: when doing upgrades, check what random kexts are still installed from years ago, and remove any you no longer need! Thanks for the replies mald0n, as always.

[ref]MaLd0n[/ref], thanks for the fast reply. Unfortunately, no change. Upgraded to Clover 5096, and tried booting with no DSDT.aml, and the same KP happens at the same point. I tried making a video of the boot logs. It is hard because it scrolls so fast, but I got a very rough video frame capture from around the time it crashes: From this I can see: 1. It is a Kernel trap / page fault 2. There is some message right before it, " trying to set protected key "FM..something". It is hard to make out. I don't know if it's relevant. 3. The KP happens right after or during the loading of FakeSMC. Maybe this is significant. I am using the Rehabman/kozlex FakeSMC, last updated September 2018. I already tried booting with all FakeSMC kexts not injected, except for FakeSMC.kext itself. But perhaps this particular FakeSMC has problems with latest Catalina? After dinner I will try another FakeSMC, like VirtualSMC. Is there any particular FakeSMC that you recommend? Thanks again.

System: H77, Core i5-3550. AMD Vega 64 8GB GPU. iMacPro 1.1 SMBIOS. I was running 10.14.6 Mojave no problems. Two weeks ago I tried Catalina beta6, and it upgraded and worked fine. Later I tried to upgrade to beta 10, and after rebooting I got KP immediately on boot. Today I tried a fresh upgrade: I cloned 10.14.6 Mojave install to new SSD, booted 10.14.6 install to confirm 100% working, and also removed all 32bit apps. Then tried 10.15 upgrade from App Store. Upgrade seemed to run fine, but again I get KP almost immediately on first reboot. Screenshot showing result of booting with -v + don't reboot on panic (click for bigger): https://i.imgur.com/gQm0Qo2l.jpg' alt='IMGUR>'> Clover is 5070 UEFI. All kexts should be latest version. I have tried booting Clover without any injected Kexts, and KP happens exactly the same. DSDT was previously patched by mald0n last year and I think is OK. I have tested with both SMBIOS iMacPro 1.1 and iMac 14.2. Here are my RunMe! files, taken from working 10.14.6 install. I cannot boot into the 10.15 install to show logs from that. Send me H77-Marv.tom.tj.2019-10-11.zip Thanks very much in advance for any help.

[ref]duece[/ref], you may be right about things getting worse with 10.14.6. My X58 is back to the config it had been in for the past year, with the 7970Ghz/R9 280X connected to 5 monitors. This requires a sleep on boot to get a picture on all monitors (or in fact, on any monitor, since 10.14.5), but after that it is pretty solid. But in the last week I've had several occasions of the GPU hanging, just like I saw with the Vega 64. Same set of Console errors related to IOAcceleratorFamilyv2, especially the fence_timeout error, and mentions of GPURestart. The first time it happened was on Sunday, when I was still testing HW encode/decode in my other machine, the H77. Suddenly out of the blue the X58 hung. I rebooted it, and it got into a situation where it was hanging minutes after boot, every time. My first thought was that the major thing I'd changed recently was my config.plist and DSDT.aml, using the updated files that mald0n provided. So I reverted to my previous config, that I'd been using for the past year or more. But it kept freezing shortly after boot. So I went back to the mald0n config/DSDT, and also made some tweask to my OC, thinking that might have been different. And the issues went away. Since Sunday it had been stable again, until this morning. I usually leave the PC on all night, but with the monitors turned off at the mains. I turned them on this morning, all got a picture, but nothing in the GUI would respond. SSHing in revealed the usual set of errors, and I had to reboot. Since I rebooted it hasn't gone down again, although there was a brief GUI freeze of 1-2 seconds, during which another load of errors appeared in Console. But this time - and I think for the first time ever - it actually recovered and now seems OK. At this point the only thing that I can see that is different is that I'm now on 10.14.6. What I don't get is the randomness of it all. Running for days then freezing out of the blue, when the system isn't even being used. And last week, running for 24 hours without a hitch after I put the R9 280X back in, then after it froze once, it then kept freezing within minutes of every single subsequent restart. Then after I tried various combos of old and new configs, and ended up back on the config I was already using, it just started working again. God knows what's going on. But the sooner I get some new, UEFI HW the better I think. It does make me wonder if I should test the H77 with Vega on 10.14.5, to see if it makes any difference to the HW encode/decode freezes I could not get rid of. No time to do that at the moment, but maybe when I've finished my current project, I will. Though it will be depressing if that works, because that would leave me in the rut of needing an old version, not able to update.

For some definition of 'easiest' It certainly might work.. whether it's easy sounds like a whole different question. Certainly sounds complex to me. But yeah, for an expert maybe not. Trouble is, as you say, none of the experts are bothering with this old hardware any more. If I had money I'd be tempted to offer $100 to someone like vit9696 to try and investigate a solution. But of course, if I had money to throw around, I could just buy HW that didn't have the problem to begin with With regards to Clover, there is now an alternative: OpenCore. I know nothing about it besides that it exists and that some developers are moving towards it. I don't even know if it supports legacy. But it might be interesting to try for a UEFI system at least; seems like maybe it has more new development going into it. I tried your suggestion of WEG disabled and long story short, HW accel eventually crashed the GPU in the same way. Not having WEG did change a few things, for example DP1 had no signal, but HDMI1 did, and so did DP3. But DP3 would flicker and sometimes go blank (without any accompanying errors in Console). Felt like maybe it was choosing the wrong Framebuffer or something, which possibly could have been fixed with a Clover FB patch. But given it had the same HW accel crashes, I didn't test any further. I also tried Catalina, on a separate drive. I was impressed that Catalina installed very painlessly. I didn't even have to upgrade Clover to get as far as the update completing (I forgot to update Clover before starting). I then installed Clover 5070 on a new USB stick to boot into Catalina for the first time, and it was all there and working pretty smoothly. A few third party app issues; the Screenflick screen recording app won't work at all, just throws a numbered error as soon as I try to start recording. ffmpeg compiled with Homebrew segmentation faults immediately, even after having been recompiled from source using XCode 11.0. But downloading a snapshot from the ffmpeg website worked. Of course, I get the same GPU hangs on HW encode in Catalina as well. I expected nothing else at this stage. But I now appear to be in a situation where the errors/crash take somewhat longer to come. It took about 45 minutes of constant HW accel encode/decode in Catalina - combined with constant running of the Heaven benchmark to load up the GPU - before it crashed. Then the next time it was about 30 minutes. That's not new in Catalina though. Before running Catalina I had a similar result in 10.14.6. On a whim I tried adding back in -rad24 and -raddvi, which I used to use but had removed on account of them not seeing to change anything, besides the colour depth info listed in System Information. The first time I changed that I really thought I had it fixed: whereas the crashes had come after 2-6 minutes before, I ran for 40+ minutes of running Screenflick to record at 60 FPS, plus ffmpeg to encode h264 to h265, before finally it went down. Oh, one minor difference in Catalina is that after the errors came and the displays froze, a shutdown -r via SSH did actually reboot the system, eventually. To be precise, on the next boot I got one of those "Your computer was restarted because of a problem" messages, talking about "watchdog timeout: no checkins from watchdog in 95 seconds". So it might have been that shutdown killed the watchdogd which caused the kernel to auto reboot. The next time it went down I tried issuing a sleep, which did shut down the displays and eventually resulted in the system not responding on ping, but it never actually powered down. Not surprising. Another useful and pertinent Catalina change: Activity Monitor now has a % GPU and GPU Time column, as well as a GPU History graph: https://i.imgur.com/kgBczmd.png' alt='IMGUR>'> Somewhat useful. Anyway, no light at the end of the HW accelerated tunnel for me. Starting tomorrow I actually need to get some damn work done, so I'll probably just go back to the config I had before this week's frustrating testing: main X58 system using the R9 280X, H77 in Windows 10. I suppose I'll get some small benefit from the H77 now having the Vega 64 8GB instead of its previous NVidia 760 2GB, but if I can't do HW accelerated Premiere Pro exports, it's going to be a marginal benefit at best. Ho hum!

I'm not using shikivga with iMacPro 1.1. My two tested methods are: 1. iMacPro 1.1, with boot arguments: dart=0 kext-dev-mode=1 2. iMacPro 14.2, with boot arguments: dart=0 kext-dev-mode=1 shikigva=96 shiki-id=Mac-7BA5B2D9E42DDD94 But yes, I haven't tested iMacPro 1.1 without WEG entirely. Or rather, I haven't since I set CSM to disable. In the past when I've tried no WEG it's failed hard, but that was before I got the card working natively on the H77. You are right that's worth a test, and I will try that now. The other thing I'm going to test - with no hope of any change - is Catalina. I'm in the process of making a backup of my install to another SSD which I can safely try Catalina on without impacting any of my main installs. Yeah there are certainly plenty of possible problem areas. However, the genuine Mac Pro crowd are using shikivga=96 with h264 encode with seemingly no problems at all, including some using Vega 64s. So it should be possible in theory. I suppose there must be some other difference between real Mac HW and simulated Hack HW that's causing these problems. Maybe even some other EFI-related issue. I know other Hack users are using Vega 64 with HW accel with no iGPU, eg there's Pavo on InsanelyMac who uses 2 x E5-2670 v2 which have no iGPU, and is the same generation as my H77 (Ivy Bridge), with a RX Vega 64, and he says he has everything fully working, including HW accel. Although whether he's tried hitting the H264 encode as hard as I am, I don't know. And of course he has a much more powerful system than mine. That could even be another factor: performance. Maybe the GVA framework expects a certain level of performance, and my crappy 4-core i5 system simply isn't keeping up? And once it fails to do so once, the card never recovers. It could be something along those lines anyway - some timing issue. The fact that the failures are not predictable with regard to timing - it could be 1 minute, it could be 6 minutes before the first failure - does point to something variable rather than concrete. Though I did get the same kinds of crashes on the X58, which is quite a bit more powerful: 6 x cores at up to 4Ghz. I hope to be getting a new workstation fairly soon. Still can't decide what to get exactly, but a HP Z840 is definitely looking possible. That would put me on Haswell, with 16+ CPU cores, and a much more recent UEFI BIOS. I'm pretty confident things should work OK in that, based on what I read of other people with similar systems. But I don't have the time to do all the necessary research right now, so it'll probably have to wait a few more weeks before I can buy anything. In the meantime, assuming neither -wegoff nor Catalina performs any miracle, I'll likely be running the H77 in Windows to do encoding there. That is if I don't just return the Vega 64 entirely, ready to get a different GPU when I do finally get a new workstation. At least I can say I've advanced my Hack knowledge and experience somewhat in the last week, even if I've not so far achieved any config I'm happy with, and spent a vast amount of time in the process

A couple more bits of info, FWIW: Once I got the Vega 64 booting reliably in the H77 with CSM disabled, I experimented with InjectATI on and off. InjectATI off: Fans work normally. GPU detected as "Radeon RX Vega 64". Metal support listed as "Supported, GPUFamily 2v1". IOKit performance statistics/info messages are fully accurate. Geekbench score: 145k. Heaven uniEngine Benchmark result: 99-101 FPS. InjectATI on: Fans mostly at 100%. GPU detected as "AMD Radeon RX Vega 64". Metal support listed as "Supported". IOKit performance statistics/info messages are often inaccurate, eg showing Power Usage at 650W (impossible), Core Clock never going above 750Mhz even at 100% utilisation, and often VRAM Free/Used does not add up to the correct amount. Geekbench score: 200k. Heaven uniEngine Benchmark: 100-102 FPS. So nearly everything is better with InjectATI off. It's just that Geekbench 4 benchmark, consistent across both Metal and OpenCL benchmarks. But then the Heaven benchmark was the same in both modes. The end result is I am not using InjectATI, because it definitely introduces problems, and while one benchmark shows it to be faster, another shows no difference. On the HW h264 encode issue: I today booted into Windows 10 and recorded 25 minutes of a game at 60 FPS, high quality, no issues. So I am almost certain the card itself is fine. It's definitely some macOS/Hack issue. I get the h264 encode crashes both with iMacPro 1.1 and with iMac 14.2 with shikivga=96. I tried doing a sleep & wake, even though it's no longer needed for multi-monitor support, but that made no difference; h264 encode still freezes the GPU even after a sleep. So I am out of ideas on that one. I have a mostly working Vega 64 in the H77, but one of the main reasons I bought the card was to get h264 encode, and if that's not reliable then I think I will be forced to stay in Windows for now. So frustrating. For the record, here are the errors I get when the GPU freezes during h264 encode: kernel[0]: (IOAcceleratorFamily2) void IOAccelFenceMachine::fence_timeout(IOTimerEventSource *): AMDRadeonAccelerator prodding blockFenceInterrupt kernel[0]: (IOAcceleratorFamily2) void IOAccelFenceMachine::fence_timeout(IOTimerEventSource *): AMDRadeonAccelerator prodding blockFenceInterrupt kernel[0]: (IOAcceleratorFamily2) AMDRadeonAccelerator: IOAccelDisplayPipeTransaction time out after 300ms. framebufferIndex=5 kernel[0]: (IOAcceleratorFamily2) framebufferIndex=5, wsaa=17 kernel[0]: (IOAcceleratorFamily2) eventInterruptEnabled=0, transactionInterruptEnabled=1, vblInterruptEnabled=0 kernel[0]: (IOAcceleratorFamily2) powerOff=0, pipeTerminated=0, acceleratorEnabled=1, fWSAA=17 kernel[0]: (IOAcceleratorFamily2) lastIOGraphicsMessageEvent=93, fbIndex=5 kernel[0]: (IOAcceleratorFamily2) transactionQueueReadCount=12055, transactionQueueWriteCount=12056 kernel[0]: (IOAcceleratorFamily2) lastCompletedTransaction: ID=12054 dirtyBits=0x1 options=0x1 kernel[0]: (IOAcceleratorFamily2) pendingTransaction ID=12055, isTransactionComplete()=0, dirtyBits=0x1, options=0x1, errorCode=0x0, submittedReturn=0xe0014042 kernel[0]: (IOAcceleratorFamily2) readTransaction ID=12056, dirtyBits=0x1, options=0x1, errorCode=0x0, submittedReturn=0xe0014042, event hasn't finished kernel[0]: (IOAcceleratorFamily2) void IOAccelFenceMachine::fence_timeout(IOTimerEventSource *): AMDRadeonAccelerator prodding blockFenceInterrupt <last message repeated many times> kernel[0]: (IOAcceleratorFamily2) virtual IOReturn IOAccelEventMachine2::waitForStamp(int32_t, stamp_t, stamp_t *): initial wait for 1 second expired. Continue wait for 4 seconds. stamp 15313 (gpu_stamp=15312) kernel[0]: (IOAcceleratorFamily2) virtual IOReturn IOAccelEventMachine2::waitForStamp(int32_t, stamp_t, stamp_t *): initial wait for 1 second expired. Continue wait for 4 seconds. stamp 9557 (gpu_stamp=9556) kernel[0]: (IOAcceleratorFamily2) void IOAccelFenceMachine::fence_timeout(IOTimerEventSource *): AMDRadeonAccelerator prodding blockFenceInterrupt <last message repeated many times> kernel[0]: (IOAcceleratorFamily2) virtual IOReturn IOAccelEventMachine2::waitForStamp(int32_t, stamp_t, stamp_t *): timeout waiting for AMDRadeonAccelerator stamp 15313 (gpu_stamp=15312) kernel[0]: (IOAcceleratorFamily2) virtual IOReturn IOAccelEventMachine2::waitForStamp(int32_t, stamp_t, stamp_t *): timeout waiting for AMDRadeonAccelerator stamp 9557 (gpu_stamp=9556) kernel[0]: (IOAcceleratorFamily2) void IOAccelFenceMachine::fence_timeout(IOTimerEventSource *): AMDRadeonAccelerator prodding blockFenceInterrupt <last message repeated many times> kernel[0]: (IOAcceleratorFamily2) virtual void IOAccelEventMachineFast2::checkGPUProgress() - Signaling hardware error on channel 0.. kernel[0]: (IOAcceleratorFamily2) void IOAccelEventMachine2::signalHardwareError(eRestartRequest, int32_t): GPURestartEnqueued stampIdx=0 type=2 kernel[0]: (IOAcceleratorFamily2) virtual void IOAccelEventMachineFast2::checkGPUProgress() - Signaling hardware error on channel 2.. kernel[0]: (IOAcceleratorFamily2) void IOAccelEventMachine2::signalHardwareError(eRestartRequest, int32_t): GPURestartSignaled stampIdx=2 type=2 prevType=0 numStamps=22 kernel[0]: (IOAcceleratorFamily2) void IOAccelEventMachine2::signalHardwareError(eRestartRequest, int32_t): GPURestartEnqueued stampIdx=2 type=2 kernel[0]: (IOAcceleratorFamily2) virtual void IOAccelEventMachineFast2::checkGPUProgress() - Signaling hardware error on channel 5.. kernel[0]: (IOAcceleratorFamily2) void IOAccelEventMachine2::signalHardwareError(eRestartRequest, int32_t): GPURestartSignaled stampIdx=5 type=2 prevType=0 numStamps=22 kernel[0]: (IOAcceleratorFamily2) void IOAccelEventMachine2::signalHardwareError(eRestartRequest, int32_t): GPURestartEnqueued stampIdx=5 type=2 kernel[0]: (IOAcceleratorFamily2) virtual void IOAccelEventMachineFast2::checkGPUProgress() - Signaling hardware error on channel 6.. kernel[0]: (IOAcceleratorFamily2) void IOAccelEventMachine2::signalHardwareError(eRestartRequest, int32_t): GPURestartSignaled stampIdx=6 type=2 prevType=0 numStamps=22 kernel[0]: (IOAcceleratorFamily2) void IOAccelEventMachine2::signalHardwareError(eRestartRequest, int32_t): GPURestartEnqueued stampIdx=6 type=2 kernel[0]: (IOAcceleratorFamily2) virtual void IOAccelEventMachineFast2::checkGPUProgress() - Signaling hardware error on channel 12.. kernel[0]: (IOAcceleratorFamily2) void IOAccelEventMachine2::signalHardwareError(eRestartRequest, int32_t): GPURestartSignaled stampIdx=12 type=2 prevType=0 numStamps=22 kernel[0]: (IOAcceleratorFamily2) void IOAccelEventMachine2::signalHardwareError(eRestartRequest, int32_t): GPURestartEnqueued stampIdx=12 type=2 kernel[0]: (IOAcceleratorFamily2) virtual void IOAccelEventMachineFast2::checkGPUProgress() - Signaling hardware error on channel 17.. kernel[0]: (IOAcceleratorFamily2) void IOAccelEventMachine2::signalHardwareError(eRestartRequest, int32_t): GPURestartSignaled stampIdx=17 type=2 prevType=0 numStamps=22 kernel[0]: (IOAcceleratorFamily2) void IOAccelEventMachine2::signalHardwareError(eRestartRequest, int32_t): GPURestartEnqueued stampIdx=17 type=2 kernel[0]: (IOAcceleratorFamily2) virtual void IOAccelEventMachineFast2::checkGPUProgress() - Signaling hardware error on channel 18.. kernel[0]: (IOAcceleratorFamily2) void IOAccelEventMachine2::signalHardwareError(eRestartRequest, int32_t): GPURestartSignaled stampIdx=18 type=2 prevType=0 numStamps=22 kernel[0]: (IOAcceleratorFamily2) void IOAccelEventMachine2::signalHardwareError(eRestartRequest, int32_t): GPURestartEnqueued stampIdx=18 type=2 kernel[0]: (IOAcceleratorFamily2) virtual void IOAccelEventMachineFast2::checkGPUProgress() - Signaling hardware error on channel 19.. kernel[0]: (IOAcceleratorFamily2) void IOAccelEventMachine2::signalHardwareError(eRestartRequest, int32_t): GPURestartSignaled stampIdx=19 type=2 prevType=0 numStamps=22 kernel[0]: (IOAcceleratorFamily2) void IOAccelEventMachine2::signalHardwareError(eRestartRequest, int32_t): GPURestartEnqueued stampIdx=19 type=2 kernel[0]: (IOAcceleratorFamily2) void IOAccelEventMachine2::hardwareErrorEvent(): setting restart type to 2 (channel 0) kernel[0]: (IOAcceleratorFamily2) void IOAccelEventMachine2::hardwareErrorEvent(): GPURestartDequeued stampIdx=0 type=2 kernel[0]: (AMDRadeonX5000) [3:0:0]: channel 0 event timeout kernel[0]: (IOAcceleratorFamily2) void IOAccelFenceMachine::fence_timeout(IOTimerEventSource *): AMDRadeonAccelerator prodding blockFenceInterrupt kernel[0]: (IOAcceleratorFamily2) void IOAccelFenceMachine::fence_timeout(IOTimerEventSource *): AMDRadeonAccelerator prodding blockFenceInterrupt kernel[0]: (IOAcceleratorFamily2) void IOAccelFenceMachine::fence_timeout(IOTimerEventSource *): AMDRadeonAccelerator prodding blockFenceInterrupt kernel[0]: (IOAcceleratorFamily2) virtual IOReturn IOAccelEventMachine2::waitForStamp(int32_t, stamp_t, stamp_t *): a graphics error occurred, exitting.. kernel[0]: (IOAcceleratorFamily2) virtual IOReturn IOAccelEventMachine2::waitForStamp(int32_t, stamp_t, stamp_t *): a graphics error occurred, exitting.. kernel[0]: (IOAcceleratorFamily2) void IOAccelFenceMachine::fence_timeout(IOTimerEventSource *): AMDRadeonAccelerator prodding blockFenceInterrupt kernel[0]: (AMDRadeonX5000) [3:0:0]: channel 0 GFX is hung! (lastReadTimestamp=0x0001212a) channelResetMask 0x00000000 kernel[0]: (AMDRadeonX5000HWLibs) AMD Cail: [3:0:0] GPU HangState 0x00000040, HangFlags 0x00000005: IndividualEngineHang 1, NonEngineBlockHang 0, FenceNotRetired 1, PerEngineReset 1, FullAsicReset 0 kernel[0]: (AMDRadeonX5000HWLibs) [3:0:0] GPU HangState 0x00000040, HangFlags 0x00000005: IndividualEngineHang 1, NonEngineBlockHang 0, FenceNotRetired 1, PerEngineReset 1, FullAsicReset 0 kernel[0]: (IOAcceleratorFamily2) virtual sIOAccelEvent *IOAccelFIFOChannel2::getFirstPendingEvent(): All are finished kernel[0]: (IOAcceleratorFamily2) virtual sIOAccelEvent *IOAccelFIFOChannel2::getFirstPendingEvent(): All are finished kernel[0]: (IOAcceleratorFamily2) virtual sIOAccelEvent *IOAccelFIFOChannel2::getFirstPendingEvent(): All are finished kernel[0]: (IOAcceleratorFamily2) virtual sIOAccelEvent *IOAccelFIFOChannel2::getFirstPendingEvent(): All are finished kernel[0]: (IOAcceleratorFamily2) virtual sIOAccelEvent *IOAccelFIFOChannel2::getFirstPendingEvent(): All are finished kernel[0]: (IOAcceleratorFamily2) virtual sIOAccelEvent *IOAccelFIFOChannel2::getFirstPendingEvent(): All are finished kernel[0]: (IOAcceleratorFamily2) virtual sIOAccelEvent *IOAccelFIFOChannel2::getFirstPendingEvent(): All are finished kernel[0]: (IOAcceleratorFamily2) virtual sIOAccelEvent *IOAccelFIFOChannel2::getFirstPendingEvent(): All are finished kernel[0]: (IOAcceleratorFamily2) virtual sIOAccelEvent *IOAccelFIFOChannel2::getFirstPendingEvent(): All are finished kernel[0]: (IOAcceleratorFamily2) void IOAccelFenceMachine::fence_timeout(IOTimerEventSource *): AMDRadeonAccelerator prodding blockFenceInterrupt kernel[0]: (AMDRadeonX5000) [3:0:0] ** AMDRadeonX5000_AMDVega10GraphicsAccelerator Device in slot: SLOT--1 ** kernel[0]: (IOAcceleratorFamily2) Trying to restart GPU (Radeon RX Vega 64)... kernel[0]: (AMDSupport) AMD Recovery Display. kernel[0]: (Sandbox) Sandbox: tailspin(1751) deny(1) sysctl-write kern.procname

I've been testing for several hours and it's late and I'm too tired - and still disillusioned - to do a full report. I'll do one tomorrow. The TLDR is: 1. With CSM disabled on the H77, the multi-display issue appears completely gone. I can boot with multiple monitors connected, no need to sleep. 2. HW accel encode appeared fixed at first; I was able to export my larger Premiere Pro project, which took 30+ minutes. 3. But it's not fixed fully. Using a screen recording app called Screenflick, recording a full screen game at 1080p 60 FPS, the GPU will crash within 1 - 5 minutes of the recording starting. The usual long list of IOAccel errors in Console, with all displays freezing. The system remains accessible via SSH, but a shutdown doesn't complete, so the only option is a hardware reboot or shutdown via power switch. 4. Tested with both iMacPro 1.1, and with my original SMBIOS for that machine, iMac 14.2 with the shikivga=96 ... config line. Identical results with both. This may end up being a usable config at least for Premiere Pro encoding, if it proves that it never crashes in that config - which I don't think is guaranteed by any means. But it's clearly not 'fixed'. At this point I have no idea if this is specific to the Vega 64 or not. It could even be specific to *this* Vega 64, although I doubt it. What this has told me - belatedly - is that there's very likely no chance of getting this working on my X58, or any system without a proper UEFI CSM. Don't know what that means for your system, dueces, but I'd presume it's the same as mine; if you had a CSM option to disable that would fix it, I imagine you'd have found it by now. I'll write a bit more tomorrow.

Errr OMG I just got the Vega 64 to boot on my H77 with two monitors connected, one HDMI. I did it by setting CSM to Disabled in BIOS. I've literally never tried that before... More testing starting now...

But I have the same issues with Vega 64 in my H77 which has UEFI and CSM. So I think there is more to it than this

I've effectively given up for now. Latest results: I mentioned earlier that I had a theory that my h264 encoding freezes might be related to OCing, on the basis that earlier in the week had a BSOD in Windows 10 when doing h264 encoding on the Vega, and that after I lowered the OC a bit, it didn't return. So earlier today I tried completely removing the OC on my X58, reverting to stock speeds with everything on AUTO. Initial results were positive: for the first time ever I got a Premiere Pro export to work with HW accel, successfully exporting a 5 minute video with no errors in Console. So then I tried a much longer project, and within 10 minutes Console was flooded with errors and all displays froze. Next I put the Vega 64 into my second Hack, the H77. This is my UEFI machine, not overclocked. I installed my second, backup SSD in the H77 so it was running the same software as my X58, including my exact Premiere Pro/After Effects install. (Everything the same except the EFI partition, which I booted from USB so as to use my H77 DSDT + config) The Vega behaved exactly the same in the H77 as it did in the X58, in all respects: from boot, a single DP works, but plugging in a second display will cause all monitors to go black, and force a restart. After sleep & wake, all ports worked. InjectATI was required to get full Geekbench 4 performance. Just about the only difference noticeable on the H77 was that using the iMacPro 1.1 SMBIOS on the H77 did not affect Speedstep. As for HW accel: same shit. After about 10 minutes of exporting the same Premiere Pro project, the Console filled with all the same errors and the machine was dead. So I basically give up for now. The irony is I never planned to buy a new GPU yet, I was going to wait until I was ready to buy a better workstation. But I was doing a lot of Premiere Pro and After Effects work, and I thought getting a new GPU now might speed things up. Ha! I've lost about 4 days from fucking around trying to get it to work, and now I'm back where I started. Well, not completely. The Vega 64 is still in my second machine, booted into Windows 10, and maybe it will provide some benefit there. Though not much, as Premiere Pro/After Effects can't use AMD encode acceleration in Windows, only Intel. I may even return the Vega. I bought it from Amazon, so I still have 3 weeks in which I can return it. Maybe the Vega 64 is just a bad card. I'd really like to get the VII Pro, as not only is it much more powerful and has 16GB, but it's also a card that's used in a real Mac - or will be when the 2019 Pro comes out. Of course it's stupidly expensive, so I doubt I'll be able to. I've seriously thought about whether I should buy a real Mac for my 'new' computer. If the 2013 Mac Pro wasn't so shit I probably would do. But it can't be expanded, and I really need 10 Gbe internet and a modern GPU, and I can't afford a new workstation plus Thunderbolt enclosures and the like. And buying the classic Mac Pro just seems silly; spending upwards of £1000 on a system that's of exactly the same generation as the one I already have. The easiest and safest thing to do would be to buy a system with a recent Intel consumer CPU, with Intel HD, like mald0n was saying. But then I will be very limited in PCIe lanes, and probably limited in RAM as well, and I wouldn't be able to go dual CPU, I'm really tempted by something like the HP Z840, which can give me 16+ cores over 2 CPUs, 64, 96GB or even 128GB of RAM, and all the PCIe slots I could ever need. But that wouldn't have an iGPU, so maybe I'd end up stuck with all the same problems. If only Apple weren't being such c***s about NVidia. Having the NVidia web drivers available would open a huge range of new cards and likely solve all these problems. I suppose I could go back to High Sierra, but I really don't like running an OS that's too old. That just introduces more problems over time. I'll already not be updating to Catalina for a while because of the stupid removal of 32bit support; being two OS' old just seems like too much. Geez, what a mess.

Yeah, the whole problem we have is we have no iGPU, so no way to use any Intel acceleration Added in 1 minute 11 seconds: And what about without deinit? I get the fan spinning up also only with InjectATI, but I take that as a good sign - because that was a known issue with the Vega 64 card, and possibly still is, at least with my Gigabyte OC which I have heard has its own fan controller. Though in my case it is just the fan spinning up - not also an increase in power usage, at least not according to the stats put into IOKit, as read by HWMonitorSMC2. It's common for me to see 2600RPM fan, with 0% utilisation and ~20W power usage. Ironically, the way to get the fan to stop spinning at full speed - at least for a time - is to put some load on the GPU, ie start playing a video. This is again a common experience from what I've read of other Vega 64 users, both Hack and real Mac Pro users. Though it was meant to be resolved in 10.14.5. So I am assuming the reason it is not resolved for me is my specific choice of Vega 64, as I found at least one site that mentioned the Gigabyte OC Vega 64s were an exception to the general fixes for fan spin, due to their proprietary fan controller. Without InjectATI I get 25% lower GeekBench 4 scores, and one time I actually had the system freeze when I tried to run the Heaven UniEngine benchmark, which didn't happen with InjectATI All I am setting is InjectATI - I don't set any of the other options in the same area. Which I believe means (though I may be wrong), that all InjectATI is doing is injecting the GPU name that Clover detects, which is "AMD Radeon RX Vega 64", versus the "Radeon RX Vega 64" that WEG puts in. Other settings, eg FBName, are all blank in my config. If I'm correct about that, then that would mean that some part of the Apple drivers is looking for a particular GPU name and being affected by it? You'd think it would be based off the Vendor ID / Card ID. So maybe there's more to it than that. I've never properly tried RadeonDeInit, so I don't really know what that does. I only tested it briefly, days ago, when I was seeing if there was any way to get rid of the need to sleep&wake. I had the impression it was an old param intended for much older cards/older versions of macOS/Clover, but who knows

I am using dart=0, and no darkwake line because mald0n's config didn't have it, and I never knew if it was doing anything anyway. I can sleep & wake fine, although sometimes it will sleep but then not wake up properly - the power light comes on, but displays never wake up, and the machine doesn't respond to ping. I imagine it's GPU related as it first started happening since I installed the Vega. I tried RadeonDeinit a couple of times and didn't notice it making any difference. However Clover's InjectATI makes a very important difference for me. Specifically: 1. It changes my GPU name from "Radeon RX Vega 64" (WEG only) to "AMD Radeon RX Vega 64" (WEG + InjectATI) 2. It changes the System Info->Graphics/Displays Metal info from: "Metal: Supported, macOS GPUFamily 2 v1" (WEG only) to "Metal: Supported" (WEG + InjectATI) 3. My Geekbench 4 score increases from ~145k (WEG only) to ~200k (WEG + InjectATI) I don't understand quite what InjectATI does, or why it makes this important difference, but clearly I need it for full GPU performance. It's possible literally all it is doing is changing the GPU name, in which case I could likely achieve the same thing with a WEG SSDT. But I haven't tested that. My current situation: 1. Using iMacPro 1.1 SMBIOS + mald0n's config.plist + mald0n's DSDT.aml. Plus I have added Clover's InjectATI to config.plist, which I need for full GPU performance. 2. From boot, I do not have working CPU PM: CPUs are locked at x12 multiplier 3. After sleep & wake, power management works OK: CPU multipliers x12 - x24 4. I have working h264 + h265 HW encode/decode. However, trying to use h264 encode often results in GPU freezes. This may be related to OC settings, as I have also had occasional issues in Windows 10. But, it's much worse in macOS. 5. I cannot use MacPro 5.1 SMBIOS as my 4K@60 display (DisplayPort 1.2) will never connect at 4K@60. It either connects at 2084x1080, or 4K@30, but almost never at 4K@60. 6. With iMacPro 1.1 SMBIOS, my 4K display always connects at 4K@60. However, it often does not display a picture. After sleep&wake I often have to unplug/replug it multiple times until it shows a picture. And I need to disable Display Sleep, as if the display goes to sleep, it will again lose the picture on the 4K after the displays wake up. 7. In Console, I get occasional errors like these: 2019-09-21 12:05:27.467141+0100 localhost kernel[0]: (IOAcceleratorFamily2) <IOAcceleratorFamily2`IOAccelEventMachine2::waitForStamp(int, unsigned int, unsigned int*)> virtual IOReturn IOAccelEventMachine2::waitForStamp(int32_t, stamp_t, stamp_t *): initial wait for 1 second expired. Continue wait for 4 seconds. stamp 1 (gpu_stamp=0) 2019-09-21 12:05:31.467235+0100 localhost kernel[0]: (IOAcceleratorFamily2) <IOAcceleratorFamily2`IOAccelEventMachine2::waitForStamp(int, unsigned int, unsigned int*)> virtual IOReturn IOAccelEventMachine2::waitForStamp(int32_t, stamp_t, stamp_t *): timeout waiting for AMDRadeonAccelerator stamp 1 (gpu_stamp=0) 2019-09-21 12:10:03.491975+0100 localhost kernel[0]: (IOAcceleratorFamily2) <IOAcceleratorFamily2`IOAccelFenceMachine::fence_timeout(IOTimerEventSource*)> void IOAccelFenceMachine::fence_timeout(IOTimerEventSource *): AMDRadeonAccelerator prodding blockFenceInterrupt 2019-09-21 12:10:03.601648+0100 localhost kernel[0]: (IOAcceleratorFamily2) <IOAcceleratorFamily2`IOAccelFenceMachine::fence_timeout(IOTimerEventSource*)> void IOAccelFenceMachine::fence_timeout(IOTimerEventSource *): AMDRadeonAccelerator prodding blockFenceInterrupt 2019-09-21 13:22:36.958127+0100 localhost kernel[0]: (IOAcceleratorFamily2) <IOAcceleratorFamily2`IOAccelDisplayPipe2::event_interrupt_gated()> AMDRadeonAccelerator [0]: transaction ID (165047) generated error (0xe00002d5). dirtyBits=0x1, options=0x1 2019-09-21 14:22:32.075500+0100 localhost kernel[0]: (IOAcceleratorFamily2) <IOAcceleratorFamily2`IOAccelDisplayPipe2::event_interrupt_gated()> AMDRadeonAccelerator [0]: transaction ID (184995) generated error (0xe00002d5). dirtyBits=0x1, options=0x1 All those errors are since my last boot, 2.5 hours ago. They are not terminal, but maybe result in slowdowns or something, I am not sure. However if I do extended h264 encoding, I will sometimes get a bunch of the blockFenceInterrupt errors, plus errors about GPURestart, and then all displays crash, and the system has to be rebooted. [ref]MaLd0n[/ref], do you think there is any further improvement that can be made to my system? I know you have done a lot of work on it already. I'd be grateful if you could let me know if you think anything more can be done. I am planning to buy a new PC sometime soon - my first 'new' PC in 9 years (new to me, though I will buy it used.) I am thinking maybe an HP Z840 workstation, as I need more PCIe lanes than modern CPUs have, eg for 10Gbe ethernet. But even if/when I get a new PC, I will still hope to use this one as a secondary system with a modern AMD GPU, eg RX 580.

Ah yeah, the HWMonitor stuff is useful. I take it you've tried the various FakeSMC variations to confirm none offer more info? I re-did that comparison yesterday, comparing two: RehabMan/Kozlek vit9696's VirtualSMC The former is the one I have used for a long time, and is the one I'm still using now. It provides the info you saw earlier, with its own bundled HWMonitor.app. The latter I tried in case it provided more GPU data on the Vega. It doesn't have a bundled HWMonitor, so I used HWMonitorSMC2, which looks a bit different to HWMonitor, and does have one useful feature - it has an option for reading GPU data from IOKit, meaning it can read all the utilisation/performance stats that GPUs like the Vega 64 now write there (and which is also accessible from command line using ioreg). I ended up uninstalling vit9696's VirtualSMC and going back to RehabMan's, even though that's not been updated in a year or so. And because HWMonitor is the only one that shows the Frequency info, and HWMonitorSMC2 is the only one that shows the Vega 64 info, I now have both running I've edited my previous post - turns out this issue existed also with my original DSDT and config.plist as well. It appears that this is yet another issue that requires a sleep & wake: before sleep, my CPU won't go above x12. After sleep, it's normal x12-x22, with x24 on turbo boosting cores. I have no idea how long this issue has existed for, because for the last 1+ years I have always put the system to sleep as soon as I got to the login screen, due to my ongoing GPU issues. I know that I haven't had the issue always, because back in High Sierra there was a time when I used an NVidia GPU, and didn't have to sleep. I know my frequencies were right then. So it could be the issue has come with 10.14.0 or a later update. Or it could be a result of switching to iMacPro 1.1. No idea. Right now it's moot, because I have to sleep & wake shortly after boot anyway. If I ever get that solved, I'll investigate it further.

[ref]MaLd0n[/ref], FYI I noticed that with latest DSDT you provided, my processor is always at x12 multiplier, like this: EDIT: Sorry, this is not related to new DSDT/config.plist. I have done more testing and same happens with old as well. It appears that before sleep, I only have x12 multiplier. After sleep & wake, I have full x22-x24, and this is same with both my original DSDT/config.plist, and the ones you have sent me. I do not know for sure if this is new behaviour or not, as before I would always put my machine to sleep at login screen. So maybe this issue has always been there.

What makes you say that? Have you read something to that effect? All I know is that I've been living with the same general issue since 10.13, first starting with my my previous GPU the R9 280X, which is now installed in my second Hack, the H77. It's worse on the Vega in that I can only boot with one monitor connected, else I can't sleep and have to reboot. But the general principle of needing to sleep in order to see a picture on all monitors has existed for me since I first installed my R9 280X over a year ago, in 10.13.x. It changed a bit in 10.14.0 in that I also started to get errors in Console, and the kernel using high CPU until a sleep was done. But the fundamental issue has remained unchanged - and unsolvable by me, despite tens of hours of trying things like FB patching, SSDTs, and every possible permutation of WEG/Clover options. Or rather, trying the options I understood - which is certainly not all of them. So based on my own experiences, I'm not seeing .6 being any different. It certainly hasn't affected my symptoms thus far. All that said, I'm certainly willing to test in .5 if there's some reason to think it would make a difference. I can restore a network backup to my spare SSD; my most recent one is from June which should be 10.14.5. Worst case the backup will be 10.14.1, in which case I can upgrade to .5 via the standalone downloads on support.apple.com.

[ref]MaLd0n[/ref], short answer: yes I can sleep & wake OK with new DSDT you provided. Full results: First boot, one monitor connected (port DP1): Boot to login screen. Click sleep. Machine sleeps. Press power to wake, machine wakes OK. Then I log in. I try sleep again. Machine sleeps. Press power to wake, machine powers on, but does not properly wake: no picture on monitor, machine cannot be pinged on network. I had to press reset button. But I had this same problem one time earlier today as well, so this is probably not connected to new DSDT. [*]Second boot (same one monitor), boot to login & sleep/wake OK. Then sleep again, this time it wakes fine. As you said, I could only wake with power button, not keyboard. Note: I did one test booting with multiple monitors connected, and there was no change - black screen, could not sleep. Probably this is expected, I just mention to be complete. Thanks again for all the work you are doing for me, it is really appreciated.

Sounds similar to what I see, except I've not seen any solid green. If I boot with only DP1 connected, everything is fine, but if any more monitors are connected before a sleep is done, then all monitors are black, and sleep fails. If your situation is like mine, then sleep & wake is going to be your only solution for the time being (pending any magic from mald0n), and I doubt WEG is the difference between being able to sleep or not. You're very likely going to need a proper DSDT to get the ability to sleep. Certainly I've needed a DSDT for a long time. I could get away without one in 10.11 and 10.12, but the first time I tried to upgrade to Sierra my system went haywire - not only wouldn't it boot, but every time I tried to boot, it changed all my BIOS settings to random values Which given I had a finely tuned and complex OC, was quite a big annoyance Admittedly my HW is even older than yours, and not even UEFI. But still; being unable to sleep is a very common situation of not having a proper DSDT, from what I've read. I eventually came back about 6 months later, and went straight to High Sierra, and this time learnt about doing things from scratch. I got a proper DSDT, thanks to a lengthy thread on InsanelyMac regarding the Gigabyte X58 series of motherboards, and that fixed sleep/wake, power management/speedstep, onboard audio, and a whole bunch more things. Not sure why you'd need to force load WEG? Just put it into EFI/CLOVER/kexts/Other? Along with Lilu of course.