iMac Pro X299 - Live the Future now with macOS 10.14 Mojave [Successful Build/Extended Guide]

[kgp]

The photo of the water block clearly shows that the VRM is directly below & in contact with the CPU water block.
The water block is obviously custom designed to cool both the CPU and the VRM, "in one fell swoop", so to speak.

Obviously the EK Monoblock also comes with the thermal pads for the VMR

Wells on the VRM Heatsink of the ASUS Monoblock exactly suit the wells and screws on the ASUS Prime X299 Deluxe for the original ASUS VMR Heatsink, which of course has to be removed from the ASUS Prime X299 Deluxe primarily to the mounting of the EK Monoblock.

 

[thenightflyer]

The photo of the water block clearly shows that the VRM is directly below & in contact with the CPU water block.
The water block is obviously custom designed to cool both the CPU and the VRM, "in one fell swoop", so to speak.

Are you serious???

 

[kgp]

Are you serious???

Unfortunately, this discussion does not seem to find any end, thus once more:

1.) I am using the EK-Monoblock for the ASUS Prime X299 Deluxe on the latter mainboard for more than 1 year.
2.) It accounts for the water blocking of both CPU and VRM (MOSFET).
3.) It works perfectly even when heavily overclocking the i9-7980XE to 4.7 GHz also thanks to my extended custom water blocking.

4.) For respective pictures of the EK-Monoblock see post #272 and post #283.

I hope we can stop now filling pages for nothing. Or do people generally believe that I don't know what I am doing or what I am taking about?

Cheers,

KGP

 

[izo1]

The photo of the water block clearly shows that the VRM is directly below & in contact with the CPU water block.
The water block is obviously custom designed to cool both the CPU and the VRM, "in one fell swoop", so to speak.

Yes that is correct, but still doesn’t change the fact that X299 is a thermonuclear bomb when it comes to heat efficiency. A specialized water cooling solution is not always the best way to go as it is expensive and not too common.

If you look at the threadripper 32core, it runs very efficiently even with an air cooler at 250watt. Intel’s 14nm process is just not built to be efficient especially when you start to increase the base and boost clocks.

If you look at the 9900k it’s the same story. It’s literally a Coffee Lake revision with 2 extra cores and solder to allow boost clock to hit 5Ghz.

Essentially, Intel is on its last legs with their refinements and they have gotten lazy because of industry domination and they’re learning their lesson now. They need to stop rushing things and making house fire CPUs and gimping reviews so people pre-order their semi-refined silicone. Their bad business practices are bad for the industry.

My comments were not for the fact that you can cool the vrms in a custom way, my comment was more about how rushed X299 was when Mobo manufacturers like Asus didn’t even put heatpipes on the VRM on launch mobos. At the time of launch, when I got on X299, Designare EX and some other board I think from MSI, were the only ones with proper VRM cooling.

There’s plenty of reviews of these boards with bad VRM cooling for X299 from reputable reviewers you can look up.

And don’t get me started on the desperate attempt by Intel to showcase a ridiculous house fire 28 core CPU with a chiller. They’re gimping their own Xeon line to “compete” instead of innovating again.

 

[MauroM]

Thanks! Give me some time to analyse all this stuff. Right now I am quite busy with other stuff being part of my real life...

Great news, compiling LiLu and Whatevergreen with configuration Debug, has solved the problem of DP operation via GC-Titan and monitor stand-by.

I had tried the release version from Github, then I remembered that in the other thread you had advised the compilation ... bad thing being too busy

But now the computer sleep causes kernel panics

acktrace (CPU 5), Frame : Return Address

0xffffffa3e782b200 : 0xffffff8005faca1d mach_kernel : _handle_debugger_trap + 0x48d
0xffffffa3e782b250 : 0xffffff80060e6b13 mach_kernel : _kdp_i386_trap + 0x153
0xffffffa3e782b290 : 0xffffff80060d859a mach_kernel : _kernel_trap + 0x4fa
0xffffffa3e782b300 : 0xffffff8005f59ca0 mach_kernel : _return_from_trap + 0xe0
0xffffffa3e782b320 : 0xffffff8005fac437 mach_kernel : _panic_trap_to_debugger + 0x197
0xffffffa3e782b440 : 0xffffff8005fac283 mach_kernel : _panic + 0x63
0xffffffa3e782b4b0 : 0xffffff80060d87bd mach_kernel : _kernel_trap + 0x71d
0xffffffa3e782b620 : 0xffffff8005f59ca0 mach_kernel : _return_from_trap + 0xe0
0xffffffa3e782b640 : 0xffffff7f8ab2a158 org.hwsensors.driver.GPUSensors : __Z13vega_get_tempP13radeon_device + 0x64
0xffffffa3e782b740 : 0xffffff7f8ab217fd org.hwsensors.driver.GPUSensors : __ZN13RadeonSensors19willReadSensorValueEP13FakeSMCSensorPf + 0x27
0xffffffa3e782b760 : 0xffffff7f8a8cf75f org.netkas.driver.FakeSMC : __ZN13FakeSMCPlugin15readKeyCallbackEPKcS1_hPv + 0x5b
0xffffffa3e782b7a0 : 0xffffff7f8a8d0d92 org.netkas.driver.FakeSMC : __ZN10FakeSMCKey8getValueEv + 0x90
0xffffffa3e782b7e0 : 0xffffff7f8a8cbedc org.netkas.driver.FakeSMC : __ZN13FakeSMCDevice18applesmc_fill_dataEP14AppleSMCStatus + 0x30
0xffffffa3e782b810 : 0xffffff7f8a8cc10b org.netkas.driver.FakeSMC : __ZN13FakeSMCDevice23applesmc_io_data_writebEPvjj + 0x61
0xffffffa3e782b850 : 0xffffff7f873babcc com.apple.driver.AppleSMC : __ZN8AppleSMC13smcWriteData8Eh + 0x150
0xffffffa3e782b890 : 0xffffff7f873bb59e com.apple.driver.AppleSMC : __ZN8AppleSMC14smcReadKeyPMIOEjhyPv + 0x134
0xffffffa3e782b8e0 : 0xffffff7f873baf28 com.apple.driver.AppleSMC : __ZN8AppleSMC20smcReadKeyPMIOStaticEP8OSObjectPvS2_S2_S2_ + 0x56
0xffffffa3e782b910 : 0xffffff8006658e15 mach_kernel : __ZN13IOCommandGate9runActionEPFiP8OSObjectPvS2_S2_S2_ES2_S2_S2_S2_ + 0xb5
0xffffffa3e782b980 : 0xffffff7f873badc3 com.apple.driver.AppleSMC : __ZN8AppleSMC17smcReadKeyWithSMCEjhyPv + 0x55
0xffffffa3e782b9d0 : 0xffffff7f873c2483 com.apple.driver.AppleSMC : __ZN14AppleSMCFamily17smcHandleYPCEventEP14SMCParamStructS1_jPy + 0x95
0xffffffa3e782ba20 : 0xffffff7f873bfc26 com.apple.driver.AppleSMC : __ZN14AppleSMCClient16smcYPCEventCheckEP14SMCParamStructS1_jPy + 0x586
0xffffffa3e782ba80 : 0xffffff80066870bc mach_kernel : _shim_io_connect_method_structureI_structureO + 0x1cc
0xffffffa3e782bae0 : 0xffffff80066852e0 mach_kernel : __ZN12IOUserClient14externalMethodEjP25IOExternalMethodArgumentsP24IOExternalMethodDispatchP8OSObjectPv + 0x340
0xffffffa3e782bb30 : 0xffffff800668e5ff mach_kernel : _is_io_connect_method + 0x20f
0xffffffa3e782bc70 : 0xffffff80060931f4 mach_kernel : _iokit_server_routine + 0x5e84
0xffffffa3e782bd80 : 0xffffff8005fb210d mach_kernel : _ipc_kobject_server + 0x12d
0xffffffa3e782bdd0 : 0xffffff8005f8cad5 mach_kernel : _ipc_kmsg_send + 0x225
0xffffffa3e782be50 : 0xffffff8005fa148e mach_kernel : _mach_msg_overwrite_trap + 0x38e
0xffffffa3e782bef0 : 0xffffff80060bfceb mach_kernel : _mach_call_munger64 + 0x22b
0xffffffa3e782bfa0 : 0xffffff8005f5a486 mach_kernel : _hndl_mach_scall64 + 0x16
      Kernel Extensions in backtrace:
        com.apple.driver.AppleSMC(3.1.9)[9A019213-59F1-34A2-8353-946F7A728A05]@0xffffff7f873b3000->0xffffff7f873d0fff
            dependency: com.apple.iokit.IOACPIFamily(1.4)[8A2C5602-298A-3199-AED0-979018ECBE16]@0xffffff7f86ed8000
            dependency: com.apple.iokit.IOPCIFamily(2.9)[2CE7BCB3-0766-3A94-A8D4-29BF3EBAEFBC]@0xffffff7f86895000
        org.netkas.driver.FakeSMC(1449.0)[BD2F7E2E-A0FD-312B-B26E-EC8744185624]@0xffffff7f8a8cb000->0xffffff7f8a8e3fff
            dependency: com.apple.iokit.IOACPIFamily(1.4)[8A2C5602-298A-3199-AED0-979018ECBE16]@0xffffff7f86ed8000
        org.hwsensors.driver.GPUSensors(1462.0)[E8CA2C45-88B1-3830-A242-3E9E1A791059]@0xffffff7f8ab21000->0xffffff7f8ab44fff
            dependency: com.apple.iokit.IOACPIFamily(1.4)[8A2C5602-298A-3199-AED0-979018ECBE16]@0xffffff7f86ed8000
            dependency: com.apple.iokit.IOPCIFamily(2.9)[2CE7BCB3-0766-3A94-A8D4-29BF3EBAEFBC]@0xffffff7f86895000
            dependency: org.netkas.driver.FakeSMC(1449)[BD2F7E2E-A0FD-312B-B26E-EC8744185624]@0xffffff7f8a8cb000

 

[kgp]

Great news, compiling LiLu and Whatevergreen with configuration Debug, has solved the problem of DP operation via GC-Titan and monitor stand-by.

I had tried the release version from Github, then I remembered that in the other thread you had advised the compilation ... bad thing being too busy

But now the computer sleep causes kernel panics

acktrace (CPU 5), Frame : Return Address

0xffffffa3e782b200 : 0xffffff8005faca1d mach_kernel : _handle_debugger_trap + 0x48d
0xffffffa3e782b250 : 0xffffff80060e6b13 mach_kernel : _kdp_i386_trap + 0x153
0xffffffa3e782b290 : 0xffffff80060d859a mach_kernel : _kernel_trap + 0x4fa
0xffffffa3e782b300 : 0xffffff8005f59ca0 mach_kernel : _return_from_trap + 0xe0
0xffffffa3e782b320 : 0xffffff8005fac437 mach_kernel : _panic_trap_to_debugger + 0x197
0xffffffa3e782b440 : 0xffffff8005fac283 mach_kernel : _panic + 0x63
0xffffffa3e782b4b0 : 0xffffff80060d87bd mach_kernel : _kernel_trap + 0x71d
0xffffffa3e782b620 : 0xffffff8005f59ca0 mach_kernel : _return_from_trap + 0xe0
0xffffffa3e782b640 : 0xffffff7f8ab2a158 org.hwsensors.driver.GPUSensors : __Z13vega_get_tempP13radeon_device + 0x64
0xffffffa3e782b740 : 0xffffff7f8ab217fd org.hwsensors.driver.GPUSensors : __ZN13RadeonSensors19willReadSensorValueEP13FakeSMCSensorPf + 0x27
0xffffffa3e782b760 : 0xffffff7f8a8cf75f org.netkas.driver.FakeSMC : __ZN13FakeSMCPlugin15readKeyCallbackEPKcS1_hPv + 0x5b
0xffffffa3e782b7a0 : 0xffffff7f8a8d0d92 org.netkas.driver.FakeSMC : __ZN10FakeSMCKey8getValueEv + 0x90
0xffffffa3e782b7e0 : 0xffffff7f8a8cbedc org.netkas.driver.FakeSMC : __ZN13FakeSMCDevice18applesmc_fill_dataEP14AppleSMCStatus + 0x30
0xffffffa3e782b810 : 0xffffff7f8a8cc10b org.netkas.driver.FakeSMC : __ZN13FakeSMCDevice23applesmc_io_data_writebEPvjj + 0x61
0xffffffa3e782b850 : 0xffffff7f873babcc com.apple.driver.AppleSMC : __ZN8AppleSMC13smcWriteData8Eh + 0x150
0xffffffa3e782b890 : 0xffffff7f873bb59e com.apple.driver.AppleSMC : __ZN8AppleSMC14smcReadKeyPMIOEjhyPv + 0x134
0xffffffa3e782b8e0 : 0xffffff7f873baf28 com.apple.driver.AppleSMC : __ZN8AppleSMC20smcReadKeyPMIOStaticEP8OSObjectPvS2_S2_S2_ + 0x56
0xffffffa3e782b910 : 0xffffff8006658e15 mach_kernel : __ZN13IOCommandGate9runActionEPFiP8OSObjectPvS2_S2_S2_ES2_S2_S2_S2_ + 0xb5
0xffffffa3e782b980 : 0xffffff7f873badc3 com.apple.driver.AppleSMC : __ZN8AppleSMC17smcReadKeyWithSMCEjhyPv + 0x55
0xffffffa3e782b9d0 : 0xffffff7f873c2483 com.apple.driver.AppleSMC : __ZN14AppleSMCFamily17smcHandleYPCEventEP14SMCParamStructS1_jPy + 0x95
0xffffffa3e782ba20 : 0xffffff7f873bfc26 com.apple.driver.AppleSMC : __ZN14AppleSMCClient16smcYPCEventCheckEP14SMCParamStructS1_jPy + 0x586
0xffffffa3e782ba80 : 0xffffff80066870bc mach_kernel : _shim_io_connect_method_structureI_structureO + 0x1cc
0xffffffa3e782bae0 : 0xffffff80066852e0 mach_kernel : __ZN12IOUserClient14externalMethodEjP25IOExternalMethodArgumentsP24IOExternalMethodDispatchP8OSObjectPv + 0x340
0xffffffa3e782bb30 : 0xffffff800668e5ff mach_kernel : _is_io_connect_method + 0x20f
0xffffffa3e782bc70 : 0xffffff80060931f4 mach_kernel : _iokit_server_routine + 0x5e84
0xffffffa3e782bd80 : 0xffffff8005fb210d mach_kernel : _ipc_kobject_server + 0x12d
0xffffffa3e782bdd0 : 0xffffff8005f8cad5 mach_kernel : _ipc_kmsg_send + 0x225
0xffffffa3e782be50 : 0xffffff8005fa148e mach_kernel : _mach_msg_overwrite_trap + 0x38e
0xffffffa3e782bef0 : 0xffffff80060bfceb mach_kernel : _mach_call_munger64 + 0x22b
0xffffffa3e782bfa0 : 0xffffff8005f5a486 mach_kernel : _hndl_mach_scall64 + 0x16
      Kernel Extensions in backtrace:
        com.apple.driver.AppleSMC(3.1.9)[9A019213-59F1-34A2-8353-946F7A728A05]@0xffffff7f873b3000->0xffffff7f873d0fff
            dependency: com.apple.iokit.IOACPIFamily(1.4)[8A2C5602-298A-3199-AED0-979018ECBE16]@0xffffff7f86ed8000
            dependency: com.apple.iokit.IOPCIFamily(2.9)[2CE7BCB3-0766-3A94-A8D4-29BF3EBAEFBC]@0xffffff7f86895000
        org.netkas.driver.FakeSMC(1449.0)[BD2F7E2E-A0FD-312B-B26E-EC8744185624]@0xffffff7f8a8cb000->0xffffff7f8a8e3fff
            dependency: com.apple.iokit.IOACPIFamily(1.4)[8A2C5602-298A-3199-AED0-979018ECBE16]@0xffffff7f86ed8000
        org.hwsensors.driver.GPUSensors(1462.0)[E8CA2C45-88B1-3830-A242-3E9E1A791059]@0xffffff7f8ab21000->0xffffff7f8ab44fff
            dependency: com.apple.iokit.IOACPIFamily(1.4)[8A2C5602-298A-3199-AED0-979018ECBE16]@0xffffff7f86ed8000
            dependency: com.apple.iokit.IOPCIFamily(2.9)[2CE7BCB3-0766-3A94-A8D4-29BF3EBAEFBC]@0xffffff7f86895000
            dependency: org.netkas.driver.FakeSMC(1449)[BD2F7E2E-A0FD-312B-B26E-EC8744185624]@0xffffff7f8a8cb000

Wake on sleep with the GC-Titan Ridge does not work with thunderbolt devices connected during sleep. Following my latest e-mail exchange with Asus, the solution requires a Firware update for the GC-Titan Ridge by Gigabyte. ASUS has not been able to remove the issue with ASUS Prime X299 Deluxe Firmware modifications.

For now, disconnect all TB devices before sleep! USB-C devices can remain connected though.. Obviously there is not other solution.

 

[MauroM]

Wake on sleep with the GC-Titan Ridge does not work with thunderbolt devices connected during boot. Following my latest e-mail exchange with Asus, the solution requires a Firware update for the GC-Titan Ridge by Gigabyte. ASUS has not been able to remove the issue with ASUS Prime X299 Deluxe Firmware modifications.

For now, disconnect all TB devices before sleep! USB-C devices can remain connected though.. Obviously there is not other solution.

I have no thunderbolt devices connected, only DP and DP-mini, is the same ?

 

[kgp]

I have no thunderbolt devices connected, only DP and DP-mini, is the same ?

The GC-Titan Ridge only has 1x DP1.4 out and 2x DP-mini in, I did not verify if sleep/wake works with this configuration, but I expect it to work as it also works with USB-C devices connected.

Otherwise use one of the DP1.4 ports of your Vega.

 

[henricjansson]

Wake on sleep with the GC-Titan Ridge does not work with thunderbolt devices connected during boot. Following my latest e-mail exchange with Asus, the solution requires a Firware update for the GC-Titan Ridge by Gigabyte. ASUS has not been able to remove the issue with ASUS Prime X299 Deluxe Firmware modifications.

For now, disconnect all TB devices before sleep! USB-C devices can remain connected though.. Obviously there is not other solution.

Does thunderbolt dock solve this sleep issue? Or is it the same?

 

[kgp]

Does thunderbolt dock solve this sleep issue? Or is it the same?

First at all, sorry there was a typo.. it should properly read:

Wake on sleep with the GC-Titan Ridge does not work with thunderbolt devices connected during sleep.

I do not have a thunderbolt dock, thus I cannot answer your question, although I guess you might witness the same issue as the problem relates with the GC-Titan Ridge firmware.