Contribute
Register

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

Status
Not open for further replies.
kgp said:
High CPU loads around 3-4%? :lol: You are kidding man, don't you? A high CPU load for me is 80-99%.. 3-4% is within the noise, sorry. What for do you have a CPU? Let it work...
Click to expand...

This is not the point. 3-4% of CPU load in totally empty Ableton Live project with 256samples latency on Skylake-x CPU is way too much. With 64samples latency which I frequently use to have "real time" feeling when playing master keyboard use 7-8% of CPU in empty project with zero audio processing. It is 2x more than on Win10 with the same hw and sw. So the question is, if the USB implementation from the guide might help with this.
 
poshook said:
This is not the point. 3-4% of CPU load in totally empty Ableton Live project with 256samples latency on Skylake-x CPU is way too much. With 64samples latency which I frequently use to have "real time" feeling when playing master keyboard use 7-8% of CPU in empty project with zero audio processing. It is 2x more than on Win10 with the same hw and sw. So the question is, if the USB implementation from the guide might help with this.
Click to expand...

I don't know.. Why don't you try?

https://www.tonymacx86.com/threads/macos-high-sierra-10-13-xhc-usb-kext-creation-guideline.242999/

Use my XHC USB kext attached to the originating post of this thread (guide) to start with..

It just needs to be adopted to your mainboard by following the XHC USB guidelines linked above.
 
kgp said:
I don't know.. Why don't you try?

https://www.tonymacx86.com/threads/macos-high-sierra-10-13-xhc-usb-kext-creation-guideline.242999/

Use my XHC USB kext attached to the originating post of this thread (guide) to start with..

It just needs to be adopted to your mainboard by following the XHC USB guidelines linked above.
Click to expand...

Thank you kgp. I thought about the issue and the reason for such jump in cpu load compared to windows might be different CPU power management of OSX. I was checking the frequencies in Intel Power Gadget and those 3-4% is related to ratios around 20-30x. So with 42x ratio, the CPU load should show much lower values. So never mind. Again, thank you for your time and effort to help all of us, it is truly appreciated
 
  • Like
Reactions: kgp
Is there an option to set the minimum ratio for CPU? Now it jumps from 12x to 42x, I would like to set it from 36x to 42x.
What I need to change in BIOS to reach stable performance. In audio applications I can get audio drops and the processor in Intel Power Gadget is going on 2-3GHz
 
poshook said:
Is there an option to set the minimum ratio for CPU? Now it jumps from 12x to 42x, I would like to set it from 36x to 42x.
What I need to change in BIOS to reach stable performance. In audio applications I can get audio drops and the processor in Intel Power Gadget is going on 2-3GHz
Click to expand...

12x is idle and 42x is max load as it should be... no need to change anything! it is perfect like this!
 
PuppiesLover said:
Lol, I haven't. I just checked the ASUS website and they have BIOS 1401 on June, 15. So the question wasn't relating anything about you guys posts, simply just a question if anyone tried out the 1401, :thumbup:
Click to expand...

If you would have read the recent posts you would see that just that question is obsolete.. ;)
 
Sadly it appears even having AGPM running is not enough to avoid the daily Nvidia kernel panics...

Code: 
Tue Jun 19 23:06:29 2018

*** Panic Report ***
mp_kdp_enter(): 68715282431, 1, 36 TIMED-OUT WAITING FOR NMI-ACK, PROCEEDING
panic(cpu 22 caller 0xffffff80166b2c39): "waitq deadlock - waitq=0xffffff80e6846a30, cpu=22\n"@/BuildRoot/Library/Caches/com.apple.xbs/Sources/xnu/xnu-4570.61.1/osfmk/kern/waitq.c:1825
Backtrace (CPU 22), Frame : Return Address
0xffffffa7877236b0 : 0xffffff801666d166 mach_kernel : _handle_debugger_trap + 0x4c6
0xffffffa787723700 : 0xffffff8016795824 mach_kernel : _kdp_i386_trap + 0x114
0xffffffa787723740 : 0xffffff8016787b10 mach_kernel : _kernel_trap + 0x4d0
0xffffffa7877237c0 : 0xffffff801661f180 mach_kernel : _return_from_trap + 0xe0
0xffffffa7877237e0 : 0xffffff801666cbdc mach_kernel : _panic_trap_to_debugger + 0x21c
0xffffffa787723910 : 0xffffff801666c99c mach_kernel : _panic + 0x5c
0xffffffa787723970 : 0xffffff80166b2c39 mach_kernel : _waitq_wakeup64_all_locked + 0xa09
0xffffffa787723a20 : 0xffffff80166b30af mach_kernel : _waitq_wakeup64_all_locked + 0xe7f
0xffffffa787723a90 : 0xffffff80166b3818 mach_kernel : _waitq_wakeup64_one_locked + 0x5d8
0xffffffa787723b30 : 0xffffff80166b3c46 mach_kernel : _waitq_wakeup64_identify_locked + 0xc6
0xffffffa787723bd0 : 0xffffff8016653716 mach_kernel : _ipc_mqueue_post + 0x76
0xffffffa787723c20 : 0xffffff801665357f mach_kernel : _ipc_mqueue_send + 0x5f
0xffffffa787723c60 : 0xffffff801664fb77 mach_kernel : _ipc_kmsg_send + 0x257
0xffffffa787723cb0 : 0xffffff8016672ea7 mach_kernel : _mach_msg_send_from_kernel_proper + 0xe7
0xffffffa787723cf0 : 0xffffff7f98ee7929 com.nvidia.web.NVDAResmanWeb : _osGetCurrentTime + 0x4e0
0xffffffa787723d30 : 0xffffff7f98f3ef55 com.nvidia.web.NVDAResmanWeb : _osSetEvent + 0x44
0xffffffa787723d50 : 0xffffff7f98ff74ca com.nvidia.web.NVDAResmanWeb : _engineNonStallIntrNotify + 0xc6
0xffffffa787723da0 : 0xffffff7f9903c9b8 com.nvidia.web.NVDAResmanWeb : _gpuPowerOn_IMPL + 0x61bf
0xffffffa787723dc0 : 0xffffff7f99695628 com.nvidia.web.NVDAGM100HalWeb : __ZN12NVDAGM100HAL5probeEP9IOServicePi + 0x13b35a
0xffffffa787723e10 : 0xffffff7f98f46148 com.nvidia.web.NVDAResmanWeb : _osIsISR + 0x424
0xffffffa787723ed0 : 0xffffff8016c997f5 mach_kernel : __ZN22IOInterruptEventSource12checkForWorkEv + 0x105
0xffffffa787723f30 : 0xffffff8016c97f62 mach_kernel : __ZN10IOWorkLoop15runEventSourcesEv + 0x1e2
0xffffffa787723f70 : 0xffffff8016c9759c mach_kernel : __ZN10IOWorkLoop10threadMainEv + 0x2c
0xffffffa787723fa0 : 0xffffff801661e4f7 mach_kernel : _call_continuation + 0x17
      Kernel Extensions in backtrace:
         com.nvidia.web.NVDAResmanWeb(10.3.1)[9E5331D7-2B37-394B-97C7-3C5B54B7C367]@0xffffff7f98ee0000->0xffffff7f99558fff
            dependency: com.apple.iokit.IOPCIFamily(2.9)[1057F053-73DE-33E4-B5BE-09DA28715DB4]@0xffffff7f96e94000
            dependency: com.apple.iokit.IONDRVSupport(519.19)[3B9AF334-51BC-3DCC-95B2-DC7386BB16FF]@0xffffff7f97e90000
            dependency: com.apple.iokit.IOGraphicsFamily(519.19)[0B3857C5-9040-3A0C-BFB4-C45E56DB01C6]@0xffffff7f9764f000
            dependency: com.apple.AppleGraphicsDeviceControl(3.18.52)[FC5E4CD4-7730-3A55-9CC5-338A64F50E42]@0xffffff7f9795f000
         com.nvidia.web.NVDAGM100HalWeb(10.3.1)[16BD04F0-8B47-3565-B416-680CAD199D22]@0xffffff7f99559000->0xffffff7f996fcfff
            dependency: com.nvidia.web.NVDAResmanWeb(10.3.1)[9E5331D7-2B37-394B-97C7-3C5B54B7C367]@0xffffff7f98ee0000
            dependency: com.apple.iokit.IOPCIFamily(2.9)[1057F053-73DE-33E4-B5BE-09DA28715DB4]@0xffffff7f96e94000

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

Incidentally, I also don't have HDMI audio working despite having made the proper kext patches (and, for good measure, having up-to-date Lilu and NvidiaFixUp, tried in various combinations) — this is ever since 10.13.4 and I'm afraid I'm going to have to use the nuclear option and replace the kext with the 10.13.3 version. Unsure why the usual prescribed fixes don't work, and it's unrelated to the kernel panics—those have been happening from the beginning...
 
Sorry to derail the thread a little bit (I promise it's related!) - people with AMD Radeon GPUs and this config, are you seeing problems with UI freezes like those described in my other thread - I can usually trigger it by opening and syncing Live Photos in Photos.app, then mousing over a few of them. If they use HEVC, within a few seconds my UI will lock.

The workaround for my Sapphire RX580 is to load the Baffin personality rather than the native Ellesmere personality. It appears to be related to the setting of the AMDU6V3 value of the IOGVACodec on the graphics accelerator node.

Are people with Vega 56/Vega 64 seeing anything like this? The reason I ask here is that most of the rest of the board are using CPUs with iGPUs (which negates the issue), so I'm getting a lot of noise every time I try to discuss the issue - I'm hoping we merry bunch of X299 users might have some shared answers/ideas.
 
tonyarnold said:
Are people with Vega 56/Vega 64 seeing anything like this? The reason I ask here is that most of the rest of the board are using CPUs with iGPUs (which negates the issue), so I'm getting a lot of noise every time I try to discuss the issue - I'm hoping we merry bunch of X299 users might have some shared answers/ideas.
Click to expand...

Get a Vega 56/64.

X299 does not have iGPU, this is where you run into trouble with the RX580 (Polaris).

RX580 is officially on the iMac 18,3 and it has an iGPU.

I only recommend the RX5xx on systems like an 8700k because it has an iGPU (which you must enable and get close as possible to an iMac 18,3 SMBIOS) for full stability.

You already spent a ton of money on your X299 build, the Vega 64 is floating around $500, I would advise getting one and selling your RX580.

Before I got a Vega FE on this current X299 build, I had a RX560 until my Vega FE came in. I was having similar issues.

I am sure there will be a way to "stabilize" a CPU without an iGPU with the RX5xx but is it really worth the hassle?

tl;dr get a Vega (after all it is on the real iMac Pro which we're trying to replicate here) card if you are on an X299 and want to have no headaches. Simple solution.
 
  • Like
Reactions: kgp
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top