Contribute
Register

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

Hello and thanks to CaseySJ for all his work and effort!


I'm returning to this question because I'm experiencing something similar myself... i.e. the computer occasionally reboots after this kernel panic:

panic(cpu 3 caller 0xffffff801453b836): nvme: "3rd party NVMe controller. PCI link down. Write. fBuiltIn=1 MODEL=SPCC M.2 PCIe SSD FW=ECFM32.1 CSTS=0xffffff US[1]=0x0 US[0]=0x41 VID=0xffff DID=0xffff CRITICAL_WARNING=0x0.\n"

On my mb I have 3 NVMe installed, all PCIe 3.0:

M.2 Slot 1: Silicon Power A80 PCIe 3
M.2 Slot 2: WD SN750 PCIe 3
M.2 Slot 3: Silicon Power A80 PCIe 3
M.2 Slot 4: Empty

I was able to verify that by moving the NVMe from slot 3 to slot 4, the issue seems to disappear.
That is, I seem to have the problem if I keep slot 3 filled.
Thank you for posting this. It seems there are some BIOS issues that need to be worked out. Will reference this information in post 1 soon.
 
1

Didn't work.
Is there some Wiresharking in your future? :)

If anyone with that controller is willing to capture some Wireshark traffic, I can try to support the controller in liquidctl.
 
Is there some Wiresharking in your future? :)

If anyone with that controller is willing to capture some Wireshark traffic, I can try to support the controller in liquidctl.
Teach me obi wan. I am happy to probe usb traffic to understand the controller and enhance the liquidctl driver.
 
Here's the Thunderbolt DROM ready to be implanted into an existing SSDT.
Has anyone tried this on Maple Ridge? I don't mind doing some tests, but I would need some direction on plugging it into existing SSDT.

On separate but similar topic, is there a way to block Maple Ridge via SSDT but leaving it enabled in BIOS? Also interested in having an SSDT that blocks the Titan Ridge card- like how we're able to leave some Nvidia GPU's installed but leaving macOS blind to it. Just thinking for test purposes and bouncing over to Windows, it would be very helpful.

Also, seeing that most of the existing SSDT's in the latest EFI have the if "Darwin" argument... any known issues with booting Windows 11 via OpenCore? I know there are driver issues in Windows with the Aquantia Ethernet port, when coming back to macOS. (I have disabled in Windows.) I'm planning on having Adobe Premiere in Windows 11 for testing purposes.
 
Teach me obi wan. I am happy to probe usb traffic to understand the controller and enhance the liquidctl driver.

@dehjomz,

Let's start with something simple:
  • Download and install Wireshark for Windows
  • One of the options during installation will be USBPcap, which we must select, but the other option (for network capture, believe, can be skipped)
  • Launch Wireshark and double-click on USBPcap1 as shown in the red box:
WireShark-Start.png


Wireshark will begin capturing all USB traffic, which can be overwhelming so we'll apply a filter to monitor only the Aura LED controller.

Start by entering a filter condition as shown here, but specify idProduct of the Aura controller on your Z690 Maximus Formula. Then click the "right arrow" icon just to the right of the "x" on the same row. That will activate the filter.

WireShark-3.png


Here we see some USB traffic to and from the Aura LED controller on Z690 ProArt. If you click on any of the rows in the top half of the window, Wireshark will show details about that packet in the lower half. Here we've clicked on the first row and expanded the USB URB section in the bottom half.

The URB is the USB Request Block and it contains a lot of "header" information including Device address, which in this particular case is Device address: 4.

WireShark-2.png


Change the filter condition in the green box to usb.device_address == 4 (use the actual device address) and click the "right arrow" icon on the right side of the green rectangle. Then click the + icon to save this filter condition as a "favorite" so you don't have to remember it every time. When you click + you can give the filter a name. As you can see on the far right side of that line, I've given the name Asus Aura LED.

WireShark-1.png


Now use any app in Windows that controls LEDs. Most likely you'll be using Asus Aura Crate. As you change color modes and colors, you'll find that Aura Crate sends a continuous stream of control packets to the LED controller. This means it's operating in "direct" mode where the software is responsible for managing the dynamic color schemes. If you change the color mode to "static" you will find that the continuous stream of control packets comes to a stop because in static mode the software does not have to keep changing LED colors.

Recommendation:
  • Use Aura Crate to set all channels to static mode so there's no continuous barrage of USB traffic
  • Stop and start Wireshark capture
  • Just change color (not mode)
  • There should be about 10-15 packets of USB traffic
  • Stop and save the capture
  • Start the capture again
  • Now select a dynamic color mode and note which mode it was
  • A huge onslaught of USB traffic will begin
  • Switch back to static color mode to stop the onslaught
  • Stop and save the capture
  • Post the two capture files

WireShark-4.png
 
Last edited:
FYI- I tried the latest 12.3 public beta last night. Still has many glitches and metal scores were terrible.
 
I’ve noticed that, when the Asus restarts from macOS, the post time is longer. As if it’s training the memory again. Reboot from Windows and Linux proceeds much more quickly.

Turns out, enabling the OpenCore kernel quirk DisableRtcChecksum seems to help.
@dehjomz,

You are right that enabling DisableRtcChecksum kernel quirk significantly improves reboot time. I've also enabled the AppleRtcRam protocol override to see what effect that has since it is related to RTC checksum.
Screen Shot 2022-02-10 at 5.13.47 PM.png
 
FYI, owners of Asus ProArt Z690-Creator WiFi are eligible for a free 3-month Adobe Creative Cloud subscription (no credit card needed) that allows us to use all products in the suite. Just got my 3-month plan set up.

 
All P-cores, all E-cores, and Hyper-Threading enabled. The maximum CPU frequency will be that of the E-cores. But multi-threading performance will be better.
Could you please explain why this would be the case? Do you have evidence of this from actual benchmark testing? Isn't this the default setting you would use for Windows 11 as well?

Is this frequency limitation caused by CPUFriend.kext / CPUFriendDataProvider.kext or something else?

A friend is reporting stable 5 Ghz measured with Intel Power Gadget and similar results of Geekbench between macOS and Windows on a Gigabyte Z690I Aorus. I have seen you make the the same statement on the Gigabyte Alder lake Golden Build, so I have to assume, that this is general and not motherboard specific.

macOS on Intel x86 architecture regards all cores as the same. It is not aware of the differences between P-cores and E-cores so it will schedule tasks at any time on any type of core.
From my understanding of P-Cores and E-Cores, macOS handles them in the same way as Windows 10 would without any special kind of prioritisation of P-Cores. This should lead to benchmark scores similar to those of Windows 10 in this comparison with Windows 11, which only shows small differences, as seen here:

 
Could you please explain why this would be the case? Do you have evidence of this from actual benchmark testing? Isn't this the default setting you would use for Windows 11 as well?
Actually, it's about the frequency of the ring bus between cores: Inter-core communication and access to L3 cache goes faster if only P-cores are active, and slower if E-cores are enabled. This is measurable, and independent of any scheduler:
Hopefully, in real multithreaded workloads, the small performance loss for P-cores is more than off-setted by having more cores sharing the work.
 
Back
Top