hibernation/sleep not working properly

[Mariok8]

Really? That would make me crazy. Did you try the USBPort.kext that @tedyun created?

if this is kext from the archive "OC 0.7.0 Z390 Gaming X EFI.zip" then I tried the only thing that changed is that bluetooth stopped working and the problem with hibernation still occurred

 

[tedyun]

if this is kext from the archive "OC 0.7.0 Z390 Gaming X EFI.zip" then I tried the only thing that changed is that bluetooth stopped working and the problem with hibernation still occurred

@Mariok8 - my BT is from my Fenvi T919 card, which is plugged into the internal USB 2.0 header. I do have some periodic issues with my BT mouse not connecting upon startup, which is a common occurrence since Monterey. The Fenvi is still working, ie., WiFi and my BT connection to my Apple Watch still work.

I'm away from my Hack right now, but I can take a look at your USBPorts map. I would tend to agree with @Leesureone that you may have to manually remap your ports by installing on an older OS with a temporary drive. It is a hassle -- I've been wanting to remap my ports since getting a new case with front panel USB 3.0, but I never seem to have the time. Although I am the type where if I couldn't get sleep to work, I would do it, since during the week, I prefer to have my Mac go to sleep during the day hours when I'm at work as to not waste power.

 

[Mariok8]

@Mariok8 - my BT is from my Fenvi T919 card, which is plugged into the internal USB 2.0 header. I do have some periodic issues with my BT mouse not connecting upon startup, which is a common occurrence since Monterey. The Fenvi is still working, ie., WiFi and my BT connection to my Apple Watch still work.

I'm away from my Hack right now, but I can take a look at your USBPorts map. I would tend to agree with @Leesureone that you may have to manually remap your ports by installing on an older OS with a temporary drive. It is a hassle -- I've been wanting to remap my ports since getting a new case with front panel USB 3.0, but I never seem to have the time. Although I am the type where if I couldn't get sleep to work, I would do it, since during the week, I prefer to have my Mac go to sleep during the day hours when I'm at work as to not waste power.

I also have fenvi but I have big sur, I do not have much time to reinstall the system, maybe I will do it someday but I doubt that it will help with hibernation

 

[tedyun]

I also have fenvi but I have big sur, I do not have much time to reinstall the system, maybe I will do it someday but I doubt that it will help with hibernation

@Mariok8 - the XDCI reason points to a USB problem and since it doesn't sound like the map is correct, it's likely this is the culprit.

If you have a vanilla install with a proper USB map, no USB devices attached and it sleeps ok, then you can find the offending device by process of elimination. I agree it's a pain to do, but, hey, isn't that why we do Hackintoshing as opposed to getting a genuine Mac ?

 

[Mariok8]

that it would be funnier, because even if I disconnect literally everything, once it goes to sleep properly and once it just turns off, it usually falls asleep properly only after a fresh restart, and not always

 

[tedyun]

that it would be funnier, because even if I disconnect literally everything, once it goes to sleep properly and once it just turns off, it usually falls asleep properly only after a fresh restart, and not always

@MarioK -- If that's happening, then you might be able to isolate the offending device.

Good luck! I've had some mysterious issues that I've had to work through that prevents sleep. It's frustrating. But in each case so far (knock on wood) I've been able to find a background process or device that is running.

 

[tedyun]

that it would be funnier, because even if I disconnect literally everything, once it goes to sleep properly and once it just turns off, it usually falls asleep properly only after a fresh restart, and not always

@Mariok8 -

Try using iMac19,1 -- keep in mind that if you switch it, you should generate a new SN, etc., and you'll also have to re-log into your AppleID etc. When you switch your system definition, it's like installing a new Mac, so you'll have problems if you use your old info.

Is there a reason you're using 17,1? I think for the Z390, people have generally been using iMac19,1 or MacPro1,1 depending on what you need it for.

 

[Mariok8]

@Mariok8 -

Try using iMac19,1 -- keep in mind that if you switch it, you should generate a new SN, etc., and you'll also have to re-log into your AppleID etc. When you switch your system definition, it's like installing a new Mac, so you'll have problems if you use your old info.

Is there a reason you're using 17,1? I think for the Z390, people have generally been using iMac19,1 or MacPro1,1 depending on what you need it for.

I'm using 17.1 because on others I had a problem with the graphics card

 

[tedyun]

I'm using 17.1 because on others I had a problem with the graphics card

I see ... it sounds like you have some decisions to make. I am waiting for the latest OpenCore to be released to update my EFI that I have posted in my build thread. Acidanthera has been delaying it, so maybe this coming Mon. I will update my build description then and recommend that you try my EFI. At one point, I had the iGPU (ie., the onboard HDMI port) working. If you want to try removing your Nvidia and using the iGPU with an iMac19,1 system ID, there is that option.

There is a problem after the rig wakes from sleep in that the display doesn't reconnect. I had to unplug then replug in the cable. I was able to fix it with a bootarg, but subsequent OpenCore releases broke it, so I haven't went back to fix it (I never use the iGPU anyway).

But if the problems stem from the USBPort, the Nvidia GPU and the System ID, then it may require some additional investment of time/money to get full functionality. As you said, if it doesn't bother you to keep the rig from sleeping, then it may be close enough. My previous Hackintosh couldn't sleep either. I do note that eventually, the motherboard died (I think the power supply was failing and fried it) so a part of me wonders if its lifespan was affected by the fact that it was running 24/7.

 

[Edhawk]

I have reviewed your USBPorts.kext/Contents/info.plist and compared this against the USB ports provided by your motherboard.

These are the ports provided by your motherboard.



This gives your system a maximum of 20 USB ports. This can be broken down as follows:

• 2 x physical USB2 ports on the rear I/O plate, using the connector type USB2 (0)
• 2 x USB2 ports from the Internal USB2 motherboard header, using the connector type Internal (255)
• 6 x physical USB3 ports on the rear I/O plate, all using the connector type USB3 (3)
  • 6 x USB3 ports (physical and
  • 6 x USB2 ports (virtual)
• 2 x USB3 ports from the Internal USB3 motherboard header port, all using the connector type USB3 (3)
  • 2 x USB3 ports (physical) and
  • 2 x USB2 ports (virtual)

Below is a screenshot showing the connector type for each USB port commonly found in PC's. Your system doesn't contain any Type-c ports, so you don't need to worry about types (9) and (10).



Your USBPorts.kext/Contents/info.plist looks like this, with as you previously stated only 13 USB ports being activated.

USBPorts.kext/Contents/info.plist, viewed in ProperTree


From the above I see that you have the following set incorrectly.

Ports SS04 and SS05 are both USB3 ports, probably serving the case front ports from the motherboard USB3 header. These are currently set as Internal (255), which is wrong. They should be set as USB3 (3).

All 11 HSxx ports are set as USB3 (3). This is probably correct for some of the ports. But your system does not have that many USB2 virtual ports served from the physical USB3 ports. There should be a maximum of 8 HSxx ports set as USB3, to correspond with the number of physical USB3 ports.

At least 3 of the HSxx ports are incorrectly set with the USB3 connector type. This could be any combination of USB2 physical ports and USB2 Internal header ports. You need to identify which ports are physical USB2 ports, i.e. the two ports on the rear I/O plate and which port(s) are served from the Internal Motherboard header. This Internal Header port could be serving a case front USB2 port, a case front USB2 card reader or an internal Bluetooth module. Only you will know the device being served from the header port and which port(s) are identified in Hackintool when it/they are in use.

If you fix these issues in your USBPorts.kext you are likely to fix the sleep/wake/hibernation issues you are facing. If you don't fix these issues you will continue to encounter these sleep/wake/hibernation issues.

Sorry to say this but I wouldn't recommend using @tedyun USBPorts.kext. As it too is wrong, as can be seen in the screenshot below taken of the info.plist in ProperTree.

USBPorts.kext/Contents/info.plist (tedyun's kext)

In this kext all the HSxx ports are set as USB2 (0), when up to 8 of these ports could be USB2 ports served from a physical USB3 port and should be set with the connector type USB3 (3). The 6 x USB3 physical ports are correctly identified and use the USB3 connector type.

What is also lacking from this kext is the correct identification of the Internal (255) port(s) from the USB2 motherboard header. They/it should not be set with the connector type USB2 (0).