Most recent kernel where this bug did not occur: 2.6.16 (maybe later) Distribution: vanilla kernel Problem Description: When temperature reaches critical value, kernel generates ACPI event AND calls /sbin/poweroff. I think, that this behaviour isn't right, because: 1) One problem is handled twice 2) Suspend to RAM can be much faster then /sbin/poweroff but it may not work on some computers. 3) I think that correct way is to handle this is in userspace with acpid instead of calling predefined binary from kernel.
Created attachment 13102 [details] Patch to disable poweroff Removed calling of poweroff.
would you please update the bug report with: 1) HW info( laptop or mobo model, lspci output, etc.) 2) acpidump result log
Generally speaking, thermal_zone driver can do nothing but just export the events and userspace I/F so that userspace can listen to the ACPI events and decide what to do next by poking the thermal userspace I/F. But when the critical trip point is reached, system is in a critical status that kernel must have its own mechanism to prevent the hardware from being destroyed by the overheating, I don't think relying on the user space is a good choice in this case. :)
Weel, my Notebook is Acer TravelMate 230 and I can provide a lot of HW Info, but I don't think it's relevant, cause object of this report wasn't bad hardware handling but something more like a cleanup. Maybe it can be experimental option in Kconfig or module parameter if you think, that it's bad default behavior. 2.6.23.1 has nocrt module parameter which allows me to disable emergency shutdown, but it also disables acpi events.
Created attachment 13554 [details] patch: export events to userspace when nocrt is set >2.6.23.1 has nocrt module parameter which allows me to disable emergency >shutdown, but it also disables acpi events. I think this is the right way to go. :) Please try this patch which disables the shutdown action when nocrt is set.
Created attachment 13585 [details] Patch to add option to Kconfig which can be used to specify default nocrt value (maybe experimental dependency should be included too) Patch from Zhang Rui sounds good and that's what I wanted to see in kernel :-D I think that option in Kconfig can be usefull too, but I understand, that everything can not be configurable.
As thermal.nocrt is a runtime switch, I don't think we should make it as a kenrel config option. And two places to configure one option seems to be duplicate. The original idea of thermal.crt is to take no action when critical trip point is reached, including the events to userspace. I'm not sure why we need to do this but IMO, the patches in comment#5 is more reasonable. An event to userspace upon critical trip point is necessary, and users can ignore this notification if no action is really needed. Len, any comments on the patch in comment#5?
Re: the patch in comment #1 to disable poweroff from the kernel critical thermal handler always... I think one could argue this either way, but we wouldn't want to make such a change suddenly, as some people could be relying on the old code. I agree that "thermal.nocrt" should just disable the shutdown action from the kernel, and should not disable the event to user-space. If somebody wants to disable both, they can use "thermal.crt=-1" So I think the patch in comment #5 is correct -- independent of the debate over what the default should be. Re: the patch in comment #6 for Kconfig to set thermal.nocrt=1. Actually, I think it would be better to combine this with the patch in comment #1. ie. If you're going to have a config option for this, then have it surround the poweroff code in the kernel. It would default to Y, which would be no change from today. Then we can debate on the list if the default should some day change, and if everybody goes for that, then the option and the code it includes can some day be deleted entirely. In the mean time, you'll are able to build the kernel you want and not have to mess with boot parameters.
patch in comment #5 shipped in Linux-2.6.24-git22 Michal, If you'd like to propose an additional config option to enable changing the default, then the best way to do that is to send it to linux-acpi@vger.kernel.org for review and feedback. this sighting is closed.