Jump to content

9 posts in this topic

Recommended Posts

This applies not only to Yosemite but to all recent versions, but since these boards are much more active than the DSDT section, I'll post it here.

 

I've recently struggled to make sleep work with my Z97MX-Gaming 5 and 4790K. It would sleep the first cycle, then instantly wake up on all subsequent cycles. On the kernel log, wake reason was "Wake reason: ?" which obviously does not help! Googling also doesn't do much because "?" can't be searched. But after some work I figured out how to make it all work.

 

The biggest offender to this kind of thing is the peripheral interfaces, namely LAN and USB. Often there is a device that keeps waking the computer up; if you're using the Corsair Hydro series, the USB pump interface is one of these devices. It's common sense, but it's also the easiest to fix because all you need is some trial and error.

 

Now, if that's not the issue (like me who only has keyboard, mouse, audio and some storage), there may be a rogue process that keeps waking the computer up. You can check verbose wake assertions and logs with:

pmset -g assertions
pmset -g log

Assertions override the power management settings, which includes sleep. This does not strictly mean these processes will completely block sleep. For example, if you have a Time Machine backup running on a local hard drive and you set hard drives to spin down when idle, Time Machine will prevent idle spin down. It's nonetheless important to note assertions because it is, after all, a list of things that affect power settings. It is possible that you have your wake issues within the assertions.

 

Logs print much more verbose information than the kernel log. You will see a wall of text, mostly of unimportant information regarding individual processes entering and waking from sleep mode. However, note that at the top of each section you will see entries without PID. These point not to processes but to the actual kernel activity, and these are the important bits. Even if your kernel log says "Wake reason: ?", you will find the exact reasons in the log. You will need to look for:

Wake [CDNVA] due to PWRB XHC1/User: Using AC

In my case, I have a working sleep configuration now, and I woke the computer using PWRB, or the power button. XHC1/User means it was either done through the USB 3.0 port or by the user itself, and since it didn't wake up by itself it's obviously me who woke it up. However, if you have issues, yours might look more like:

Wake [CDNVA] due to GLAN EHC1 EHC2: Using AC

In this case, GLAN (LAN), EHC1 and EHC2 (USB 2.0) woke the computer up. If you see GLAN, your computer may have woken up because of network issues. The most common setting that causes GLAN wake is "Wake for Ethernet Access" under the Energy Saver panel in System Preferences. Disable it.

 

 


My system wokes up immediately after going to sleep.

 

Terminal says: 

kernel[0] <Notice>: Wake reason: PXSX PXSX

I found PXSX in my DSDT, it is returns

                    Name (_PRW, Package (0x02)
                    {
                        0x09, 
                        0x04
                    })

I tried to delete that section but no success. Please help me to fix this problem.

 

 

 

Concerning Dark Wake

 

I was personally helping abn0rmal.pdx with his issue. His pmset -g log returned the following:

2015-06-13 08:45:58 +0300 DarkWake     DarkWake [CDN] due to PXSX PXSX/: Using AC

Screen%20Shot%202015-06-22%20at%204.02.5

 

As you can see from the screenshot of my IOReg, PXSX is a generic device name for PCIe connected cards such as your Ethernet and my USB 3.0 PCIe card. NexHimself suggests that in some cases GLAN can be replaced by PXSX, but it is important to note that it's not always a network card. Therefore, before we go ahead and mess with device names in the DSDT, we need to focus on the actual wake mechanism. Note that the process that caused wake was "DarkWake." From what I can gather, dark wake is a state of half-sleep, half-wake, triggered by "Wake for Ethernet Access" which ends up breaking your sleep/wake. If you see this in your log, I suggest using the common boot flag of darkwake=0. 

 

It is also possible that RTC0 is among the reasons. If so, your computer is waking up because of an RTC alarm. This is a setting in the BIOS that you must disable for sleep, and you can find it in the power section of most BIOSes. There are some settings in Clover's configuration as well that affect RTC: AppleRTC under KernelAndKextPatches, Rtc8Allowed under ACPI/DSDT, and FIX_RTC_20000 and FixHPET_0010 under ACPI/DSDT/Fixes. You do not need Rtc8Allowed, and you most likely do not need Fix_RTC. Also, starting with Mavericks, you do not need FixHPET. Only enable AppleRTC if your CMOS resets after a wake or reboot. Rtc8Allowed is an proposed (snake oil? we don't know yet) method of fixing CMOS resets instead of patching AppleRTC.kext like the AppleRTC setting, and it does not really work. 

 

If you see EHC1, EHC2 and so on, USB 2.0 is waking the computer up. Again, this might point to actual devices plugged into the computer. However, it could also mean incorrect settings in your Clover config.plist. Only enable USB injection and FixOwnership if you need them. You should disable AddClockID and HighCurrent to rule out any extraneous causes regarding USB sleep issues.

 

All wake reasons (GLAN, EHC1, etc.) are affected by DSDT settings. If you don't have one, you can find guides on how to extract yours. Let's take a look at the DSDT.

 

 

DSDT

 

Clover has a lot of settings in config.plist that affect the DSDT. The bulk of these settings are under the ACPI/DSDT/Fixes menu. Usually you do not need most of these settings, and it is sometimes safe to completely delete this entry. If you're still unsure about it, try to slim it down as much as you can. 

 

It's also useful to have all of these disabled except the ones you really need while editing your DSDT yourself. That way you know exactly how your DSDT affects your computer, and that it's not Clover that's causing issues.

 

You sometimes need a _DSM injection which inserts device specific methods/properties that you see on your IOReg. Most of the time you do not need it, and when you do, Clover injection does this for you. It is advisable to keep it in Clover.

 

However, there are cases where Clover injects them in the wrong places. A Z97/H97 series board may have a weird USB setup like mine and Clover was having a hard time finding the right USB device. Try moving the _DSM entry from the root hub (HUBN) to the actual device (XHC1 etc.) and vice versa. I was interested in enabling the high current mod, which is injected in the same place as the USB injection under the same _DSM entry. I moved the power settings (e.g. "AAPL,current-available") from the root hub to the actual ports (e.g. HS10 and SS04) for it to work.

 

_PRW

 

Each wake reason (GLAN, etc.) are "Device" entries in the DSDT, located in _SB.PCI0. Here I will use GLAN from my original DSDT as an example.

        Device (GLAN)
        {
            Name (_ADR, 0x00190000)
            OperationRegion (GLBA, PCI_Config, Zero, 0x0100)
            Field (GLBA, AnyAcc, NoLock, Preserve)
            {
                DVID,   16, 
                        Offset (0xCC), 
                        Offset (0xCD), 
                PMEE,   1, 
                    ,   6, 
                PMES,   1
            }
and so on...

Within each device, you have many "methods" that give the device properties. We're interested in the _PRW method, which controls power. If you've edited DSDTs before you will know this little bugger well.

            Method (_PRW, 0, NotSerialized)
            {
                Return (GPRW (0x0D, 0x04))
            }

 

There may be incorrect settings in your raw DSDT, as shown above. GPRW should return 0x09, 0x04. If your DSDT returns something else, that needs fixing.

            Method (_PRW, 0, NotSerialized)
            {
                Return (GPRW (0x09, 0x04))
            }

Apply this to each device that you saw in your pmset log. If an ACPI expert could enlighten us on exactly how _PRW works, that would be great. If you want some more detail on the Clover suggestions, check out the Clover wiki.

 

 

If I forgot any tips, post your own! The more the better!

Share this post


Link to post
Share on other sites
Advertisement

My system wokes up immediately after going to sleep.

 

Terminal says: 

kernel[0] <Notice>: Wake reason: PXSX PXSX

I found PXSX in my DSDT, it is returns

                    Name (_PRW, Package (0x02)
                    {
                        0x09, 
                        0x04
                    })

I tried to delete that section but no success. Please help me to fix this problem.

Share this post


Link to post
Share on other sites

 

My system wokes up immediately after going to sleep.

 

Terminal says: 

kernel[0] <Notice>: Wake reason: PXSX PXSX

I found PXSX in my DSDT, it is returns

                    Name (_PRW, Package (0x02)
                    {
                        0x09, 
                        0x04
                    })

I tried to delete that section but no success. Please help me to fix this problem.

 

 

PXSX is a network device most of the time, did you check for this: 

 

 

 The most common setting that causes GLAN wake is "Wake for Ethernet Access" under the Energy Saver panel in System Preferences. Disable it.

GLAN can be replaced by PXSX in this case. 

Share this post


Link to post
Share on other sites

I discovered the repercussions of the _PRW patch.

Changing to 0x09, 0x04 disables wake by that device completely, at least on the two boards that I tested on. If it's applied to a USB device (EHC, XHC) it will disable wake by USB keyboard and mouse, etc. This will probably limit how you wake the computer to the power button. If we could investigate this further I'd appreciate it.

Share this post


Link to post
Share on other sites

I have been having sleep problems and not until I saw your post did I realize that it might be unavoidable.  I do have the hydro series water cooling pump for my CPU and it is plugged directly into the motherboard via a USB header, I also use corsair commander which also plugs to the motherboard via a USB header.  Am I stuck with sleep problems because of that?  I have disabled network sleep in the bios and in the settings.  Here is my relevant log entries about sleep:

 

Dec 13 15:24:21 Stormageddons-iMac kernel[0]: Wake reason: GLAN XHC HDEF (Network)
Dec 13 15:25:19 Stormageddons-iMac kernel[0]: Wake reason: GLAN XHC HDEF (Network)
Dec 13 15:26:18 Stormageddons-iMac kernel[0]: Wake reason: GLAN XHC HDEF (Network)
Dec 13 15:27:14 Stormageddons-iMac kernel[0]: Wake reason: GLAN XHC HDEF (Network)
Dec 13 15:28:13 Stormageddons-iMac kernel[0]: Wake reason: GLAN XHC HDEF (Network)
Dec 13 15:29:11 Stormageddons-iMac kernel[0]: Wake reason: GLAN XHC HDEF (Network)
Dec 13 15:30:11 Stormageddons-iMac kernel[0]: Wake reason: GLAN XHC HDEF (Network)
Dec 13 15:31:08 Stormageddons-iMac kernel[0]: Wake reason: GLAN XHC HDEF (Network)
Dec 13 15:32:08 Stormageddons-iMac kernel[0]: Wake reason: GLAN XHC HDEF (Network)
Dec 13 15:33:04 Stormageddons-iMac kernel[0]: Wake reason: GLAN XHC HDEF (Network)
Dec 13 15:33:11 Stormageddons-iMac kernel[0]: full wake promotion (reason 1) 2282 ms

Share this post


Link to post
Share on other sites

I applied the fix to return 0x09 instead of 0x0D. my syslog was complaining about EHC2,HDEF preventing sleep. Now I don't know/care what EHC2 was at this time. However my HDEF is my webcam. On resume, I lose my webcam. Essentially I think the underlying USB port is not waking up until I reboot. 

 

Can anyone help me? How do I get back the internal USB ports I'm losing on resume?

Share this post


Link to post
Share on other sites

Can you help me?

2017-05-28 00:48:43.990312+0200  localhost kernel[0]: (AppleACPIPlatform) Wake reason: GLAN EH02 EH01

2017-05-28 00:48:43.990313+0200  localhost kernel[0]: (AppleACPIPlatform) Wake reason: GLAN EH02 EH01

2017-05-28 00:48:56.066356+0200  localhost kernel[0]: (AppleACPIPlatform) Wake reason: GLAN EH02 EH01

2017-05-28 00:48:56.066357+0200  localhost kernel[0]: (AppleACPIPlatform) Wake reason: GLAN EH02 EH01

2017-05-28 00:52:28.961815+0200  localhost kernel[0]: (AppleACPIPlatform) Wake reason: PWRB EH02 EH01 (User)

2017-05-28 00:52:28.961816+0200  localhost kernel[0]: (AppleACPIPlatform) Wake reason: PWRB EH02 EH01 (User)

Share this post


Link to post
Share on other sites

localhost kernel[0]: (AppleACPIPlatform) Wake reason: GLAN XHC XDCI (Network)

 

What should this wake reason related?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Jancey
      I used this command: diskutil info disk0s2 | grep -i "Partition UUID" | rev | cut -d' ' -f 1 | rev

      But I accidentally removed the wrong disk and now my main windows drive is not appearing in the bootloader. I can't figure out how to get it back. I tried resetting my windows drive, but I kept getting an error. I also reset my mac and reinstalled Catalina.
    • By gengstapo
      @Hervé
       
      Im having similar issue with my HS setup, dell latitute 3480, i5-7200U
      Once the hdmi plugged in, the laptop display went blank, only could see the external tv
      But, when i put my laptop to sleep & wake up again, both screen got display (hdmi still connected)
      Even the hdmi could be plugged off & in (after sleep), the laptop display is fine
       
      What could be the culprit?
      Dell’s MacBook Pro IORegistry.zip
      config.plist.zip
    • By TomZanna
      Hi, I'm trying to install Mac Os Catalina on a HP 550-132NL.
      The system has:
      i7-6700
      RAM 12 GB
      GT 730
      LAN Realtek RTL8161
      ALC3863
       
      It passes the verbose phase but after the Apple logo goes away, it gets stuck on a grey screen and I can only move the pointer.
      Can I try to boot with the iGPU?
       
      origin.zip
      CLOVER_dGPU_USB_3.zip
    • By MaLd0n
      --Donations via PayPal--
      https://tinyurl.com/r2bvzm7
       
      --Original Topic--
      https://www.olarila.com/topic/6874-olarila-hackbook-lenovo-ideapad-s145-mojave-catalina-full-dsdt-patches/
       

       
      -Perfect HackBook, HDMI Audio/Video, Bluetooth, AirPlay, Sleep, Lid Sleep, Auto Sleep, Audio, etc!
      -Wifi card has been replaced with Dell DW1560!
      -I'm using a S145-15IWL Model with Intel Core i5 8265u / Intel UHD Graphics 620
      -Update bios/uefi to last version
       
      --Installation--
      https://www.olarila.com/topic/5794-guide-install-macos-with-olarila-image-step-by-step-install-and-post-install-windows-or-mac/
       
      --Clover Folder--
      Just paste EFI folder inside EFI partition
      https://www.olarila.com/files/Clover.Folder/Lenovo IdeaPad S145.zip
      Notebooks with ELAN trackpad use it with my folder above
      IdeaPad S145 ELAN.zip
       
      Bluetooth Broadcom
      Bluetooth Broadcom.zip
       
      CPUFriend for i5-8265U
      CPUFriend i5-8265U.zip
       
      --Full DSDT Patches--
      -My DSDT
      DSDT Lenovo IdeaPad S145.zip
       
      This DSDT work on S145-14IWL, S145-15IWL, V14-IWL, V15-IWL models
      -Patches
      -FIX ERRORS AND WARNINGS -REMOVE UNUSED SCOPES / DEVICES -HIGH PRECISION EVENT TIMER -SATA SERIE 11 ID -DMAC -REMOVE LINES, PROBLEMATIC and UNUSED -SLPB -DARWIN / WINDOWS 2015 -XHCI -PLUGIN TYPE -HDAS to HDEF -HDEF -REAL TIME CLOCK -ARTC -IRQs -SBUS -BUS1 -MCHC -ALS0 -SHUTDOWN -FWHD -USBX -PMCR -PPMC -XSPI -GMM -IMEI -EC -PRWs -_DSMs -PNLF -BRIGHTNESS KEYS -I2C -NATIVE USB -ARPT -GFX0 -DTGP -kUSBCompanionIndex -io-device-location -FULL RENAMED DEVICES   --IGPU Patch--
      Video solution with HDMI Audio and Video
      <key>PciRoot(0x0)/Pci(0x2,0x0)</key> <dict> <key>AAPL,GfxYTile</key> <data> AQAAAA== </data> <key>AAPL,ig-platform-id</key> <data> CQClPg== </data> <key>device-id</key> <data> pT4AAA== </data> <key>enable-hdmi20</key> <data> AQAAAA== </data> <key>framebuffer-con0-alldata</key> <data> AAAIAAIAAACYAAAA </data> <key>framebuffer-con0-enable</key> <integer>1</integer> <key>framebuffer-con1-alldata</key> <data> AQEJAAAIAADHAQAA </data> <key>framebuffer-con1-enable</key> <integer>1</integer> <key>framebuffer-con2-alldata</key> <data> AgYKAAAEAADHAQAA </data> <key>framebuffer-con2-enable</key> <integer>1</integer> <key>framebuffer-fbmem</key> <data> AACQAA== </data> <key>framebuffer-patch-enable</key> <data> AQAAAA== </data> <key>framebuffer-stolenmem</key> <data> AAAwAQ== </data> <key>framebuffer-unifiedmem</key> <data> AAAAgA== </data> <key>hda-gfx</key> <string>onboard-1</string> <key>model</key> <string>Intel Corporation, Cannon Point-LP Iris Plus Graphics 655</string> </dict>   --Native USB Fix for Notebooks - No Injector/Kext Required--
      https://www.olarila.com/topic/6878-guide-native-usb-fix-for-notebooks-no-injectorkext-required/
      https://www.olarila.com/topic/6181-guide-native-usb-fix-for-desktops-no-injectorkext-required-skylake/
       
       
      -ScreenShots

































      -Links
       
       
      Clover https://github.com/CloverHackyColor/CloverBootloader
      AirportBrcmFixup.kext https://github.com/acidanthera/AirportBrcmFixup
      AppleALC.kext https://github.com/acidanthera/AppleALC
      Brcm Bluetooth https://github.com/acidanthera/BrcmPatchRAM
      Lilu.kext https://github.com/acidanthera/Lilu
      SystemProfilerMemoryFixup.kext https://github.com/Goldfish64/SystemProfilerMemoryFixup
      VirtualSMC.kext https://github.com/acidanthera/VirtualSMC
      VoodooI2C.kext https://github.com/alexandred/VoodooI2C
      VoodooPS2Controller.kext https://github.com/acidanthera/VoodooPS2
      WhateverGreen.kext https://github.com/acidanthera/WhateverGreen
      MaciASL - https://github.com/acidanthera/MaciASL
      acpica - https://github.com/acpica/acpica
      AptioMemoryFix.efi https://github.com/acidanthera/AptioFixPkg
      ApfsDriverLoader.efi https://github.com/acidanthera/AppleSupportPkg
      HFSPlus.efi https://github.com/JrCs/CloverGrowerPro/blob/master/Files/HFSPlus/X64/HFSPlus.efi?raw=true
      Hackintool https://github.com/headkaze/Hackintool
       
      -Credits and thanks to the old and new people in the community who developed patches, kexts and bootloaders!
       
      Slice, Kabyl, usr-sse2, jadran, Blackosx, dmazar, STLVNUB, pcj, apianti, JrCs, pene, FrodoKenny, skoczy, ycr.ru, Oscar09, xsmile, SoThOr, RehabMan, Download-Fritz, Zenit432, cecekpawon, Intel, Apple, Oracle, Chameleon Team, crazybirdy, Mieze, Mirone, Oldnapalm, netkas, Elconiglio, artut-pt, ErmaC, Pavo, Toleda, Master Chief and family, bcc9, The King, PMheart, Sherlocks, Micky1979, vit9696, vandroiy2013, Voodoo Team, Pike R. Alpha, lvs1974, Austere.J, CVad, Sampath007, onemanosx, erroruser, Jenny David, Olarila Facebook Community, Hackintosh Facebook Community and many others!
       
      We're all here to have fun and learn from each other!
    • By kevin_1351
      tl;dr: VirtualSMC causes me a flood of log messages and correlated cpu spikes. FakeSMC doesn't.
       
      Hi, I have almost finalized my Huawei Matebook X Pro Opencore setup and everything is working very well besides wifi/bt ofc (which is about to change).
       
      However, I noticed how the cpu usage sometimes went up a little and when looking at the Console I could see a never-ending flood of:
      default 14:05:05.983292+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:05.982975+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:05.982996+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:06.985932+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:06.985949+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:06.986134+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:39.426574+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:39.426729+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:39.426585+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:41.431085+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:41.431097+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:41.431246+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:42.433068+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:42.433227+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:42.433078+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:43.434453+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:43.434465+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:43.434622+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:44.436155+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:44.436166+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0  
      As you can see, multiple of these per second. Another guy with the same computer is also having this issue and posted a dsdt change to fix it. This fix didn't solve anything though
      He tried to limit the Notify call by implementing a state change requirement before calling Notify.
       
      Here is the original acpi:
      Scope (_SB) { Device (LID) { Name (_HID, EisaId ("PNP0C0D") /* Lid Device */) // _HID: Hardware ID Method (_LID, 0, NotSerialized) // _LID: Lid Status { Local0 = One Local0 = ^^PCI0.LPCB.EC0.RPIN (0x05, 0x06) If ((Local0 == 0x55)) { Local0 = Zero } Else { Local0 = One } ^^PCI0.GFX0.CLID = Local0 Return (Local0) } } Device (PWRB) { Name (_HID, EisaId ("PNP0C0C") /* Power Button Device */) // _HID: Hardware ID Method (_STA, 0, NotSerialized) // _STA: Status { Return (0x0B) } } } Scope (_SB.PCI0.LPCB.EC0) { Method (_Q81, 0, NotSerialized) // _Qxx: EC Query, xx=0x00-0xFF { Local0 = ^^^^LID._LID () If ((Local0 == Zero)) { ADBG ("LID-OFF") SGOV (0x02030009, Zero) SGOV (0x02060000, Zero) } Else { ADBG ("LID-ON") SGOV (0x02030009, One) SGOV (0x02060000, One) Notify (ALSD, 0x80) // Status Change } Notify (LID, 0x80) // Status Change } } Which he changed to: 
      Scope (_SB) { Device (LID) { Name (_OLD, One) // assuming everything else.. the lid should start open? Name (_HID, EisaId ("PNP0C0D") /* Lid Device */) // _HID: Hardware ID Method (_LID, 0, NotSerialized) // _LID: Lid Status { Local0 = One Local0 = ^^PCI0.LPCB.EC0.RPIN (0x05, 0x06) If ((Local0 == 0x55)) { Local0 = Zero } Else { Local0 = One } Return (Local0) } } Device (PNLF) { Name (_HID, EisaId ("APP0002")) // _HID: Hardware ID Name (_CID, "backlight") // _CID: Compatible ID Name (_UID, 0x0A) // _UID: Unique ID Name (_STA, 0x0B) // _STA: Status } Device (PWRB) { Name (_HID, EisaId ("PNP0C0C") /* Power Button Device */) // _HID: Hardware ID Method (_STA, 0, NotSerialized) // _STA: Status { Return (0x0B) } } } Scope (_SB.PCI0.LPCB.EC0) { Method (_Q81, 0, NotSerialized) // _Qxx: EC Query, xx=0x00-0xFF { Local0 = ^^^^LID._LID () If ((Local0 == Zero)) { ADBG ("LID-OFF") SGOV (0x02030009, Zero) SGOV (0x02060000, Zero) } Else { ADBG ("LID-ON") SGOV (0x02030009, One) SGOV (0x02060000, One) Notify (ALSD, 0x80) // Status Change } If ((^^^^LID._OLD != Local0)) { Notify (LID, 0x80) // Status Change ^^^^LID._OLD = Local0 } } } Besides me not seeing any reason to declare _OLD in LID. The idea itself shouldn't be too bad right? Well, as I said, his fix didn't work.
       
      In fact, to prove that Method _Q81 doesn't have anything to do with the issue at all, I created a Clover/Opencore patch to change _Q81 to XQ81. This resulted in my lid not working at all of course, but the log flooding still persisted!
      So _Q81 doesn't have anything to do with the issue afaik.
       
      Now, further Google searches led me to a chinese post where he tied the issue to VirtualSMC. And indeed, by migrating to FakeSMC the issue is no more.
       
      Unfortunately, I'm very fond of VirtualSMC for various reasons. So I would very much like to keep it. If not I'd have to implement the old way of doing Battery monitoring etcetc. Which isn't very elegant and update proof as it requires DSDT patching.
       
      So, I do believe that the issue may very well be in the DSDT code, perhaps in the ambient light part. I'm not very skilled at this and just started studying the ACPI spec 3 days ago.
       
      Could someone please help me out? Thanks a lot in advance
       
       
      origin.zip
      OC.zip
×