Bug 9167 - No TZ.temp update, no fan control (64-bit only) - Acer Aspire 5720, 7720Z - Santa Rosa, T7300
Summary: No TZ.temp update, no fan control (64-bit only) - Acer Aspire 5720, 7720Z - S...
Status: CLOSED PATCH_ALREADY_AVAILABLE
Alias: None
Product: ACPI
Classification: Unclassified
Component: BIOS (show other bugs)
Hardware: All Linux
: P1 blocking
Assignee: Zhang Rui
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-15 11:26 UTC by Marco Calviani
Modified: 2008-06-25 08:19 UTC (History)
11 users (show)

See Also:
Kernel Version: 2.6.22 and 2.6.23
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
dmesg (22.62 KB, application/octet-stream)
2007-10-15 11:28 UTC, Marco Calviani
Details
Content of files in /proc/acpi/thermal_zone/TZ01/ (242 bytes, text/plain)
2007-10-15 12:04 UTC, Tommaso Falchi Delitala
Details
Kernel config (standard) for KNOPPIX 5.1.1 (74.64 KB, application/octet-stream)
2007-10-16 00:36 UTC, Marco Calviani
Details
Kernel config (custom) for Gentoo Linux (x86_64) (43.96 KB, application/octet-stream)
2007-10-16 00:37 UTC, Marco Calviani
Details
acpidump with original DSDT (167.71 KB, application/octet-stream)
2007-10-18 05:35 UTC, Marco Calviani
Details
Ivo Sabev's files (28.66 KB, application/octet-stream)
2007-12-25 08:10 UTC, Ivo Sabev
Details
Working .config for kernel 2.6.23 (gentoo-r3) 32bit (39.59 KB, text/plain)
2008-01-09 03:10 UTC, Tommaso Falchi Delitala
Details
2.6.23-gentoo-r3 working kernel. (47.32 KB, text/plain)
2008-01-09 05:17 UTC, Marco Calviani
Details
My kernel config (68.65 KB, text/plain)
2008-01-11 03:02 UTC, Ivo Sabev
Details
dmesg, lspci, dmidecode outputs (166.35 KB, application/octet-stream)
2008-01-11 03:03 UTC, Ivo Sabev
Details
Archive containing Acer 5720 Fan Control Script + Binary Patcher (5.87 KB, application/octet-stream)
2008-03-19 02:59 UTC, David Edwards
Details
Updated Archive containing Acer 5720 Fan Control Script + Binary Patcher (7.18 KB, application/octet-stream)
2008-03-31 19:36 UTC, David Edwards
Details
Updated Archive containing Acer 5720 Fan Control Script + Binary Patcher (12.17 KB, application/octet-stream)
2008-04-11 06:12 UTC, David Edwards
Details

Description Marco Calviani 2007-10-15 11:26:40 UTC
Distribution: 
Gentoo Linux x86_64 version

Hardware Environment:
ACER Aspire 5720, x86_64 environment

Problem Description:
I have thermal issues with my Acer Aspire 5720 (Santa Rosa, T7300 Intel Core 2 Duo).
In particular:
# cat /proc/acpi/thermal_zone/TZ01/trip_points
critical (S5):           100 C
so that there is no rules for activating the fans.
Additionally /proc/acpi/thermal_zone/TZ01/temperature does not get updated neither
if i change the polling_freqency, so that even if the core temperature
reaches 70-80C the fans never starts.
The only way to control the core temperature is via the coretemp kernel module, but since in the ACER laptops the fan is masked from the user, nothing can be done (at user level).

My original DSDT table is here:
http://aceracpi.googlecode.com/svn/trunk/dsdt/acer/aspire/5720.dsl
(but you can find it also here http://acpi.sourceforge.net/dsdt/view.php)
The original, as dumped from /proc/acpi/dsdt, does not compile, but i've manage to wipe
out the errors and warning.  Also in this case, however, the ACPI behaviour is still the same.

All the ACPI modules are built in the monolithic kernel.

I've tried different configurations:
kernel 2.6.22-gentoo-r8
kernel 2.6.22.10
kernel 2.6.23-rc8-mm2
but the results are always the same.
Comment 1 Marco Calviani 2007-10-15 11:28:12 UTC
Created attachment 13170 [details]
dmesg

dmesg log file
Comment 2 Tommaso Falchi Delitala 2007-10-15 11:55:27 UTC
Hello,
I'm experiencing the same problem, same hardware as Marco.
I can add that this problem seems to affect only x86_64 arch. When running Gentoo Linux 32 bit and Knoppix 5.1 (32 bit) the fan works as expected and CPU doesn't get hotter then 60°C, even with 3 cpu-burn-in tests running at the same time and a divx film playing.
In x86_64 arch instead the temperature goes up to 100°C and over, until the machine switches off automatically. 
Also on Windows Vista the fan works normally.
Comment 3 Tommaso Falchi Delitala 2007-10-15 12:04:41 UTC
Created attachment 13172 [details]
Content of files in /proc/acpi/thermal_zone/TZ01/
Comment 4 Marco Calviani 2007-10-15 12:11:55 UTC
I've got exactly the same results as Tommaso for what concern Knoppix 32bit and the content of /proc/acpi/thermal_zone/TZ01/ and the experience with Vista (32bit).
Please note that also with
echo "2 seconds" > /proc/acpi/thermal_zone/TZ01/polling_frequency
the ACPI temperature remains the same with 64bit linuxes.
Comment 5 Zhang Rui 2007-10-15 19:20:26 UTC
Well, from the dsdt you attached, ACPI can not control the temperature on this laptop.
I mean no active cooling device(fan) or passive cooling device(processor) available in thermal zone TZ01.
>I can add that this problem seems to affect only x86_64 arch.
Could you attach the content of /proc/acpi/thermal_zone/TZ01/ when running Gentoo Linux 32 bit and Knoppix 5.1 (32 bit) please?
Please attach the kernel config file both in x86_64 and i386 arch.
Comment 6 Marco Calviani 2007-10-16 00:36:02 UTC
Hi Rui,
   i'm attaching the config file for Gentoo x86_64 with kernel 2.6.22 and for Knoppix 5.1.1 (2.6.19).

The content of /proc/acpi/thermal_zone/TZ01 is the same for both distributions and it is:

cat /proc/acpi/thermal_zone/TZ01/*
<setting not supported>
cooling mode:   critical
<polling disabled>
state:                   ok
temperature:             40 C
critical (S5):           100 C
Comment 7 Marco Calviani 2007-10-16 00:36:46 UTC
Created attachment 13176 [details]
Kernel config (standard) for KNOPPIX 5.1.1
Comment 8 Marco Calviani 2007-10-16 00:37:40 UTC
Created attachment 13177 [details]
Kernel config (custom) for Gentoo Linux (x86_64)

(This configuration file has also been used for the vanilla kernel test)
Comment 9 Zhang Rui 2007-10-17 00:36:20 UTC
For x86_64 kernel, could you please clear CONFIG_HWMON, recompile the kernel and try again? Hwmon conficts with ACPI themral/fan control sometimes.
Comment 10 Marco Calviani 2007-10-17 05:29:14 UTC
Hi,
  i've tried deselecting the HWMON option, but no way, i'm always getting the same 
/proc/acpi/thermal_zone/TZ01/temperature (stuck at 40C), even if i change the polling_frequency, and the core temperature reaches >60C (in this case the thermal_zone should be higher if understood correctly). In the case of KNOPPIX i saw this number change.

 
Comment 11 Zhang Rui 2007-10-18 01:26:25 UTC
re comment #8, it seems that you are using a customized DSDT? please try the original DSDT on your laptop, and please attach the full acpidump output.
Comment 12 Marco Calviani 2007-10-18 05:35:30 UTC
Created attachment 13197 [details]
acpidump with original DSDT
Comment 13 Marco Calviani 2007-10-18 06:00:31 UTC
... and i have this for cat /proc/acpi/thermal_zone/TZ01/*

cat /proc/acpi/thermal_zone/TZ01/*
<setting not supported>
<polling disabled>
state:                   ok
temperature:             0 C
critical (S5):           100 C
Comment 14 Tommaso Falchi Delitala 2007-10-19 07:07:45 UTC
I also tried  to compile all ACPI features as modules and auto-load them at boot. They were loaded without problems, but the problem was not fixed.
Thermal zone is sill not updated when CPU get hotter/colder. 

Today I was able to see the fan running, because I rebooted after making CPU 75-80 C hot. At boot time ACPI entered in the correct thermal_zone (75 C) and fan started, but kept going also when CPU cooled down to 36 C. Thermal_zone was still fixed at 75 C.
Comment 15 Marco Calviani 2007-10-19 07:12:58 UTC
I can confirm that the behaviour is the same.
Comment 16 Marco Calviani 2007-10-19 09:43:41 UTC
Additionally i would like to report the success in running Ubuntu Linux 7.10 i386 version (temperature gets updated and fan starts after 60C). While i have always the same problem for the x86_64 version.
Comment 17 Tommaso Falchi Delitala 2007-11-03 12:02:07 UTC
New BIOS released by ACER (v. 1.19), but the problem is still here! 
Does anybody know someone to contact in ACER/ACER-support, who could help to fix the problem?

We could also try to run Vista 64bit and see if we experience the same issue (maybe it's a wider 64bit incompatibility...not only with linux)! I don't have any copy of the 64 bit version right now... but I will ask to my university if they can give me one!
Comment 18 Radoslav Stoyanov 2007-11-28 09:32:22 UTC
The arch/x86_64/kernel/acpi/processor.o seems to be created from arch/i386/kernel/acpi/processor.c file and seems that it is not compatible code with 64bit system. I hope that hint to help to the linux kernel developers ,since I have exactly the same problem, tried EVERYTHING and believe me it is not config issue!
Comment 19 Radoslav Stoyanov 2007-11-28 09:34:08 UTC
Vista 64 bit works perfect, except one problem, after return from standby also forgots about the fan:). M$ - nothing can be done about it:)
Comment 20 Radoslav Stoyanov 2007-11-28 12:55:58 UTC
Also as probable problem place I see boot.c at same location ...
Comment 21 Radoslav Stoyanov 2007-11-28 12:56:42 UTC
Also as probable problem place I see boot.c at the same location ...
Comment 22 Radoslav Stoyanov 2007-11-29 01:02:51 UTC
More info about the behaviour:
1. Starting linux with all acpi settings correctly enabled.
2. If the processor is cold the fan doesn't start. Then it goes to critical temperature and the system shutsdown.
3. Restart, now the bios runs the fan, the kernel shuts it down on load. After "udev" load - the fan is started again and never stops until the system is restarted.
4. restart, now the fan starts again with lower speed by bios. kernel loads but right after udev loads - the fan is shutted down and never started again until the cpu overheat the secure temperature and then shuts down. 
Comment 23 Radoslav Stoyanov 2007-11-29 01:19:53 UTC
Sorry forgot to tell the system characteristics:
Acer 5720z, intel dual core 1.43GHz, X3100 video, 2GB ram ...
Fedora Core 8 , tried with kernels 2.6.23.1 , 7 and 9 - completely same behaviour
With windows vista 64 bit works normal (except wakeup from standby)
With windows XP SP2 32 bit works normal too
Haven't tested with 32bit linux, but as Marco said - seems it works ok there too.
So my suspicions are that some 32 bit structures are incompatible with the 64 bit system somehow. I see much #ifdef and #else in the code about x86_64 - could be that some code needed to intialise the acpi structures is missing .., or 32 bits are processed and in 64 bits word somehow goes mess because of the big endian swaps of the most significant bits ... Please solve that problem since makes impossible to use my laptop under 64 bit linux, but I need that!
Comment 24 Tommaso Falchi Delitala 2007-11-30 15:11:52 UTC
Yes Radoslav, you got it right... the problem seems to be not the fan itself, but the automatic update of acpi thermal zone. Its value is correctly read at boot time, but then is not updated!
Comment 25 Radoslav Stoyanov 2007-12-03 03:56:47 UTC
New info, I installed i386 version of Fedora 8, compiled same linux 2.6.23.9 kernel. Now acpi is updated correct, but this what makes very hard impression is that there are much more choices in the menu config for the kernel compilation, and the new accessible options are not related with the i386 architecture, so I continue to think that some needed code from i386 architecture is locked wrong in the x86_64 architecture.
Comment 26 Stephane Bausson 2007-12-19 13:06:10 UTC
I have exactly the same issue with ACER 7720Z + linux-2.6.23.9 based on Mandriva 2008 x64. Fan work on old Fedora 6.
Comment 27 Ivo Sabev 2007-12-25 08:07:37 UTC
I have this issue onx86 architecture with acer aspire 5720.
After return from suspend to ram or disk the fan is not started.
The temperature in /proc/acpi/thermal_zone/TZ01/temperature is not updated no matter what is written in /proc/acpi/thermal_zone/TZ01/polling_frequency.

I am attaching outputs from:
lspci -vxxxx
dmidecode

and the kernel config

output from cat /proc/acpi/thermal_zone/TZ01/*
<setting not supported>
polling frequency:       1 seconds
state:                   ok
temperature:             75 C
critical (S5):           100 C

This output is after restart of the system, because it reached 80 degrees celsius after return from suspend to ram. I viewed it trough lm_sensors, which reports the temperature corectly:

sensors
coretemp-isa-0000
Adapter: ISA adapter
temp1:       +36°C  (high =  +100°C)

coretemp-isa-0001
Adapter: ISA adapter
temp1:       +35°C  (high =  +100°C)

Actually the problem is the same as descirbed by Radoslav in comment 22
Comment 28 Ivo Sabev 2007-12-25 08:10:44 UTC
Created attachment 14182 [details]
Ivo Sabev's files
Comment 29 federico 2008-01-03 14:19:04 UTC
I've the same hardware as above : acer 5720
I've tried gutsy 7.10 64bit and then 32bit there aren't differences.

federico@core2duo:~$ sudo cat /proc/acpi/thermal_zone/TZ01/*
<setting not supported>
polling frequency:       5 seconds
state:                   ok
temperature:             0 C
critical (S5):           100 C
federico@core2duo:~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Core 0:      +39°C  (high =   +85°C)                   

coretemp-isa-0001
Adapter: ISA adapter
Core 1:      +40°C  (high =   +85°C)                   

federico@core2duo:~$ sudo hddtemp /dev/sda
/dev/sda: Hitachi HTS541612J9SA00: 29°C
Comment 30 Len Brown 2008-01-06 22:37:37 UTC
If I read the comments above correctly...

32-bit Linux works perfectly
1. /proc/acpi/thermal_zone/.../temperature
   changes to reflect gross changes in system temperature
2. fan speed changes to reflect changes in system temperature
   
64-bit Linux fails:
   i) /proc/acpi/thermal_zone/.../temperature
      reflects boot-time temperature, but never changes
   ii) fan speed reflects boot-time demand for fan,
      but never changes.

As stated above, ACPI is not involved in fan control on this system.
Indeed, 64-bit Linux may have provoked the system firmware or EC
to fail somehow, and the ACPI temperature file above is simply
a victim of that, as is the firmware-controlled fan.

My first guess would be incompatibility with CONFIG_HWMON --
say a 64-bit bug in a sensor driver --
but it seems that CONFIG_HWMON=n does not help.

Please let me know if my summary is incorrect.
BTW. does the Acer BIOS have any SETUP options related to the fan
or thermal control?
Comment 31 Stephane Bausson 2008-01-07 01:23:55 UTC
I am giving partial answer, and will provide the complete answer later and let other people impacted by the issue confirm/complete the answer ...

- BIOS : In fact except Time and Date there is almost nothing you can parameter, so nothing related to fan and temperature control in BIOS 1.18

- 64 bits : No /proc/acpi/thermal_zone/.../temperature does not get updated and fan state never change : it stays OFF if T°C < limit at boot time and stay on if T°C > limit. 
Besides faking the temperature reported by acpi_thermal_get_temperature() does not change anything.

- CONFIG_HWMON : I confirm that disabling that flag does not change anything.
Comment 32 Ivo Sabev 2008-01-07 02:51:47 UTC
No, 32-bit Linux does not work corectly on my laptop.
About BIOS config - comment 31 is true. I am glad that Acer allowed date/time config in BIOS....
Comment 33 Stephane Bausson 2008-01-08 00:48:49 UTC
To complete my previous answer ...
For Linux 32bits, kernel 2.6.18.1:
    - /proc/acpi/thermal_zone/xxx/fan is empty
    - /proc/acpi/thermal_zone/xxx/temperature is updated
    - Fan is controled active/inactive depending temperature

If needed I can try with latest kernel compiled in 32bits.
Comment 34 Marco Calviani 2008-01-08 01:14:25 UTC
I would like to confirm what has been reported by Stephane on 32bit, using kernel 2.6.22 and 2.6.23. Fans are not controlled by userspace, but they are working correctly (automatically) when the CPU on-core temperature increase above 55C.
I confirm that with both those kernels 64bit linux version present the problem of the absence of temperature updating.

Regards
Comment 35 Davis Zanetti Cabral 2008-01-08 05:16:57 UTC
(In reply to comment #30)
> Please let me know if my summary is incorrect.
> BTW. does the Acer BIOS have any SETUP options related to the fan
> or thermal control?

No. BIOS only have options to boot order change, system date, ahci/ide modes and passwords.
Comment 36 Davis Zanetti Cabral 2008-01-08 05:42:52 UTC
(In reply to comment #34)
> I would like to confirm what has been reported by Stephane on 32bit, using
> kernel 2.6.22 and 2.6.23. Fans are not controlled by userspace, but they are
> working correctly (automatically) when the CPU on-core temperature increase
> above 55C.
> I confirm that with both those kernels 64bit linux version present the
> problem
> of the absence of temperature updating.

2.6.24-rc has this too.
But 2.6.19 works and thermal zone seems to be updated!
Comment 37 Len Brown 2008-01-08 22:14:56 UTC
So I think we have...

64-bit:
Latest kernel that works: 2.6.19 (comment #34)
Earliest kernel that fails: 2.6.22 (comment #1)

Can somebody narrow down the exact kernel where
this first broke on 64-bit machines?
It would be ideal if you can
locate the exact commit using git-bisect.

32-bit:
2.6.18 works (comment #33)
2.6.19 works (comment #6)
unknown kernel version fails for Ivo (comment #32)
   Ivo, can you post your dmesg
   and your .config for others to try?
2.6.22 works (comment #34)
2.6.23 works (comment #34)
   Marco, can you attach your working .config for Ivo to try?
Comment 38 Tommaso Falchi Delitala 2008-01-09 03:10:47 UTC
Created attachment 14378 [details]
Working .config for kernel 2.6.23 (gentoo-r3) 32bit
Comment 39 Davis Zanetti Cabral 2008-01-09 04:51:07 UTC
(In reply to comment #37)
> 64-bit:
> Latest kernel that works: 2.6.19 (comment #34)

2.6.19 of livecd of gentoo. But I think that be 32 bits. 
Because after installation yesterday the problem persisted and the machine overheat 3 times and turn off without fans work. TZ.temp show 0º.

Until now, only 32 bits works.
 
Whatever Windows Vista 32/64 bits works.
Comment 40 Marco Calviani 2008-01-09 05:16:02 UTC
Hi Len,
   i would like to confirm that fan/temp control is NOT working (at least on my machine) from/to kernel 2.6.18-2.6.23 64bit.
I'm attaching kernel config, but it should be similar to Tommaso's.

m
Comment 41 Marco Calviani 2008-01-09 05:17:46 UTC
Created attachment 14379 [details]
2.6.23-gentoo-r3 working kernel.

Working config for 2.6.23-gentoo-r3 (32bit). Apart from some addition it is the same to the one used in previous kernels.
Comment 42 Zhang Rui 2008-01-09 16:57:27 UTC
Could anybody try git-bisect to narrow down the problem on 64 bit please?
Comment 43 Stephane Bausson 2008-01-10 02:12:13 UTC
I think there is a confusion here, my understanding is that there is not any 64 bit linux kernel with which the fan is working properly.
If I am wrong please give the linux kernel version in 64 bits that is OK.
Comment 44 Marco Calviani 2008-01-10 02:22:22 UTC
Hi agree with Stephane. As far as i experienced no 64bit kernel is working.
Comment 45 Ivo Sabev 2008-01-11 03:02:08 UTC
My kernel version is 2.6.23.9
I am attaching the requested outputs + additional
Comment 46 Ivo Sabev 2008-01-11 03:02:46 UTC
Created attachment 14411 [details]
My kernel config
Comment 47 Ivo Sabev 2008-01-11 03:03:17 UTC
Created attachment 14412 [details]
dmesg, lspci, dmidecode outputs
Comment 48 Ben Vinnerd 2008-01-30 00:49:19 UTC
I also have this problem with my Acer Aspire 5720. 64bit linux. Have just upgraded BIOS to v1.21 and problem remains.
Comment 49 Moz 2008-02-04 13:48:24 UTC
I am using the 32 bit kernel 2.6.22-14-generic compiled by ubuntu on my Aspire 7720z with bios version 1.19 and are experiencing the same problem after a hibernate or suspend. Only on first boot the TZ1 temperature in /proc gets updated regularly but after suspend or hibernate the temperature get updated once on startup resulting in a fan that is always on max speed or worse overheating processors. Maybe it is unrelated but it seems pretty similar. Looking at the bios  dsdt code I find the ThermalZone _TMP method confusing ECON seems to be initialized but not set and DTSE seems to be initialized to 0x00 or are these registers updated directly by the hardware?
Comment 50 Tommaso Falchi Delitala 2008-02-12 02:50:30 UTC
BIOS v1.25 is out, but the problem remains.

In the features list of this update they claim to have:
"Remove brightness SCI event to avoid brightness control problem under Linux."
Maybe they are not completely blind to Linux users problems!Could we try to contact someone in Acer and try to explain the problem?
I think trying to go trough normal Customers Service is useless, we would need to contact someone in the tech department (or something like that)!
Comment 51 Ben Vinnerd 2008-02-12 03:19:44 UTC
Is it a linux problem, or an Acer one? Or both? I'm not sure myself. Does anyone know, or would like to hazard a guess?
Comment 52 Stephane Bausson 2008-02-28 14:26:50 UTC
New BIOS 1.29 is released on Acer site ...
We can see:   1). Update Tj85 cpu fan-table for Thermal request.

Maybe it could worth tring it but myself i can not since I only have linux on my PC and can not use Windows upgrade tool.

If somebody try let us know.
Comment 53 Davis Zanetti Cabral 2008-02-28 15:45:27 UTC
I updated BIOS now and the system overheated with 5 minutes of use.
No fan control and temp go up 85 degrees quickly. But the system isnt halted 
now, but I turn off when notice that fan isnt work.
After, when at the BIOS, fan works...

----- Original Message ----- 
From: <bugme-daemon@bugzilla.kernel.org>
To: <daviscabral@gmail.com>
Sent: Thursday, February 28, 2008 7:26 PM
Subject: [Bug 9167] No TZ.temp update, no fan control (64-bit only) - Acer 
Aspire 5720, 7720Z - Santa Rosa, T7300


> http://bugzilla.kernel.org/show_bug.cgi?id=9167
>
>
>
>
>
> ------- Comment #52 from sbausson@gmail.com  2008-02-28 14:26 -------
> New BIOS 1.29 is released on Acer site ...
> We can see:   1). Update Tj85 cpu fan-table for Thermal request.
>
> Maybe it could worth tring it but myself i can not since I only have linux 
> on
> my PC and can not use Windows upgrade tool.
>
> If somebody try let us know.
>
>
> -- 
> Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
> 
Comment 54 Zhang Rui 2008-02-28 22:21:10 UTC
does boot parameter "ec_intr=0" help?
Comment 55 Davis Zanetti Cabral 2008-02-29 05:22:47 UTC
Nops rui.
Here a video that show this:
http://www.youtube.com/watch?v=QX9t0u6-rfU

Thanks!
Comment 56 Stephane Bausson 2008-02-29 13:43:54 UTC
I filled a support ticket here (for EMEA) : http://support.acer-euro.com/request/index.html

Maybe it could worth if every body who wants this is issue being solved to fill this too to get more support from Acer on this.
Comment 57 Davis Zanetti Cabral 2008-03-05 09:20:51 UTC
some news????
Comment 58 Stephane Bausson 2008-03-06 00:53:56 UTC
Yesterday after an over heating shut down, my PC thermal/cooling control (on 64 kernel) was working fine. This is the first time I saw that. Temperature in /proc/acpi/thermal_zone/temperature was updated.
I do not know what to conclude with that. It looks there is something at init that make it work or not work properlly.
Comment 59 Tommaso Falchi Delitala 2008-03-06 01:18:05 UTC
Stephane, 
what do you mean by "Temperature in /proc/acpi/thermal_zone/temperature was updated"? Did it change continuously during use or was it just different from "0 C" after boot? Was fan properly controlled (started and stopped as needed) or was it just running all time?

In this second case there's no news: TZ is known to be correctly set to the real temp at boot. So if you reboot your machine when it is already hot, you will read something different from 0 C. But from then TZ is not updated anymore (so fan keeps running even if you CPU reaches 10 C).
Comment 60 Stephane Bausson 2008-03-06 01:24:56 UTC
- Value /proc/acpi/thermal_zone/temperature was going up and down as per real temperature (But by step of 5 °C, at least this was my feeling)
- Fan was controlled properly ... (SPEED 1 up to 55°C, SPEED2, up to 65°C, etc ...)
Comment 61 Davis Zanetti Cabral 2008-03-06 02:52:45 UTC
What did you do to this??? I need to use my notebook :((((
Comment 62 David Edwards 2008-03-15 08:09:28 UTC
I have a workaround that works for me, with x86_64 2.6.22-14-generic (Ubuntu Gutsy) and 2.6.24-12-generic (Ubuntu Hardy). Here is what I did.
1. I installed BIOS v1.31. I don't know if it is crucial, but the DSDT has been compiled with the Intel rather than the Microsoft compiler and the gibberish in _OSC has gone along with the myriad of warnings and errors in the earlier versions.
2. I turn the fan on by writing 0x4040 to 0x7F6BCEAF in /dev/mem
3. I turn the fan off by writing 0x2828 to 0x7F6BCEAF in /dev/mem
The bytes correspond to DTS1 and DTS2 in NVST (from reading the dis-assembled DSDT), the values from which the temperature in /proc/acpi/thermal_zone/TZ01/temperature are derived. I deduce that these locations are supposed to have the temperatures in C for the two CPU cores. Furthermore, since there are no other methods in the DSDT that reference them, I deduce that the Embedded Controller is supposed to update them. Since it must be able to do so in 32 bit mode, perhaps the 64 bit kernel prevents it?
Comment 63 David Edwards 2008-03-15 13:26:56 UTC
Further to comment #62, I find that after I have switched the fan on and off manually, the fan comes on and goes off on its own, and the temperature is updated automatically, although the granularity recorded appears to be 5 C.
Comment 64 Davis Zanetti Cabral 2008-03-17 07:09:19 UTC
How did you do this?
Thanks!
Comment 65 David Edwards 2008-03-17 13:35:45 UTC
Using a binary patch utility, something that takes as arguments the value that I want to write in (eg. x2828), the offset (x7F6BCEAF), and the file (/dev/mem). I use one I wrote myself, which I will cheerfully contribute if required, but there must be loads of things out there with enthusiastic developers supporting them to do this sort of thing!
Comment 66 Davis Zanetti Cabral 2008-03-17 18:47:39 UTC
I have the same system and BIOs that you.
Can you send me this?

Thanks.
Comment 67 Stephane Bausson 2008-03-18 15:19:56 UTC
I confirm that even with BIOS 1.18 + Linux 2.6.25-rc4 I can control the fan by writing into 0x7F6BCEAF:
0x40 to switch ON
0x28 to switch OFF

This is going to help in the meanwhile.
Comment 68 Davis Zanetti Cabral 2008-03-18 18:27:44 UTC
This works for me too.
Thanks David Edwards, you are the guy! :D
Comment 69 David Edwards 2008-03-19 02:59:49 UTC
Created attachment 15344 [details]
Archive containing Acer 5720 Fan Control Script + Binary Patcher 

This is the fix I sent to Davis Cabral. It is an archive containing a script and binary for controlling the CPU fan on an Acer 5720 or similar under a 64 bit Linux. Apologies in advance if this is considered an abuse of the Kernel Bug Tracker.

To use it:
-    Unpack with tar xjf acer5720_fan_64.tar.bz2
-    Adjust tunable parameters in acer5720_fancontrol.sh to your taste.

Copy mempat and acer5720_fancontrol.sh somewhere convenient, bearing in mind that acer5720_fancontrol.sh needs to find mempat in its PATH.

Arrange for acer5720_fancontrol.sh to be executed at start-up, eg. (as on my Ubuntu) kicking it off in the background from /etc/rc.local.

Hope this helps, no liability accepted for bringing about the end of the world etc. etc.
Comment 70 Jeffrey Hundstad 2008-03-25 20:57:15 UTC
BIOS question.  I see that the US site has v1.25 but it seems that the European site has v1.32.

First question: does anyone know if the European BIOS is OK with US machines?
Second question: does v1.32 fix the fan problem.
Comment 71 David Edwards 2008-03-26 11:57:08 UTC
My experience with BIOS v1.32 and Ubuntu Hardy (Kernel 2.6.24-12-generic x86_64) is as follows.
1. The DSDT is compiled with the Microsoft ASL compiler, and has all the errors that the v1.31 lacks. However, there is new code. I cleaned it up using the v1.31 source as a model.
2. When booted with ec_intr=0 (see comment 54), the fan is on all the time, at the slowest speed, even though the temperature in the thermal_zone is below the threshold. The fan didn't speed up, and the thermal_zone temperature was not updated, when I pushed the temperature higher by loading the CPU.
3. When booted without ec_intr=0, the fan stayed off, unless I turned it on (see comment 62).
4. When booted with ec_intr=0 and acpi_osi=!Linux, the fan stayed on all the time. However, the thermal_zone value temperature was updated, and the fan sped up, when I pushed the temperature higher by loading the CPU. When I took the load off, the temperature dropped, and the fan slowed down. However, the fan never stopped altogether.
5. By ear, I can detect 4 different fan speeds, which seem to come in to play at 50, 66, 74 and 80 C, when I set the temperature in thermal_zone manually. Someone with better hearing may be able to identify more!
6. Once the fan is running, shut-off temperatures are a few degrees lower, eg. 45.
Comment 72 Jeffrey Hundstad 2008-03-26 13:40:15 UTC
Bug as it was responded to by Acer America:

Customer (Jeffrey Hundstad) 	03/25/2008 11:21 PM 
I've installed Linux 64-bit. The fans do not start and the system gets hot rapidly. I am using BIOS v1.25. You can find out more at:
http://bugzilla.kernel.org/process_bug.cgi

- Is there a fix?
- Is it possible to flash to BIOS v1.32 available from the European website at http://support.acer-euro.com/drivers/notebook/as_5720.html ? Will that driver work with my model Aspire 5720Z? Will it fix the problem?

Customer (Jeffrey Hundstad) 	03/25/2008 11:25 PM 
The URL to find out more info was wrong above. Please use this instead:
http://bugzilla.kernel.org/show_bug.cgi?id=9167

Response (Hal) 	03/26/2008 01:46 PM 
Dear Jeffrey Hundstad,

Thank you for contacting Acer America. Acer America does not provide Linux drivers or support. I do not know of any plans to provide Linux drivers , BIOS updates or support in the future. You can try checking with the vendors of the internal components to see if they offer Linux drivers. I'm sorry I am unable to assist with this issue.

Customer (Jeffrey Hundstad) 	03/26/2008 02:17 PM 
You DO NOT plan on supplying BIOS updates for this machine anymore?
Really?

The second part of the question remains, does the BIOS v1.32 from Europe work with the American 5720?

Response (Hal) 	03/26/2008 02:36 PM 
Dear Jeffrey Hundstad,

Thank you for contacting Acer America. I apologize but I have checked the records and there are no available BIOS updates for the system. Also, Acer only supports the pre-installed hardware and software for the system so we do not have information if the BIOS v1.32 will work. If you prefer to download the BIOS update, please note that the original BIOS flash will not be available from Acer. You may download it at your own discretion. Acer will not be able to provide support if the BIOS update does not work properly.
Comment 73 Jeffrey Hundstad 2008-03-26 20:43:22 UTC
OK, first sorry for the noise; but obviously, I'm anxious to get my laptop working...

The status of this bug is "NEEDINFO".  What specifically are we waiting on?  I'm willing to help.
Comment 74 Jeffrey Hundstad 2008-03-26 22:00:04 UTC
BIOS v1.33 is available at http://support.acer-euro.com/drivers/notebook/as_5720.html
or
ftp://ftp.work.acer-euro.com/notebook/aspire_5720/vista/Bios/

File: v1.33.zip  	1401 KB  	03/26/2008  	02:54:00 PM

I have no idea if this will work for the American laptop.  But someone with the European model can sure try it.  There is no change log on this version.
Comment 75 Stefano Marinelli 2008-03-27 15:43:21 UTC
Acer Aspire 5715Z, Ubuntu Hardy Heron (beta) AMD64 version: same situation.
Thanks to David Edwards, I can now use my new laptop.
I've still that crappy Vista on a partition on my disk so I'm ready for any test.
Comment 76 David Edwards 2008-03-30 14:15:51 UTC
I have tried v1.33. DSDT is now again compiled with the Intel rather than Micro$oft ASL compiler; very few differences from the DSDT included in v1.32 other than those required to make the DSDT compliant with the specs. for such things. I haven't noticed any difference in behaviour; the system got very hot if I didn't run the fan control script, unless I booted with ec_intr=0. I personally think that this problem is a Linux x86_64 bug rather than an Acer bug, simply because 32-bit works, but US non-support not-withstanding, Acer are issuing new BIOS's about once a fortnight, so they wouldn't do that for no reason. Zhang Rhui, bug assignee, is there anything you would like us to do?
Comment 77 David Edwards 2008-03-31 19:36:06 UTC
Created attachment 15547 [details]
Updated Archive containing Acer 5720 Fan Control Script + Binary Patcher 

Improved version of previous Fan Control Script + Binary patcher. Unpack the archive using tar xjf, copy the files somewhere convenient, ensure mempat is accessible in the PATH, and run the script at boot, eg. from /etc/rc.local.

Another thought. Perhaps the temperature is recorded by SMM BIOS code, triggered by SMI Interrupts, and the 64 bit Linux inhibits these.
Comment 78 Stefano Marinelli 2008-03-31 23:47:47 UTC
Thank you David!
I'm going to install it immediately and update my blog with the new link (I've talked about it and put a link to your comment here).
Just one note: I had to comment the "exit 0" because sometimes, when working, tz_tmp may be equal to last_tmp and the script exits, leading to further overheating.
Thank you!
Comment 79 Anthony DeRobertis 2008-04-01 19:10:29 UTC
FYI, on a machine with 1GiB of memory, the address is x3F6BCEAF.
Comment 80 David Edwards 2008-04-11 06:12:25 UTC
Created attachment 15734 [details]
Updated Archive containing Acer 5720 Fan Control Script + Binary Patcher 

Added a 32 bit patching binary as well as a 64 bit binary, since I understand that 32-bit-only laptops are also affected.

Added more patch address values found by others.

Stopped the fan control script exiting just because the laptop has succeeded in updating the thermal zone value unaided, since it is reported that this does not mean that thermal control has really started to work properly.

Added a README.txt.

Unpack using tar xjf acer5720_fan_64.tar.bz2
Comment 81 Jeffrey Hundstad 2008-04-30 14:27:22 UTC
Can someone explain to me how with the Comment #80 attachment why this can not be fixed in the kernel?  It appears we know the problem and the fix.
Comment 82 Ben Vinnerd 2008-04-30 23:58:45 UTC
I don't do any work on the linux kernel myself, i'm merely a humble user like yourself :)

But, it's probably due to bigger priorities i guess.
Comment 83 Sur 2008-05-11 15:18:20 UTC
(In reply to comment #80)
> Created an attachment (id=15734) [details]
> Updated Archive containing Acer 5720 Fan Control Script + Binary Patcher 
> 
> Added a 32 bit patching binary as well as a 64 bit binary, since I understand
> that 32-bit-only laptops are also affected.
> 
> Added more patch address values found by others.
> 
> Stopped the fan control script exiting just because the laptop has succeeded
> in
> updating the thermal zone value unaided, since it is reported that this does
> not mean that thermal control has really started to work properly.
> 
> Added a README.txt.
> 
> Unpack using tar xjf acer5720_fan_64.tar.bz2
> 

Does this work with v1.34? I suppose NVST has changed. There's EDTS addition.
Comment 84 David Edwards 2008-05-12 07:42:51 UTC
(In reply to comment #83)

You would have to increment the address by 1 (ie. B0 rather than AF at the end).

However, on my machine, which is an Acer 5720 with 2GB, the combination of BIOS v. 1.34 with the Ubuntu Hardy 2.6.24-16-generic kernel, controls the fan without the assistance of any special boot flags, or the script.

I have suspended the thing to RAM, and I have hibernated it, and the fan has continued to work more or less as I would expect it to on each occasion that I have restarted.

So it looks as though BIOS v. 1.34 finally fixes it. Thankyou Acer!

The DSDT for v. 1.34 is compiled with the Micro$oft ASL compiler, and gives syntax errors with the Intel compiler. I fixed them on my system, but I don't think they matter, since the fan appeared to work before I had established that the DSDT wouldn't go through 'iasl'.
Comment 85 Sur 2008-05-12 08:27:20 UTC
(In reply to comment #84)
> 
> I have suspended the thing to RAM, and I have hibernated it, and the fan has
> continued to work more or less as I would expect it to on each occasion that
> I
> have restarted.
> 
> So it looks as though BIOS v. 1.34 finally fixes it. Thankyou Acer!

I have Aspire 5715z 2GB, and the fan never stops after return from standby.
Acpi thermal seems stuck @35C, coretemp goes way low like 4-5C per core.
Comment 86 David Edwards 2008-05-12 10:22:04 UTC
(In reply to comment #85)

Does the script (with the corrected address) help in this case?
Comment 87 Sur 2008-05-13 09:14:12 UTC
(In reply to comment #86)

The new address is correct, but the script is not usable because I observe a different behaviour now (I suppose it started with 1.3x series of BIOSes introducing WMI1 Device in DSDT):

My Aspire 5715z has 32-bit and 64-bit Hardy Heron, and Vista Home Basic installed. Regardless of cold boot or return from stanby of the said OSes (including Vista w/Acer's ePower thing running), I suffer overcooling.
Also, the following message that appeared in kern.log everytime fan was turned on/off has vanished (which, I suppose, is a Good Thing):
    APIC error on CPU0: 40(40)


The regular observation is fan starting @50C, and stopping @45C (TZ01/temp reading). 
However, sometimes it starts around 40-45C, albeit quieter than that @50C. TZ01/temp quickly drops to 40, then to 35. Coretemp readings go way lower.
At this point patching the value 2828 (or lower) no longer stops the fan, I have to patch a 50C (3232) first. Because, I suppose, the firmware to turn it off is not aware of an active fan triggered somewhere @40-45C, hence assumes the fan is off at 45C or lower.

I wonder why noone else complains about overcooling. Maybe it occurs with T2330 processor only. 
Note: setting polling_frequency had no effect so far.
Comment 88 David Edwards 2008-05-13 15:40:19 UTC
(In reply to comment #86)

The script could be adapted to your use case. Essentially, believing coretemp, and switching the fan on and off with two operations, high/low for off, and low/high for on, to make sure that the firmware obeys,
Comment 89 Jeffrey Hundstad 2008-05-26 08:43:57 UTC
> So it looks as though BIOS v. 1.34 finally fixes it. Thankyou Acer!

For my Aspire 5720-4126 "5720Z" the v. 1.34 BIOS seems to have my fans working as well.  No thermal shutdowns in days. ...lucky too, cause the last time I installed Linux -- I accidentally nuked Vista (sigh...)
Comment 90 Davis Zanetti Cabral 2008-05-26 08:54:14 UTC
With me, Acer 5720-6738, BIOS 1.34 solved the problem with fans.

But now, sometimes, the computer freezes on start up.
Screen stay black, but leds turned on. 

If I restart, he back to normal work.
Comment 91 David Edwards 2008-05-28 02:31:28 UTC
(In reply to comment #90)

I have seen this symptom with a different model of Acer (an old Travelmate 291), and obviously a different BIOS. For me, it started after I switched from the old Intel Graphics Driver (i810) to the new one. I don't think I have seen it on AC power. I didn't switch back because the new driver was obviously much faster ...
Comment 92 Tommaso Falchi Delitala 2008-06-13 04:53:30 UTC
I confirm new bios 1.40 (and maybe also 1.34... I didn't test) resolves the problem!Fan is correctly started and stopped! I propose to close the bug and mark it as resolved if no one objects!
Comment 93 Sur 2008-06-25 08:19:45 UTC
For the record, 
bios v1.40 seems to have resolved the allegedly overcooling issue I described previously. I don't get those ridiculously low temp. readings anymore.

Note You need to log in before you can comment on or make changes to this bug.