Z690 Chipset Motherboards and Alder Lake CPU

[Talanca]

Have you properly mapped your USB Ports? Also are you using the AQUANTIA 10GbE LAN for networking purposes?

Hello, thanks for your quick response.
With the new port limit patch fix in OC 0.9.3 I did the mapping with hackintool, and it's working much better than with USBToolBox. I didn't tried disabling the Aquantia NIC, it's fully recognized via SSDT-AQUANTIA-AQC113C and forceaquiantiaethernet quirk. Also intel i225-V is working without specify device-id in DeviceProperies or patches, with built in com.apple.DriverKit-AppleEthernetE1000 loaded.
VTD is enabled, but without dropping DMAR table
But now that you mention it I see a lot of errors in the SSDT load log. Although it confirms that 25 ACPI AML tables successfully acquired and loaded

Sleep Wake failure in EFI

Failure code:: 0x00000000 0x0000001f

Please IGNORE the below stackshot

================================================================
Date/Time: 2023-07-11 17:09:42.276 -0300
OS Version: ??? ??? (Build ???)
Architecture: x86_64
Report Version: 40
Incident Identifier: CD781821-A67B-49C2-82F8-040B00A29795

Data Source: Stackshots
Shared Cache: E15DC6AC-9320-3B97-95DE-B6E917A43EC4 slid base address 0x7ff80bb94000, slide 0xbb94000 (System Primary)
Shared Cache: 3435F190-0CA3-3DF3-945A-B71E80A5867B slid base address 0x7ff802561000, slide 0x2561000 (DriverKit)

Event: Sleep Wake Failure
Duration: 0.00s
Steps: 1

Boot args: keepsyms=1 debug=0x100 -wegnoigpu agdpmod=pikera -noht40

Time Awake Since Boot: 14s



Process: swd [381]
Shared Cache: E15DC6AC-9320-3B97-95DE-B6E917A43EC4 slid base address 0x7ff80bb94000, slide 0xbb94000 (System Primary)
Architecture: x86_64
Footprint: 552 KB
Time Since Fork: 2s
Num samples: 1 (1)

Thread 0x99f 1 sample (1) priority 4 (base 4)
<thread QoS background (requested background), thread darwinbg, process darwinbg, IO tier 2>
1 start + 1903 (dyld + 25631) [0x7ff80bc3241f] 1
1 ??? [0x10e8185ce] 1
1 ??? [0x10e818362] 1
1 __stack_snapshot_with_config + 10 (libsystem_kernel.dylib + 49986) [0x7ff80bf58342] 1
*1 ??? [0xffffff800040ed96] 1
*1 ??? [0xffffff8000a5ed90] 1
*1 ??? [0xffffff8000961486] 1
*1 ??? [0xffffff8000430d5f] 1
*1 ??? [0xffffff800043064a] 1
*1 ??? [0xffffff800046e7dd] (running) 1

Binary Images:
0x7ff80bc2c000 - 0x7ff80bcc45cf dyld (1066.8) <5DB85B72-C63A-3182-91E5-5C942EC30E48> /usr/lib/dyld
0x7ff80bf4c000 - 0x7ff80bf85ff7 libsystem_kernel.dylib (8796.121.3) <EB4E80A0-99DA-32DC-B9AD-394FBB50A0AC> /usr/lib/system/libsystem_kernel.dylib

 

[Talanca]

** Reboot After Second Wake-from-Sleep Has Been Fixed **​

After patching two ACPI tables on Gigabyte Z690 Aero G, the system is now able to sleep and wake properly each time. This is being posted after the 3rd consecutive wake-from-sleep.

The two patches for most Gigabyte Z690 boards are as follows:

Patch 1: Table IgfxSsdt

• Table Signature: SSDT
• OemTableID: 49676678 53736474
• Find: 4D435F5F
• Replace: 4D434843
• Comment: Change MC__ to MCHC
• Count = 0
• Limit = 0
• Skip =0
• Enabled = True

Patch 2: Table GSWApp

• Table Signature: SSDT
• OemTableID: 47535741 7070
• Find: 43031419 41444247
• Replace: 43031419 58444247
• Comment: Change ADBG to XDBG
• Count = 1
• Limit = 0
• Skip = 0
• Enabled = True

After making these changes, the boot log looks much better:

kernel: (AppleACPIPlatform) ACPI:
kernel: (AppleACPIPlatform) ACPI:
kernel: (AppleACPIPlatform) 23 ACPI AML tables successfully acquired and loaded
kernel: (AppleACPIPlatform) 23 ACPI AML tables successfully acquired and loaded
kernel: (AppleACPIPlatform)
kernel: (AppleACPIPlatform)

These changes will be added to V4 of the EFI to be uploaded to Z690 Aero G build guide soon.
View attachment 535266

Hi @CaseySJ
I'm still struggling with the hang on the second sleep.
Apparently the ACPI patch Change ADBG to XDBG is not working on the Z690 Aero D motherboard.
When looking for the rename in MaciASL at System DSDT wich is automatically loaded when opening... having the patch activated, it doesn't show the rename to XDBG, it still appears as ADBG.
Could it be that this motherboard needs to specify another value in the patch?
Thanks in advance

 

[CaseySJ]

Hi @CaseySJ
I'm still struggling with the hang on the second sleep.
Apparently the ACPI patch Change ADBG to XDBG is not working on the Z690 Aero D motherboard.
When looking for the rename in MaciASL at System DSDT wich is automatically loaded when opening... having the patch activated, it doesn't show the rename to XDBG, it still appears as ADBG.
Could it be that this motherboard needs to specify another value in the patch?
Thanks in advance

The fix for ADBG actually takes place in the SSDT or table called GSWApp. So let's try this:

• Run MaciASL
• Select File -> Export Tableset...
• Post the tableset file

 

[Talanca]

The fix for ADBG actually takes place in the SSDT or table called GSWApp. So let's try this:

• Run MaciASL
• Select File -> Export Tableset...
• Post the tableset file

Searching for gswapp does not return any results, I don't know if I'm doing it wrong

But it shows a table when searching for ADBG, I don't know if it has something to do with it

Thanks for your time

 

[CaseySJ]

Searching for gswapp does not return any results, I don't know if I'm doing it wrong

But it shows a table when searching for ADBG, I don't know if it has something to do with it

...

The SSDT GSWApp does indeed exist and contains a method called ADBG:

Let's change the ACPI patch to this:

Patch 2: Table GSWApp

• Table Signature: SSDT
• OemTableID: 47535741 7070
• Find: 41444247
• Replace: 58444247
• Comment: Change ADBG to XDBG
• Count = 1
• Limit = 0
• Skip = 0
• Enabled = True

Let's make this change, reboot, and see if 2nd sleep/wake cycle is okay.

 

[Talanca]

The SSDT GSWApp does indeed exist and contains a method called ADBG:
View attachment 569142View attachment 569143
Let's change the ACPI patch to this:

Patch 2: Table GSWApp

• Table Signature: SSDT
• OemTableID: 47535741 7070
• Find: 41444247
• Replace: 58444247
• Comment: Change ADBG to XDBG
• Count = 1
• Limit = 0
• Skip = 0
• Enabled = True

Let's make this change, reboot, and see if 2nd sleep/wake cycle is okay.

It does the first sleep well, and now it can enter the second! (before this modification it didn't, it hung trying to enter the second sleep and unable to complete it turning off leds and fan), but when it wakes up it restarts.

Should ADBG show up renamed as XDBG in MaciASL with the ACPI patch?
It keeps showing entries with ADBG and none with XDBG

 

[CaseySJ]

…

Should ADBG show up renamed as XDBG in MaciASL with the ACPI patch?
It keeps showing entries with ADBG and none with XDBG

Yes it should show up as XDBG, but only in the GSWApp SSDT.

It may be helpful to run this in Terminal:

log show --last boot | head -1500 > ~/Documents/bootlog.txt

This will create a file in Documents folder called bootlog.txt. Please post that file.

 

[Talanca]

Yes it should show up as XDBG, but only in the GSWApp SSDT.

It may be helpful to run this in Terminal:

log show --last boot | head -1500 > ~/Documents/bootlog.txt

This will create a file in Documents folder called bootlog.txt. Please post that file.

This is driving me crazy!!!!
I did all the USB mapping methods to try to solve the sleep issue (USBPorts, USBMap and USBInjectAll + SSDT-UIAC), using any of them all the ports work correctly. With corpnewt's USBMap tried both AppleUSBHostMergeProperties and the legacy MergeNub, and also the IOPathMatch option. I'm currently testing with SSDT-UIAC and it works fine too. With any of the options mentioned, an error of speed not supported in XHCI3 appears on boot, I don't know if it is related to SSDT-MAPLE-RIDGE-RP05-V2.aml.
In all the options mentioned above, tried doing the mapping including XCH3 and without XCH3. Now I'm using it as in your Asus Z690 ProArt guide, with SSDT-UIAC mapping only XHCI
Either way, when trying to go to sleep by disabling both Thunderbolt and Aquantia related DSDTs, as well as disabling Thunderbolt from the bios and with any USB mapping method, it does the exact same thing:
First sleep it does fine, in the second when trying to come back from sleep it restarts. One thing I noticed is that when entering the second sleep, it does not turn off the power led as in the first

 

[Edhawk]

I think the six ports in the screenshot relate to your 3 x Type-C connectors, as each port supports 2 x USB ports in the USB configuration, a Type-C physical port (9) and a USB2 virtual port (9).

If your USB 3.2 Gen 2 (Type-C) ports work at 20 Gbps speeds then this may be what the message is saying is not supported in macOS. I would have thought that macOS would just limit the speed to the supported 10 Gbps for USB3.2 Gen 1. As shown in the table below.

USB speeds

Logical thing to try is excluding the XHC3 controller from your USBPorts or USBMap kext. You may need to disable these ports in your bios, to really exclude them from the startup processes.

Looking through your Bootleg.txt I noticed that XHCI@14000000 is also showing an issue, with inconsistent speed ID's. XHCI@14000000 relates to your XHC USB controller from the Intel Chipset. This probably means your USBPorts.kext/Contents/Info.plist contains different ID's for similar ports.

Posting a copy of your USBPorts.kext would be the next logical step, so we can see what you are using and if any editing is required.

 

[Talanca]

I think the six ports in the screenshot relate to your 3 x Type-C connectors, as each port supports 2 x USB ports in the USB configuration, a Type-C physical port (9) and a USB2 virtual port (9).

If your USB 3.2 Gen 2 (Type-C) ports work at 20 Gbps speeds then this may be what the message is saying is not supported in macOS. I would have thought that macOS would just limit the speed to the supported 10 Gbps for USB3.2 Gen 1. As shown in the table below.

View attachment 569295 USB speeds

Logical thing to try is excluding the XHC3 controller from your USBPorts or USBMap kext. You may need to disable these ports in your bios, to really exclude them from the startup processes.

Looking through your Bootleg.txt I noticed that XHCI@14000000 is also showing an issue, with inconsistent speed ID's. XHCI@14000000 relates to your XHC USB controller from the Intel Chipset. This probably means your USBPorts.kext/Contents/Info.plist contains different ID's for similar ports.

Posting a copy of your USBPorts.kext would be the next logical step, so we can see what you are using and if any editing is required.

Oh ok, thanks for the clarification on the speed of the XHC3 USB-C.
Currently XHC3 is not included in the mapping. Regarding the speed inconsistency in XHCI@14000000, I thought it could be because HSxx is disabled and left only SSxx on two of the ports in order to reach 15.
Here’s included the SSDT's made with SSDTime, and the SSDT-UIAC that I use together with USBInjectAll, obviously when I don't use USBPorts.kext. Also tried adding the power properties into USBMap.kext s has not have to use SSDT-USBX, but the result is the same with the sleep behavior. Tried without using SSDT-EC also, but again, its the same.
Thanks for the help!

EDIT: I forgot to mention that I tried to map with USBMap because of this