After update I had performance issue with ~50% one core CPU load in idle, so I checked what task increase load, and I think it’s issue happened after acpi: Always read EC_DATA after burst enable command · haiku/haiku@588830e · GitHub
1 Like
CC @smrobtzz.
I think this happens on some systems before this commit, so it may be a regression technically but it may just have exposed your system as having the same problems as some others?
Maybe, but I can’t check that cause my previous package state was created months ago, so no useful information for debugging.
For more full report my hardware setup is Lenovo Thinkpad T14 gen 1 with 10th gen Intel core i5
1 Like
Not the same thing I think. On some system the way to hold the lock changed is not the standard one, and it cause cpu to spin endlessly pegging a CPU. This does not seem to be the case here but feel free to investigate the other cases.
We setup embedded controller handling way too late (after ACPI _INIs have been called), so it’s not unexpected the firmware would behave strangely
Can we fix that without too much difficulty?
5 Likes
That change was merged in hrev59763. Is this improved now?
1 Like
Unfortunately issue still exist, I update my system to hrev59772, and still have same output in syslog and same acpi_task with high CPU load. I can provide more information for analysis if that helps to fix that
1 Like
No, and for now system fall in KDL on ACPI after update acpi: Use x86 PCI config method directly during startup · haiku/haiku@d18fd60 · GitHub
2 Likes
I’m also getting the same KDL on my PC which never had the ACPI related issues the patch was meant to help resolve. Also someone on the IRC channel is having the same issue since upgrading to hrev59869 from hrev59867.
I’ve added my KDL to the related ticket on the bugtracker in case it helps but it looks to be the same.
I’m also getting the same KDL on my PC which never had the ACPI related issues the patch was meant to help resolve. 
hrev59869 64 bit
2 Likes
The patch is maybe too general - if somehow specify to those systems where the KDL at ACPI issue happened at shutdown, then it won’t cause problem at others at boot time.
If I understood well the new patch would use some PCI config values to fillup ACPI tables with these values, as Intel seems does on recent systems this way, so Haiku would follow this method instead it was before, as not initiliazing PCI earlier during ACPI init.
In the note at defining new Kernel Panic - it was created to catch similar problem that caused to develop the new patch that would fix the ACPI issue with KDL at shutdown.
Well, seems the panic might catch more than expected, or the patch works not the planned way on system which had no problems with the old method.
2 Likes
I too am getting this KDL now 
1 Like
It’s been fixed now in hrev59873, according to the ticket (https://dev.haiku-os.org/ticket/20196#comment:5). Just needs to be built, which should be soon.
1 Like
Yes, it’ll be in tonight’s nightly. The KDL actually uncovered a quite bad bug, which has now been fixed also.
5 Likes
Thanks so much for looking into it and resolving it so quickly, much appreciated.
3 Likes
I really appreciate this fast reaction…thank you very much
2 Likes