Most recent kernel where this bug did not occur: Happened since S3 started working for me (2.6.11) Distribution: Debian testing/unstable Hardware Environment: TP 600X Software Environment: hacked DSDT (will attach acpidmp output) Problem Description: I usually raise the THM2 zone trip point and set the polling interval to 10 seconds. After S3 resume, the rip points are reset to their default values. So on wakeup suspend/resume script raises the trip point again (and sets the polling interval to 10 seconds). Then maybe 10 minutes later the trip points get reset anyway and the fan turns on. Raising the trip points again works, and they stay raised. Steps to reproduce: cd /proc/acpi/thermal_zone echo 120:0:40:50:0 > THM2/trip_points echo 10 > THM2/polling_frequency # to work around TP600X DSDT bug where only THM0 polls echo 10 > THM0/polling_frequency <unload dubious modules, then S3 suspend and resume> /* now after wakeup: fan will be on if THM2 >= 39 C, the default */ /* so do reset again: */ cd /proc/acpi/thermal_zone echo 120:0:40:50:0 > THM2/trip_points echo 10 > THM2/polling_frequency # to work around TP600X DSDT bug where only THM0 polls echo 10 > THM0/polling_frequency /* All is fine for 10 minutes or so, then fan turns on again and THM2 trip point is back to 39 C */
Created attachment 5724 [details] acpidmp output
Created attachment 6697 [details] DSDT debug info patch It is not clear if the trip points are updated by _WAK method, i.e. on system's wakeup, or under another circumstances. Here is the DSDT debugging patch. It adds debug prints on trip points updates (i.e. Notify(.., 0x81)) and trip point methods calls (i.e. _AC0, _PSV) for thermal zones THM0, THM2. Boot with option acpi_debug=0xffffffff just to be sure ;) To see the corelation between BIOS and kernel, please use the applied DSDT patch with this one: http://bugzilla.kernel.org/attachment.cgi?id=6678&action=view
Sorry this response took so long. In the last few weeks I'd noticed a new but related problem: the trip point would revert to the default even if the laptop had never been to sleep (in addition to the usual behavior of doing it a while after waking up). I just switched to 2.6.15 and the new problem went away. However, the old problem of the trip points changing after wakeup is still there. Here's the dmesg output right after wakeup. The kernel and DSDT's have the patches you gave and I booted with acpi_debug=0xffffffff. [ACPI Debug] String: [0x26] "------- TWAK: Notify (\_TZ.THM0, 0x81)" ------------------ Got thermal event 0x81 [ACPI Debug] String: [0x26] "------- TWAK: Notify (\_TZ.THM2, 0x81)" [ACPI Debug] String: [0x1B] "------- THM0._PSV: 00000E49" [ACPI Debug] String: [0x1B] "------- THM0._AC0: 00000E30" ------------------ Got thermal event 0x81 [ACPI Debug] String: [0x1B] "------- THM0._AC0: 00000C32" ------------------ Got thermal event 0x81 ------------------ Got thermal event 0x81 Here's the dmesg output after the latest change, which was 30 minutes after waking from S3 (the wake script puts up the trip points, so the output below is from when they spontaneously dropped back to the default, or maybe a bit after in case the temperature wasn't high enough when they dropped back): [ACPI Debug] String: [0x26] "------- _Q42: Notify (\_TZ.THM2, 0x81)" ------------------ Got thermal event 0x81 [ACPI Debug] String: [0x1B] "------- THM0._AC0: 00000BFB" ------------------ Got thermal event 0x80 -Sanjoy
Well, the trip points are being updated by the _WAK method on wakeup (first case), and by the event _Q42 from the embedded controller (second case). I don't know the reason of the trip points reseting, possibly to prevent too high thermal limit setting. To avoid it you can comment out appropriate code lines and re-compile the DSDT.