Most recent kernel where this bug did *NOT* occur: Distribution: Debian Hardware Environment: Clevo D41J notebook Software Environment: Problem Description: Sometimes the following message appears in dmesg: ACPI Exception (thermal-0412): AE_NOT_FOUND, Invalid active threshold [0] [20070126] The message repeats about every 10 minutes. Steps to reproduce: Load thermal kernel module.
Created attachment 11604 [details] Output of acpidump (version 20060606-1)
There is a typo in the bug report: the laptop model is Clevo D4J and the product code is D410J.
It seems to be a buggy bios to me. "_AC0" method is offered while "_AL0" is not. It means that the thermal zone has an active trip point while there is no active device(fan) associated with it. This offends the ACPI spec so that a warning is thrown out. A bios update may help.
As far as I know there is no BIOS update available: http://www.clevo.com.tw/download/ftpOut.asp?Lmodel=D4x0J<ype=9&submit=+GO+
As far as I understand offering the _AC0 method and _AL0 method will not change during runtime. However, the current implementation checks for the active device each time the trip point is reached. Is it possible to check this condition only once at the startup? Does this behaviour allowed by ACPI spec?
Hi, Marton, An OEM can reset _ACx and _PSV and notify OSPM to reevaluate the control methods to retrieve the new policy threshold settings. And the OEM -provided AML code must execute a Notify(thermal_zone, 0x81) statement to request OSPM to re-evaluate the policy thresholds by obtaining the current values for the _ACx and _PSV objects. This is what I got from the ACPI spec 2.0. So I think it's necessary for the thermal driver to re-evaluate the _ACx method when a notification 0x81 is received. Reject this bug. :)
problem fixed by http://marc.info/?l=linux-acpi&m=120522267418715&w=2
Created attachment 19820 [details] patch vs 2.6.29-rc1 applied this patch from Rui to acpi-test tree
Rui, Márton, It isn't clear to me that I got the right patch, as it is not the one mentioned in comment #7, and that one is not in my mail archives.
the patch in comment #8 is not good as we should not re-evaluate the _PSL and _ALx method when receiving notification 0x81, according to the ACPI spec. and the patch in comment #7 is the right fix. and Marton has tested in a couple of different kernel releases. :p
Created attachment 19834 [details] patch vs 2.6.29-rc1 the previous patch has been reverted from the acpi test tree. this patch, refreshed from comment #7 has been applied to the acpi test tree.
*** Bug 12203 has been marked as a duplicate of this bug. ***
shipped in linux-2.6.29-rc2 closed
Linux kernel 2.6.29-rc2 is working correctly on Clevo D4J, product code D410J. Thank you very much for you work!