VirtualSMC & "clamshellClosed 0..." flooding in Console.App

[profzei]

Hi, hope this section is right. I have the following issue for a very long time!

If I use VirtualSMC & its plugins then I get in Console.App a flooding series of this message:

I'm using release 1.1.5 This issue is not present if I use FakeSMC This issue is documented: 1- http://bbs.pcbeta.com/forum.php?mod=viewthread&tid=1819231 2- https://github.com/gnodipac886/MatebookXPro-hackintosh/issues/75

I'm using OpenCore 0.5.9: all is working... My repo with my updated EFI is https://github.com/profzei/Matebook-X-Pro-2018

[vit9696]

Why is that an issue for you? I guess this is caused by SMCBackLight due to missing lighting sensor. Just do not install what does not work for you?

[profzei]

The machine has a native working light sensor in _SB.PCI0.LPCB.EC0_.ALSD so that macOS adjust automatically the laptop screen dimmer. There is no need of a fake ALS0 device... I think it should be important discuss and learn why this issue is related to VirtualSMC (which is great!)

[vit9696]

Does removing SMCLightSensor resolve the problem? If so, that means that SMCLightSensor is slightly inefficient, and you can consider contributing a patch to make it better, as for us the issue is not really reproducible. Could be due to your light sensor being slow.

[profzei]

Removing SMCLightSensor.kext:

• disables automatic screen brightness adjustment
• doesn't resolve the problem i.e. the flooding messages "clamshellClosed 0..." still persists...

[vit9696]

Right, could you then remove all the plugins AND static keys specified in the Indo.plist? It will be reasonsble to try to figure out, which key is causing it.

[profzei]

Sorry for my little knowledge, but what do you mean for "static keys specified in the Indo.plist"? Where can I find "Indo.plist"?

[profzei]

I removed SMCBatteryManager, SMCLightSensor and SMCProcessor -> no issue! I loaded only SMCLightSensor AND SMCProcessor -> no issue!

If I load SMCBatteryManager without my SSDT-BATT-HUAWEI.aml -> issue is present! If I load SMCBatteryManager with my SSDT-BATT-HUAWEI.aml -> issue is present!

For creating SSDT-BATT-HUAWEI.aml I followed instruction by RehabMan, GZXiaobai and Star-Dev

[profzei]

The issue seems to be related to SMCBatteryManager.kext... how is it possible?

I spent a lot of time and efforts to figure out the cause of the issue...

If I create a hot patch to remove the following code, then the issue is resolved but LID is not working anymore (obviously)

Device (LID)
        {
            Name (_HID, EisaId ("PNP0C0D"))  // _HID: Hardware ID
            Method (_LID, 0, NotSerialized)  // _LID: Lid Status
            {
                Store (One, Local0)
                Store (^^PCI0.LPCB.EC0.RPIN (0x05, 0x06), Local0)
                If (LEqual (Local0, 0x55))
                {
                    Store (Zero, Local0)
                }
                Else
                {
                    Store (One, Local0)
                }

                Store (Local0, ^^PCI0.GFX0.CLID)
                Return (Local0)
            }
        }

If, instead, I create a hot patch and I modify \_SB.LID._LID method as follows (using the rename_LID to XLID in config.plist), then the issue is resolved BUT sleep closing LID is not working

Scope (\_SB.LID)
    {
        Method (_LID, 0, NotSerialized) // LID status
        {
            If (_OSI ("Darwin"))
            {
                Store (One, Local0)
                Store (\_SB.PCI0.LPCB.EC0.RPIN (0x05, 0x06), Local0)
                If (LEqual (Local0, 0x55))
                {
                    Store (Zero, Local0)
                }
                Else
                {
                    Store (One, Local0)
                }

                Store (Local0, \_SB.PCI0.GFX0.CLID)

                If (LEqual (Local0, Zero))
                {
                    \_SB.ADBG ("LID-OFF")
                    \_SB.SGOV (0x02030009, Zero)
                    \_SB.SGOV (0x02060000, Zero)
                }
                Else
                {
                    \_SB.ADBG ("LID-ON")
                    \_SB.SGOV (0x02030009, One)
                    \_SB.SGOV (0x02060000, One)
                    Notify (\_SB.PCI0.LPCB.EC0.ALSD, 0x80)
                }                
                Notify (\_SB.LID, 0x80)

                Return (Local0)
            }
            Else
            {
                Return (\_SB.LID.XLID ())
            }
        }
    }

I really don't know why the issue is related to SMCBatteryManager.kext...

[vit9696]

Given the messages I think without any previous ones, I think the code triggering the message might be this (IOPMRootDomain.cpp, XNU kernel):

    /*
     * AC Adaptor connected
     *
     *  -> reevaluate lid state
     */
    if (msg & kIOPMSetACAdaptorConnected) {
        acAdaptorConnected = (0 != (msg & kIOPMSetValue));
        msg &= ~(kIOPMSetACAdaptorConnected | kIOPMSetValue);

        // Tell CPU PM
        informCPUStateChange(kInformAC, !acAdaptorConnected);

        // Tell BSD if AC is connected
        //      0 == external power source; 1 == on battery
        post_sys_powersource(acAdaptorConnected ? 0:1);

        sendClientClamshellNotification(); /* will print clamshell closed */

        // Re-evaluate the lid state
        eval_clamshell = true;

        // Lack of AC may have latched a display wrangler tickle.
        // This mirrors the hardware's USB wake event latch, where a latched
        // USB wake event followed by an AC attach will trigger a full wake.
        latchDisplayWranglerTickle( false );

#if HIBERNATION
        // AC presence will reset the standy timer delay adjustment.
        _standbyTimerResetSeconds = 0;
#endif
        if (!userIsActive) {
            // Reset userActivityTime when power supply is changed(rdr 13789330)
            clock_get_uptime(&userActivityTime);
        }
    }

The log message itself should not be a problem. This must be something with your LID handling in ACPI. Closing as a user configuration bug.

[profzei]

Thank you for you r reply.

These are messages (in Console.app Thread 0x74) before the flooding:

You are right: the log message itself is not a problem... BUT here I have flooding messages and this flood causes, sometimes, high cpu occupancy and then machine's stall...

[ghost]

Is it because you are not touching your computer? Turn off display like https://discussions.apple.com/thread/250828259 - after the time passes makes lot of flood?

[profzei]

@asgmeonerandom No: the flood begins soon after booting machine In general, the machine is working right: sleep and wake-up are ok, but sometimes, disregarding what I'm doing with it, this flood increases with high cpu occupancy (kernel_task -> 100% or even higher...) and then I need to shutdown machine itself!

[profzei]

This is a screenshot not limited on thread ID 0x74

[profzei]

I checked a lot of times: I have Zero ACPI Errors in my bootlog... are you sure "the polling method" is not too aggressive ? Are you sure is not related to ALSD and not ALS0?

[profzei]

@vit9696 : I tried to understand the piece of code you reported in your answer... I see (thanks to commented code) that AC should report value 1 when on battery while in my issue I have PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 even if machine is on battery... Could this is relevant? As stated before I have Zero ACPI Errors

[vit9696]

@profzei, ac is acAdaptorConnected, so it should be reported as 1 only when your laptop is charging. As for ALSD/ALS0, I do not know. But if it is not the SMCLightSensor kext, nothing else in macOS should be able to poll this.

[profzei]

Further investigation report:

1- If I use SMCBatteryManager.kext then this is what I see with IORegistryExplorer:

i.e. I see that AppleSmartBatteryManager is not attached to BAT0: is this the supposed way SMCBatteryManager correctly works? Probably yes, because, for example, external battery viewers, such as Wattagio, are able to see "battery presence"

2- If, instead, I use ACPIBatteryManager then this is what IORegistryExplorer shows:

i.e., in this case, AppleSmartBatteryManager is attached to BAT0 and the flooding messages PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 almost disappear from Console.app (in this case, external battery viewers DON'T fully work ahime! )

What do I mean with "almost disappear"? Here is the log only for ThreadID 0x74: Log_using_ACPIBatteryManager.txt

There's, in my opinion, something weird:

default 16:03:44.188514+0200    kernel  PMRD: Clamshell disabled
default 16:03:44.188522+0200    kernel  PMRD: clamshell closed 0, disabled 1, desktopMode 0, ac 1 sleepDisabled 0
default 16:03:44.188524+0200    kernel  PMRD: clamshell closed 0, disabled 1, desktopMode 0, ac 1 sleepDisabled 0

or

default 16:04:37.465641+0200    kernel  PMRD: Desktop mode
default 16:04:37.465672+0200    kernel  PMRD: clamshell closed 0, disabled 1, desktopMode 0, ac 1 sleepDisabled 0
default 16:04:37.465678+0200    kernel  PMRD: clamshell closed 0, disabled 1, desktopMode 0, ac 1 sleepDisabled 0
default 16:04:37.465890+0200    kernel  PMRD: Clamshell enabled
default 16:04:37.465902+0200    kernel  PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 1 sleepDisabled 0
default 16:04:37.465908+0200    kernel  PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 1 sleepDisabled 0

Why, in your opinion, there are those changes? and why there is ac 1? You correctly pointed me to the fact that ac 1 means that my laptop is charging... but, in this case, I have ac 1 without my machine being plugged in (it was working ON battery only)...

@vit9696 : sorry I'm really sorry boring you with this issue!

[vit9696]

Well, I cannot tell you anything about other kexts really. But is correct that nothing is attached to BAT0 with ours. The difference is that our kexts implements a virtual Apple-made battery, that takes it data from ACPI batteries, and let the native Apple driver (AppleSmartBatteryManager) work with it. All the other kexts replace Apple battery driver, and their AppleSmartBatteryManager is not made by Apple, and is thus prone to errors.

There were several changes in the battery kext recently by @zhen-zen. Could check the latest version. Or perhaps he has any observations.

[zhen-zen]

I suppose that something's wrong with your _LID implementation or some _QXX event notify _LID frequently. Apple's ACPILid driver is attached to that device and subscribes to its notifications.

Have you enabled debug message for VirtualSMC? If it's ACadapter's issue, related log will also be there.

And for supplement info, they won't be enabled unless related fields are filled in SSDT. Perhaps that won't help.

[profzei]

Hi @zhen-zen , honestly I didn't enable debug message for VirtualSMC: tomorrow morning I'll try!

I tried to hotpatch 8 times LID's code trying inspiration from what I found in forum but this issue is quite rare! I also tried an approach with 2 _Qxx methods, but without success!

I know very well that this is not a forum but anyway (since I'm desperate... it's three weeks I'm working on it without any success!) I attached my DSDT and my hotpatches: DSDT copy.dsl.zip

SSDT-LID.dsl.zip SSDT-LID2.dsl.zip SSDT-LID3.dsl.zip SSDT-LID4.dsl.zip SSDT-LID5.dsl.zip SSDT-LID6.dsl.zip SSDT-LID7.dsl.zip SSDT-LID8.dsl.zip

If you could point me in the right direction, I'll be very grateful!

[profzei]

Hi @zhen-zen , sorry for delay in reply. In the following you can find: sys_bootlog_debug_2020_08_16.txt system_log_debug.txt system_log_debug_after_sleep.txt

My actual configuration is: OpenCore 0.6.0 Official release VirtualSMC and plugins 1.1.5 Official release in DEBUG Mode In boot-args I added -vsmcdbg and smcdebug=0xff options... are they right/enough?

I'm not able to figure out the meaning of Debug messages...

[benbender]

I'm seeing the same issue on a T480. No modifications on the LID-device and It also happens for every battery-quickpoll. To me it seems that SMCBatteryManager resets the AC-status and causes this.

[zhen-zen]

It seems that AC0 is notified only once and has no issue. The following quick polls will only happen after AC status change and will last for 1 minute at 1/sec.

The _LID should only be notified by the _Q81 method. Maybe a debug log could be inserted there to track the frequency. If there's no issue with that frequency, I'm afraid there are something to do with PMRootDomain on real Mac.

[zhen-zen]

And in the log you provided, PMRD seems to check the clamshell mode every 1s and output 2 lines each time. However, the battery status updating process is read only and won't trigger other checks.

In your DSDT, Notify (BAT0, 0x81) is called in _BST and I'm afraid that might caused the issue. I suppose the notification happens when current capacity is larger than last fully charged capacity.

[benbender]

@zhen-zen You were right in my case. Redid my battery-patches and the error seems to be gone. Not sure where it was and its too late to dig deeper. But anyway, thank you again!

[profzei]

@zhen-zen I applied the second tip which was to cancel the call to Notify (BAT0, 0x81) in _BST function: NO success! Then I also tried to cancel all the calls to Notify (BAT0, 0x81) which I found in _QA1, _QA3 and _QB1 function: NO success! At this point I just have to learn how to use ACPIDebug to apply your first suggestion ... I am quite discouraged ...

[benbender]

Oh yes, error came back after a reboot for me, too. But I don't have time to investigate much further atm... :/

[zhen-zen]

@zhen-zen I applied the second tip which was to cancel the call to Notify (BAT0, 0x81) in _BST function: NO success! Then I also tried to cancel all the calls to Notify (BAT0, 0x81) which I found in _QA1, _QA3 and _QB1 function: NO success! At this point I just have to learn how to use ACPIDebug to apply your first suggestion ... I am quite discouraged ...

So how often is _LID triggered? There need to be some event sources.

[benbender]

@zhen-zen Sadly it doesn't seem to be caused by the _LID()-method. Added Debugging and it's once called on boot and if I reopen the lid after close. Meanwhile the log is full of clamshell-messages. Any other ideas?

[ghost]

@zhen-zen I applied the second tip which was to cancel the call to Notify (BAT0, 0x81) in _BST function: NO success! Then I also tried to cancel all the calls to Notify (BAT0, 0x81) which I found in _QA1, _QA3 and _QB1 function: NO success! At this point I just have to learn how to use ACPIDebug to apply your first suggestion ... I am quite discouraged ...

did you check in maciASL that change saved?

[profzei]

@asgmeonerandom

did you check in maciASL that change saved?

Yes, sure!

[benbender]

I did more digging and for me it correlates with calls to GBST(), which is a proxy-method for _BST on a dual-battery-system (T480). There is not much going on in this method - no Notify-calls at all. The only thing that caught my attention was a call to AC._PSR(). That method also does nothing really interesting besides returning a var from the EC, telling if the AC is plugged in. Does anyone that make sense to anyone more familiar with OS X-internals?

PS: It's not caused by _LID()-calls... :/

[profzei]

Hi @zhen-zen : Sorry for the late reply but I was very busy in real life... You were right: after a lot digging (and after having learned how to use ACPIDebug.kext) it seems that the issue correlates with calls to _BST() method, but NOT to Notify (BAT0, 0x81) as @benbender also reported...

I wrote this naive SSDT-RMDT-TEST separating the function code into blocks to locate the "offending" call...

Scope (\_SB.PCI0.BAT0)
    {        

        Method (_BST, 0, Serialized) // _BST: Battery Status
        {
            If (_OSI ("Darwin"))
            {
                \RMDT.P1 ("ABCD-Enter method _SB.PCI0.BAT0.XBST")
                \RMDT.P1 ("ABCD-First block begin")
                Store (Zero, Index (\_SB.PCI0.BAT0.PBST, Zero))
                Store (Ones, Index (\_SB.PCI0.BAT0.PBST, One))
                Store (Ones, Index (\_SB.PCI0.BAT0.PBST, 0x02))
                Store (Ones, Index (\_SB.PCI0.BAT0.PBST, 0x03))
                \RMDT.P1 ("ABCD-First block end")
                \RMDT.P1 ("ABCD-Second block begin")
                \RMDT.P2 ("ABCD-BATP(Zero)=", \_SB.PCI0.LPCB.EC0.BATP (Zero))
                If (LNot (\_SB.PCI0.LPCB.EC0.BATP (Zero)))
                {
                    Return (\_SB.PCI0.BAT0.PBST)
                }
                \RMDT.P1 ("ABCD-Second block end")
                \RMDT.P1 ("ABCD-Third block begin")
                \RMDT.P2 ("ABCD-GBYT(Zero)=", \_SB.PCI0.LPCB.EC0.GBYT (Zero))
                If (LEqual (\_SB.PCI0.LPCB.EC0.GBYT (Zero), 0xFF))
                {
                    Return (\_SB.PCI0.BAT0.PBST)
                }
                \RMDT.P1 ("ABCD-Third block end")
                \RMDT.P1 ("ABCD-Fourth block begin")
                BATS (Zero)
                Store (\_SB.PCI0.LPCB.EC0.BSTS (), Local0)
                \RMDT.P2 ("ABCD-BSTS=", Local0)
                Store (\_SB.PCI0.LPCB.EC0.BCRT (), Local1)
                \RMDT.P2 ("ABCD-BCRT=", Local1)
                Store (\_SB.PCI0.LPCB.EC0.BRCP (), Local2)
                \RMDT.P2 ("ABCD-BRCP=", Local2)
                Store (\_SB.PCI0.LPCB.EC0.BVOT (), Local3)
                \RMDT.P2 ("ABCD-BVOT=", Local3)
                BATR ()
                \RMDT.P1 ("ABCD-Fourth block end")
                \RMDT.P1 ("ABCD-Fifth block begin")
                If (LNotEqual (Local0, Ones))
                {
                    If (LNotEqual (Local1, Ones))
                    {
                        If (LNotEqual (Local2, Ones))
                        {
                            If (LNotEqual (Local3, Ones))
                            {
                                \_SB.PCI0.BAT0.FBST (Local0, Local1, Local2, Local3)
                                \_SB.PCI0.BAT0.CBST ()
                            }
                        }
                    }
                }
                \RMDT.P1 ("ABCD-Fifth block end")
                \RMDT.P1 ("ABCD-Sixth block begin")
                Store (\_SB.PCI0.BAT0.LFCC, Local4)
                Divide (\_SB.PCI0.BAT0.LFCC, 0xC8, Local5, Local4)
                Store (\_SB.PCI0.LPCB.EC0.BIF2 (), Local5)
                \RMDT.P1 ("ABCD-Sixth block end")
                \RMDT.P1 ("ABCD-Seventh block begin")
                If (LEqual (\_SB.PCI0.BAT0.PUNT, Zero))
                {
                    Multiply (Local5, 0x0A, Local5)
                }
                \RMDT.P1 ("ABCD-Seventh block end")
                \RMDT.P1 ("ABCD-8th block begin")
                If (LGreaterEqual (\_SB.PCI0.BAT0.LFCC, Local5))
                {
                    Subtract (\_SB.PCI0.BAT0.LFCC, Local5, Local5)
                }
                Else
                {
                    Subtract (Local5, \_SB.PCI0.BAT0.LFCC, Local5)
                }
                \RMDT.P1 ("ABCD-8th block end")
                \RMDT.P1 ("ABCD-9th block begin")
                If (LGreater (Local5, Local4))
                {
                    Notify (BAT0, 0x81)
                }
                \RMDT.P1 ("ABCD-9th block end")
                \RMDT.P1 ("ABCD-Leave method _SB.PCI0.BAT0.XBST")
                Return (\_SB.PCI0.BAT0.PBST)
            }
            Else
            {
                Return (\_SB.PCI0.BAT0.XBST ())
            }
        }
    }

I attach the boot log (sys_bootlog_ACPI01.txt) and the one (sys_console_log_after_boot.txt) relating to the normal use of the system: sys_bootlog_ACPI01.txt sys_console_log_after_boot.txt and SSDT-RMDT-TEST.aml SSDT-RMDT-TEST.aml.zip

I seem to be able to conclude that the "offending" call must take place in the first 4 blocks... do you agree? But in those blocks there are no notify calls...

This issue happens both without my SSDT-BATT-HUAWEI.aml and in its presence... when I use my SSDT-BATT-HUAWEI.aml I get zero ACPI errors... so it should be ok! I attach: SSDT-BATT-HUAWEI.aml.zip DSDT.aml.zip ALL ORIGINAL SSDT.zip

Honestly I don't know how to proceed further! Any hints?

[profzei]

Hi @zhen-zen @benbender I didi more digging... I commented the code of my first 4 blocks (putting as constant those 4 values, Local0 -> Local3, battery discharge rate doesn't work) using SSDT-RMDT-TEST-REMOVE.aml.zip but the issue is still present! See this bootlog: sys_bootlog_REMOVE02.txt What does it mean? Is it random that all "offending" calls occur within the method _BST()? or is it necessary to ask ourself what is missing? and if so what should I watch? maybe some unspecified state of the clamshell? As you can see from the log, the _LID() method is called only 3 times during boot and never after ...

[benbender]

@profzei I think you are on the wrong track and I was wrong. I suspect an event (LID/AC) in OSX to trigger PM-updates which in turn lead to battery- and clamshell-updates. I suspect you are tracing a symptom and not the source. It doesn't seem to be specific to a specific brand and I saw the list of other reports about the bug you compiled. Interestingly they didn't date past febr 2019. So it may be a rare bug introduced by virtualsmc around there.

I'm also not sure if it will persist on a fresh install or if the problem needs special circumstances to show up. Additionally there is the problem that the symptoms are quite subtile and I'm unsure if its widespread or a cornercase.

But at the end I didn't had time to look deeper into it as I'm not especially familiar with osx PM internals/virtualsmc and it would be quiet a task for me.

[profzei]

@benbender Probably you are right! What I can add is:

• the issue is still present in a fresh install for Catalina 10.15.6
• the issue is still present in Big Sur Beta 5 with latest VirtualSMC kexts (compiled by repo)

[benbender]

If you are willing to progress, some suggestions to narrow it down in ACPI:

• disable the original battery-device in ACPI by patching _HID and add a fake one (see BATC-implementation here in this repo for how to) returning just static packages in _BIF, _BST etc. If the problem persist, battery is most probably not the cause of the problem.
• rename the _LID-method and replace it with a method just returning One (if it is boolean, if I remember correctly). See if the problem persists. Same as above.

ALS-device is most probably not the source because I don't have any in my T480 ;)

[profzei]

@benbender Ok! I'll try your hints!

You have noticed that references to this "issue" didn't date past February 2019: so I tried to replace VirtualSMC + SMCBatteryManager + SMCLightSensor + SMCProcessor with their 1.0.0 versions (i.e. the initial version of this project dated September 2018)... What did I find? ...the issue was/is present! ...Maybe there wasn't any reference since most people used ACPIBatteryManager.kext...

I suspect this isn't a very rare issue/bug since in many forums there are references on random high cpu kernel_task (which is the symptom) but in general there isn't much digging since a reboot may solves that strange issue!

CC @vit9696 @zhen-zen

[ghost]

@profzei can you try that https://www.tonymacx86.com/threads/lid-sensor-flooding-log-with-clamshellstatechanged.272312/#post-1914744 and report if it worked?

[profzei]

Hi @asgmeonerandom Thank you for your help! Before posting here, I had already tried the solution proposed in tonymacx86 i.e. commenting/deleting LID device... obviously it works, but it is not a viable solution for a laptop! ...sleep&wake don't work then...

[benbender]

Hey @vit9696, @zhen-zen,

I've implemented BIS in my battery-implementation and noticed that those "storms" are significantly reduced since I disabled battery-quickpoll. I can observe that, with a full battery on AC, the log-entries completely disappear and are coming back as soon as I unplug the AC and VSMC is starting to poll the battery.

As it occured before I implemented BIS I'm quite sure it's not related to that and rather when VSMC calls _BST. So my conclusion would be that it's a bug in SMCBatteryManager.

My theory would be, that it's caused here: https://github.com/acidanthera/VirtualSMC/blob/460be0d664237f8a34ef0b33dfa0452d1bcf9396/Sensors/SMCBatteryManager/BatteryManager.cpp#L83

From my understanding the kIOPMSetACAdaptorConnected-event causes a whole reevaluation of the PMDomain as OSX thinks the status has changed while in fact it hasn't.

I asked myself if it would be possible to hold the actual state of the AC-connection somewhere and only post the power-notification on a real change and not on every poll.

Sadly I don't have the deeper OSX-knowledge to investigate further, but I think it may be worth investigating as it seems affect all people with notebooks I spoke to (even if they didn't noticed until I asked them - mostly thinkpad-users).

[vit9696]

Probably worth a reopen to at least keep it here. CC @usr-sse2 @lvs1974

[benbender]

Thank you @vit9696!

Just as a refinement and because large portions of this bug-report are a bit inaccurate - the problem isn't really the update messages as they seem to be quite normal even on a genuine mac:

 PMRD: clamshell closed 0, disabled 0/0, desktopMode 0, ac 0

but the state-changes like the following (which causes in fact, depending on the situation, quite a bit of work):

2020-11-01 21:32:15.556908+0100 0x323      Default     0x0                  124    5    loginwindow: [com.apple.loginwindow.logging:Standard] clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2
2020-11-01 21:32:15.556922+0100 0xca9      Default     0x0                  379    3    sharingd: [com.apple.sharing:Daemon] Clamshell change detected (clamshell closed: NO, clamshell sleep on close: NO)
2020-11-01 21:32:15.556940+0100 0xca9      Default     0x0                  379    3    sharingd: [com.apple.sharing:Daemon] Clamshell change detected (clamshell closed: NO, clamshell sleep on close: YES)
2020-11-01 21:32:15.657420+0100 0xd2e      Default     0x0                  319    0    NotificationCenter: [com.apple.unc:dnd] Counting clamshell display

Even more with quickpoll enabled and a rapid-polling frequency...

Edit: And another note - The change I had in mind was once implemented and later removed by @usr-sse2: https://github.com/acidanthera/VirtualSMC/commit/96a686464c4cb0b9c121ad2229d88773c005ed35

[cedroxim]

I had this problem with my laptop, with virtualsmc I have a high cpu process from Kernel_tas, using fakesmc I don't have this problem but I had a buggy battery indicator.

[Mateo1234454545]

I tried both SMCbatterymanager.kext and ACPIBatteryManager.kext , first on Catalina and the second on Big Sur with the same efi folder. This is what I found: 1) With AcpiBatteryManagerkext ,acpiacadapter is loaded under ac. With SMCBatteryManager.kext is not. 2)With AcpiBatteryManagerkext ,applesmartbatterymanager under bat0. With SMCBatteryManager.kext is not. 3) With SMCBatteryManager.kext I get one more ACPI error. 4) Cycle count is diffirent between the two.

Attaching debug files for both. Hope It can help someone solve it. ACPIBatteryManager CycleCount.pdf SMCBatteryManager CycleCount.pdf SMCBatteryManager debug.zip ACPIBatteryManager Debug.zip

[Mateo1234454545]

This is the ACPI error with SMCBatteryManager.kext

2020-11-14 06:22:00.129160+0200 0x71 Default 0x0 0 0 kernel: (AppleACPIPlatform) ACPI Exception: AE_NOT_FOUND, 2020-11-14 06:22:00.129161+0200 0x71 Default 0x0 0 0 kernel: (AppleACPIPlatform) ACPI Exception: AE_NOT_FOUND, 2020-11-14 06:22:00.129162+0200 0x71 Default 0x0 0 0 kernel: (AppleACPIPlatform) During name lookup/catalog 2020-11-14 06:22:00.129163+0200 0x71 Default 0x0 0 0 kernel: (AppleACPIPlatform) During name lookup/catalog 2020-11-14 06:22:00.129165+0200 0x71 Default 0x0 0 0 kernel: (AppleACPIPlatform) (20160930/psobject-310) 2020-11-14 06:22:00.129165+0200 0x71 Default 0x0 0 0 kernel: (AppleACPIPlatform) (20160930/psobject-310) 2020-11-14 06:22:00.129167+0200 0x71 Default 0x0 0 0 kernel: (AppleACPIPlatform) ACPI Error: 2020-11-14 06:22:00.129168+0200 0x71 Default 0x0 0 0 kernel: (AppleACPIPlatform) ACPI Error: 2020-11-14 06:22:00.129169+0200 0x71 Default 0x0 0 0 kernel: (AppleACPIPlatform) Method parse/execution failed 2020-11-14 06:22:00.129170+0200 0x71 Default 0x0 0 0 kernel: (AppleACPIPlatform) Method parse/execution failed 2020-11-14 06:22:00.129172+0200 0x71 Default 0x0 0 0 kernel: (AppleACPIPlatform) [_SB.PCI0.RP08.PXSX] (Node ffffff804b964630) 2020-11-14 06:22:00.129173+0200 0x71 Default 0x0 0 0 kernel: (AppleACPIPlatform) [_SB.PCI0.RP08.PXSX] (Node ffffff804b964630) 2020-11-14 06:22:00.129175+0200 0x71 Default 0x0 0 0 kernel: (AppleACPIPlatform) , AE_NOT_FOUND 2020-11-14 06:22:00.129175+0200 0x71 Default 0x0 0 0 kernel: (AppleACPIPlatform) , AE_NOT_FOUND 2020-11-14 06:22:00.129177+0200 0x71 Default 0x0 0 0 kernel: (AppleACPIPlatform) (20160930/psparse-632) 2020-11-14 06:22:00.129177+0200 0x71 Default 0x0 0 0 kernel: (AppleACPIPlatform) (20160930/psparse-632) 2020-11-14 06:22:00.133778+0200 0x71 Default 0x0 0 0 kernel: (AppleACPIPlatform) ACPI: 2020-11-14 06:22:00.133779+0200 0x71 Default 0x0 0 0 kernel: (AppleACPIPlatform) ACPI: 2020-11-14 06:22:00.133781+0200 0x71 Default 0x0 0 0 kernel: (AppleACPIPlatform) Executed 65 blocks of module-level executable AML code 2020-11-14 06:22:00.133782+0200 0x71 Default 0x0 0 0 kernel: (AppleACPIPlatform) Executed 65 blocks of module-level executable AML

[benbender]

@Mateo1234454545 Those ACPI-errors are errors in your ACPI and have no direct connection to VirtualSMC or this bug-report. Presumeably your device-paths/namespace in your battery-patch are wrong.

[Mateo1234454545]

Maybe , but with acpibatterymanager.kext there is not such error.

[benbender]

So VirtualSMC accesses a codepath which is defective in your ACPI. The error is your ACPI, not VirtualSMC.

[zhen-zen]

I would assume it's a firmware issue. Try install acpid in Linux (LiveCD) and monitor the output from sudo ACPI_listen. You might need to start the acpid service manually via sudo systemctl start acpid. Some machines would report battery events periodically.