Bug 14198 - ACPI (kacpid) 100% CPU usage
Summary: ACPI (kacpid) 100% CPU usage
Status: REJECTED WILL_NOT_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: BIOS (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: ykzhao
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-21 07:32 UTC by Henric Blomgren
Modified: 2009-09-29 06:24 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.31
Subsystem:
Regression: No
Bisected commit-id:

Attachments
acpidump output (86.34 KB, text/plain)
2009-09-21 07:32 UTC, Henric Blomgren 		Details
lspci -vxxx (19.32 KB, text/plain)
2009-09-21 07:33 UTC, Henric Blomgren 		Details
grep -R . /sys/firmware/acpi/interrupts/* (2.13 KB, text/plain)
2009-09-21 10:00 UTC, Henric Blomgren 		Details
try the custom DSDT (157.95 KB, patch)
2009-09-24 03:32 UTC, ykzhao 		Details | Diff
Add an attachment (proposed patch, testcase, etc.)

Description Henric Blomgren 2009-09-21 07:32:48 UTC 
Created attachment 23124 [details]
acpidump output

I've got a problem with one of my home debian nodes and I'm lead to
believe it is to do with the acpi system.

When installing 2.6.26 (debian vanilla) the system randomly locks up
with the message:
BUG: soft lockup detected on CPU#0! 61s
While kacpid consumes 100% cpu according to top.

With this being an older kernel I took it upon myself to build 2.6.31
to see if there was any change.
The system does not lock up any more, but kacpid still consumes close
to 100% cpu and I'm getting this in my dmesg:
[45699.978868] ACPI Error (psparse-0537): Method parse/execution
failed [\_SB_.PCI0.LPC_.SMBR] (Node f7812c48), AE_AML_INFINITE_LOOP
[45699.978905] ACPI Error (psparse-0537): Method parse/execution
failed [\_SB_.PCI0.LPC_.INIT] (Node f7812c30), AE_AML_INFINITE_LOOP
[45699.978936] ACPI Error (psparse-0537): Method parse/execution
failed [\_GPE._L00] (Node f78101b0), AE_AML_INFINITE_LOOP
[45699.978970] ACPI Exception: AE_AML_INFINITE_LOOP, while evaluating
GPE method [_L00] 20090521 evgpe-568
(constantly repeating).

acpidump attached
Comment 1 Henric Blomgren 2009-09-21 07:33:37 UTC 
Created attachment 23125 [details]
lspci -vxxx
Comment 2 Henric Blomgren 2009-09-21 07:35:09 UTC 
Booting with acpi=off fixes the problem, but I thought I would report this issue since it is happening with the latest kernel.
Comment 3 ykzhao 2009-09-21 09:28:33 UTC 
Will you please attach following output?
   grep -R . /sys/firmware/acpi/interrupts/*

Thanks.
Comment 4 Henric Blomgren 2009-09-21 10:00:41 UTC 
Created attachment 23127 [details]
grep -R . /sys/firmware/acpi/interrupts/*
Comment 5 ykzhao 2009-09-24 03:32:15 UTC 
Created attachment 23164 [details]
try the custom DSDT

Will you please try the attached custom DSDT and see whether the issue still exists?
How to use the custom DSDT can be found in 
http://www.lesswatts.org/projects/acpi/faq.php

I already attach the file of DSDT.hex. So you can start from the step 5.

Thanks.
Comment 6 ykzhao 2009-09-24 03:36:28 UTC 
Hi, Henric
    From the acpidump & lspci it seems that maybe this issue is related with the broken BIOS.
    From the lock info it seems that this issue is related with the following AML code in the SMBR method.
    While (LNot (And (HSTS, 0x1E, Local0)))
                    {
                        Store (0xEE, IO80)
                    }
    And it seems that HSTS is the status register of SMBUS controller.
    From the DSDT it seems that the I/O base address for SMBus controller is 0x2000. But we can know that the 0x2000 I/O base address is used by the ethernet device.
    
So IMO this is a BIOS bug.

Thanks.
Comment 7 Henric Blomgren 2009-09-24 09:51:18 UTC 
I am away for the weekend and will test this and get back to you next week. Cheers
Comment 8 ykzhao 2009-09-29 06:24:27 UTC 
As this bug is caused by the broken BIOS, this bug will be rejected and marked as "Won't fix".
thanks.
Note You need to log in before you can comment on or make changes to this bug.