GPP0 instant waking out of sleep. How to disable?

[IKON]

Can you post a copy of your IOReg with the 980 Pro uninstalled, I would like to see what change this made if the GPP0 device is not visible.

Sure! Check Attached File.

 

[IKON]

P.S. I updated to Ventura and it also doesn't fix sleep...

I also think the PTXH denominator in the previous wakeup instance I gave you might be me pressing the keyboard after the sleep/wake that happens anyway (Goes to sleep, hear a click from PSU powering down, immediately click from PSU powering up, everything turns on again except screen, then I click my keyboard). as it happens 4 seconds after the normal GPP0 wake.

2022-09-28 11:36:00.317044+0200 localhost kernel[0]: (AppleACPIPlatform) ACPI S3 WAKE
2022-09-28 11:36:00.323721+0200 localhost kernel[0]: (AppleACPIPlatform) Facs->FirmwareWakingVector: 0x0
2022-09-28 11:36:00.323723+0200 localhost kernel[0]: (AppleACPIPlatform) Facs->Length: 0x40
2022-09-28 11:36:00.323724+0200 localhost kernel[0]: (AppleACPIPlatform) Facs->Version: 0x2
2022-09-28 11:36:00.323724+0200 localhost kernel[0]: (AppleACPIPlatform) Facs->XFirmwareWakingVector: 0x0
2022-09-28 11:36:00.323725+0200 localhost kernel[0]: (AppleACPIPlatform) Facs->OspmFlags: 0x0
2022-09-28 11:36:00.323757+0200 localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: GPP0
2022-09-28 11:36:00.323757+0200 localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: GPP0

And then a few seconds later:

2022-09-28 11:36:04.456699+0200 localhost kernel[0]: PMRD: power clamped AMDFramebufferVega10 100000568, ps 2->1, cflags 0x2011)
2022-09-28 11:36:04.456729+0200 localhost kernel[0]: (IOAcceleratorFamily2) IOReturn IOAccelDisplayPipe::display_change_handler(void *, IOFramebuffer *, IOIndex, void *) event = <6> at <529971601965>
2022-09-28 11:36:04.456732+0200 localhost kernel[0]: (IOAcceleratorFamily2) IOReturn IOAccelDisplayPipe::display_change_handler(void *, IOFramebuffer *, IOIndex, void *) completed at <529971604540> taking <2575> ns
2022-09-28 11:36:04.459525+0200 localhost kernel[0]: (IOUSBHostFamily) AppleUSB20HubPort@00a40000: AppleUSBHostPort::enumerateDeviceComplete_block_invoke: enumerated 0x1b1c/1b13/0308 (Corsair K70 RGB Gaming Keyboard / 7) at 12 Mbps
2022-09-28 11:36:04.459541+0200 localhost kernel[0]: (IOUSBFamily) AppleUSBLegacyRoot@(null): AppleUSBLegacyRoot::usbServiceCallback: controller <private> (PTXH) usbServiceArray <private>(count 1) options 0x00000000
2022-09-28 11:36:04.459545+0200 localhost kernel[0]: (IOUSBFamily) AppleUSBLegacyRoot@(null): AppleUSBLegacyRoot::usbServiceCallback: [0] <private>
2022-09-28 11:36:04.459547+0200 localhost kernel[0]: (IOUSBFamily) AppleUSBLegacyRoot@(null): AppleUSBLegacyRoot::usbServiceCall: controller <private> (PTXH) usbService <private> (Corsair K70 RGB Gaming Keyboard ) options 0x00000000
2022-09-28 11:36:04.459556+0200 localhost kernel[0]: (IOUSBFamily) AppleUSBLegacyRoot@(null): AppleUSBLegacyRoot::getOrCreateLegacyControllerGated: located existing AppleUSBController@00000000
2022-09-28 11:36:04.459558+0200 localhost kernel[0]: (IOUSBFamily) AppleUSBLegacyRoot@(null): AppleUSBLegacyRoot::usbServiceCallGated: IOUSBHostDevice <private> (Corsair K70 RGB Gaming Keyboard )
2022-09-28 11:36:04.459565+0200 localhost kernel[0]: (IOUSBFamily) AppleUSBLegacyRoot@(null): AppleUSBLegacyRoot::addDeviceToUsbPlane:
2022-09-28 11:36:04.459702+0200 localhost kernel[0]: (IOUSBFamily) AppleUSBLegacyRoot@(null): AppleUSBLegacyRoot::usbServiceCall: usbServiceCallbackGated completed with 0x00000000 and service <private>
2022-09-28 11:36:04.459709+0200 localhost kernel[0]: (IOUSBFamily) AppleUSBLegacyRoot@(null): AppleUSBLegacyRoot::usbServiceCall: registering Corsair K70 RGB Gaming Keyboard @00a40000 (<private>) for matching
2022-09-28 11:36:04.460968+0200 localhost kernel[0]: (AMDRadeonX5000) [12:0:0]: Controller is enabled, finish initialization
2022-09-28 11:36:04.461341+0200 localhost kernel[0]: (IOAcceleratorFamily2) IOReturn IOAccelDisplayPipe::display_change_handler(void *, IOFramebuffer *, IOIndex, void *) event = <4> at <529976213516>
2022-09-28 11:36:04.461343+0200 localhost kernel[0]: (IOAcceleratorFamily2) IOReturn IOAccelDisplayPipe::display_change_handler(void *, IOFramebuffer *, IOIndex, void *) completed at <529976216141> taking <2625> ns
2022-09-28 11:36:04.461349+0200 localhost kernel[0]: (IOAcceleratorFamily2) IOReturn IOAccelDisplayPipe::display_change_handler(void *, IOFramebuffer *, IOIndex, void *) event = <4> at <529976221391>
2022-09-28 11:36:04.461449+0200 localhost kernel[0]: (IOAcceleratorFamily2) IOReturn IOAccelDisplayPipe::display_change_handler(void *, IOFramebuffer *, IOIndex, void *) completed at <529976321569> taking <100178> ns
2022-09-28 11:36:04.461456+0200 localhost kernel[0]: (IOAcceleratorFamily2) IOReturn IOAccelDisplayPipe::display_change_handler(void *, IOFramebuffer *, IOIndex, void *) event = <8> at <529976328472>
2022-09-28 11:36:04.461478+0200 localhost kernel[0]: (IOAcceleratorFamily2) IOReturn IOAccelDisplayPipe::display_change_handler(void *, IOFramebuffer *, IOIndex, void *) completed at <529976351244> taking <22772> ns
2022-09-28 11:36:04.467957+0200 localhost kernel[0]: PMRD: trace point 0x27 detail 0x00000000
2022-09-28 11:36:04.467967+0200 localhost kernel[0]: PMRD: power clamped IODisplayWrangler 1000004c0, ps 4->0, cflags 0x2011)
2022-09-28 11:36:04.467971+0200 localhost kernel[0]: PMRD: system wake events: GPP0 PTXH
2022-09-28 11:36:04.467972+0200 localhost kernel[0]: system wake events: GPP0 PTXH

There is some clutter, but here you can see I do a call on the keyboard after which the system wake event with PTXH shows up.

Edit: the real problem is in the first quote. If you want to see more of the Kernal, let me know, I will do a sleep call and post you the entire section up until waking up.

 

[Edhawk]

My apologies, GPP0 has been removed from your IOReg when your 980 Pro is removed. I didn't expect that, as normally the device is retalined but with nothing attached.

The really strange thing is the PTXH controller is not shown as connected to the GPP0 PCI Bridge, but rather is connected to GPP1 PCI bridge in both IOReg's.

Only the Samsung 980 Pro is shown as being connected to the GPP0 in your original IOReg. So with the drive and the device missing, logically it shouldn't be making a wake call on AppleACPIPlatform.

 

[IKON]

My apologies, GPP0 has been removed from your IOReg when your 980 Pro is removed. I didn't expect that, as normally the device is retalined but with nothing attached.

The really strange thing is the PTXH controller is not shown as connected to the GPP0 PCI Bridge, but rather is connected to GPP1 PCI bridge in both IOReg's.

Only the Samsung 980 Pro is shown as being connected to the GPP0 in your original IOReg. So with the drive and the device missing, logically it shouldn't be making a wake call on AppleACPIPlatform.

I know right! Would it help if I shared my EFI with you? Maybe I did something wrong there and the OS is recognising GPP0 as something different?

 

[Edhawk]

This is more likely to be a DSDT.aml coding issue than it is to be an error in your OC setup.

If you do post your EFI, I will have a look to see it isn't something erroneous in your setup.

Just remember to redact/delete your Serial Number, MLB, ROM and SystemUUID from your config.plist before you post a copy here.

Can you post a copy of the Hackintool > PCIe > export files from your system. These need to be generated/exported with the Samsung 980 Pro installed in the system.

Hackintool > PCIe tab

Can you alsos post a copy of the Dump ACPI tables from Hackintool > Utilities tab, so I can see what is present in your system DSDT & SSDT's regarding GPP0 device.

Hackintool > Utilities tab

 

[IKON]

This is more likely to be a DSDT.aml coding issue than it is to be an error in your OC setup.

If you do post your EFI, I will have a look to see it isn't something erroneous in your setup.

Just remember to redact/delete your Serial Number, MLB, ROM and SystemUUID from your config.plist before you post a copy here.

Can you post a copy of the Hackintool > PCIe > export files from your system. These need to be generated/exported with the Samsung 980 Pro installed in the system.

Can you alsos post a copy of the Dump ACPI tables from Hackintool > Utilities tab, so I can see what is present in your system DSDT & SSDT's regarding GPP0 device.

Hackintool > Utilities tab

Yes All three of them in the attachment. I scanned all SSDT's and the DSDT and GPP0 is ONLY in the DSDT and the pcidevices.txt. There is nothing about it in ANY of the SSDT's. The same applies to GPP1. If we move on, GPP8 is in SSDT 5, 6 and 7. These SSDT's, DSDT and pcidevices.txt are also the only files that have a mention of "GPP"(didn't scan the EFI but I believe it's the same).

 

[Edhawk]

First, you should not have a copy of your DSDT.aml in your /EFI/OC/ACPI folder, ever! This is a big no - no as far as OpenCore is concerned.

I assume the DSDT.aml in the ACPI folder hasn't been patched/edited in any way. So there is no need to have this table in the ACPI folder. I stronly recommend you remove the DSDT.aml from the ACPI folder and any companion entry in the config.plist.

The only items that should be placed in the ACPI folder are custom SSDT's, which have been created/added to make your system work with macOS.

I am looking to see if an additional SSDT-SBUS- would help your system, but can;t see the full ACPI path for the SBUS device in your pciedevices.txt file.

Second, Can you post a screenshot of the Hackintool > PCIe tab, fully expanded so all the IOReg Name, IOReg IOName and Device Paths are shown. As shown in the example below.



If you are wondering what the SSDT does, here is a link to the Dortania post installation guide for creating this SSDT.

Fixing SMBus support (SSDT-SBUS-MCHC) | Getting Started With ACPI

Third, I don't think the SSDT-RX-Vega 64-version2.3.aml is set correctly for your system. The Device ID/IOReg Name looks completely wrong for your card, going by the partitial IOReg Name visible in the pciedevices.txt file.

screenshot of wrong device address

Screenshot of DGPU information from pciedevices.txt


Thre is no SWDS device/path in the SSDT, so it won't be looking in the correct location for your Vega 64.

Fourth, Do you need both AGPMInjector.kext and dAGPM.kext, aren't these two kexts both providng GPU power management, the same as the SSDT-RX-Vega 64 table?

If you get the SSDT set correctly then you probably won't need the two kexts.

The rest of the OC sub-folder content is fine.

I haven't reviewed your config.plist just yet but will do so shortly.

 

[Edhawk]

The 'Drivers' section has been duplicated in the config.plist. The first instance of this section sits above the ACPI section, which is wrong. The second instance of the Drivers section is in the correct position.

You should delete the duplicate 'Drivers' section at the top of the config.plist, immediately below the Root entry.



You are using the -radcodec boot argument, why? Your Vega 64 doesn't use a spoofed PID, so you shouldn't need this boot argument. Use of the boot argument is explained below.

-radcodec to force the spoofed PID to be used in AMDRadeonVADriver​

Revised EFI
I have made the following changes to your setup.

1. Deleted DSDT.aml and config.plist entry.
2. Deleted SSDT-RX-Vega 64.... and config.plist entry.
3. Delete duplicate Drivers section from config.plist
4. Deleted -radcodec boot arg from config.plist.
5. Removed unnecessary place holder entries, to make reading and navigating the config easier.
6. Added a populated Resources folder to OC folder.
7. Changed OC boot option from Builtin to External, so you have a graphical GUI in place of the text Picker list when you boot OC.

You need to add your Serial Number etc. to the PlatformInfo > Generic section before you use this EFI.

We can look at creating the SSDT-SBUS table and editing your RX Vega64 SSDT once you have booted with the revised EFI.

Let's see if this helps.

 

[Edhawk]

Posting a copy of the pcidevices.dsl table would suffice in place of the screenshot showing the Hackintool > PCIe tab. As this table contains the correct device path for the SBUS device.

Example of the details provided in the pcidevices.dsl table from my old AMD FX Hack is shown below.

Example of SMBus section from pcidevices.dsl table.

It will also show the correct path to be used in the RX Vega 64 power management SSDT.

 

[IKON]

....

Oh my god, I am so ashamed! SO MANY mistakes crept in while I was tinkering like a mad man trying to figure this out! It's sometimes so frustrating, so you start clicking away and making mistakes (p.s. be sure to scan point 7. really fast )

So nice of you to put so much effort in this! I am very grateful! I bet you've been through some stuff yourself with 5 hackintoshes . To react to your list of points:

1. Oké, I did not know that. I did setup the DSDT with a guide and someone recommended placing it there. It was in an attempt to fix the sleep issue. I doubt the guide now however since I shouldn't even have put the DSDT there. Maybe I should make a new one IF needed.

2. Here you go

3. This is one of those things I totally missed out on in all the hassle of fixing whatever was wrong. Because one of the problems was that the performance of the GPU were meh in 3d applications. I was hoping to fix it with this. Maybe we can set it up later if needed Thanks for your watchful eye seeing everything!

4. The AGPMinjector was added because I thought the power management of the GPU might have been off doing the wake up call on the PCIe slot of the card (I thought of which was on the Matisse Bridge, though at this point I am not even sure anymore). The dAGPM was part of the Vega 64 aml to increase performance (see point 3.). Should I remove them both for now?

5. The double drivers section is a mistake I think where I clicked somewhere. I never noticed and I must have looked past it 45 times. Thank you!

6. The -radcodec was also suggested somewhere on a forum on fixing some issues (see point 3.).

7. You made a new EFI! You are a legend sir, because booting with this thing fixed the sleep issue! This is an awesome step in the right direction, especially with all the mistakes I made along the way! Thanks a million!

8. Oke, that would be nice. The dsl file for the SMBus is attached in the files. I will benchmark the Vega before we start tinkering with it now everything is normal. The VGA error led on my MOBO is off as well now. If the test is bad, I will let you know.

9. The only thing left for me after that (I THINK, but I am a Hackintosh rookie in training at the moment ) is a Memory Modules patch, since I am getting a Memory Modules Misconfigured message every time I boot.