- Joined
- Oct 7, 2021
- Messages
- 2
- Motherboard
- Toshiba Tecra Z50-C
- CPU
- i7-6500u
- Graphics
- Intel HD 520
- OS X/macOS
- 10.13.x
- Bootloader
- OpenCore (UEFI)
- Mobile Phone
- Android
I have a propensity to be verbose. I'll try and give all relevant information as truncated as possible.
My laptop (in profile) is running OC 0.7.3, I'll update to 0.7.4 soonish, on Big Sur 11.6.
I'm using Lilu, VirtualSMC (including SMCBatteryManager) and the battery in my laptop does work fine. The issue is surrounding ACPI events. QuickPolling is never enabled, so updates only ever happen every 60 seconds. (Polling only, not interrupt)
Checking my DSDT, there are no >8 bit registers so ECEnabler is irrelevant, and I only have 1 battery.
When looking in Linux, ACPICA tools (acpi_listen) shows 5 events when unplugging or plugging in AC:
For reference, the TOS6208 shows up as VALZ in my DSDT.
So ACPI notifications are being handled by ACPI in, what I would expect, a somewhat normal manner.
The "battery PNP0C0A:00 00000080 00000001" happens every second or so automatically, my guess is that it's being polled by the OS each second, though I could be entirely incorrect.
One of the things I've discovered is that my EC is hidden from the DSDT. It shows in one of my dumped SSDT's as an external reference in the ACPI code, however there's no actual H_EC (as referenced by my SSDT) so I have a terrible time looking for things like interrupts. I'm having side issues with my brightness keys (Brightness works, I can't remap the keys) but that's a different issue I'll figure out some other time.
I extracted my DSDT via iasl, (Not MACiasl, not in Linux) as recommended by RehabMan, and it does compile just fine. (It also doesn't show in Windows device manager which is... curious)
At any rate in DSDT for my battery, _STA, _BST and _BIF all respond with useful information. My guess is that ADP1 (my AC adapter in DSDT) isn't notifying SMCBatteryManager when the status changes. If the interrupts come from my H_EC which seems to be hidden, this could be an issue. Linux and Windows both work, but of course I understand macOS handles this differently.
Another relevant note:
When I put my machine to sleep, or reboot, the normal polling cycle starts again and I do get updates every 60 seconds until the polling type 4 AND the battery is full is registered. At that point no further updates happen. It's looking for an interrupt which my laptop never generates. Fast polling never initiates.
I've reached out to a couple of developers - they insist it's a DSDT configuration issue, but I'm entirely stuck. I've read a forum thread a long time ago from RehabMan with someone who had a somewhat similar issue, but as soon as I enable notify(BAT1, 0x80) or similar in my DSDT, the battery and ADP1 get caught in a notification loop and they ping each other repeatedly and it slows the computer down immensely (hundreds of notifications to each other each second) and drains the battery, and also doesn't fix the problem.
I've included a zip with my ACPI dump in the root folder, IORegistryExplorer dump, as well as the main files used in my EFI with my serial info data removed. I have a bunch of SSDT's that are not in use as I was experimenting. I have a completely different EFI folder I use for debugging with debug statements injected into my DSDT to try and trace where everything goes and what's being called/notified.
I am totally stuck. I've been troubleshooting this for months, and am hoping someone here might be able to help push me in the right direction to get this fixed. Any help someone can offer would be hugely appreciated.
My laptop (in profile) is running OC 0.7.3, I'll update to 0.7.4 soonish, on Big Sur 11.6.
I'm using Lilu, VirtualSMC (including SMCBatteryManager) and the battery in my laptop does work fine. The issue is surrounding ACPI events. QuickPolling is never enabled, so updates only ever happen every 60 seconds. (Polling only, not interrupt)
Checking my DSDT, there are no >8 bit registers so ECEnabler is irrelevant, and I only have 1 battery.
When looking in Linux, ACPICA tools (acpi_listen) shows 5 events when unplugging or plugging in AC:
For reference, the TOS6208 shows up as VALZ in my DSDT.
So ACPI notifications are being handled by ACPI in, what I would expect, a somewhat normal manner.
The "battery PNP0C0A:00 00000080 00000001" happens every second or so automatically, my guess is that it's being polled by the OS each second, though I could be entirely incorrect.
One of the things I've discovered is that my EC is hidden from the DSDT. It shows in one of my dumped SSDT's as an external reference in the ACPI code, however there's no actual H_EC (as referenced by my SSDT) so I have a terrible time looking for things like interrupts. I'm having side issues with my brightness keys (Brightness works, I can't remap the keys) but that's a different issue I'll figure out some other time.
I extracted my DSDT via iasl, (Not MACiasl, not in Linux) as recommended by RehabMan, and it does compile just fine. (It also doesn't show in Windows device manager which is... curious)
At any rate in DSDT for my battery, _STA, _BST and _BIF all respond with useful information. My guess is that ADP1 (my AC adapter in DSDT) isn't notifying SMCBatteryManager when the status changes. If the interrupts come from my H_EC which seems to be hidden, this could be an issue. Linux and Windows both work, but of course I understand macOS handles this differently.
Another relevant note:
When I put my machine to sleep, or reboot, the normal polling cycle starts again and I do get updates every 60 seconds until the polling type 4 AND the battery is full is registered. At that point no further updates happen. It's looking for an interrupt which my laptop never generates. Fast polling never initiates.
I've reached out to a couple of developers - they insist it's a DSDT configuration issue, but I'm entirely stuck. I've read a forum thread a long time ago from RehabMan with someone who had a somewhat similar issue, but as soon as I enable notify(BAT1, 0x80) or similar in my DSDT, the battery and ADP1 get caught in a notification loop and they ping each other repeatedly and it slows the computer down immensely (hundreds of notifications to each other each second) and drains the battery, and also doesn't fix the problem.
I've included a zip with my ACPI dump in the root folder, IORegistryExplorer dump, as well as the main files used in my EFI with my serial info data removed. I have a bunch of SSDT's that are not in use as I was experimenting. I have a completely different EFI folder I use for debugging with debug statements injected into my DSDT to try and trace where everything goes and what's being called/notified.
I am totally stuck. I've been troubleshooting this for months, and am hoping someone here might be able to help push me in the right direction to get this fixed. Any help someone can offer would be hugely appreciated.
