Contribute
Register

Asus Z690 ProArt Creator WiFi (Thunderbolt 4) + i7-12700K + AMD RX 6800 XT

Interesting... CFG Lock appears to be unlocked on the Formula, I've never had a problem.

1720 seems to have accelerated the resume-from-sleep process...I've timed it on earlier bioses, and I'm seeing a speed up of 4-5 seconds. On early bioses, it took the formula up to 15 seconds to wake from sleep. It's gotten better over time, and with 1720, the time is approx. 7 seconds.

I dusted off my old z170 skylake box, with a MSI Gaming M7 z170, and it resumes from sleep incredibly fast, within 1-2 seconds...


12.5.1 works well on both a real mac and the z690 formula machine. Sleep is working. The only issue I have is Bluetooth consumes 100% CPU when the system resumes from sleep until I turn off Bluetooth and turn it back on.

It is recommended to upgrade to 12.5.1, ASAP, as it has been developed to mitigate already-exploited zero-day security vulnerabilities in the kernel and in webkit.

About the Bluetooth staying at 100% you can use brew and install sleepwatcher. I created a script to just do a pkill bluetoothd on wake (bluetoothd will auto restart) to clear the 100% cpu usage and it's been working great for me.

 
About the Bluetooth staying at 100% you can use brew and install sleepwatcher. I created a script to just do a pkill bluetoothd on wake (bluetoothd will auto restart) to clear the 100% cpu usage and it's been working great for me.

I like this tool Bluesnooze
 
** Asus ROG Strix Z690-i Mini-ITX **
Firmware 1720

No issues upgrading to the latest BIOS​


Screenshot 2022-08-19 at 7.02.11 AM.png
 
BIOS updated to. 1720. No issues…..
 
Looks like I'm having a sleep issue. I just updated to Monterey 12.5.1 and BIOS 1720. Not sure if one of these is the culprit, but this is a new issue. Although, I rarely let my computer sleep, I can't help but think one of the two changes above has something to do with it. Anyone else?

panic(cpu 0 caller 0xffffff800fec3a1a): Sleep transition timed out after 180 seconds while calling power state change callbacks. Suspected bundle: com.apple.iokit.IOGraphicsFamily. Thread 0x6dad2.
Failure code:: 0x00000002 00000014

Backtracing specified thread
Panicked task 0xffffff9076f50670: 682 threads: pid 0: kernel_task
Backtrace (CPU 0), panicked thread: 0xffffff90751a5000, Frame : Return Address
0xffffffeafdca3770 : 0xffffff800f7c952b mach_kernel : _machine_switch_context + 0xdb
0xfffffffffccabb70 : 0xffffff800f6aa642 mach_kernel : _thread_unstop + 0x21c2
0xfffffffffccabbe0 : 0xffffff800f6a83d7 mach_kernel : _thread_block_reason + 0xc7
0xfffffffffccabc30 : 0xffffff800f7c62ec mach_kernel : _lck_mtx_lock_wait_x86 + 0x14c
0xfffffffffccabc70 : 0xffffff800f7c5b0b mach_kernel : _lck_mtx_lock_slow + 0x1bb
0xfffffffffccabca0 : 0xffffff7fa8748ecd com.apple.iokit.IOGraphicsFamily : __ZN18IOGraphicsWorkLoop9closeGateEv + 0x27
0xfffffffffccabcd0 : 0xffffff7fa8762f61 com.apple.iokit.IOGraphicsFamily : __ZN28IOGraphicsControllerWorkLoop9closeGateEv + 0x9
0xfffffffffccabce0 : 0xffffff7fa874c03b com.apple.iokit.IOGraphicsFamily : __ZN18IOGraphicsWorkLoop14timedCloseGateEPKcS1_ + 0x49
0xfffffffffccabd70 : 0xffffff7fa87589f4 com.apple.iokit.IOGraphicsFamily : __ZN13IOFramebuffer22powerStateWillChangeToEmmP9IOService + 0x38
0xfffffffffccabdb0 : 0xffffff800fe2881a mach_kernel : __ZN9IOService23driverInformPowerChangeEv + 0x2fa
0xfffffffffccabe50 : 0xffffff800fe280d4 mach_kernel : __ZN9IOService15pmDriverCalloutEPS_ + 0x34
0xfffffffffccabe70 : 0xffffff800f6d2655 mach_kernel : _thread_call_delayed_timer + 0x505
0xfffffffffccabee0 : 0xffffff800f6d3722 mach_kernel : _thread_call_delayed_timer + 0x15d2
0xfffffffffccabfa0 : 0xffffff800f61f19e mach_kernel : _call_continuation + 0x2e
Kernel Extensions in backtrace:
com.apple.iokit.IOGraphicsFamily(597.0)[A3D63B23-B497-3720-82BA-EB74C1CD8E22]@0xffffff7fa873f000->0xffffff7fa876dfff
dependency: com.apple.iokit.IOPCIFamily(2.9)[22B97C0A-53BF-3843-B4B5-4DE866C375B0]@0xffffff8012235000->0xffffff8012261fff

Process name corresponding to current thread (0xffffff90751a5000): kernel_task
Boot args: keepsyms=1 debug=0x100 alcid=13 -wegnoigpu agdpmod=pikera chunklist-security-epoch=0 -chunklist-no-rev2-dev

Mac OS version:
21G83
 
Added my GC-TitanRidge-V2 card back into the ProArt for some experimenting today.
I decided to first try the newer patched NVM67 that @CaseySJ provided in the repository. I was curious if this would make a difference when trying to hot plug my Envoy Express enclosure, which it did not- still only works when plugged in before boot. Also my TS4 dock is still a no-go when connected to the Titan Ridge card. So at this point, the only way the TS4 works is when looped through my UltraFine monitor when plugged into on-board Maple Ridge port. I left my built-in thunderbolt on-board enabled, so I moved the XHC3 to XHC4 on the Titan Ridge card via SSDT. The result is that I have lost XHC on both Thunderbolt buses as I verified via Hackintool. I'm going to keep experimenting the next day or two to see if I can get better results.

EDIT: Disabling on-board Maple Ridge Thunderbolt in BIOS restores XHC4 on the TitanRidge bus (Moved from XHC3) so it appears there is a conflict.

EDIT2: I have re-enabled on-board Maple Ridge and switched it to be XHC4 via SSDT. Now TR card is XHC3 and both are now seen in Hackintool. First time now... my Envoy Express is recognized in thunderbolt bus, but is not mounting.
@CaseySJ @dehjomz Is this still the same thunderbolt issue? Any ideas?
 
Last edited:
Added my GC-TitanRidge-V2 card back into the ProArt for some experimenting today.
I decided to first try the newer patched NVM67 that @CaseySJ provided in the repository. I was curious if this would make a difference when trying to hot plug my Envoy Express enclosure, which it did not- still only works when plugged in before boot. Also my TS4 dock is still a no-go when connected to the Titan Ridge card. So at this point, the only way the TS4 works is when looped through my UltraFine monitor when plugged into on-board Maple Ridge port. I left my built-in thunderbolt on-board enabled, so I moved the XHC3 to XHC4 on the Titan Ridge card via SSDT. The result is that I have lost XHC on both Thunderbolt buses as I verified via Hackintool. I'm going to keep experimenting the next day or two to see if I can get better results.
If the envoy express is using jhl6240 it will not hotplug properly using current implementations and NVMs of maple ridge… if you get an enclosure with Jhl6340 or Titan ridge, hotplug should work on the pro art.
 
If the envoy express is using jhl6240 it will not hotplug properly using current implementations and NVMs of maple ridge… if you get an enclosure with Jhl6340 or Titan ridge, hotplug should work on the pro art.
I believe that's what's going on with the on-board Maple Ridge ports, but the newer patched NVM67 on Titan Ridge appears to be problematic as well. The same GC-TitanRidge V2 card in my Z390 Aorus Master with patched NVM33 did allow hot plug with my Envoy Express. At some point, I'll flash back to NVM33 and try it out in my ProArt to see if it still works.
 
I believe that's what's going on with the on-board Maple Ridge ports, but the newer patched NVM67 on Titan Ridge appears to be problematic as well. The same GC-TitanRidge V2 card in my Z390 Aorus Master with patched NVM33 did allow hot plug with my Envoy Express. At some point, I'll flash back to NVM33 and try it out in my ProArt to see if it still works.
My experience with the flashed NVM for the onboard Titan Ridge on Z490 is that support for Thunderbolt hubbing (made available by Goshen Ridge TB4 July 8440 docks) stopped working. I had to use the stock Z490 NVM in order to use multiple Thunderbolt devices on the same dock.

So I gave up on the flashed NVM endeavor. I wished it worked out, but turns out at least for my then use case, stock NVM was fine.
 
Back
Top