https://bugzilla.kernel.org/show_bug.cgi?id=19452
Manuel Ullmann <ullman.b...@posteo.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #162611|0 |1
is obsolete| |
--- Comment #26 from Manuel Ullmann <ullman.b...@posteo.de> ---
Created attachment 164731
--> https://bugzilla.kernel.org/attachment.cgi?id=164731&action=edit
bash script used as workaround for this bug
So the case of the fan being too fast did now come up a few times and as
expected the script was buggy. I fixed that, did some other cleanup and
considered, that the cooling device order in thermal_zone changes from session
to session, so I do a little bit sorting. The script has now been working for
quite a while. There is room for improvement, but it does what it has to.
If the reported temperature decreases by 2°C too fast, the fan will still shut
down, so I can´t avoid this. I´m testing currently, whether waiting longer than
30 seconds in the tooHigh case will change anything. If not, I can comment the
whole tooHigh part, simply echo 34000 to emul_temp and reinitialise the fan.
Nevertheless I can´t avoid it if I have to activate a fan state for 55000 trip
point, while the current temperature is already at 65°C.
--
You are receiving this mail because:
You are on the CC list for the bug.
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
