Search results

Hi! Thanks for the late reply! I'll give it a try!

The only references to _LID are in the LID0 method in my DSDT: Device (LID0) { Name (_HID, EisaId ("PNP0C0D")) // _HID: Hardware ID Name (LIDF, Zero) Name (WMIF, Zero) Method (_LID, 0, NotSerialized) // _LID: Lid Status...

Thanks. Can you please tell me where I should look for the notify calls? In the Console or one of the logs?

Appear to be having a similar problem... see my thread here. I get this flooding the Console/logs: clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2

Problem appears to have become sporadic... sometimes it happens, sometimes it doesn't. Still presenting with the same repeated message in Console that only begins to appear once the kernel_task/CPU issue starts: clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2

Against all logic, I re-instated the VirtualSMC battery kext and the problem seems to have solved itself. Unless some other change I've made

Can anyone see anything wrong with my battery methods? (See below) I still can't figure out what's wrong. Device (BAT0) { Name (_HID, EisaId ("PNP0C0A")) // _HID: Hardware ID Name (_UID, Zero) // _UID: Unique ID Name (_PCL, Package (0x01) // _PCL...

Sorry to wake an old thread, I'm having a problem that I think may be related. kernel_task runs at 100% all the time if I have a battery status kext loaded and I'm pretty sure this is a DSDT/APCI issue. How did you find the initial error: " ACPI Error: Method parse/execution failed...

Any thoughts on whether that extra from my kernel log represents the cause of the issue? If so, does anyone have any idea how to limit the polling of the 'clamshell'? None of this appears in the kernel log if no battery management kext is loaded. Thank you!

So I went ahead and rejigged my ACPI files. I've applied minimal patching to my DSDT. I created new PR files and what stands out is that my kernel_log.txt is FULL of the following: 2019-02-12 05:24:56.594227+0000 0x221 Default 0x0 93 5 loginwindow...

I think I'll try working with my ACPI files from scratch. Would you recommend using: iasl -dl DSDT.aml SSDT*.aml For the disassembly, without the -da modify or refs.txt, since I have a Kabylake (Refresh) CPU?

I've tried replacing FakeSMC and its plugins with VirtualSMC, which includes its own battery management kext. I get the same results, so I suspect the problem is with my ACPI config. Updated PR files attached.

I'm not ruling anything out completely, but I don't see what else it could be. I'm not sure how I'd go about editing the code, either. Are there any alternatives to ACPIBatteryManager I could try so I can be completey sure that it's the problem? Perhaps there's something wrong with my ACPI...

I re-read your guide and have been able to get proper AC adapter detection without retaining SSDT-x2_0-Cpu0Ist.aml, however the CPU usage/kernel_task issue remains. The behaviour still only occurs if ACPIBatteryManager.kext is loaded (currently using the latest debugging version of the kext)...

Determined that the SSDT required for proper AC adapter detection is SSDT-x2_0-Cpu0Ist.aml and removed all unnecessary ACPI files. No change to kernel_task/CPU usage issues. Updated PR files attached. Would appreciate any contributions, please! @RehabMan

Thanks, but I'm not sure which SSDTs can be removed. I tried early (see post #4) and it only made things much worse. Any suggestions?

Kexts should now be properly installed. Updated PR files attached. Could you take another look, please @RehabMan ?

Since my original post, I have resolved all but the last issue listed, for which I have opened a separate thread here. As recommended, I have tried using the debug version of ACPIBatteryManager.kext, but have been unable to determine anything from the logs. PR files attached. Could you take a...

I'm completely stumped. Is there any chance you could take a look when you get chance please @RehabMan? Thank you!

I'm 99% sure now that the problem is to do with my ACPI files and I suspect it's a bug in the battery methods. I briefly tried swapping out fakeSMC for VirtualSMC and its related drivers and kexts, but got the same results (have now swapped back). Unfortunately, I'm not really knowledgable...