Hibernation Fix about x1c6-hackintosh HOT 78 CLOSED

@savvamitrofanov Nice! Do you have any docs/sources for the claim about the upper memory-bank? It aligns with my experiences, but I wasn't able to find any info when I looked around...

I was able to boot relatively clean after hibernation without CSM. So it should be possible, but my tests are a bit outdated. Afaik CSM is generally discouraged in OpenCore...

Hello! Information is inside your firmware. I reversed DxeCmosInit module (95BF86AD-A1E0-4143-B487-004B1C2E05FA) which performs RTC initialization and various validation checks in upper-bank. It is clearly seen that operations are performed at port addresses 0x72, 0x73, which corresponds to 0x80-0xFF RTC Memory. Also there is routine which validates some values in upper bank, and return EFI_VOLUME_CORRUPTED if it is wrong, that causes to execute code which perform call to LenovoErrorProtocol (my guess) interface to spawn 251 error code with given text.

EFI_STATUS __fastcall ValidateChecksum()
{
  unsigned __int8 v0; // r8
  unsigned __int8 v1; // al
  char v2; // r8
  __int16 v3; // r9
  __int16 v4; // r9
  unsigned __int8 v5; // al
  __int16 v6; // r8
  unsigned __int8 v7; // al
  unsigned __int8 v8; // al
  __int16 v10; // r10
  unsigned __int8 v11; // al
  __int16 v12; // r8
  unsigned __int8 v13; // al

  v0 = 16;
  do
  {
    v1 = sub_A20(v0);
    v0 = v2 + 1;
    v4 = v1 + v3;
  }
  while ( v0 <= 0x2Du );
  __outbyte(0x70u, 0x2Eu);
  v5 = __inbyte(0x71u);
  v6 = v5 << 8;
  __outbyte(0x70u, 0x2Fu);
  v7 = __inbyte(0x71u);
  if ( v4 != v6 + v7 )
    return EFI_VOLUME_CORRUPTED;
  __outbyte(0x70u, 0x79u);
  v8 = __inbyte(0x71u);
  if ( v8 != 90 )
    return EFI_VOLUME_CORRUPTED;
  v10 = sub_A78();
  __outbyte(0x72u, 0x1Fu);
  v11 = __inbyte(0x73u);
  v12 = v11 << 8;
  __outbyte(0x72u, 0x1Eu);
  v13 = __inbyte(0x73u);
  return -(v12 + v13 != v10) & 0x800000000000000Aui64;
}

EFI_STATUS __fastcall WorkWithHigherBank(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
{
  EFI_STATUS Status2; // rax
  EFI_STATUS Status; // rbx
  __int64 v4; // rdx
  EFI_PCD_PROTOCOL *PcdInstance; // rax
  __int64 v6; // rdx
  UINT8 UpperOffset1E; // al
  unsigned __int8 UpperOffset1F; // al
  LENOVO_SHOW_ALERT_PROTOCOL *LenovoThrowErrorProtocolInterface; // [rsp+58h] [rbp+10h]

  LenovoThrowErrorProtocolInterface = SystemTable;
  Status2 = gEfiBootServices->LocateProtocol(&LenovoThrowErrorProtocol, 0i64, &LenovoThrowErrorProtocolInterface);
  if ( (Status2 & 0x8000000000000000ui64) == 0i64 )
  {
    Status = sub_4C8();
    if ( (Status & 0x8000000000000000ui64) != 0i64 )
    {
      WorkWithLowerBank();
      if ( Status == EFI_DEVICE_ERROR )
      {
        (LenovoThrowErrorProtocolInterface->field_8)(
          dword_C20,
          dword_C24,
          dword_C28,
          dword_C2C,
          0i64,
          off_C30,
          off_C38,
          qword_C40);
      }
      else if ( Status == EFI_INVALID_PARAMETER )
      {
        (LenovoThrowErrorProtocolInterface->field_8)(
          dword_C78,
          dword_C7C,
          dword_C80,
          dword_C84,
          0i64,
          off_C88,
          off_C90,
          qword_C98);
      }
    }
    Status2 = ValidateChecksum();
    if ( Status2 == EFI_VOLUME_CORRUPTED )
    {
      DoSomethingWithRTCMem(EFI_VOLUME_CORRUPTED, v4);
      PcdInstance = GetPcdProtocolInterface();
      LOBYTE(v6) = 1;
      (PcdInstance[1].Get16)(0x115i64, v6);
      // Work with 0x1E in upper bank
      // outportb(0x72, 0x1E)
      __outbyte(0x72u, 0x1Eu);
      // Read from 0x1E in upper bank (128-255 range)
      // inportb(0x73)
      UpperOffset1E = __inbyte(0x73u);
      if ( UpperOffset1E || (__outbyte(0x72u, 0x1Fu), (UpperOffset1F = __inbyte(0x73u)) != 0) )
      {
        // Fill 0x1E and 0x1F with 0x00
        __outbyte(0x72u, 0x1Eu);
        __outbyte(0x73u, 0);
        __outbyte(0x72u, 0x1Fu);
        __outbyte(0x73u, 0);
      }
      else
      {
        // Fill 0x1E, 0x1F with 0xFF
        __outbyte(0x72u, 0x1Eu);
        __outbyte(0x73u, 0xFFu);
        __outbyte(0x72u, 0x1Fu);
        __outbyte(0x73u, 0xFFu);
      }
      // Show 251 CMOS Checksum error
      Status2 = (LenovoThrowErrorProtocolInterface->field_8)(
                  dword_CA0,
                  ErrorCode,
                  dword_CA8,
                  dword_CAC,
                  0i64,
                  off_CB0,
                  SystemCmosEror251Msg,
                  qword_CC0);
    }
  }
  return Status2;
}

About CSM. I agree that it's not a right solution, but it gives me the vector to perform research – memory map.
I compared two memory maps with CSM and without CSM (diffcheck), and I found, that with enabled CSM – firmware allocates 1 page with EfiRuntimeCode type at the physical offset 0x8b000. Lack of such regions can cause serious problem, if this memory range used for something in runtime. So I created simple DXE driver which allocates this page, like CSM and viola. I got working hibernation.
Next step, improve ReservedMemory option in OpenCore to do such allocations out-of-box ;)
You could try OC from this branch acidanthera/OpenCorePkg@76bf9bd
Example ReservedMemory dict with hibernation fix added into Sample.plist

from x1c6-hackintosh.

The above driver helped with my X1 Extreme's black screen, though it reboots shortly after displaying the lock screen so I have some further debugging to do I think. Thanks!

Edit: Needed to enable DiscardHibernateMap and now it's working

from x1c6-hackintosh.

Follow up on my previous testing - so I was having an issue where if I rebooted before attempting to go into hibernate then waking up, I would see the login screen before it abruptly reset due to some error. Turns out it was possibly RebuildAppleMemoryMap causing issues. Disabling that + DiscardHibernateMap, and then enabling EnableWriteUnprotector fixed this.

from x1c6-hackintosh.

@benbender
a) My RTC definition seems identical to yours:

  Device (RTC)
        {
            Name (_HID, EisaId ("PNP0B00") /* AT Real-Time Clock */)  // _HID: Hardware ID
            Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
            {
                IO (Decode16,
                    0x0070,             // Range Minimum
                    0x0070,             // Range Maximum
                    0x01,               // Alignment
                    0x08,               // Length
                    )
                IRQNoFlags ()
                    {8}
            })
        }

b) How would we confirm that?
c) Regarding IRQ, this is standard assignments:

IRQ 0 | System Timer (CMOS)
IRQ 1 | Keyboard
IRQ 2 | Cascaded with IRQ 9
IRQ 3 | Default COM2 and COM4
IRQ 4 | Default COM1 and COM3
IRQ 5 | LPT2
IRQ 6 | Floppy Drive Controller
IRQ 7 | LPT1
IRQ 8 | Real Time Clock
IRQ 9 | SEE 2
IRQ 10 | Open
IRQ 11 | Open
IRQ 12 | PS/2 mouse or Open
IRQ 13 | Math Coprocessor
IRQ 14 | Primary Hard Drive controller
IRQ 15 | Secondary Hard Drive controller

If someone still has Windows, could confirm this in Device Manager? Lenovo may have custom IRQ assignments.

TIMR should be one that's related to sound, that patch is not needed as far as I know and is really for legacy hardware.

RTC likely our culprit for our hibernation error. Just as we previous suspected, it is likely some conflicts with AppleRTC our own, and bad RTC regions will need to be excluded.
Again, this is standard CMOS map, I don't know if Lenovo does it differently or how we would even confirm it.
http://www.bioscentral.com/misc/cmosmap.htm

EDIT: I'm going to try the suggested default exclusions in RTCMemoryFixup README and see if that changes anything.

from x1c6-hackintosh.

BTW, if it's not clear: Testing should be done with a debug-build of opencore and target=67/0x43 so it writes log-files for early boot in boot.efi. rtc-blacklist will most likely be handled in boot.efi.

And I would suggest to remove every other hack (ACPI, RtcMemoryFixup, boot-args, etc) around RTC-handling for testing and only try rtc-blacklist and DisableRTCChecksum.

from x1c6-hackintosh.

Your checksum is different because you have different data :)

58/59 - I would assume that you can count 0-indexed in row 50 from between 0 to F. so 58 (8th col, starting from 0, row 50) is 00 for you and 59 is FE. Matches.

from x1c6-hackintosh.

Interestingly, in OC boot log:
Translated HibernateMode Auto to 3
That is with hibernatemode set to 25. I will try RTC and NVRAM in HibernateMode within config.plist to see if OC detects 25 as the hibernation mode.

from x1c6-hackintosh.

/**
  Hibernate detection bit mask for hibernate source usage.
**/
#define HIBERNATE_MODE_NONE   0U
#define HIBERNATE_MODE_RTC    1U
#define HIBERNATE_MODE_NVRAM  2U

  if (AsciiStrCmp (HibernateMode, "None") == 0) {
    HibernateMask = HIBERNATE_MODE_NONE;
  } else if (AsciiStrCmp (HibernateMode, "Auto") == 0) {
    HibernateMask = HIBERNATE_MODE_RTC | HIBERNATE_MODE_NVRAM;
  } else if (AsciiStrCmp (HibernateMode, "RTC") == 0) {
    HibernateMask = HIBERNATE_MODE_RTC;
  } else if (AsciiStrCmp (HibernateMode, "NVRAM") == 0) {
    HibernateMask = HIBERNATE_MODE_NVRAM;
  } else {
    DEBUG ((DEBUG_INFO, "OC: Invalid HibernateMode: %a\n", HibernateMode));
    HibernateMask = HIBERNATE_MODE_NONE;
  }

  DEBUG ((DEBUG_INFO, "OC: Translated HibernateMode %a to %u\n", HibernateMode, HibernateMask));

  HibernateStatus = OcActivateHibernateWake (HibernateMask);
  DEBUG ((DEBUG_INFO, "OC: Hibernation detection status is %r\n", HibernateStatus));

This "hibernatemode" is an internal variable of OC and not the apple hibernatemode. I would use NVRAM (cause we are trying to avoid RTC).

from x1c6-hackintosh.

Correction: By blocking the upper 128byte of CMOS I was able to hibernate and come back - but with a bios-cmos-error.

Logs:

2020-07-02 19:13:13.723063+0200 0x73       Default     0x0                  0      0    kernel: (Lilu) HibernationFixup      init: @ (DBG) HibernationFixup bootstrap DBG-133-2020-05-04
2020-07-02 19:15:25.000926+0200 0x2b5      Default     0x0                  166    7    bluetoothd: (IOBluetooth) [com.apple.bluetooth:CBXPCManager] kIOMessageSystemWillPowerOn; didWakeFromHibernation = 0
2020-07-02 19:15:25.001143+0200 0x2b5      Default     0x0                  166    7    bluetoothd: (IOBluetooth) [com.apple.bluetooth:CBXPCManager] systemPowerNotification: kIOMessageSystemHasPoweredOn - didWakeFromHibernation = 0 wakefromBT = 0 gControllerTransportType = USB
2020-07-02 19:16:33.297327+0200 0x3669     Default     0x0                  0      0    kernel: PMRD: phase 0, standby 1 delay 10800 timer 0, poweroff 0 delay 0 timer 0, hibernate 0x19
2020-07-02 19:16:33.325066+0200 0x74       Default     0x0                  0      0    kernel: PMRD: phase 1, standby 1 delay 10800 timer 86400, poweroff 0 delay 0 timer 0, hibernate 0x19
2020-07-02 19:16:33.457084+0200 0x5c4      Default     0x0                  0      0    kernel: PMRD: hibernateMode 0x19
2020-07-02 19:16:33.457086+0200 0x5c4      Default     0x0                  0      0    kernel: hibernate image path: /var/vm/sleepimage
2020-07-02 19:16:33.457088+0200 0x5c4      Default     0x0                  0      0    kernel: hibernate image path: /var/vm/sleepimage
2020-07-02 19:16:33.457419+0200 0x5c4      Default     0x0                  0      0    kernel: hibernate_page_list_setall(preflight 1) start
2020-07-02 19:16:33.457422+0200 0x5c4      Default     0x0                  0      0    kernel: hibernate_page_list_setall(preflight 1) start
2020-07-02 19:16:36.479643+0200 0x5c4      Default     0x0                  0      0    kernel: hibernate_flush_memory: buffer_cache_gc freed up 45433 wired pages
2020-07-02 19:16:36.479647+0200 0x5c4      Default     0x0                  0      0    kernel: hibernate_flush_memory: buffer_cache_gc freed up 45433 wired pages
2020-07-02 19:16:36.479648+0200 0x5c4      Default     0x0                  0      0    kernel: hibernate_flush_memory() considered(1600542) reentered_on_q(940931) found_dirty(659611)
2020-07-02 19:16:36.479654+0200 0x5c4      Default     0x0                  0      0    kernel: hibernate_alloc_pages act 335733, inact 448269, anon 298581, throt 0, spec 325817, wire 465558, wireinit 95517
2020-07-02 19:16:36.479658+0200 0x5c4      Default     0x0                  0      0    kernel: hibernate_alloc_pages act 335733, inact 448269, anon 298581, throt 0, spec 325817, wire 465558, wireinit 95517
2020-07-02 19:16:36.479722+0200 0x5c4      Default     0x0                  0      0    kernel: (Lilu) HibernationFixup      HBFX: @ (DBG) IOHibernateSystemSleep is called, result is: 0
2020-07-02 19:16:36.479727+0200 0x5c4      Default     0x0                  0      0    kernel: (Lilu) HibernationFixup     iokit: @ (DBG) getOSData IOHibernateState has 1 value
2020-07-02 19:16:36.479730+0200 0x5c4      Default     0x0                  0      0    kernel: (Lilu) HibernationFixup      HBFX: @ (DBG) Current hibernate state from IOPMRootDomain is: 1
2020-07-02 19:16:37.103342+0200 0x74       Default     0x0                  0      0    kernel: PMRD: phase 2, standby 1 delay 10800 timer 86400, poweroff 0 delay 0 timer 0, hibernate 0x19
2020-07-02 19:16:37.859896+0200 0x74       Default     0x0                  0      0    kernel: hibernate_page_list_setall(preflight 0) start
2020-07-02 19:16:37.859897+0200 0x74       Default     0x0                  0      0    kernel: hibernate_teardown started
2020-07-02 19:16:37.859899+0200 0x74       Default     0x0                  0      0    kernel: hibernate_teardown: wired_pages 465552, free_pages 7754761, active_pages 40011, inactive_pages 95938, speculative_pages 0, cleaned_pages 0, compressor_pages 84
2020-07-02 19:16:37.859900+0200 0x74       Default     0x0                  0      0    kernel: hibernate_teardown_pmap_structs done: last_valid_compact_indx 174602
2020-07-02 19:16:37.859901+0200 0x74       Default     0x0                  0      0    kernel: hibernate_teardown: mark_as_unneeded_pages 8192, 104842, 69338
2020-07-02 19:16:37.859902+0200 0x74       Default     0x0                  0      0    kernel: hibernate_teardown completed - discarded 182372
2020-07-02 19:16:37.859903+0200 0x74       Default     0x0                  0      0    kernel: hibernate_page_list_setall time: 808 ms
2020-07-02 19:16:37.859906+0200 0x74       Default     0x0                  0      0    kernel: WARNING: hibernate_page_list_setall skipped 43008 xpmapped pages
2020-07-02 19:16:37.859907+0200 0x74       Default     0x0                  0      0    kernel: hibernate_page_list_setall found pageCount 354208
2020-07-02 19:16:37.859908+0200 0x74       Default     0x0                  0      0    kernel: IOHibernatePollerOpen, ml_get_interrupts_enabled 0
2020-07-02 19:16:37.859909+0200 0x74       Default     0x0                  0      0    kernel: IOHibernatePollerOpen(0)
2020-07-02 19:16:37.859912+0200 0x74       Default     0x0                  0      0    kernel: hibernate_rebuild started
2020-07-02 19:16:37.859913+0200 0x74       Default     0x0                  0      0    kernel: hibernate_rebuild_pmap_structs done: last_valid_compact_indx 174602
2020-07-02 19:16:37.859914+0200 0x74       Default     0x0                  0      0    kernel: hibernate_rebuild completed - took 307 msecs
2020-07-02 19:16:37.859917+0200 0x74       Default     0x0                  0      0    kernel: hibernate_machine_init: state 2, image pages 200836, sum was b50728f6, imageSize 0x1b0e8000, image1Size 0xe829000, conflictCount 0, nextFree 3
2020-07-02 19:16:37.859919+0200 0x74       Default     0x0                  0      0    kernel: hibernate_newruntime_map time: 2 ms, IOPolledFilePollersOpen(), ml_get_interrupts_enabled 0
2020-07-02 19:16:37.859923+0200 0x74       Default     0x0                  0      0    kernel: hibernate_machine_init reading
2020-07-02 19:16:37.859924+0200 0x74       Default     0x0                  0      0    kernel: PMStats: Hibernate read took 419 ms
2020-07-02 19:16:37.859925+0200 0x74       Default     0x0                  0      0    kernel: hibernate_machine_init pagesDone 336869 sum2 cdfbfee2, time: 419 ms, disk(0x20000) 498 Mb/s, comp bytes: 434974720 time: 243 ms 1703 Mb/s, crypt bytes: 210497536 time: 79 ms 2513 Mb/s
2020-07-02 19:16:37.861873+0200 0x74       Default     0x0                  0      0    kernel: (Lilu) HibernationFixup      HBFX: @ (DBG) restoreMachineState returned 0x0 for device AppleACPIPCI, options = 0x1
2020-07-02 19:16:37.862149+0200 0x74       Default     0x0                  0      0    kernel: (Lilu) HibernationFixup      HBFX: @ (DBG) restoreMachineState returned 0x0 for device AppleACPIPCI, options = 0x2
2020-07-02 19:17:14.157888+0200 0x2b5      Default     0x0                  166    7    bluetoothd: (IOBluetooth) [com.apple.bluetooth:CBXPCManager] kIOMessageSystemWillPowerOn; didWakeFromHibernation = 1
2020-07-02 19:17:15.453153+0200 0x2b5      Default     0x0                  166    7    bluetoothd: (IOBluetooth) [com.apple.bluetooth:CBXPCManager] systemPowerNotification: kIOMessageSystemHasPoweredOn - didWakeFromHibernation = 1 wakefromBT = 0 gControllerTransportType = USB

from x1c6-hackintosh.

Did 2 more tests:

a) without rtc-blacklist and without DisableRtcChecksum
b) without DisableRtcChecksum

Same result. Could hibernate and come back, but had a Bios-CMOS-Checksum-Error while waking up.

I'll end my journey to hibernation here, but it's most likely possible with the tools on our hands and fiddling out the right 2 bytes to block. If someone wants to catch up, I would suggest to test byte by byte with the rtcwrite-efi-tool.

from x1c6-hackintosh.

Just as a hint, I think the missing bytes to block are 0x38-0x3F:

[*] RC = 0x8000001C << RTC Configuration (msgbus port 0xC3, off 0x3400)
[02] UE = 1 << Upper 128 Byte Enable
[03] LL = 1 << Lower 128 Byte Lock
[04] UL = 1 << Upper 128 Byte Lock
[31] BILD = 1 << BIOS Interface Lock-Down
[+] Protected bytes (0x38-0x3F) in low 128-byte bank of RTC memory are locked
[+] Protected bytes (0x38-0x3F) in high 128-byte bank of RTC memory are locked

(Output from chipsec on a t480, probably same on x1c6)

from x1c6-hackintosh.

Just for test you can load this from OpenCore drivers and check if black screen is gone
LenovoAllocateRTCodePage.efi.zip
UPD: Do not use test driver in production, use ReservedMemory option with latest OpenCore bootloader build

from x1c6-hackintosh.

This is great news. Thank you @savvamitrofanov !
I'm away atm but as soon as I return I'll test it myself and push it to the repo.

from x1c6-hackintosh.

Small update:

• Hibernate mode 3 seems to function, though extended testing is needed.
  It seems that hibernate mode 25 will trigger CMOS error upon entering sleep. Though I am not sure if this is due to my own CMOS battery. An additional tester is needed, please lmk.

from x1c6-hackintosh.

S3 sleep is working well for me (hibernate = 3).
Achieved kernel panic after macOS tried to change from sleep to hibernate once, attached.
Now changed standby to 0 so hibernate is disabled, no more panics yet.
panic-hibernate-1.txt

from x1c6-hackintosh.

@Ranguvar Could you try setting hibernate mode to 25 and see what happens on your machine?

from x1c6-hackintosh.

Hi @tylernguyen I've been using your guide for 1 day, just finished on my X1C and noticed that the computer didn't sleep on LID closed or Apple --> Sleep as well. Because when I open the lid, it almost screened up instantly and the plate is warm, I also lost 25% in 1hr of sleep and LED light won't blink but constantly on. That was during the hibernation = 0.
Now I just changed to 3 hope it would make a difference :(

from x1c6-hackintosh.

@duylenfq

Please run pmset -g log | grep -e "Wake.*due to " to see what's preventing your laptop from sleeping.

Also, please read and check against this guide

from x1c6-hackintosh.

I did check the guide, so far this is what it returned

Just to clarify I remapped USB correctly under Hackintool and during sleep nothing attached via USB externally...

from x1c6-hackintosh.

@Ranguvar Could you try setting hibernate mode to 25 and see what happens on your machine?

Leave standby 0 or 1?

from x1c6-hackintosh.

With hibernatremode on 25 and standby on 1, I left my laptop alone.
When I came back to it, I do not recall if it was off or if the LED was pulsing, but it booted to the BIOS splash screen.

I had an error display, 0251: System CMOS Checksum bad - Default configuration used.

macOS did then fail to boot once, but I don't have the log. It is working again now.

from x1c6-hackintosh.

With hibernatemode on 25 and standby on 0, it seems I got the normal sleep I did with hibernate mode on 3?

from x1c6-hackintosh.

I did check the guide, so far this is what it returned

Just to clarify I remapped USB correctly under Hackintool and during sleep nothing attached via USB externally...

@duylenfq You need to turn Power Nap off. I'll update this in the 5_README-other so others can see.

With hibernatemode on 25 and standby on 0, it seems I got the normal sleep I did with hibernate mode on 3?

@Ranguvar Can you do an extended test and confirm power drainage with hibernatenmode=25?

from x1c6-hackintosh.

hi @tylernguyen I didn't have Power nap enabled, it was disabled from day 1

I will also try hibernatemode=25 and see if it works on my machine

Since I am using intel wifi, I disable USB map for bluetooth as well, hope this will returns good result.

In the meanwhile, the LED light is not still blinking, constantly on no matter what....

from x1c6-hackintosh.

@duylenfq

Make sure you don't have powernap enabled for the power adapter either. Also, how are you using intel wifi? which kext are you using? What's your machine model?

In addition, what's your bios settings? Is wake-on-lan disabled?

Are there any USB devices connected during sleep?

Please check pmset -g assertions and clear power assertions to default.

Btw, Hackintool is not good for mapping USB ports, it uses an outdated version of USBMap. It's better for you just to use USBMap directly instead.

from x1c6-hackintosh.

@tylernguyen my model is exactly as yours with identical specs, except my wifi card is not replaced yet (waiting for DW1560 to be shipped. Some details below:
info.txt
Bios is also exactly as your guide, I disabled wake on LAN and dock to be sure, WWAN also disabled along with SD card reader. When I tested the sleep, just click on Sleep and leave the laptop alone, nothing connected to it.
I remapped USB accordingly to USBMap as well, nothing changed yet....

I did a double check AHCI mapping and I have the same rooting as yours, SB.PCI0.LPCB.EC
Edit1: My wifi kext is from here: https://www.tonymacx86.com/threads/success-working-intel-wifi-drivers-for-7265ac-on-catalina.292207/page-14 https://www.tonymacx86.com/attachments/appleintelwifi-kext-catalina-zip.450679/
Edit2: try removing AHCI patching and left only the basic (kexts unchanged) didn't seem to help with sleep.... Kinda make a compromise to live with it as of now ...
Edit 3: found this, checking why....

from x1c6-hackintosh.

I just had the machine stay sleeping and it required a reboot when trying to resume, using standby 0 and hibernatemode 25.

I did also have Power Nap on, as I was plugged into an AC adapter this time, though.

Not sure how to run an extended test other than recording battery percentages before/after sleep of say 1hr?

So far hibernatemode 25 is either as good as or better than 3 with standby 0 and Power Nap off, I can't be sure yet.

from x1c6-hackintosh.

@duylenfq from the first output, HID activity is usually an issue from USB mapping, what power injection did you use?

Please clear NVRAM and check if it works. Also, please upload a zip of your EFI with SMBIOS info removed. I will inspect your EFI and try to guess what's wrong. But so, I would recommend you do a fresh install and test sleep before installing any 3rd-party apps or tools.

Sleep was never an issue with this project, I suspect it maybe caused by the Intel WiFi kext, since it is really the only thing different from our two machines (I recommend against intel wifi currently anyway because it's very buggy and incomplete.)

@Ranguvar
Power nap causes problems. I recommend you disable it on both power and battery.
And yes, there's really no other tests than just charging it to 100%, setting hibernatemode to 3 or 25, let it drain for hours, then comparing the two results.

Be sure to record your pmset -g settings as you set them.

For now, I suggest you keep standby constant and only change hibernatemode when testing.
Also, how did you avoid CMOS error with hibernatemode 25, I keep running into it whenever I tried.

from x1c6-hackintosh.

hi @tylernguyen I have some updates:

• Fresh installed x2 with wifi card replaced by DW 1560, not really helped for sleep problem. I also tried disabling all USB port see if it works and I have the HID issue:

• I also checked my USB setup (I mapped 5 times just to make sure I didn't miss anything) and status = good, however sleep problem not fixed

--> The sleep problem is not as annoying as [HDMI port not working at all + dark screen on mistaken combo key to screenshot] This drives me crazy when I need to work and present a screen. Spent more than 1 week on this now :( if you could help I would gladly donate for your great work thus far.
Thank you in advance.

from x1c6-hackintosh.

@duylenfq
I've just taken a look at your EFI. Some comments:

• SSDT-UIAC is meant to be used with USBInjectAll

• USBMap does the same thing as SSDT-UIAC and USBInjectAll
  These two setups are mutually exclusive, either SSDT-UIAC and USBInjectAll or USBMap, not both.

• Similarly, SSDT-PNLF and SSDT-PNLF-SKL_KBL do the same thing, use one only.

• SSDT-EXT* are all extensions of SSDT-PTSWAK, so SSDT-PTSWAK needs to be loaded first in OpenCore config.plist

Please read my ACPI doc: https://github.com/tylernguyen/x1c6-hackintosh/blob/master/docs/4_README-ACPIpatching.md

Specifically, please pay attention to the SSDT-PTSWAK section and confirm your own _WAK and _PTS properties in source DSDT. Yours may be different from mine.

• Is there a specific reason for you to use SMBIOS 14,3? 14,1 is a better SMBIOS for compatibility and it's the SMBIOS that my project is designed around. I suggest you switch to 14,1

• You are injecting AppleALC layout-id twice, one in devices and another time in boot arguments. Please inject only in 1 place.

• I see that you you have VoodooI2C installed, do you have a touchscreen?

• SSDT-GPI0 is also installed, this patch is meant for I2C touchpad. As far as I know, x1c6 do not have touchpads unless installed aftermarket?

• Similarly, x1c6 do not have an ambient light sensor so you can remove SMCLightSensor

• WhateverGreen is loaded too late in config.plist. Load it earlier, but after Lilu.

• Again, you are loading VoodooInput twice, one with VoodooI2C, and another time with VoodooPS2, please only use one.

• You are using BuiltIn BootPicker, so there's no need for OpenCanopy.efi and the Resources folder.

• If you do not have a touchscreen or a known I2C device, please remove the package entirely, I suspect that this might be causing your sleep problems.

But overall, please take a look at all my comments and clean your setup. It seems very messy.

It seems like this config.plist was made from scratch, is there a reason for you to do so? I think a better approach would be starting off with my Opencore-EFI. After that, you can add the things you need, be it touchscreen, WiFi

from x1c6-hackintosh.

Thanks @tylernguyen for the response and check. Due to the instability of the OS so far, mostly with sleep and HDMI totally unusable I set it aside (for now) and back to Windows to be able to work and collaborate with my colleagues. I did a check as you said + another attempt on using your exact folders (except changed platform info, CPU friend, and USBinjectall). So far it only costs time and effort, although I could use the machine just with the internal display, without HDMI it's a deal-breaker for me though.....

I think as of now just for my case, the OS is far less stable compared to my hack desktop, I will stick to it for awhile....

from x1c6-hackintosh.

@tylernguyen I've briefly tried to make hibernatemode 25 work and it did - but resulted in the same CMOS-error you observed. I did it out of curiosity while beeing happy with mode 3.

I think the problem we are facing is takled by the following kext, butI didn't try to debug my RTC-Banks to make it work. If you are interested: https://github.com/acidanthera/RTCMemoryFixup

from x1c6-hackintosh.

Just stumbled upon this issue which may be related: acidanthera/bugtracker#765

from x1c6-hackintosh.

@benbender Thanks for bringing this to my attention. I will look into that issue and continue testing hibernate mode 25.

from x1c6-hackintosh.

@benbender With the fixes on that issue applied, I'm still getting CMOS error. Could you confirm that behavior? It seems that we would need to create our own exclusions after all.

from x1c6-hackintosh.

I didn't investigate yet, but plan to do so because there seems to be more functionality depending on working RTC/CMOS. The important information for me are a) there are changes from 10.15.4 onwards and b) there are new options in OC 0.5.9 to handle it. Rest is object to fiddling around.

Important first question is size and correctness of our RTC-ACPI-definition.

To get started, some questions to clearify:

a) my RTC-Definition (stock ACPI, latest Bios) - same for you?

        Device (RTC)
        {
            Name (_HID, EisaId ("PNP0B00") /* AT Real-Time Clock */)  // _HID: Hardware ID
            Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
            {
                IO (Decode16,
                    0x0070,             // Range Minimum
                    0x0070,             // Range Maximum
                    0x01,               // Alignment
                    0x08,               // Length
                    )
                IRQNoFlags ()
                    {8}
            })
        }

b) I had messages in the past that I have only 128bytes of RTC-Memory. We need to confirm if this is correct?

c) I didn't find any informations about this IRQ-TIMR-RTC-patches and if they are needed or not (besides "something" with the audio-devices). Do you have any informations about the purpose of that patch and if its needed on x1c6/t480/t480s?

from x1c6-hackintosh.

Regarding

a) Fine :)

b)

❯ sudo ./rtcread
Password:
00: 20 59 54 56 09 10 03 01 07 20 26 02 50 81 00 00
10: 00 00 00 00 0E 80 02 00 3C 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CC
30: 00 3C 20 00 00 FF 03 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 C2 01 00 07 00 00 00 00 46 00 00 80
50: 01 00 00 00 FF FF FF FF 00 7D 00 00 00 00 00 00
60: 01 00 00 00 02 00 03 04 00 00 00 01 00 FF 01 00
70: 00 00 30 00 00 00 00 00 00 5A 00 00 49 53 B2 00
80: 44 45 41 44 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 15 00 00 00 00 00 00 00 00 00 00 00 00 00
A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
B0: 87 5A 40 E1 00 00 00 00 00 00 00 00 00 00 00 00
C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00
D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
E0: 00 44 00 00 00 00 00 00 00 00 00 00 00 00 00 00
F0: 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00
Checksum is 04 81 vs 00 7D from rtc (0)

That one shows entries for 00-FF, so we would have full 256bytes and no need to fix here.

For c) So I wouldn't try to patch until necessity is clear. Btw, where did you get the IRQ-Listing from?

Regarding testing with RTCMemoryFixup I'm not sure if that's the way to go for 10.15.4+. My impression atm is that RTC is working correct for us and AppleRTC is simple overwriting the checksum fields.

I would try to approach like this, but don't have time because of work: acidanthera/bugtracker#765 (comment)

0x5859 might be actually the wrong values for us.

from x1c6-hackintosh.

Source for IRQ assignments: https://www.helpwithpcs.com/upgrading/change-irq-settings.htm

0x5859 is probably the wrong values for us.

The problem is that CMOS reset doesn't happen on boot, it happens on wake of hibernation. But it doesn't really create a KP panic so what logs am I even supposed to look at to see the problem?

Also, this is likely the best description of our issue:
acidanthera/bugtracker#765 (comment)

EDIT: For reference, this is AppleRTC table: https://github.com/acidanthera/VirtualSMC/blob/master/Tools/rtcread/rtcread.c#L45
I wonder if we need to rename our RTC device and just create a fake one?

from x1c6-hackintosh.

//
// There currently are 2 places main RTC checksum is calculated in AppleRTC.kext
// __ZN8AppleRTC14updateChecksumEv and __ZN8AppleRTC19rtcRecordTracePointEjjj.
// Since we do not want to completely break RTC and/or saving tracepoints to RTC
// we patch-out __ZN8AppleRTC8rtcWriteEjh call arguments (0x58 and 0x59) with
// invalid (out of range) value 0xFFFF in 4 places.
//

From OC-Source. So DisableRTCChecksum disables the check of 0x58 0x59 in AppleRTC and rtc-blacklist blocks writing to it.

From my rtcdump:

50: 01 00 00 00 FF FF FF FF 00 7D 00 00 00 00 00 00

And:

Checksum is 04 81 vs 00 7D from rtc (0)

00 7D would be 58/59.

I think this handles checksums on apple's software-side, but we have an additional problem in case of mode 25 hibernation where the encryption-keys for the memory-images are written to the rtc and, because of that, the rtc-checksum is b0rked at bios-level which eventually results in the bios-error at the reboot after hibernation. So we need to fix both.

From HibernationFixup-Changelog:

v1.2.1
Save hibernation keys in NVRAM only if boot-arg -hbfx-dump-nvram is specified or if the second bank of RTC memory (next block of 128 bytes) is not available

I would assume that holding the hibernation-keys in nvram should fix the issue. So my suggestion:

• rtc-blacklist 0x58/0x59
• disableRTCChecksum
• HibernationFixup Debug-build
• hbfx-dump-nvram + hbfxdbg-bootargs
• Testing & hoping - and log-checking ;)

from x1c6-hackintosh.

@benbender My checksum is different than yours:

00: 41 53 59 23 10 02 03 01 07 20 26 02 40 80 00 00
10: 00 00 00 00 0E 80 02 00 3C 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CC
30: 01 FE 20 00 00 FF 03 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 C2 01 00 07 00 00 00 00 46 00 00 80
50: 01 00 00 00 FF FD FF FF 00 FE 00 00 00 00 00 00
60: 01 00 00 00 02 00 03 00 00 00 00 01 00 FF 01 00
70: 00 00 30 00 00 00 00 00 00 5A 00 00 49 53 B2 00
80: 44 45 41 44 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00
D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
E0: 00 44 00 00 00 00 00 00 00 00 00 00 00 00 00 00
F0: 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00
Checksum is 0C CE vs 00 FE from rtc (0)

Also, how did you get that 00 7D would be 58/59?

from x1c6-hackintosh.

Hm.. still seeing CMOS error.

nvram.plist.zip

from x1c6-hackintosh.

Some ideas:

• You don't get the CMOS-Error on a normal reboot, right?

• Does the Bootlog (on the efi-partition) give any clues? (normal- and hibernate-reboot)

• Dump the RTC before going on hibernate and afterwards and have a look on the differences.

If nothing helps, one has to go the route from the bug and test byte by byte which vars in CMOS are triggering the error.

from x1c6-hackintosh.

@benbender

Nope, only on hibernation mode 25 wake.
No, as far as I can tell, OpenCore only logs the boot process, which looks normal. On hibernate wake, OC doesn't seem to be logging anything.

from x1c6-hackintosh.

How does the system behave after the CMOS-Error? Does it boot normally? In the nvram.plist there are entries about hibernation - are there entries in the syslog about it? What does pmset -g log tell you?

Next step for me, after some information gathering described above, would be to try to use RtcMemoryFixup to block the upper memory bank (rtcfx_exclude=80-FF) and see how the system behaves.

from x1c6-hackintosh.

@benbender CMOS resets just lead a page either continue boot or enter BIOS. If the former is selected, it leads to macOS screen with bars underneath and becomes unresponsive. It looks like this:

Which is interesting because that seems to indicate that macOS thinks it's safe sleep, or some sort of panic sleep mode, rather than hibernate 25.

And as far as I can tell, pmset -g log doesn't show anything useful:
pmset-logs.txt

from x1c6-hackintosh.

could you upload the boot-log of an OC-Debug-Build for waking up from hibernation? Without a clue what OC/OSX-Kernel are trying to do there, we are stuck.

from x1c6-hackintosh.

could you upload the boot-log of an OC-Debug-Build for waking up from hibernation? Without a clue what OC/OSX-Kernel are trying to do there, we are stuck.

That's problem from before. OC-Debug doesn't seem to be writing on hibernation wake, only on boot up.

from x1c6-hackintosh.

Anything in syslog? And just to be sure: sleepimage is untouched in your setup? could you, just to check, post pmset -g?

...

But to be honest, it doesn't seem to be worth the effort if we couldn't get some serious clou about the problem. There seems to be a mixture of problems between bios/rtc/nvram and possibly os x-bugs (there are many reports about problems with mode 25 in catalina) - and it's not a usecase used very often anymore.

I would suggest to enable sleepmode 3, which is default on macs anyway. And if battery drain bothers you, you have to disable tcpkeepalive, powernap etc and the system will loose nearly zero power over time.

from x1c6-hackintosh.

Sleepimage is untouched. And sure:

➜  ~ pmset -g                      
System-wide power settings:
Currently in use:
 standbydelaylow      300
 standby              0
 halfdim              1
 hibernatefile        /var/vm/sleepimage
 proximitywake        0
 powernap             0
 gpuswitch            2
 disksleep            10
 standbydelayhigh     300
 sleep                1
 autopoweroffdelay    300
 hibernatemode        25
 autopoweroff         1
 ttyskeepawake        1
 displaysleep         2
 tcpkeepalive         0
 highstandbythreshold 50
 lidwake              1

Mode 3 is the default mode I have been for a while now, all those adjustments made. And I still feel as though it doesn't last me long enough on a single charge compared to Linux or Windows. I can usually squeeze in extra 1-2 of mixed sleep/usage on those other platforms.
You may be right though, this issue might just be way above our heads and involve too many things. I guess it's time for me to replace the battery my on laptop anyway.

@benbender
When you get the chance, can you try replicate the steps and test above on your machine. If you get the same results and experience as me, I will close this issue and flag it as out of scope and waiting for outside development

from x1c6-hackintosh.

Yes, I will and report back.
You didn't fiddle with the sleepimage, right?

For sleepmode 3: if you have a significant power draw in mode 3, something doesn't power down properly. TB? (which I don't use)

For battery-live: f.e. you power-up TB by your docs, which will cost you about 2W constantly. Without patching the firmware, there is no real way to have proper PM on TB on Hackintosh afaik. And I think we have similar problems with the GPU and Cardreader f.e. So yes, there is a drawback in power-usage.

from x1c6-hackintosh.

Yes, I will and report back.
You didn't fiddle with the sleepimage, right?

For sleepmode 3: if you have a significant power draw in mode 3, something doesn't power down properly. TB? (which I don't use)

For battery-live: f.e. you power-up TB by your docs, which will cost you about 2W constantly. Without patching the firmware, there is no real way to have proper PM on TB on Hackintosh afaik. And I think we have similar problems with the GPU and Cardreader f.e. So yes, there is a drawback in power-usage.

Nope, sleepimage is vanilla.

Good point, I'm an active TB3 user, which is probably the culprit. I will update the docs in this repo to recommend turning it off if not being used.

It is likely that this issue will need to be re-investigated once there's a stable Big Sur release.

from x1c6-hackintosh.

Just to don't double the effort: Did you try to block the upper 128byte of the CMOS-bank?

from x1c6-hackintosh.

Config:
config Kopie.plist.zip

pmset -g log:

2020-07-02 19:17:15 +0200 HibernateStats      	hibmode=25 standbydelaylow=10800 standbydelayhigh=86400                    	          rd=419 ms
2020-07-02 19:17:15 +0200 WakeTime            	WakeTime: 3.881 sec
2020-07-02 19:17:15 +0200 Kernel Client Acks  	Delays to Wake notifications: [IOThunderboltController driver is slow(msg: SetState to 2)(401 ms)] [AppleHDADriver driver is slow(msg: SetState to 1)(489 ms)] [RMIBus driver is slow(msg: SetState to 1)(1033 ms)] [IOUSBMassStorageDriverNub driver is slow(msg: SetState to 1)(1421 ms)]
2020-07-02 19:17:15 +0200 Assertions          	PID 126(powerd) Created InternalPreventSleep "com.apple.powermanagement.acwakelinger" 00:00:00  id:0x0xd0000807c [System: DeclUser SRPrevSleep IntPrevDisp kCPU kDisp]
2020-07-02 19:18:01 +0200 Assertions          	PID 126(powerd) TimedOut InternalPreventSleep "com.apple.powermanagement.acwakelinger" 00:00:45  id:0x0xd0000807c [System: DeclUser SRPrevSleep IntPrevDisp kCPU kDisp]
2020-07-02 19:19:31 +0200 Assertions          	PID 126(powerd) TimedOut InternalPreventDisplaySleep "com.apple.powermanagement.delayDisplayOff" 00:05:36  id:0x0x1000008001 [System: DeclUser IntPrevDisp kDisp]

(relevant) pre-Boot-Log:

02:820 00:003 OCB: boot-image pre-fix - PciRoot(0x0)/Pci(0x1D,0x2)/Pci(0x0,0x0)/SasEx(0x010000006479A722,0xD32831377074616C,0x0,NoTopology,0,0,0)/2b34c8000:3D21E3FB-B902-43A4-A28F-0E94D5ACD618
02:822 00:001 OCB: boot-image post-fix - PciRoot(0x0)/Pci(0x1D,0x2)/Pci(0x0,0x0)/NVMe(0x1,37-31-28-D3-22-A7-79-64)/2b34c8000:3D21E3FB-B902-43A4-A28F-0E94D5ACD618
02:844 00:022 OCB: boot-image post-fix remainder - 2b34c8000:3D21E3FB-B902-43A4-A28F-0E94D5ACD618
02:846 00:001 OCB: boot-image is 142 bytes - Success
02:848 00:002 OCB: NVRAM hibernation is 1 / Success / 44
02:855 00:006 OC: Hibernation detection status is Success
02:857 00:002 OC: Panic log does not exist
02:859 00:001 OC: OcLoadKernelSupport...
02:861 00:001 OC: All green, starting boot management...
02:863 00:001 OC: Handing off to external boot controller
02:865 00:001 OC: Ready for takeoff in 0 us

Bottom line:
it's possible and relatively seemles if one figures out the right bytes to block

from x1c6-hackintosh.

Just as a hint, I think the missing bytes to block are 0x38-0x3F:

[*] RC = 0x8000001C << RTC Configuration (msgbus port 0xC3, off 0x3400)
[02] UE = 1 << Upper 128 Byte Enable
[03] LL = 1 << Lower 128 Byte Lock
[04] UL = 1 << Upper 128 Byte Lock
[31] BILD = 1 << BIOS Interface Lock-Down
[+] Protected bytes (0x38-0x3F) in low 128-byte bank of RTC memory are locked
[+] Protected bytes (0x38-0x3F) in high 128-byte bank of RTC memory are locked

(Output from chipsec on a t480, probably same on x1c6)

Great find! There is an option in the unlocked BIOS to unlock that range if I remember correctly. I'm in the processing of resetting my own BIOS so I will report back once that is done and I can experiment again.

from x1c6-hackintosh.

Great find! There is an option in the unlocked BIOS to unlock that range if I remember correctly. I'm in the processing of resetting my own BIOS so I will report back once that is done and I can experiment again.

Saw that too and tried it (without blocking anything) a few days back with hibernatemode 25 and got a bios-checksum error :/

from x1c6-hackintosh.

I was messing around with hibernation on my X1 extreme, and I believe that the findings should be similar to whatever is found on similar X1 devices.

I was able to get rid of the CMOS error by preventing macOS from writing at addresses 80-AB onto the RTC. I have not narrowed down this at all, but this is the field in which the hibernate cipher key is put.

• OpenCore reading the cipher key
• RTC struct
  Note that the field is 44 bytes in total, or the size of 80-AB where it is written. I verified with @tylernguyen and he doesn't get the CMOS error anymore.

I'm stuck at a black screen though after trying to boot macOS. OpenCore logging tells me that it is getting to EXITBS:START (or past? since OC doesn't log anything beyond boot.efi) but have not been able to find any other info.

Edit: For blocking, I'm currently using RTCMemoryFixup to block 80-AB

from x1c6-hackintosh.

@1Revenger1 Strangely I had reversed results: Could come back from hibernation but with the annoying CMOS-error...

Settings used:

• Kernel > DisableRTCChecksum
• rtc-blacklist 5859 (via nvram)
• -rtcfx_exclude=80-FF

I don't have much time to debug atm, but I would suggest the combination of:

• Kernel > DisableRTCChecksum
• rtc-blacklist 5859 (via nvram)
• -rtcfx_exclude=80-AB

from x1c6-hackintosh.

I do know that it also writes to B0-B7 as well for hibernation which you could try excluding as well.

DisableRTCChecksum has no affect on my device, as I've never needed to block 5859. I only get CMOS errors during hibernate, which excluding 80-AB fixed. I did try DisableRTCChecksum and rtcfx_exclude=80-AB and I got no change in behavior - still stuck at a black screen.

from x1c6-hackintosh.

Then I would try to force nvram for hibernation:

• boot-arg: -hbfx-dump-nvram
• misc -> hibernate-mode from "auto" to "nvram"

Additionally you could use the DEBUG-build of OC and let it write the log to where it crashes

from x1c6-hackintosh.

OC already recognizes that it's hibernation - I can provide the log if you want but it detects it through NVRAM.
The log also says that it gets to/past EXITBS:START which is the last line usually you see in OC logs with AppleDebug enabled.

Edit: Here is the log
opencore-2020-08-12-222447.txt

from x1c6-hackintosh.

@1Revenger1 preboot-log seems fine. Could you check "pmset -g log" and "log show --last 1h|grep -i hibern" for clues after a crash?

from x1c6-hackintosh.

Hrm, I do get a wake failure log on boot but I mostly assumed that was from the second attempt at booting (which fails) which caused that. I can get check those after I wake up though.

For testing hibernation, I set hibernatemode=25 and just press "sleep" under the apple logo in the top left, if your looking for the reason why it hibernates. I'm not sure it really logs more than that? I'll check though

from x1c6-hackintosh.

@1Revenger1 I'm interested in the log about the crash while coming back from hibernation. I suspected that there would be something in syslog?

from x1c6-hackintosh.

macOS has no logs what so ever from when it tries to boot from hibernation, so this unfortunately does not seem useful.
Here is a set of timestamps to go with the logs:
13:23 -> Go to Hibernate
13:26 -> Try to boot from hibernate (Freezes at this point unless I don't have debug=0x100 in my boot args)
13:29 -> Force shutdown/boot again. (Booting again at this point causes a reset). Finally get back into macOS third time booting after going into hibernate

I'm guessing that the wake failure panic is most likely coming from that second attempt at booting, where it just resets almost instantly after you try to boot again.

sys.txt
panic.txt
pmset_log.txt

Edit: Now that I think about it, it may be worth it to check NVRAM in linux after that firce boot where it freezes?

from x1c6-hackintosh.

@1Revenger1 see daliansky/XiaoMi-Pro-Hackintosh#414. Problem doesn't seem to be specific to thinkpads :/

from x1c6-hackintosh.

Testing hibernation on 3 in my case bluetooth is dead after wakeup. Wonder if I'm missing something:

❯ pmset -g
System-wide power settings:
Currently in use:
 standbydelaylow      3600
 standby              1
 halfdim              1
 hibernatefile        /var/vm/sleepimage
 proximitywake        0
 powernap             0
 gpuswitch            2
 disksleep            10
 standbydelayhigh     3600
 sleep                1
 autopoweroffdelay    36000
 hibernatemode        3
 autopoweroff         1
 ttyskeepawake        1
 displaysleep         2
 tcpkeepalive         0
 highstandbythreshold 50
 lidwake              1

The results are great though <1% per hour.

from x1c6-hackintosh.

Sup guys! I got working hibernation on my T490 with Whiskey Lake cpu using OpenCore bootloader. As I saw "RTC Lock" chipset option isn't the main cause of checksum error, due to I also had this behaviour on my board with disabled RTC Lock in PCH settings. Higher bank (128-255) used by Lenovo for sensitive or diagnostic information like setup settings checksum, that's why checksum error thrown, if any data had been written into it.
So first of all you should use RTCMemoryFixup and HibernationFixup.
Then remove ranges from rtc-blacklist, if you use any, and add 80-AB range into exclude for RTCMemoryFixup (rtcfx_exclude=80-AB). This actions should fix checksum error. After this you need to set HibernateMode to NVRAM.
The main problem - black screen after wake could be fixed by enabling CSM support inside BIOS Setup Utilty, seems it affects memory map and do something tricky which resolves restore from hibernation file into black screen.
Also you can check my set of quirks
config.plist

from x1c6-hackintosh.

@savvamitrofanov Nice! Do you have any docs/sources for the claim about the upper memory-bank? It aligns with my experiences, but I wasn't able to find any info when I looked around...

I was able to boot relatively clean after hibernation without CSM. So it should be possible, but my tests are a bit outdated. Afaik CSM is generally discouraged in OpenCore...

from x1c6-hackintosh.

@savvamitrofanov Very interesting stuff and way above my knowledge. Will try to find time to test tomorrow. Thank you very much and keep us informed of any other findings/improvements you may make!

from x1c6-hackintosh.

Can confirm. Same result as for @1Revenger1. Thanks @savvamitrofanov! 👍

from x1c6-hackintosh.

Do not push the driver to the repository. It was meant to be a dirty test not ready for producfion. Use OpenCore 0.6.2 that has this functionality builtin via ReservedMemory section (refer to Sample.plist for exact values).

from x1c6-hackintosh.

@vit9696 That's awesome! I'll update the repo next Monday when 0.6.2 comes out then. Thank you for your work.

from x1c6-hackintosh.

@tylernguyen Jfyi it's already implemented in https://github.com/EETagent/T480-OpenCore-Hackintosh and works fine. But from my point of view it shouldn't be the default because it's not the default on genuine Macbooks and takes substantially longer to wake. But it's a "nice to have" in case you are suffering from battery drain on sleep and for completeness.

from x1c6-hackintosh.

The default for a macbook pro afaik is Sleepmode 3 (looking at man pmset), with standby times of 12 hours above 50% battery and 3 hours below 50% battery, before going to hibernate.

from x1c6-hackintosh.

Hibernation mode 25 now supported on the repo as of 985d3a2. Enable it via the command line if that is your preferred mode. Thank you @benbender @1Revenger1 @savvamitrofanov @vit9696

from x1c6-hackintosh.

Hi folks! I am currently using Tyler's EFI from before 2022-8-24 and after 2022-4-20, with OC 0.8.2. The date of the entry in the changelog is not there anymore. Not sure why!

I was able to get everything working but noticed that I was encountering the 0251 CMOS bad checksum error when turning on the computer from hibernation using hibernatemode 25. My BIOS config is not reset when this happens, but it is annoying to encounter that (and the beeping) every time I wake from hibernate.

I did not understand why this was happening (especially after reading this thread) until I noticed in the changelog that "RTCMemoryFixup.kext" was removed on 2022-2-21. Out of curiosity, I added that kext back in the Kexts folder and config.plist, and set rtcfx_exclude=80-AB in my boot-args (per one of savvamitrofanov's previous comments.)

After applying the change and rebooting twice (just in case), I no longer see the error. It has only been a day and I have only tried this about 6 times, so I'll be testing this long term. Thought I would share this for anyone who might still be encountering this issue.

from x1c6-hackintosh.

@alarsama

Sorry. I was intending to update this fix with one that doesn't depend on RTCMemoryFixup.kext but entirely forgot about it.

I'll double check the issue in the coming days and get back to you.

from x1c6-hackintosh.

@tylernguyen no worries! Just wanted to share the solution if anyone else encountered it. I appreciate you replying and wanted to express gratitude to you for sharing your EFI for the x1c6!

from x1c6-hackintosh.