Bug 11976

please re-open when you can reproduce the issue using a recent
kernel.org.  eg. 2.6.27.stable

Compiled vanilla kernel 2.6.27.5, Same result :(

# uname -r
2.6.27.5

# dmesg
BUG: soft lockup - CPU#0 stuck for 61s! [kacpid:98]
Modules linked in: snd_hda_intel snd_pcm snd_timer 8139too mii snd snd_page_alloc r8169
CPU 0:
Modules linked in: snd_hda_intel snd_pcm snd_timer 8139too mii snd snd_page_alloc r8169
Pid: 98, comm: kacpid Not tainted 2.6.27.5 #1
RIP: 0010:[<ffffffff8027f443>]  [<ffffffff8027f443>] kmem_cache_alloc+0x80/0xab
RSP: 0000:ffff88003e801d20  EFLAGS: 00000202
RAX: ffff880028c973a8 RBX: 00000000000080d0 RCX: 0000000000000000
RDX: ffff880028c973a8 RSI: 00000000000080d0 RDI: ffff88003f1c7b00
RBP: 0000000000000000 R08: 0000000000000000 R09: ffff880028d012d0
R10: ffff88003d8e8568 R11: ffff88003d8e8400 R12: 0000000000000000
R13: 0000000000000202 R14: 0000000000000001 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffffffff80725a00(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 000000000047695c CR3: 0000000023c98000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400

Call Trace:
 [<ffffffff8037faf4>] acpi_ps_alloc_op+0x73/0x92
 [<ffffffff8037f17b>] acpi_ps_parse_loop+0x25b/0x854
 [<ffffffff8037eafd>] acpi_ps_parse_aml+0x77/0x29e
 [<ffffffff8037fd52>] acpi_ps_execute_method+0x124/0x1c6
 [<ffffffff8037caa5>] acpi_ns_evaluate+0x14d/0x1a4
 [<ffffffff803742b8>] acpi_ev_asynch_execute_gpe_method+0xbf/0x112
 [<ffffffff8036d25e>] acpi_os_execute_deferred+0x0/0x2c
 [<ffffffff8036d281>] acpi_os_execute_deferred+0x23/0x2c
 [<ffffffff8023f03c>] run_workqueue+0x7e/0xfa
 [<ffffffff8023f0b8>] worker_thread+0x0/0xec
 [<ffffffff8023f19a>] worker_thread+0xe2/0xec
 [<ffffffff80242169>] autoremove_wake_function+0x0/0x2e
 [<ffffffff80242169>] autoremove_wake_function+0x0/0x2e
 [<ffffffff80241bb0>] kthread+0x3d/0x63
 [<ffffffff8020c1f9>] child_rip+0xa/0x11
 [<ffffffff80241b73>] kthread+0x0/0x63
 [<ffffffff8020c1ef>] child_rip+0x0/0x11

Will you please attach the output of acpidump, dmesg when automatic fan throttling is enabled in BIOS?
Thanks.

Created attachment 18751 [details]
acpidump with throtteling enabled

Created attachment 18752 [details]
dmesg with throtteling enabled

There is no difference (in acpidump/dmesg) if throtteling is enabled or not. So not sure if this is of any help. Sometimes the boot-process doesn't get past "floppy0: no floppy controllers found". If you look at the dmesg, you see that a few lines above it initialises some acpi-stuff (but that's just a wild guess).

Just tell me when you need more info!

Hi, Marcel
    From the acpidump we can know that GPE 0x1D is shared by several ACPI devices(SLPB, UAR2, UAR1). 
    As the SLPB is run-time wakeup GPE, it will be enabled. If GPE 0x1D is triggered, the L1D ACPI object will be evaluated, in which the WAKE object will called. The following is the definition about WAKE object.
     >Method (WAKE, 0, NotSerialized)
                {
                    If (And (PSTS, 0x01))
                    {
      >                  If (LAnd (And (PST1, 0x04, Local0), And (PEN1, 0x04, Local1)))
       >                 {
        >                    Store (Local0, PST1)
         >                   Notify (\_SB.PCI0.LPC.UAR1, 0x02)
          >              }
           >             Store (PST1, PST1)
            >            Store (PSTS, PSTS)
            >       }
     At the same time we know that the bit 2/3 of PEN1 is cleared when the _PSW object is called to disable the wake ability of the UAR1/UAR2 devices.
     > Method (_PSW, 1, NotSerialized) 
                    {
                        If (LEqual (Arg0, Zero))
                        {
                            And (PEN1, 0xFB, PEN1)
                        }

                }
      So there is nothing to do in the WAKE object except the following:
      >Store (PST1, PST1)
      >Store (PSTS, PSTS)
      In such case the trigger source about GPE 0x1D can't be cleared and the GPE 0x1D will be triggered infinitely. So the kacpid usage will be almost 100%.
      
      But it is interesting that there is no problem if the automatic fan throttling is disabled in BIOS.
      Maybe this is caused by the BIOS and can't be fixed by Linux-kernel.
      thanks.
    

Please verify that the board has the latest BIOS.
In BIOS SETUP, if you choose to set all the settings
to default, what is this feature set to?

Please paste the output from
grep acpi /proc/interrupts
grep . /sys/firmware/acpi/interrupts/*

I'm not sure how Zhao-Yakui concluded we're screaming
in _L1D, but the above will confirm it.

Yakui,
in addition to the above... _L1D also evaluates
Store (0x01, ILED)
which I would hope turns out to be something to turn off
the interrupt source.

Created attachment 18814 [details]
interrupts/debug info, throttling enabled

Shipped BIOS: LF94510J.86A.0099.2008.0731.0303
Current BIOS: LF94510J.86A.0103.2008.0814.1910

The upgrade didn't help. Still kacpid problems.
The debug above (id=18814) is from the old BIOS version.

The good news is, that the feature is disabled by default.

Hi, Marcel
    Thanks for the test. It seems that the issue can't be resovled by the BIOS upgrading. Only when the feature is disabled in BIOS, the problem will disappear.
    Will you please confirm whether the windows can work well on this box if the feature is enabled in BIOS? (Please check whether the cpu usage is very high).
    Thanks.
    

I'm testing D945GCLF2. I had described troubles with Debian testing kernel 2.6.26-1 (100% kacpid cpu usage). Now I'm running 2.6.28-rc6 and I do not experience this issue. It seems to be solved.

marcel, can you please try 2.6.28-rc6 to see if the problem has been fixed?

I am experiencing a similar problem after ArchLinux recently upgraded its kernel to 2.6.27.  Mine is slightly different in that kacpid uses 20-50% of the cpu instead of all of it.  I installed the 2.6.28-rc6 kernel to see if the problem was fixed, but kacpid still takes over after running anything cpu intensive.  The problem occurs on my laptop, which is a Compal ifl90 with intel core2duo.

Jori,
the problem only happens if the BIOS "auto fan throttling" option is enabled
please make sure if you have the same problem.
if it's not the same bug, please open a new bug report and attach the acpidump and "grep . /sys/firmware/acpi/interrupts/*"

Created attachment 19122 [details]
Disable the global SMI on the Intel ICH chipset

Will you please try the debug patch on the latest kernel and see whether the issue still exists?(Of course the FAN throtting should be enabled in BIOS)
    In the debug patch the SMI is disabled.
    Thanks.

Will you please attach the output of lspci -vxxx?
    From the dmesg in comment #5 it seems that the I/O address for SMbus is 0x3000-0x301f.
    But from the acpidump it seems that the I/O address for SMbus controller is
0x2000-0x2016. And in the AML code the SMbus controller will be accessed.
    It is incorrect.
    
    

Created attachment 19123 [details]
try the custom DSDT in which the I/O address for SMbus controller is changed from 0x2000 to 0x3000

Does someone try the custom DSDT and see whether the problem still exists? Of course the Fan throtting should be enabled in BIOS.
   In the custom DSDT the I/O address is changed from 0x2000 to 0x3000.
   Thanks.

How to use the custom DSDT can be found in 
   http://www.lesswatts.org/projects/acpi/faq.php

Thanks.

Sorry, have been busy the last weeks.
I'm currently running vanilla-sources-2.6.28_rc7

# uname -r
2.6.28-rc7

Unfortunately I still have kacpid problems.
I'm now gonna lock into the custom DSDT.

The custom DSDT seems to fix the problem. I'm not yet 100% certain, as the system is only running a few minutes so far (but normaly i can trigger the problem by then). I also do see kacpid in "top" from time to time, but it will no longer hog the cpu.

# uname -r
2.6.28-rc7

As a side note, you need sys-power/iasl on gentoo. Download the patch above and save as DSDT.dsl. Then simply fallow the faq from step 4.

Can this change be implemented into the default kernel or do we need to patch each kernel version ourself? You may change the status at your discretion.

Thanks for so quick response.
    From the test result it is confirmed that this issue is related with BIOS. On the box there exists the SMbus controller. But the I/O address defined in PCI and AML code is different. The SMBus I/O address obtained from the PCI config space is 0x3000-0x301f. From the AML code the I/O address is 0x2000-0x201f.
    
   When the Fan throtting is enabled in BIOS, the GPE0 will be triggered and in the _L00 object the SMbus I/O port will be accessed. As the SMbus I/O port defined in AML code is incorrect, it can't be accessed correctly. If the Fan throtting is disabled, maybe the GPE0 won't be triggered and SMbus I/o port won't be accessed. 
   
   Based on the above analysis and test result, it is confirmed that this issue is related with the BIOS. And it had better be fixed by BIOS upgrading.
   Thanks.
   

yes, this is a BIOS bug that we can not fix in Linux/ACPI.
you need to either upgrade your BIOS to see if it has been fixed or use the customized DSDT for each version of your kernel.
close this bug.
Marcel, please re-open it if you can reproduce this problem with the customized DSDT.