Distribution: Debian Hardware Environment: Compaq Evo N410c Problem Description: I have found a weird problem: using /proc/acpi/thermal_zone/TZ1/trip_points, I can set all but the active[2] temperature. Steps to reproduce: root@buena:/proc/acpi/thermal_zone/TZ1# cat * <not supported> <polling disabled> state: active[2] temperature: 44 C critical (S5): 94 C passive: 90 C: tc1=1 tc2=2 tsp=100 devices=0xc1522c00 active[0]: 80 C: devices=0xc1524d20 active[1]: 65 C: devices=0xc1524c80 active[2]: 40 C: devices=0xc1524c00 root@buena:/proc/acpi/thermal_zone/TZ1# echo -n "95:0:91:81:66:41" > trip_points root@buena:/proc/acpi/thermal_zone/TZ1# cat * <not supported> <polling disabled> state: active[2] temperature: 44 C critical (S5): 95 C passive: 91 C: tc1=1 tc2=2 tsp=100 devices=0xc1522c00 active[0]: 81 C: devices=0xc1524d20 active[1]: 66 C: devices=0xc1524c80 active[2]: 40 C: devices=0xc1524c00 Regards, Hugo
Created attachment 2693 [details] dmesg
Created attachment 2694 [details] dmidecode output
Created attachment 2695 [details] acpidmp output
acpi_thermal_write_trip_points() in thermal.c only reads up to active1. It doesn't take into account other values.
Created attachment 2697 [details] Patch making acpi_thermal_write_trip_points() consider all trip points The current acpi_thermal_write_trip_points() only considers 5 values: critical, hot, passive, active0 and active1. This patch makes it consider all the relevant values. One can now do, with 1 active point: echo -n "100:90:80:70" > trip_points With 3, you can do: echo -n "100:90:80:70:60:50" > trip_points Etc, trip_points being under /proc/acpi/thermal_zone/*. With this code, the limitation on the number of trip points is set by ACPI_THERMAL_MAX_ACTIVE, which is AFAICT a global limitation. I have tested it and it works for me. Regards, Hugo
Created attachment 2698 [details] Patch making acpi_thermal_write_trip_points() consider all trip points v2 The patch I previously sent had some memory management issues. This version should be OK. For a description, please refer to #2697.
Created attachment 2730 [details] another (shorter) patch for the same problem Note that with my patch, you need to supply at least 5 values, to be compatible to the old behaviour, but lowering the limit is trivial.
Yes, my patch is slightly more complex but doesn't have any hard-coded limits. The drawback with the simpler patch is that, would somebody have 50 trip points (would that ever happen?), we would need to change the code again. Another one is, as you mention, that one needs to echo a lot of trailing :0's. But it does fix my problem (well, at least for a while as mentioned in #2592), so either is fine by me.
the limit of 10 trip points is in the ACPI spec, you don't need to echo additional ":0", since sscanf just returns the number of matches found. Thus the for "(i = 0; i < num - 3; i++)" loop. I explicitly tested this case (my machine has four trip points and i set only 2 or three). The lower limit of 5 arguments (2 trip points) is just for backwards compatibility with the old behaviour where you always needed to provide exactly 5 values and can easily be changed to allow setting of a single trip point). So let the gurus decide on what they like better, i believe both are working well. ;-)
Stefan, Could you update and clear your patch? So, Len will apply it. thanks,
Created attachment 3284 [details] corrected patch #2730, against vanilla 2.6.7 the change to patch #2730 is - int active[9]; + int active[ACPI_THERMAL_MAX_ACTIVE]; it is obviously correct since i use active[0]...active[9], ACPI_THERMAL_MAX_ACTIVE is defined as 10.
shipped in 2.6.9 closing
*** Bug 2074 has been marked as a duplicate of this bug. ***