Hervé

With sleepimage file removed from /var/vm and hibernate file pointing to /dev/null ?

Can't see anything wrong with the OC setup. What are your power management settings? Sleep or hibernate? Looking at the KP info you posted, it seems graphics related. I would suggest you remove that forceRenderStandby=0 boot arg in your OC config.

No weird Github bug, no click on the wrong thing. I assume you did not verify that "Release" section, with v1.0 version... The other stuff looks correct indeed but most people will go to the Release stuff you know. The setup posted there is that of your E6530's.

Looks like you got it quite wrong somewhere... Your Aspire TC-780 is a Kaby Lake/HD630 desktop, yet the OC EFI you posted on your repo applies to a... Sandy Bridge/HD4000 laptop (with Haswell MBP11,3 SMBIOS) and it's clearly not for Ventura. I guess you posted your Latitude E6530's Big Sur setup, oops !

No, you do not delete/remove the audio device properties your inject in your OC config. Did you reset NVRAM after applying the ALC fix and adjusting your OC config with the boot args? 2 comments on your OC config by the way: you should avoid injecting your audio layout id in the audio device properties section and as a boot-arg. It's Ok as long as they're both the same but if you start experimenting with different ids, well... you're running Big Sur so you should be disabling SIP with csr-active-config value 0xFEF, not 0xFFF; latter will prevent you from getting OS updates. See our FAQ topic on disabling SIP for details.

Sorry, my mistake, I didn't read your question properly and with all due attention. Afaik, there are only 3 supported hibernation modes: 0, 3 and 25. You can check those out in the built-in manual pages through Terminal command line: man pmset

Don't hesitate to Google for this kind of things, especially as it's nothing specific to macOS or Hackintosh... Sleep -> memory contents is retained as is and computer does not shutdown. Power LED usually fades in and out as an indication. Wake is immediate. Computer still consumes a little power from the battery so it would completely drain out after a several hours/a few days, depending on battery charge level and wear. This is usually the preferred mode of operation for computers that are used on a very regular basis. Hibernation -> memory contents is dumped to disk and computer shuts down. Wake is slower because computer boots and reloads memory contents from disk. Computer consumes no battery during hibernation. This is usually preferred for computers subject to long period of inactivity. For many years, plain old sleep was recommended on Hackintosh computers because hibernation was not properly/fully supported and often caused crashes/KPs.

Could you try and run without this IOElectrify kext to see if it makes any changes? Remember to reset NVRAM on rebooting after you disable this kext in your OC config.

Not a Precision M model -> moving the to adequate section.

OP's setup is not optimised and partly contradictory. For instance: SSDT-UIAC patched table and USBPorts kext -> should only have one or the other SSDT-EC-USBX_Laptop and SSDT-USBX patches tables -> each with different power settings for USB ports SSDT-AC patched table -> really required? There are probably more patched tables than really necessary and a clean-up needed. SSDT-EC-USBX_Laptop table: Scope (\_SB) { Device (USBX) { Name (_ADR, Zero) // _ADR: Address Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If (LEqual (Arg2, Zero)) { Return (Buffer (One) { 0x03 }) } Return (Package (0x04) { "kUSBSleepPortCurrentLimit", 0x0BB8, "kUSBWakePortCurrentLimit", 0x0BB8 }) } [...] } SSDT-USBX table: Scope (\_SB) { Device (USBX) { Name (_ADR, Zero) // _ADR: Address Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If (LEqual (Arg2, Zero)) { Return (Buffer (One) { 0x03 }) } Return (Package (0x08) { "kUSBSleepPowerSupply", 0x13EC, "kUSBSleepPortCurrentLimit", 0x0834, "kUSBWakePowerSupply", 0x13EC, "kUSBWakePortCurrentLimit", 0x0834 }) } } } Disabling sleep functionality in BIOS is a pretty poor workaround to a broken but most useful feature on a laptop...

That and experiment with other desktop KBL framebuffers as provided in the WEG user manual. But, more importably, what kind of video output port are you using? KBL FB 0x59120000 defines 3 DP ports: ID: 59120000, STOLEN: 38 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x0000110B TOTAL STOLEN: 39 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 115 MB, MAX OVERALL: 116 MB (122171392 bytes) Model name: Intel HD Graphics KBL CRB Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz Mobile: 0, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP [3] busId: 0x06, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP 01050900 00040000 87010000 02040A00 00040000 87010000 03060A00 00040000 87010000

I confirm Jake's statement.

Locking this thread due to lazy folks unable to follow/read above statement and comply.

OCLP tool has evolved a lot since then so feel free to experiment with it. My advise is to: 1st install Big Sur with SMBIOS of a supported MacBook Pro (eg: MBP11,4 or MBP11,2). It'll be very slow with poor performance on 1st boot setup. once Big Sur is installed (without graphics acceleration), download latest version of OCLP but don't run it. modify your bootloader's config to change SMBIOS to MBP8,1 and add boot arg -no_compat_check. reboot Big Sur and run OCLP, applying only the SIP settings and the legacy graphics settings. if you use OpenCore, make sure to apply Reset NVRAM at OC Picker when you reboot after you've changed your config file. On reboot, your should be running Big Sur with OpenGL-only (no Metal) graphics acceleration. But, as I said so many times, it won't be bug free and you will experiment those graphics defect everybody does. Ideally, upgrade your RAM to 8GB so that macOS allocates 512MB to VRAM.

No ASF2-ralted power off then, which is re-assuring because these are a nightmare when it comes to root cause. So, other than the ACPI-related cause, nothing other than your own manual forced shutdown, at least for today. Regarding ACPI Power Management shutdown, my guess would be that it's due to excessive heat causing CPU to go into protection mode. Do you have any CPU T° monitoring in place at all like with HWMonitor app? You'll have to post a zipped copy of your OC EFI folder or, at least of that SSDT-5470 patched table of yours, for us to provide further assessment. Using these single SSDTs really is best avoided as, once again, likely to be proven more problematic than beneficial... Do you experience the same behaviour if you disable your (DW1820A) Wifi card in BIOS or physically remove it? I know you apply the required ASPM patch but...

Please don't quote messages to post replies; forum provides a Reply box at the bottom of each page. Your code is Ok but if you renamed your table, make sure you also rename it in your OC config and Reset NVRAM at OC Picker when you reboot. I've tested the stated principle on my own E7270 (with a different SSDT of course) and it works just fine.

RTC-related issue, causing CMOS reset and BIOS settings to return to default. There are bootloaders values you can use in your config to avoid that. It's documented in the OpenCore materials (GitHub repo and probably Dortania). Failing that, you'll find it somewhere on our forum (just can't remember where); from memory it's was something that propped up with Catalina 10.15.4. I probably listed the fix under the Software Matters section so look it up. The issue really depends on the platform you try to run macOS on so please post your system's specs, ideally add them in signature.

You would not have this kind of problem with Clover. However, with OpenCore, one solution to fix this is to apply an "If Darwin" condition to your SSDT so that it only applies to OS X/macOS and will be ignored when you boot any other OS. This may be done as follows: DefinitionBlock (<bla bla bla>) { External <bla bla bla> ... If (_OSI ("Darwin")) /* places SSDT code under condition of running OS X/macOS */ { Device (RMCF) { ... } Scope (_SB.PCI0.RP05.PEGP) { ... } ... ... ... Device (RMD3) { ... } } /* endif */ } In other words, you place all the code past the heading External declarations within this conditional section: If (_OSI ("Darwin")) { ... } and Bob's your uncle!

You should be able to get the brightness keys working by applying the ACPI patches described in the thread dedicated to that matter in our Technical info/R&D section. 'don't understand your issue. Won't work, no support for this type of hardware in macOS.

Check your BIOS logs. Any ASF2 related entries?

Your Maxwell Quadro M1200 (not M12000) appears correctly disabled since it's not visible in IOReg. But first thing first: please post your system's specs in order to confirm whether your Precision is indeed fitted with a Skylake CPU, not a Kaby Lake CPU. Right now, you seem to be confused on the matter. Your IOReg suggests to me you have a Skylake model (iGPU with device id 8086:191b = HD530). Regarding the (apparent) Intel HD 530 iGPU, despite running Big Sur and Monterey (you took your IOReg in Big Sur), not Ventura, you inject Kaby Lake properties (device id 0x5912 and KBL framebuffer 0x591b0000), not Skylake. You also use SMBIOS MBP14,3. If you have a Skylake CPU with HD530 graphics, this is incorrect given that Big Sur and Monterey are expected to run with SKL settings, not Kaby Lake HD6x0 settings (and you do not use WhateverGreen kext v1.6.X with boot arg -igfxsklaskbl). You also: inject boot arg agpdmod=vit9696 which is unlikely to be required inject a whole load of properties which, I think, is irrelevant: I certainly don't inject any if this on my Skylake/HD520 Latitude E7270 and HDMI output works just fine, I just need to inject the boot arg igfxonln=1 to retain built-in LCD when HDMI is connected. Assuming you indeed have a Skylake platform with HD530 graphics, you really should: revert to SKL properties injection (device-id likely not required, SKL framebuffer 0x191b0000 or 0x19160000); see the WEG manual here. remove the properties I've highlighted in red use SMBIOS MBP13,1 if applicable, patch your BIOS to set DVMT to 64MB so that you no longer need to patch fbmem and stolenmem in your config (and gain 4K output along the way). If you were to continue with Kaby Lake settings and retain KBL framebuffer 0x591b0000, please note that you'll have to: update Lilu and its PlugIns (AppleALC and -most importantly- WhateverGreen) to the latest versions and add boot arg -igfxsklaskbl to your config. patch connector con1 for HDMI output or it won't work. Patch is explained here. It's best to opt for KBL framebuffer 0x59160000 which natively supports HDMI output.

As Jake & I said, you need to Reset NVRAM after making changes to your OpenCore config. Only you can do it. Of course you need to have the necessary OpenCore EFI module installed in the Drivers folder. You can configure OpenCore to display this option in the Picker by enabling the module in your config or you can press [SPACE] at the Picker to obtain the option. You'll find tutos on YouTube if you care to search a little. I would also suggest that : you use the latest version of OpenCore you use the latest versions of your add-on kexts you never mix a kext and its PlugIns from a different version (or expect trouble); eg: VirtualSMC & PlugIns... If you want to continue engaging in building your own OpenCore setup, I strongly recommend you start by reading & learning about OpenCore. The Dortania documentation is a good place to start. Otherwise, you'll just continue to struggle to get anywhere... https://dortania.github.io/OpenCore-Install-Guide/ https://dortania.github.io

Did you Reset NVRAM from the OpenCore Picker (the OpenCore menu at startup)? It's essential/mandatory you do that after any OC config change.

You probably have an erroneous OC config file. Possibly a typo somewhere. Get it checked by the validator.

I'm not familiar with several of those patched SSDT tables you use. All I can suggest is that you compare with setups of other similar 5490 or 7490 posted on the forum.