Contribute
Register

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

OK, So I reinstalled the macOS Ventura and just realized that if I go into the BIOS and change nothing, just save and exit I do NOT need to Reset NVRAM.
 
I could never get the onboard Intel Bluetooth to work so added a Fenvi FV-T919 PCI card. In case anyone finds this post and doesn't want to trawl through the thread for details I disabled the following in OpenCore to make it work.

BlueToolFixup
BRcmFirmwareData
BrcmPatchRAM3
IntelBTPatcher
IntelBluetoothFirmware

Also disabled onboard Bluetooth in BIOS.

I'm using MacOS Ventura 13.2.1 with OpenCore 0.8.9.
 
Last edited:
So my random beach ball lockup crashes are NVMe related. I'm using a WDSN770. Any thoughts? Lastest nvmefix.kext is installed.

I should add that this NVMe was working fine in Z490 Vision D.
panic(cpu 1 caller 0xffffff80221866a2): nvme: "3rd party NVMe controller. Loss of MMIO space. Write. fBuiltIn=1 MODEL=WD_BLACK SN770 2TB FW=731100WD CSTS=0xffffffff US[1]=0x0 US[0]=0x67 VID=0x15b7 DID=0x5017 CRITICAL_WARNING=0x0.\n" @IONVMeController.cpp:6090
Panicked task 0xffffff8bdee45670: 287 threads: pid 0: kernel_task
Backtrace (CPU 1), panicked thread: 0xffffff8bde8baaa0, Frame : Return Address
0xfffffffffed8ba20 : 0xffffff801f87bebd mach_kernel : _handle_debugger_trap + 0x41d
0xfffffffffed8ba70 : 0xffffff801f9de5e6 mach_kernel : _kdp_i386_trap + 0x116
0xfffffffffed8bab0 : 0xffffff801f9cd953 mach_kernel : _kernel_trap + 0x4d3
0xfffffffffed8bb00 : 0xffffff801f81ba70 mach_kernel : _return_from_trap + 0xe0
0xfffffffffed8bb20 : 0xffffff801f87c28d mach_kernel : _DebuggerTrapWithState + 0xad
0xfffffffffed8bc40 : 0xffffff801f87ba46 mach_kernel : _panic_trap_to_debugger + 0x2b6
0xfffffffffed8bca0 : 0xffffff80201148b3 mach_kernel : _panic + 0x84
0xfffffffffed8bd90 : 0xffffff80221866a2 com.apple.iokit.IONVMeFamily : __ZN16IONVMeController14CommandTimeoutEP16AppleNVMeRequest.cold.1
0xfffffffffed8bda0 : 0xffffff80221697cb com.apple.iokit.IONVMeFamily : __ZN16IONVMeController13FatalHandlingEv + 0x141
0xfffffffffed8bdd0 : 0xffffff8020049bb5 mach_kernel : __ZN18IOTimerEventSource15timeoutSignaledEPvS0_ + 0xa5
0xfffffffffed8be40 : 0xffffff8020049ab8 mach_kernel : __ZN18IOTimerEventSource17timeoutAndReleaseEPvS0_ + 0xc8
0xfffffffffed8be70 : 0xffffff801f8cef35 mach_kernel : _thread_call_delayed_timer + 0x505
0xfffffffffed8bee0 : 0xffffff801f8d0002 mach_kernel : _thread_call_delayed_timer + 0x15d2
0xfffffffffed8bfa0 : 0xffffff801f81b19e mach_kernel : _call_continuation + 0x2e
Kernel Extensions in backtrace:
com.apple.iokit.IONVMeFamily(2.1)[F339820D-7E46-3DDB-850D-C9BAD0659979]@0xffffff8022161000->0xffffff802218dfff
dependency: com.apple.driver.AppleMobileFileIntegrity(1.0.5)[C1F85B71-5DE2-3354-8158-D34EE65F6D0A]@0xffffff8020fb1000->0xffffff8020fd2fff
dependency: com.apple.iokit.IOPCIFamily(2.9)[49A13CB8-C698-3079-8A27-74A3B097E492]@0xffffff8022436000->0xffffff8022462fff
dependency: com.apple.iokit.IOReportFamily(47)[7628142B-AC63-3C0C-B32D-F94B359121C0]@0xffffff8022474000->0xffffff8022476fff
dependency: com.apple.iokit.IOStorageFamily(2.1)[B70CE90E-3064-37AD-B553-651F18B761B3]@0xffffff802257b000->0xffffff8022591fff

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

Because the error message says “loss of MMIO space”, see if below post helps. It’s for Gigabyte, but similar options may be present in Asus BIOS.

 
Because the error message says “loss of MMIO space”, see if below post helps. It’s for Gigabyte, but similar options may be present in Asus BIOS.
I've seen that on the Gigabyte boards. I couldn't find anything about it in Asus. I have now moved the NVMe to the slot closest to the CPU. I had my Windows drive there. I just pulled it for now. I'll put it in another slot later.

Before the computer crashed/locked randomly but the last lock up was after approx 6 or 7 minutes of video streaming and doing nothing else. Since I moved the drive, I've been streaming for 40 min now. I'll let it run for a bit longer and see how it goes.

Moving the drive to the first slot may be the answer with this board.
 
Does NVMEFix manage JUST the boot drive or all the NVME's in the system?

From my understanding (and from what I've read on this forum), people are saying you don't need to run the fix kext when running WD drives, true? Or should you always run it regardless?

I'm running an SN850 without the kext and seems to be working fine? Perhaps @ffk can try without and see if it makes a difference?

I initially had my macOS boot drive on the 2nd NVMe slot as the Windows Drive was on the first, and I didn't have an issue, now swapped them around and still no issue. I don't think it particularly matters which slot you use.

EDIT: If you are using NVMEFIX, however, try version 1.08. I read it fixed some other people's problems that were introduced when using 1.09 and above.
 
Last edited:
I initially had my MacOS boot drive on the 2nd NVMe slot as the Windows Drive was on the first and i didn't have an issue, now swapped them around and still no issue, so i don't think it particularly matters which slot you use.
I had the Mac NVMe in the very bottom slot.

I have since moved it to the top. Been running since my last post without a crash. :thumbup:
 
I am still on BIOS 2104. Have you tried that version.
Finally, I found the problem.
I have 2 M.2 SSDs. When I remove the second one (for data), macOS can be boot normally.

Then I fully reformat that M.2 SSD, and now works.
Problem fixed, but still have no idea what's wrong.
Anyway, Mac Pro is back.
Thank you very much !!
 
Thank you as well.
You are on Ventura, aren’t you? Which SSDT-MAPLE-RIDGE-RP05 version did you use for testing? I tried both V1B and V2 but I could not get it to work on Ventura 13.3 beta 2 (beta 1 & previous didn't work either IIRC).
I'm on Ventura 13.2.1 ... I don't use beta version. The reconnection of usb.c devices works with both V1B and V2 but, at the monent, I'm using V2 because of the NHI spoof.
 
Last edited:
Gigabyte has forcefully removed :eek: support for Titan Ridge through BIOS updates for some Z690/Z790 boards. So if you need a Hackintosh with working Thunderbolt, the best bet looks like a (flashed) GC-Titan Ridge (while supplies last!) in a non-Gigabyte motherboard.
@etorix Can you elaborate more and tell me which Gigabyte z690/790 motherboards have lost the support for Titan Ridge?
 
Back
Top