Jump to content

[Help needed] VirtualSMC causes periodic updates of clamshell state


kevin_1351
 Share

1 post in this topic

Recommended Posts

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

Link to comment
Share on other sites

 Share

×
×
  • Create New...