Contribute
Register

How to build your own iMac Pro [Successful Build/Extended Guide]

Status
Not open for further replies.


Looks similar to the KP I previously encountered when waking up the hack from sleep.

Code:
Fri Jan 19 08:19:14 2018

*** Panic Report ***
panic(cpu 0 caller 0xffffff800616e2f9): Kernel trap at 0xffffff800618c664, type 13=general protection, registers:
CR0: 0x0000000080010033, CR2: 0x000000010d359000, CR3: 0x000000001c2d6000, CR4: 0x00000000003627e0
RAX: 0x000000007e008003, RBX: 0xffffff8006857320, RCX: 0x00000000000000e2, RDX: 0x0000000000000000
RSP: 0xffffff8203e4bbf0, RBP: 0xffffff8203e4bc20, RSI: 0x0000000000000003, RDI: 0xffffff80068572c0
R8:  0x0000000100000201, R9:  0xffffff8009757036, R10: 0x0000000000000003, R11: 0xffffff80067705ab
R12: 0xffffff8006777f56, R13: 0x0000000000000001, R14: 0x0000000000000000, R15: 0xffffff8006777f3c
RFL: 0x0000000000010046, RIP: 0xffffff800618c664, CS:  0x0000000000000008, SS:  0x0000000000000010
Fault CR2: 0x000000010d359000, Error code: 0x0000000000000000, Fault CPU: 0x0, PL: 0, VF: 0

Backtrace (CPU 0), Frame : Return Address
0xfffffd000004c270 : 0xffffff800604f5f6 mach_kernel : _handle_debugger_trap + 0x506
0xfffffd000004c2c0 : 0xffffff800617c6f4 mach_kernel : _kdp_i386_trap + 0x114
0xfffffd000004c300 : 0xffffff800616e109 mach_kernel : _kernel_trap + 0x5e9
0xfffffd000004c380 : 0xffffff8006001120 mach_kernel : _return_from_trap + 0xe0
0xfffffd000004c3a0 : 0xffffff800604f02c mach_kernel : _panic_trap_to_debugger + 0x25c
0xfffffd000004c4d0 : 0xffffff800604edac mach_kernel : _panic + 0x5c
0xfffffd000004c530 : 0xffffff800616e2f9 mach_kernel : _kernel_trap + 0x7d9
0xfffffd000004c6b0 : 0xffffff8006001120 mach_kernel : _return_from_trap + 0xe0
0xfffffd000004c6d0 : 0xffffff800618c664 mach_kernel : _xcpm_perf_bias_set + 0x294
0xffffff8203e4bc20 : 0xffffff800618c96e mach_kernel : _xcpm_init + 0xde
0xffffff8203e4bc60 : 0xffffff800617ac41 mach_kernel : _acpi_sleep_kernel + 0x471
0xffffff8203e4bcd0 : 0xffffff7f886d5028 com.apple.driver.AppleACPIPlatform : __ZN23AppleACPIPlatformExpert13sleepPlatformEv + 0x1ee
0xffffff8203e4bd20 : 0xffffff7f886d9485 com.apple.driver.AppleACPIPlatform : __ZN12AppleACPICPU7haltCPUEv + 0x75
0xffffff8203e4bd40 : 0xffffff80066afd28 mach_kernel : __Z16IOCPUSleepKernelv + 0x248
0xffffff8203e4bd90 : 0xffffff80066dd6a5 mach_kernel : __ZN14IOPMrootDomain15powerChangeDoneEm + 0x335
0xffffff8203e4be00 : 0xffffff80066780ab mach_kernel : __ZN9IOService8all_doneEv + 0x6fb
0xffffff8203e4be50 : 0xffffff8006675298 mach_kernel : __ZN9IOService23actionPMWorkQueueInvokeEP11IOPMRequestP13IOPMWorkQueue + 0x878
0xffffff8203e4beb0 : 0xffffff80066722c3 mach_kernel : __ZN13IOPMWorkQueue17checkRequestQueueEP11queue_entryPb + 0x43
0xffffff8203e4bef0 : 0xffffff8006672152 mach_kernel : __ZN13IOPMWorkQueue12checkForWorkEv + 0x82
0xffffff8203e4bf30 : 0xffffff800668e872 mach_kernel : __ZN10IOWorkLoop15runEventSourcesEv + 0x1e2
0xffffff8203e4bf70 : 0xffffff800668deac mach_kernel : __ZN10IOWorkLoop10threadMainEv + 0x2c
0xffffff8203e4bfa0 : 0xffffff80060004f7 mach_kernel : _call_continuation + 0x17
      Kernel Extensions in backtrace:
         com.apple.driver.AppleACPIPlatform(6.1)[F3FE62D2-09B6-33CC-8BEF-680B9D05A8BD]@0xffffff7f886c9000->0xffffff7f88764fff
            dependency: com.apple.iokit.IOACPIFamily(1.4)[8794C760-FDD9-3664-ADED-4A9BBEC6E517]@0xffffff7f87448000
            dependency: com.apple.iokit.IOPCIFamily(2.9)[5FDD9BD2-2824-32FE-846C-103A487FC2E2]@0xffffff7f86894000
            dependency: com.apple.driver.AppleSMC(3.1.9)[259F0A4B-0AAB-30F3-8896-629A102CBD70]@0xffffff7f87451000

BSD process name corresponding to current thread: kernel_task
Boot args: darkwake=1 npci=0x2000 keepsyms=1 debug=0x100

What fixed this for me was to enable the kernel patch xcpm_core_scope_msrs © Pike R. Alpha.
Even with a patched BIOS (to unlock the MSR 0x02 register) I must enable the patch to avoid KP on wake.

Interesting. Same tracedump. So it means that this KP is also triggered when waking up from sleep. :thumbup:

So maybe by resolving the sleep issue we'll be able to resolve the KP that's happening to us during long periods of uptime!
 


Looks similar to the KP I previously encountered when waking up the hack from sleep.

Code:
Fri Jan 19 08:19:14 2018

*** Panic Report ***
panic(cpu 0 caller 0xffffff800616e2f9): Kernel trap at 0xffffff800618c664, type 13=general protection, registers:
CR0: 0x0000000080010033, CR2: 0x000000010d359000, CR3: 0x000000001c2d6000, CR4: 0x00000000003627e0
RAX: 0x000000007e008003, RBX: 0xffffff8006857320, RCX: 0x00000000000000e2, RDX: 0x0000000000000000
RSP: 0xffffff8203e4bbf0, RBP: 0xffffff8203e4bc20, RSI: 0x0000000000000003, RDI: 0xffffff80068572c0
R8:  0x0000000100000201, R9:  0xffffff8009757036, R10: 0x0000000000000003, R11: 0xffffff80067705ab
R12: 0xffffff8006777f56, R13: 0x0000000000000001, R14: 0x0000000000000000, R15: 0xffffff8006777f3c
RFL: 0x0000000000010046, RIP: 0xffffff800618c664, CS:  0x0000000000000008, SS:  0x0000000000000010
Fault CR2: 0x000000010d359000, Error code: 0x0000000000000000, Fault CPU: 0x0, PL: 0, VF: 0

Backtrace (CPU 0), Frame : Return Address
0xfffffd000004c270 : 0xffffff800604f5f6 mach_kernel : _handle_debugger_trap + 0x506
0xfffffd000004c2c0 : 0xffffff800617c6f4 mach_kernel : _kdp_i386_trap + 0x114
0xfffffd000004c300 : 0xffffff800616e109 mach_kernel : _kernel_trap + 0x5e9
0xfffffd000004c380 : 0xffffff8006001120 mach_kernel : _return_from_trap + 0xe0
0xfffffd000004c3a0 : 0xffffff800604f02c mach_kernel : _panic_trap_to_debugger + 0x25c
0xfffffd000004c4d0 : 0xffffff800604edac mach_kernel : _panic + 0x5c
0xfffffd000004c530 : 0xffffff800616e2f9 mach_kernel : _kernel_trap + 0x7d9
0xfffffd000004c6b0 : 0xffffff8006001120 mach_kernel : _return_from_trap + 0xe0
0xfffffd000004c6d0 : 0xffffff800618c664 mach_kernel : _xcpm_perf_bias_set + 0x294
0xffffff8203e4bc20 : 0xffffff800618c96e mach_kernel : _xcpm_init + 0xde
0xffffff8203e4bc60 : 0xffffff800617ac41 mach_kernel : _acpi_sleep_kernel + 0x471
0xffffff8203e4bcd0 : 0xffffff7f886d5028 com.apple.driver.AppleACPIPlatform : __ZN23AppleACPIPlatformExpert13sleepPlatformEv + 0x1ee
0xffffff8203e4bd20 : 0xffffff7f886d9485 com.apple.driver.AppleACPIPlatform : __ZN12AppleACPICPU7haltCPUEv + 0x75
0xffffff8203e4bd40 : 0xffffff80066afd28 mach_kernel : __Z16IOCPUSleepKernelv + 0x248
0xffffff8203e4bd90 : 0xffffff80066dd6a5 mach_kernel : __ZN14IOPMrootDomain15powerChangeDoneEm + 0x335
0xffffff8203e4be00 : 0xffffff80066780ab mach_kernel : __ZN9IOService8all_doneEv + 0x6fb
0xffffff8203e4be50 : 0xffffff8006675298 mach_kernel : __ZN9IOService23actionPMWorkQueueInvokeEP11IOPMRequestP13IOPMWorkQueue + 0x878
0xffffff8203e4beb0 : 0xffffff80066722c3 mach_kernel : __ZN13IOPMWorkQueue17checkRequestQueueEP11queue_entryPb + 0x43
0xffffff8203e4bef0 : 0xffffff8006672152 mach_kernel : __ZN13IOPMWorkQueue12checkForWorkEv + 0x82
0xffffff8203e4bf30 : 0xffffff800668e872 mach_kernel : __ZN10IOWorkLoop15runEventSourcesEv + 0x1e2
0xffffff8203e4bf70 : 0xffffff800668deac mach_kernel : __ZN10IOWorkLoop10threadMainEv + 0x2c
0xffffff8203e4bfa0 : 0xffffff80060004f7 mach_kernel : _call_continuation + 0x17
      Kernel Extensions in backtrace:
         com.apple.driver.AppleACPIPlatform(6.1)[F3FE62D2-09B6-33CC-8BEF-680B9D05A8BD]@0xffffff7f886c9000->0xffffff7f88764fff
            dependency: com.apple.iokit.IOACPIFamily(1.4)[8794C760-FDD9-3664-ADED-4A9BBEC6E517]@0xffffff7f87448000
            dependency: com.apple.iokit.IOPCIFamily(2.9)[5FDD9BD2-2824-32FE-846C-103A487FC2E2]@0xffffff7f86894000
            dependency: com.apple.driver.AppleSMC(3.1.9)[259F0A4B-0AAB-30F3-8896-629A102CBD70]@0xffffff7f87451000

BSD process name corresponding to current thread: kernel_task
Boot args: darkwake=1 npci=0x2000 keepsyms=1 debug=0x100

What fixed this for me was to enable the kernel patch xcpm_core_scope_msrs © Pike R. Alpha.
Even with a patched BIOS (to unlock the MSR 0x02 register) I must enable the patch to avoid KP on wake.


Hey you may have something here @JimmyS,

I too can confirm through my observations that I did notice to either begin to have/or just noticed the KPs happening once I was suggested to disable the kernel patch xcpm_core_scope_msrs © Pike R. Alpha. I know you guys say sleep and things wasn't working but I want to say sleep wasn't an issue in the very beginning of my build....actually was quite responsive on waking up. This could be something to look in to.
 
@AnaktuvGod could you try to check if you can trigger the same KP with your current configuration when sleep/waking the computer? (note that I've had success triggering KP when letting it to sleep for about 2min, if woken up too soon like a few seconds it seems to wake up just fine)

I believe the issue comes from a device that is misbehaving on our board.
 
power sleep testing.png

Testing...
 
Just want to add that @JimmyS has a prime deluxe so let's not just single it down to the R6E. He's having the same issue surrounding wake/sleep as well
 

Thanks. What I meant by letting it to sleep for 2min was that once it's sleeping don't wake it up immediately, but wait 2 minutes. I've had success waking it up ~30 seconds after it goes to sleep. It seems the more it sleeps the less likely it will come back to life.
 
Also has anyone tried implementing some AirPort Express possibilities on our boards? (M.2 WiFi) by swapping out the existing wifi card in the Asus GO! module with a Broadcom one? I would like to know has anyone had success in this field as I'm looking into grabbing for the iX299 Pro. I notice different Broadcom wifi cards (BCM94352Z mainly) with some ending with AE. Could this be an indication of Airport Express capable?

bcm ver2.png

AE ver1.png

bcm diff chipset ae.png

Slightly different version from BCM94352Z (shown - BCM94350Z-AE). AirPort Extreme capable?
 
Thanks. What I meant by letting it to sleep for 2min was that once it's sleeping don't wake it up immediately, but wait 2 minutes. I've had success waking it up ~30 seconds after it goes to sleep. It seems the more it sleeps the less likely it will come back to life.

I was going to mention that as well. Problems I notice is when it's sleeps for long periods not brief naps.
 
Just want to add that @JimmyS has a prime deluxe so let's not just single it down to the R6E. He's having the same issue surrounding wake/sleep as well

One thing is sleep/wake which does not work currently with any boards. The other thing are your apparent Rampage VI KP issues during normal system use.

If you find a solution for the Sleep/Wake issue with Error E3 for all boards fine with me. But again please don't mix things and spread your Rampage VI system instabilities during standard system use to all boards, which is definitely not the case.
 
I want to underline that I never experienced this KP when computer was awake, regardless of activity or load level.

I tried everything I knew before the patch fixed it for me:
- disabled devices that were not absolutely necessary (integrated WIFI & BT, sound, second ethernet, TB3 AIC), USB devices
- disconnected all drives other than the NVME boot drive
- experimented with different Clover releases, different Aptiofix drivers
- changed power management options in the BIOS
- with SSDT & without SSDT (SSDTPRGEN)
- different BIOS releases, original and patched.

Wake from sleep always resulted in the KP until I enabled the Pike's patch.

At the moment sleep/wake is working just fine.
 
Last edited:
Status
Not open for further replies.
Back
Top