Thank you for helping me.Thanks for sharing!
Was and wasn't, it didn't do what it did with x299 system or unless somehow I screwed up.So SSDT-SLEEP is (was?) for debug purposes. There's nothing to fix the system bus, no USB map and you're still using the port limit quirk—but you've solved the sleep issue otherwise.
Any reason why you've introduced SSDT-IMEI from the previous C612 generation?
Sorry I'm not sure what do you mean?I'm not familiar yet with these path fixing SSDTs, but the GFX1 SSDT lacks the _DSM method of GFX0.
If you introduce and load this modified SSDT-GFX1, does it make any change to the behaviour of the second GPU in slot 3 or to the way it's displayed in IORegistryExplorer?
You're absolutely right without patching 0X1AA the system just hangs on C621 board well at least on ASUS it does, and seem that the lates UEFI patch doesn't completely patch the bios or screws something up because whilst the patched bios WILL let you boot it'll cause an instant kernel panic o the wake from sleep, but if done from OC sleep and wake are perfect.In my (admittedly limited) experience with C422 and C621 boards, while Dortania's documentation is generally very thorough and works perfectly with consumer boards, the HEDT guide follows the consumer guide too closely and is not by itself sufficient to successfully boot a server/workstation-class board. For instance, the Kernel section does NOT mention unlocking MSR 0x1AA (AppleXcpmExtraMsrs), which is an additional requirement to boot on this class of hardware, similar and alongside to unlocking MSR 0xE2 (AppleXcpmCfgLock).
That's actually perfectly fine!
Server/HEDT boards now tend to comply with ACPI 6.3 specification and generically define their processors as "devices" while OS X expects to find ACPI 6.2 "processor" objects. With such an ACPI 6.3 DSDT, the OS X boot process stalls just after loading ACPI tables because OS X cannot find a processor to run onto—which is quite a bummer.
@metacollin devised a solution by wrapping the CPxx devices and their methods in PRxx processor objects, which is what the SSDT-CPU-WRAP does. Any further SSDT which refers to processors, such as SSDT-PLUG, should then load after SSDT-CPU-WRAP and attach to the wrapping PRxx objects and not to the actual CPxx devices.
I have seen only few ACPI 6.3 DSDTs so far, and I own only one of these boards—which is not enough to get to the bottom of this CPU wrapping wizardry. After making my own SSDT, I found I could actually boot with @metacollin 's SDDT cut down to one socket, although my Gigabyte board and his Supermicro board do not define the same set of methods and functions for their processors (and not all of these are defined in the DSDT). So it doesn't appear necessary to wrap up everything.
Someone has suggested that it is sufficient to wrap just the CPUs themselves (like what Dortania is now doing for HyperV), but I could not succeed and confirm this. Examining ACPI tables from yet another manufacturer could be of interest.
Thank you very much.I'll have a look at this tomorrow (Tuesday) and get back to you with any thoughts or recommendations.
Click on "+ Quote", then click "Reply".Sorry guys I can't seem to figure out how this multi-quote thing works so I'll do the old way.
Or maybe SSDT-SLEEP doesn't work on C621 as it does on X299. (Is there documentation on it somewhere?)Was and wasn't, it didn't do what it did with x299 system or unless somehow I screwed up.
I realised that anyone could download the firmware and tried patching 1102 and 6702. The process appeared to work for both, with 28 and 24 bytes replaced. But of course it takes the actual board to check there is no side effect. If you think that reverting to the original firmware has solved the sleep issue, I'd recommend removing all other attempts at fixing sleep.You're absolutely right without patching 0X1AA the system just hangs on C621 board well at least on ASUS it does, and seem that the lates UEFI patch doesn't completely patch the bios or screws something up because whilst the patched bios WILL let you boot it'll cause an instant kernel panic o the wake from sleep, but if done from OC sleep and wake are perfect.
My wrapping SSDT does what it should for all CPU methods from the DSDT. Can't tell about further CPU methods which could be defined in SSDT*.aml or OEM*.aml files—that's why I look at the full SysReport folder for wrapping. I wondered whether Asus defined some method for CPU power states which is not used by Gigabyte, and thus is not wrapped by my SSDT, and whether this could explain the sleep issue. But if the unpatched firmware fixes your sleep issue, all is well.Also attaching raw DSDT.aml dump from OC.
I think you were looking at IOReg with the SSDT active in the system, this is the IOReg without SSDT for GFX0Single GPU
The ACPI path (address) for the single GPU with three active displays is
IOACPIPlane:/_SB/PC02@0/BR2A@0/D035@ffff/BRG0@0/GFX0@0
This translates to (SB.PC02.BRA2.D035.BRG0.GFX0) or (SB.PC02.BRA2.D035.BRG0) so the path(s) used in the SSDT you tried were wrong.
Thats my problem, I even installed the windows to test it the second GPU works perfectly fine under windows.Dual GPUs
In comparison the IOReg ACPI Paths for the dual GPU setup were as follows:
IOACPIPlane:/_SB/PC02@0/BR2A@0/D035@ffff/BRG0@0/GFX0@0 - GPU 1
This translates to (SB.PC02.BRA2.D035.BRG0.GFX0) & (SB.PC02.BRA2.D035.BRG0), matching the paths when only one GPU was installed.
IOACPIPlane:/_SB/PC03@0/BR3A@0/D037@ffff - GPU 2
Translates as (SB.PC02.BRA3.D037) and stops, there is no GFX1 associated with this GPU. It shows no connectors being available, unsurprisingly. So it probably doesn't work and is probably just sitting there wasting electricity.
"Technically" yesWhich 'Slot' is this card mounted within, 'Slot-3', i.e. third from top?
Attached.You do not appear to have WhateverGreen.kext or AppleALC.kext installed in your system, can I ask why not? Under the Resources section of both IOReg's only Lilu.kext is showing as being present.
Provide copy of EFI
Can you post a copy of your EFI folder, but remove the Serial, MLB, ROM etc. from your config.plist so we can see what you are using to boot your system.
I have assumed you don't have any third-party kexts installed in your /Library/Extensions or /System/Library/Extensions folder.
To be quite honest I just didn't have a chance to look into USB, I was waiting to get both GPUs working then the TB3/4 then get the all USB ports setup.USB ports
(Off Topic) Your USB configuration is a bit off to my mind. You have ports HS01-HS08 inclusive and SS01-SS06 inclusive active in your system. They all have the same connector Type (0xff), which I believe means all the ports are set as USB2. This is very wrong as the SSxx ports should be set as USB3 and some of the HSxx ports should also be set as USB3, others as 'Internal' (bluetooth connection). You have a few USB3.1/2 Type-C ports, which do not seem to be active or are not included in the setup you are using.
I actually tried that with 0 results, I get black screen with/without Pikera argument.@Edhawk Thanks for your insights.
The config.plist provided above shows WhateverGreen… but disabled. Perhaps the effect of too many "Snapshot" (not "Clean Snapshot") in ProperTree?
Anyway, I suppose the next thing to try would be with WhateverGreen enabled, loaded, and no GFX SSDT.
Yup x299 works perfectly, I just left the USB at the end since its the easiest thing to fix.The system for which help is required is the work-in-progress Asus Pro C621-64L Sage/10G in @ramazarusx signature, not the (presumably fully working) X299 board currently under his profile.
4 back USB 3.2 Gen 1, 1 USB 3 header, 1 USB 2 header + 2 USB 3.2 Gen 2 (ASMedia controller)
This should be within the 15 port limits but doing a full USB map and removing the port limit quirk can only improve stability.
Thank you!Click on "+ Quote", then click "Reply".
Put the pointer in the quoted message where you want to cut and hit "return". Repeat as needed.
I removed both of them, IMEI I think was there because I guess it was late and I put it there without realizing that I didn't need it. Removed Sleep lets see what happens.Or maybe SSDT-SLEEP doesn't work on C621 as it does on X299. (Is there documentation on it somewhere?)
Has it brought any visible improvement? If not, I'd suggest to remove it.
Same question, and same suggestion for SSDT-IMEI. Or had you put it in response to a kernel message about IMEI?
I'm 6702 with both patched by OC works perfectly fine and got full sleep, its the BIOS patching that was causing the panic.I realised that anyone could download the firmware and tried patching 1102 and 6702. The process appeared to work for both, with 28 and 24 bytes replaced. But of course it takes the actual board to check there is no side effect. If you think that reverting to the original firmware has solved the sleep issue, I'd recommend removing all other attempts at fixing sleep.
Attaching the SysReport.My wrapping SSDT does what it should for all CPU methods from the DSDT. Can't tell about further CPU methods which could be defined in SSDT*.aml or OEM*.aml files—that's why I look at the full SysReport folder for wrapping. I wondered whether Asus defined some method for CPU power states which is not used by Gigabyte, and thus is not wrapped by my SSDT, and whether this could explain the sleep issue. But if the unpatched firmware fixes your sleep issue, all is well.
Already installed, Thank you very much.I used your DSDT to make a further SSDT to fix the system bus for OS X. This is not necessary to boot but recommended by Dortania post-install.
/_SB/PC02@0/BR2A@0/D035@ffff/BRG0@0/GFX0@0 should translate toDual GPUs
In comparison the IOReg ACPI Paths for the dual GPU setup were as follows:
IOACPIPlane:/_SB/PC02@0/BR2A@0/D035@ffff/BRG0@0/GFX0@0 - GPU 1
This translates to (SB.PC02.BRA2.D035.BRG0.GFX0) & (SB.PC02.BRA2.D035.BRG0), matching the paths when only one GPU was installed.
IOACPIPlane:/_SB/PC03@0/BR3A@0/D037@ffff - GPU 2
Translates as (SB.PC02.BRA3.D037) and stops, there is no GFX1 associated with this GPU. It shows no connectors being available, unsurprisingly. So it probably doesn't work and is probably just sitting there wasting electricity.
DefinitionBlock ("", "SSDT", 2, "ACDT", "BRG0", 0x00000000)
{
External (_SB_.PC03.BR3A.D037, DeviceObj)
Scope (\_SB.PC03.BR3A.D037)
{
Device (BRG0)
{
Name (_ADR, Zero) // _ADR: Address
Device (GFX1)
{
Name (_ADR, Zero) // _ADR: Address
}
}
}
}
DefinitionBlock ("", "SSDT", 2, "ACDT", "BRG0", 0x00000000)
{
External (_SB_.PC02.BR2A.D035, DeviceObj)
Scope (\_SB.PC02.BR2A.D035)
{
Device (BRG0)
{
Name (_ADR, Zero) // _ADR: Address
Device (GFX0)
{
Name (_ADR, Zero) // _ADR: Address
Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method
{
If ((Arg0 == ToUUID ("a0b5b7c6-1318-441c-b0c9-fe695eaf949b") /* Unknown UUID */))
{
Local0 = Package (0x06)
{
"built-in",
Buffer (One)
{
0x00 // .
},
"AAPL,slot-name",
Buffer (0x07)
{
"Slot-1"
},
"model",
Buffer (0x16)
{
"AMD Radeon RX 5700 XT"
}
}
}
Return (Zero)
}
}
}
}
}