Contribute
Register

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

Status
Not open for further replies.
In regards to the occasional kp'ing, No intensive tasks at all.... simply just let the computer run. I would say it was running for over 24+ but not more than 2 days without panicking. And it seemed to have happened 2x within 1 Hour from the first panic. Same message as I posted and stated before. All typical safe mode bios boot / Mac OS X shut down error popup like a normal crash. Dunno...

Now thing is I need to test it like I said for longer periods of time with ...

A.) Power set to never shut down the entire system (monitor & iX299 Pro)

B.) Power set to never shut down but allow to the monitor to sleep

C.) Power set for monitor and iX299 Pro to sleep.

* This is the name I reference all of our boards contained in this thread. (I just slapped an i in front since most if not all of us is using the iMac Pro 1,1 SMBIOS

I can tell you now it seems to happen mostly upon waking from a sleep state. Every time it crashes I notice the display doesn't wake and I have to hard reboot. Then I get hit with that KP reason and explanation from Mac that I posted.

I want to note and cancel out the OC theory as I don't overclock...Well at the moment but no overclocking at the moment...7900x and 2400 ram... same $#!+ different toilet.

So we can eliminate the OC theory for sure, which is good.

I would also like to add that have a stable rock solid configuration under Windows: I've been gaming, watching movies, Youtube 8K, stress testing Prime95 for days, no issue at all. So it's definitely coming from MacOS and the hacks we have or lack.

I have a 7980XE myself, so it's not the CPU.

That leaves us with a few possibilities:

- We managed to make the same mistake in Clover and that's why this issue is only happening to us.
- Our R6E motherboard requires more hacks that we haven't figured out yet.
- One of the hacks we have is not compatible for the R6E motherboard.

That's all I can think of for now since nobody else on this thread has any issue after 24h+ uptime.

I'll keep monitoring my uptime, as for now I have 13h+ and no freeze/KP. I'll keep you up to date here.

Like I said earlier I made some changes which I suspect were causing this issue, let's see if they work. In the meantime could you please tell me which kexts you're using in your "Others" folder of Clover?
 
Looks good to me. Is it working now?

Yes I did start the install process but now I get this message. Did I miss something again?
 

Attachments

  • IMG_0658.JPG
    IMG_0658.JPG
    5.7 MB · Views: 124
In regards to the occasional kp'ing, No intensive tasks at all.... simply just let the computer run. I would say it was running for over 24+ but not more than 2 days without panicking. And it seemed to have happened 2x within 1 Hour from the first panic. Same message as I posted and stated before. All typical safe mode bios boot / Mac OS X shut down error popup like a normal crash. Dunno...

Now thing is I need to test it like I said for longer periods of time with ...

A.) Power set to never shut down the entire system (monitor & iX299 Pro)

B.) Power set to never shut down but allow to the monitor to sleep

C.) Power set for monitor and iX299 Pro to sleep.

* This is the name I reference all of our boards contained in this thread. (I just slapped an i in front since most if not all of us is using the iMac Pro 1,1 SMBIOS

I can tell you now it seems to happen mostly upon waking from a sleep state. Every time it crashes I notice the display doesn't wake and I have to hard reboot. Then I get hit with that KP reason and explanation from Mac that I posted.

Sleep/Wake does not work at present. Please don't use it at all and disable all related settings. We have to stabilise your Rampage VI Systems without using the Sleep/Wake functionality.
 
Sleep/Wake does not work at present. Please don't use it at all and disable all related settings. We have to stabilise your Rampage VI Systems without using the Sleep/Wake functionality.

I don't use sleep at all. So we can also eliminate this theory.
 
@AnaktuvGod, one of my reply is awaiting moderation approval. #4526

You'll get more info about what I think it comes from once it's approved.
 
I don't use sleep at all. So we can also eliminate this theory too.

This is not a just a theory. @AnaktuvGod seems to use Sleep/Wake. Everybody should work with and talk about the same system configuration. Otherwise, we will never be able to identify the real problem with the Rampage VI.
 
This is not a just a theory. @AnaktuvGod seems to use Sleep/Wake. Everybody should work with and talk about the same system configuration. Otherwise, we will never be able to identify the real problem with the Rampage VI.

This is not what is causing his KP. You can see from the KP dump that we have exactly the same tracedump. I'm not using sleep, he is using sleep. So it is not sleep that's causing the KP. Science!

This is by having small differences in configurations that we'll be able to crosscheck what is in common and locate the issue. Not by having the same configuration. Logic!
 
fair enough... I just leave everything default after install. Not like I chose to make it sleep, it's just the way things are set after installing Mac. I have 2 hard drives I test on.. one which is the main one called Hackintosh HD (NVMe M.2) I try to leave as clean and vanilla as possible and the other called Practice HD (250GB SATA 2.5 HDD) where I mess around and play with different settings before I set them permanently on the Hackintosh HD
 
So, just to confirm, could you give us more detail about the issue? How long has the computer been running? Was there any intensive tasks running? Was there a message displayed when this happened?
I've already reported the issue there: #30 but I'm afraid that it won't help much, as it seems to be clearly related to our specific build.

Notice the following lines:



I've tried a couple of things recently to revolve it, but I don't have enough uptime to confirm if that worked, I'll let you know if it's the case.

Now the thing is, either it's related to our specific motherboard, or it's related to our Clover config... for that we need confirmation on this thread that people are actually able to run their machine for 24H+ straight without issue.

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.
 
Status
Not open for further replies.
Back
Top