kacpid eats 99% cpu, and fan doesn't activate!

[Andrew Bennetts]

This started happening since I upgraded to linux-image-2.6.8.1-3-686 from
linux-image-2.6.8.1-1-686 yesterday.

Since then, I've now had the system start running extremely slowly due to kacpid
using 99% of the CPU. On top of that, it fails to turn on the CPU fan even
though I can feel my laptop getting disturbingly hot.

Running /usr/bin/acpi hangs when this happens.

I can rmmod all the acpi related modules (the ones that /etc/init.d/acpid
modprobes), but it doesn't fix the problem. Trying to modprobe them again fails
-- the modprobe of the 'ac' module just hangs.

The only workaround I have found for this a reboot.

I've marked this a "major" severity, but I'm tempted to say it should be
"critical"...

[Andrew Bennetts (spiv)]

More details about my system:

It's an HP NC6000 laptop. The lspci output:

andrew@trogdor ~ $ lspci
0000:00:00.0 Host bridge: Intel Corp. 82855PM Processor to I/O Controller (rev 03)
0000:00:01.0 PCI bridge: Intel Corp. 82855PM Processor to AGP Controller (rev 03)
0000:00:1d.0 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #1 (rev 03)
0000:00:1d.1 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #2 (rev 03)
0000:00:1d.2 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #3 (rev 03)
0000:00:1d.7 USB Controller: Intel Corp. 82801DB (ICH4) USB2 EHCI Controller
(rev 03)
0000:00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 83)
0000:00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 03)
0000:00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage
Controller (rev 03)
0000:00:1f.3 SMBus: Intel Corp. 82801DB/DBM (ICH4) SMBus Controller (rev 03)
0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801DB (ICH4) AC'97 Audio
Controller (rev 03)
0000:00:1f.6 Modem: Intel Corp. 82801DB (ICH4) AC'97 Modem Controller (rev 03)
0000:01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility
Radeon 9600 M10]
0000:02:04.0 Network controller: Intel Corp. PRO/Wireless LAN 2100 3B Mini PCI
Adapter (rev 04)
0000:02:06.0 CardBus bridge: O2 Micro, Inc. OZ711M3 SmartCardBus MultiMediaBay
Controller
0000:02:06.1 CardBus bridge: O2 Micro, Inc. OZ711M3 SmartCardBus MultiMediaBay
Controller
0000:02:06.2 System peripheral: O2 Micro, Inc. OZ711Mx MultiMediaBay Accelerator
0000:02:06.3 CardBus bridge: O2 Micro, Inc. OZ711M3 SmartCardBus MultiMediaBay
Controller
0000:02:0e.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5705M_2
Gigabit Ethernet (rev 03)
andrew@trogdor ~ $ lspci -n
0000:00:00.0 Class 0600: 8086:3340 (rev 03)
0000:00:01.0 Class 0604: 8086:3341 (rev 03)
0000:00:1d.0 Class 0c03: 8086:24c2 (rev 03)
0000:00:1d.1 Class 0c03: 8086:24c4 (rev 03)
0000:00:1d.2 Class 0c03: 8086:24c7 (rev 03)
0000:00:1d.7 Class 0c03: 8086:24cd (rev 03)
0000:00:1e.0 Class 0604: 8086:2448 (rev 83)
0000:00:1f.0 Class 0601: 8086:24cc (rev 03)
0000:00:1f.1 Class 0101: 8086:24ca (rev 03)
0000:00:1f.3 Class 0c05: 8086:24c3 (rev 03)
0000:00:1f.5 Class 0401: 8086:24c5 (rev 03)
0000:00:1f.6 Class 0703: 8086:24c6 (rev 03)
0000:01:00.0 Class 0300: 1002:4e50
0000:02:04.0 Class 0280: 8086:1043 (rev 04)
0000:02:06.0 Class 0607: 1217:7223
0000:02:06.1 Class 0607: 1217:7223
0000:02:06.2 Class 0880: 1217:7110
0000:02:06.3 Class 0607: 1217:7223
0000:02:0e.0 Class 0200: 14e4:165e (rev 03)

[Matt Zimmerman (mdz)]

I assume this was caused by the ACPI update; it will probably need to go
upstream to the ACPI guys

[Herbert Xu (herbert-gondor)]

(In reply to comment #0)
> Since then, I've now had the system start running extremely slowly due to kacpid
> using 99% of the CPU. On top of that, it fails to turn on the CPU fan even

When this happens please switch to the console and hit CTRL-SCROLLLOCK. After
that please send us the resulting kernel output.

[Andrew Bennetts (spiv)]

(In reply to comment #3)
> When this happens please switch to the console and hit CTRL-SCROLLLOCK. After
> that please send us the resulting kernel output.

Nothing happens... I don't have a normal scroll lock key on this laptop keyboard,
though. I tried Fn+Ctrl+Home (Fn+Home is marked as being scroll lock), but nothing
happened.

Is there anything else I should try?

[Andrew Bennetts (spiv)]

Created an attachment (id=265)
kern.log

Sorry, I'm a little slow tonight... I see now that something did happen, just
not on screen, but instead in my kern.log. My kern.log is attached.

[Herbert Xu (herbert-gondor)]

(In reply to comment #5)
> Sorry, I'm a little slow tonight... I see now that something did happen, just
> not on screen, but instead in my kern.log. My kern.log is attached.

Unfortunately you've got so many processes that the important one kacpid has
scrolled off. Can you please minimise the number of processes before you hit
CTRL-SCROLLLOCK so that we can get the trace of kacpid?

Thanks.

[Andrew Bennetts (spiv)]

Created an attachment (id=350)
Complete kern.log since bootup

Here is another kern.log, with every line since klogd started. I only hit
Ctrl-Scrolllock once. Again, no sign of kacpi in this dump!

Please excuse the long delays in getting this information for you -- this
kernel started running flawlessly for me, until this morning when this happened
again after only about 10 minutes.

[Andrew Bennetts (spiv)]

Created an attachment (id=352)
kern.log with kacpid

Finally! I had to kill almost every process, and remove a few modules (like
irda stuff), but eventually I got kacpid into the dump.

[Andrew Bennetts (spiv)]

Attachment 352 should satisfy the NEEDINFO.

[Herbert Xu (herbert-gondor)]

Please try the vmlinuz image at

http://gondor.apana.org.au/~herbert/ubuntu/acpi/vmlinuz-2.6.8.1-3-686

It has ACPI debugging enabled. Once you reproduce the problem simply attach the
entire kern.log here. Thanks.

[Andrew Bennetts (spiv)]

Created an attachment (id=398)
kern.log from debugging kernel

Kernel log attached. System boot was at 10:55am or so. The problem occurred
between 7:00pm and 7:30pm, I think, I wasn't watching the system closely at the
time.

[Herbert Xu (herbert-gondor)]

I'm sorry but you need to enable debugging by echoing 0xffffffff into
/proc/acpi/debug_layer and /proc/acpi/debug_level. Could you please repeat the
test after doing that? Thanks.

[Andrew Bennetts (spiv)]

(In reply to comment #12)
> I'm sorry but you need to enable debugging by echoing 0xffffffff into
> /proc/acpi/debug_layer and /proc/acpi/debug_level. Could you please repeat the
> test after doing that? Thanks.

Ouch... those options rapidly fill my disk (not helped by the fact that it logged
in triplicate in messages, syslog and kern.log)!

Is it sufficient for me to echo 0xffffffff to those files after kacpid starts
spinning? Otherwise, I'm not likely to have much luck with this, I simply don't
have the spare disk space to do this for more than 10 minutes or so.

[Herbert Xu (herbert-gondor)]

OK, please try 0x200 in debug_level. You need to do this before kacpid starts
spinning so we know where it's stuck.

[Andrew Bennetts (spiv)]

(In reply to comment #14)
> OK, please try 0x200 in debug_level. You need to do this before kacpid starts
> spinning so we know where it's stuck.

(I accidentally set both debug_level and debug_layer to 0x400 initially,
then back to 0x200... in hindsight, did you mean debug_level = 0x200 and
debug_layer = 0xffffffff?)

Oct 11 11:06:41 localhost kernel: nsdump-0081 [104] ns_print_pathname : [C127]
Oct 11 11:06:41 localhost kernel: nssearch-0100 [106] ns_search_node :
Searching \_SB_.C046.C059.C0E9.C131 (c14d7c28) For [C127] (Untyped)
Oct 11 11:06:41 localhost kernel: nssearch-0154 [106] ns_search_node :
Name [C127] (Untyped) not found in search in scope [C131] c14d7c28 first child
00000000
Oct 11 11:06:41 localhost kernel: nssearch-0220 [106] ns_search_parent_tree :
Searching parent for C127
Oct 11 11:06:41 localhost kernel: nssearch-0100 [107] ns_search_node :
Searching \_SB_.C046.C059.C0E9 (dfb39ba8) For [C127] (Untyped)
Oct 11 11:06:41 localhost kernel: nssearch-0128 [107] ns_search_node :
Name [C127] (Mutex) dfb36528 found in scope [C0E9] dfb39ba8
Oct 11 11:06:41 localhost kernel: nsobject-0238 [102] ns_detach_object :
Node df9e0510 [__L0] Object de089ba8
Oct 11 11:06:41 localhost kernel: nsobject-0238 [102] ns_detach_object :
Node df9e0558 [__L3] Object c1635ba8
Oct 11 11:06:41 localhost kernel: nsobject-0238 [102] ns_detach_object :
Node df9e05b8 [__L7] Object de089e28
Oct 11 11:06:41 localhost kernel: nsobject-0238 [102] ns_detach_object :
Node df9e0458 [__A0] Object de089da8
Oct 11 11:06:41 localhost kernel: nsobject-0238 [102] ns_detach_object :
Node df9e0470 [__A1] Object c1635d28
Oct 11 11:06:41 localhost kernel: nsaccess-0404 [102] ns_lookup :
Searching relative to prefix scope [C131] (c14dca28)
Oct 11 11:06:41 localhost kernel: nsaccess-0508 [102] ns_lookup :
Simple Pathname (1 segment, Flags=3)
Oct 11 11:06:41 localhost kernel: nsdump-0081 [102] ns_print_pathname : [C12F]
Oct 11 11:06:41 localhost kernel: nssearch-0100 [104] ns_search_node :
Searching \_SB_.C131 (c14dca28) For [C12F] (Untyped)
Oct 11 11:06:41 localhost kernel: nssearch-0154 [104] ns_search_node :
Name [C12F] (Untyped) not found in search in scope [C131] c14dca28 first child
00000000
Oct 11 11:06:41 localhost kernel: nssearch-0220 [104] ns_search_parent_tree :
Searching parent for C12F
Oct 11 11:06:41 localhost kernel: nssearch-0100 [105] ns_search_node :
Searching \_SB_ (dfb4cca8) For [C12F] (Untyped)
Oct 11 11:06:41 localhost kernel: nssearch-0128 [105] ns_search_node :
Name [C12F] (Package) c14dcd28 found in scope [_SB_] dfb4cca8
Oct 11 11:06:41 localhost kernel: exnames-0208 [105] ex_name_segment :
Appended to - C12F
Oct 11 11:06:41 localhost kernel: nsaccess-0404 [104] ns_lookup :
Searching relative to prefix scope [C131] (c14dca28)
Oct 11 11:06:41 localhost kernel: nsaccess-0508 [104] ns_lookup :
Simple Pathname (1 segment, Flags=3)
Oct 11 11:06:41 localhost kernel: nsdump-0081 [104] ns_print_pathname : [C12F]
Oct 11 11:06:41 localhost kernel: nssearch-0100 [106] ns_search_node :
Searching \_SB_.C...

[Herbert Xu (herbert-gondor)]

(In reply to comment #15)
> I'll try again with debug_level = 0x200 and debug_layer = 0xffffffff
> unless you suggest something else :)

Yes that's what I meant.

[Scott James Remnant (Canonical) (canonical-scott)]

Random thing to try (this fixes things for me):

boot with init=/bin/sh
rmmod thermal
modprobe thermal

(It looks like the order the modules are loaded in the initrd is wrong, thermal
has to come after fan to be able to control them)

[Andrew Bennetts (spiv)]

(In reply to comment #17)
> Random thing to try (this fixes things for me):
>
> boot with init=/bin/sh
> rmmod thermal
> modprobe thermal

Haha! This didn't quite work:

"Critical temperature reached (256 C), shutting down."

Seeing that my system still works, I don't think it's running *quite* that hot :)

Incidentally, 2.6.8.1-3 sees only one thermal device:

andrew@trogdor ~ $ acpi -V
     Battery 1: charged, 100%
     Thermal 1: ok, 32.0 degrees C
  AC Adapter 1: on-line

But 2.6.8.1-1 saw three. 2.6.8.1-1 also coped just fine with
"rmmod thermal; modprobe thermal".

[Andrew Bennetts (spiv)]

Finally, after two days of not happening, it happened twice this morning.

First time was before booting had finished, so my system hung at loading ACPI
modules, so I didn't get a chance to capture any useful information.

The second time, it was about 10 minutes after booting, and I had the debug
flags set in /proc, but no output. I even saw exactly when it started (I saw
the CPU graph on my gnome panel suddenly jump to 100% and stay there, often I
don't notice for a few minutes).

Also, I'm starting to suspect that the "fan doesn't activate" half of this bug
is actually a seperate bug. If I do something CPU intensive under the -3 kernel,
the fan doesn't turn on (although I can manually turn it on in /proc). I wonder
if this is related to this kernel only seeing one thermal zone, rather than
three?

Scott, I don't think bug 9063 is related, at least not to the kacpid spinning
issue I see, so I don't think saying this bug depends on it is accurate. (In
fact, if 2341 were fixed, I wouldn't be able to boot this kernel to try to diagnose
this bug! (see comment #18))

[Herbert Xu (herbert-gondor)]

(In reply to comment #19)
> The second time, it was about 10 minutes after booting, and I had the debug
> flags set in /proc, but no output. I even saw exactly when it started (I saw

Can you please cat their values?

I might have to turn it into an unconditional printk.

[Andrew Bennetts (spiv)]

(In reply to comment #20)
> (In reply to comment #19)
> > The second time, it was about 10 minutes after booting, and I had the debug
> > flags set in /proc, but no output. I even saw exactly when it started (I saw
>
> Can you please cat their values?

I'm currently back to running 2.6.8.1-1 (after this bug hit for a third time
today), but I did check this at the time, and it reported back the same values
I had echoed to it.

[Daniel Stone (daniels)]

Looking at the latest ACPI patchset, there's no fixes for this in there that I
can see.

People on various other sites (IIRC, Yoper Forums was the most comprehensive)
reported that booting with noacpi nolacpi pci=off, fixed it for them. I don't
think this is quite workable, however. They also report that Red
Hat/Fedora/Mandrake work OK, and Fedora's stock kernel has *no* ACPI patches
whatsoever, so I think something in the acpi.sf.net patchset is breaking this.
Huzzah.

[Daniel Stone (daniels)]

*** Bug 8985 has been marked as a duplicate of this bug. ***

[Scott James Remnant (Canonical) (canonical-scott)]

Ok, was a hunch. Notably I *don't* see any problems with the thermal zones on
the nc4010

syndicate scott% ls /proc/acpi/thermal_zone
TZ1/ TZ2/ TZ3/

syndicate scott% cat /proc/acpi/thermal_zone/TZ1/trip_points
critical (S5): 103 C
passive: 100 C: tc1=1 tc2=2 tsp=100 devices=0xddfce540
active[0]: 80 C: devices=0xddb44800
active[1]: 55 C: devices=0xddb44760
active[2]: 48 C: devices=0xddb446e0
active[3]: 40 C: devices=0xddb44660

syndicate scott% cat /proc/acpi/thermal_zone/*/temperature
temperature: 68 C
temperature: 64 C
temperature: 33 C

etc.

I'll keep an eye on it, but we may have found a difference between the 4010 and
6000 (other than size).

[Herbert Xu (herbert-gondor)]

(In reply to comment #21)
> I'm currently back to running 2.6.8.1-1 (after this bug hit for a third time
> today), but I did check this at the time, and it reported back the same values
> I had echoed to it.

OK, I've made it an unconditional printk in

http://gondor.apana.org.au/~herbert/ubuntu/acpi/vmlinuz-2.6.8.1-3-686.1

Please test. Thanks.

[Andrew Bennetts (spiv)]

Created an attachment (id=533)
kern.log with latest test kernel

Apologies for the delay, I didn't have internet access during the weekend.

This is a complete kern.log from a boot that showed the problem before I'd even
finished logging in.

Thanks for your patience!

[Herbert Xu (herbert-gondor)]

*** Bug 9167 has been marked as a duplicate of this bug. ***

[Herbert Xu (herbert-gondor)]

This bug has been known for a while

http://bugzilla.kernel.org/show_bug.cgi?id=3191

[Herbert Xu (herbert-gondor)]

Created an attachment (id=536)
Fix SMBus resource conflict

This patch which is in 2.6.9 should fix the problem. I've compiled a kernel
image for 2.6.8.1-3-686 at

http://gondor.apana.org.au/~herbert/ubuntu/acpi/vmlinuz-2.6.8.1-3-686.2

[Andrew Bennetts (spiv)]

(In reply to comment #29)
> Created an attachment (id=536) [edit]
> Fix SMBus resource conflict
>
> This patch which is in 2.6.9 should fix the problem. I've compiled a kernel
> image for 2.6.8.1-3-686 at
>
> http://gondor.apana.org.au/~herbert/ubuntu/acpi/vmlinuz-2.6.8.1-3-686.2
>

Ok, I'm running it now. A good sign is that now sees all thermal zones that
2.6.8.1-1 used to:

andrew@trogdor ~ $ acpi -V
     Battery 1: charged, 98%
     Thermal 1: ok, 41.0 degrees C
     Thermal 2: ok, 52.0 degrees C
     Thermal 3: ok, 32.0 degrees C
  AC Adapter 1: on-line

This kernel doesn't seem to emit this message, either:
    "PCI: Cannot allocate resource region 4 of device 0000:00:1f.3"

So, superficially at least, it looks more like the old behaviour so far :)

I'll report back here after a few days, or after the bug occurs, which ever
happens first...

[Henrik Hellerstedt (henrik8888)]

The 2.6.8.1-3-686.2 kernel provided by herbert seems to fix even my problem with
the fans (ie no thermal) stopped working as reported in bug
https://bugzilla.ubuntu.com/show_bug.cgi?id=2261.

some info about the 2.6.8.1-3-686.2 running on my machine here:
http://anka.org/henrik/ubuntu/bug/fan.WORKING.2.6.8.1-3-686.2

Ill report back in a few days if it continues to work as expected.

[Matt Zimmerman (mdz)]

The upstream bug mentions a tool called acpidmp, which we do not seem to have in
Ubuntu. Would this be a good thing for us to include in the future for
diagnostic use?

[Herbert Xu (herbert-gondor)]

Yes it is useful to have. Although even without it you can use od -x or even
tar to get the info from /proc.

[Andrew Bennetts (spiv)]

(In reply to comment #30)
> I'll report back here after a few days, or after the bug occurs, which ever
> happens first...
>

It's been working just fine. It seems your kernel fixes the bug.

[Henrik Hellerstedt (henrik8888)]

(In reply to comment #31)
> The 2.6.8.1-3-686.2 kernel provided by herbert seems to fix even my problem with
> the fans (ie no thermal) stopped working as reported in bug
> https://bugzilla.ubuntu.com/show_bug.cgi?id=2261.
>
> some info about the 2.6.8.1-3-686.2 running on my machine here:
> http://anka.org/henrik/ubuntu/bug/fan.WORKING.2.6.8.1-3-686.2
>
> Ill report back in a few days if it continues to work as expected.

Same here, Herberts kernel seems to fix the problem. Thanks!

[Nicholas Reid (njreid)]

(In reply to comment #29)
> Created an attachment (id=536) [edit]
> Fix SMBus resource conflict
>
> This patch which is in 2.6.9 should fix the problem. I've compiled a kernel
> image for 2.6.8.1-3-686 at
>
> http://gondor.apana.org.au/~herbert/ubuntu/acpi/vmlinuz-2.6.8.1-3-686.2
>

Hi Herbert - It would be great to try your updated kernel, however it seems that
link is no longer valid. Any update on when this fix might be integrated into
the hoary 686 kernel?

Thanks,

Nic

[Henrik Hellerstedt (henrik8888)]

If you dare http://anka.org/devnull/vmlinuz-2.6.8.1-3-686.2

md5sum: 8b80f27d4f1350224398260cfeb91ec3

Maybe herbert just can verify the md5 sum if he doesent want to
put it up again to save his bandwidth....

(In reply to comment #36)
> (In reply to comment #29)
> > Created an attachment (id=536) [edit] [edit]
> > Fix SMBus resource conflict
> >
> > This patch which is in 2.6.9 should fix the problem. I've compiled a kernel
> > image for 2.6.8.1-3-686 at
> >
> > http://gondor.apana.org.au/~herbert/ubuntu/acpi/vmlinuz-2.6.8.1-3-686.2
> >
>
> Hi Herbert - It would be great to try your updated kernel, however it seems that
> link is no longer valid. Any update on when this fix might be integrated into
> the hoary 686 kernel?
>
> Thanks,
>
> Nic
>

[Fabio Massimo Di Nitto (fabbione)]

According to the bug references/comments this has been fixed upstream since
2.6.9. So any
upgrade to a kernel higher than 2.6.9 has the fix.

Fabio

[Henrik Hellerstedt (henrik8888)]

Im sorry to say that this problem has appeared in 2.6.10-2-686.

When the box is booted everything seems fine except that the fan isnt spinning down.
And sometimes kacpi freaks and eats everything it can get, if i dont reboot at once
the load continues to rise up until the box stops responding.

Hopefully all info needed is at:
http://anka.org/henrik/ubuntu/bug/fan.NOT.working.2.6.10-2-686

cheers

[Andrew Bennetts (spiv)]

A data point: I upgraded to hoary last weekend, and in the few days I've been
running it (continuously, 24 hours/day), I haven't seen this problem -- so it's
still fixed for me.

$ dpkg -l linux-image-2.6.10-2-686
...
ii linux-image-2.6.10-2-686 2.6.10-10 Linux kernel image for
version 2.6.10 on PPro/Celeron/PII/PIII/PIV

$ uname -a
Linux trogdor 2.6.10-2-686 #1 Wed Jan 19 18:58:12 UTC 2005 i686 GNU/Linux

[Nicholas Reid (njreid)]

(In reply to comment #39)
> Im sorry to say that this problem has appeared in 2.6.10-2-686.
>
> When the box is booted everything seems fine except that the fan isnt spinning
down.
> And sometimes kacpi freaks and eats everything it can get, if i dont reboot at
once
> the load continues to rise up until the box stops responding.
>
> Hopefully all info needed is at:
> http://anka.org/henrik/ubuntu/bug/fan.NOT.working.2.6.10-2-686
>
>
> cheers
>

Yes, I second this - Since 2.6.10-2-686 I've also seen the problem.
I'll generate the relevant debug output when I'm back on that kernel; have
swapped to 2.6.9-1-686 to get some work done at the moment.

[Andrew Bennetts (spiv)]

(In reply to comment #40)
> A data point: I upgraded to hoary last weekend, and in the few days I've been
> running it (continuously, 24 hours/day), I haven't seen this problem -- so it's
> still fixed for me.
>
> $ dpkg -l linux-image-2.6.10-2-686
> ...
> ii linux-image-2.6.10-2-686 2.6.10-10 Linux kernel image for

But when I upgraded to 2.6.10-11, it came back. When kacpid spins like that, I see
the same messages being logged, over and over again, very fast:

Jan 27 12:13:55 localhost kernel: ACPI-0552: *** Error: AE_AML_NO_OPERAND
while evaluating method [_L11] for GPE[ 0]
Jan 27 12:13:55 localhost kernel: ACPI-1138: *** Error: Method execution
failed [\_SB_.C046.C059.C08F] (Node dfb4c720), AE_AML_NO_OPERAND
Jan 27 12:13:55 localhost kernel: ACPI-1138: *** Error: Method execution
failed [\_GPE._L11] (Node dfb41660), AE_AML_NO_OPERAND

So, this appears to be a regression 2.6.10-11 -- 2.6.10-10 has been fine for me.

> version 2.6.10 on PPro/Celeron/PII/PIII/PIV
>
> $ uname -a
> Linux trogdor 2.6.10-2-686 #1 Wed Jan 19 18:58:12 UTC 2005 i686 GNU/Linux
>

[Henrik Hellerstedt (henrik8888)]

Problems still exist with 2.6.10-13 (hoary) for me on my HP Compaq nc8000, the
fan is running like crazy, but kacpid seems to behave
better than under 2.6.10-11.

The problem seems to be with the thermal and fan

# modprobe thermal
    ACPI-1138: *** Error: Method execution failed [\_SB_.C045.C058.C08E] (Node
dfb4c740), AE_AML_NO_OPERAND
    ACPI-1138: *** Error: Method execution failed [\_TZ_.C203] (Node dfb43f40),
AE_AML_NO_OPERAND
    ACPI-1138: *** Error: Method execution failed [\_TZ_.TZ1_._TMP] (Node
dfb438c0), AE_AML_NO_OPERAND
    ACPI-1138: *** Error: Method execution failed [\_SB_.C045.C058.C08E] (Node
dfb4c740), AE_AML_NO_OPERAND
    ACPI-1138: *** Error: Method execution failed [\_TZ_.C203] (Node dfb43f40),
AE_AML_NO_OPERAND
    ACPI-1138: *** Error: Method execution failed [\_TZ_.TZ2_._TMP] (Node
dfb417c0), AE_AML_NO_OPERAND
ACPI: Thermal Zone [TZ3] (33 C)

# modprobe fan
ACPI: Fan [C209] (off)
ACPI: Fan [C20A] (off)
ACPI: Fan [C20B] (off)
ACPI: Fan [C20C] (off)

cheers

[Matthew Garrett (mjg59)]

The problems now are different to the original ones - #5807 is for dealing with
the current bug. It appears to be fixed in upstream, so we should have it sorted
in the next kernel upload.

This bug has been marked as a duplicate of bug 12194.