Bug 9167

Created attachment 13170 [details]
dmesg

dmesg log file

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.

Created attachment 13172 [details]
Content of files in /proc/acpi/thermal_zone/TZ01/

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.

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.

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

Created attachment 13176 [details]
Kernel config (standard) for KNOPPIX 5.1.1

Created attachment 13177 [details]
Kernel config (custom) for Gentoo Linux (x86_64)

(This configuration file has also been used for the vanilla kernel test)

For x86_64 kernel, could you please clear CONFIG_HWMON, recompile the kernel and try again? Hwmon conficts with ACPI themral/fan control sometimes.

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.

 

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.

Created attachment 13197 [details]
acpidump with original DSDT

... 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

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.

I can confirm that the behaviour is the same.

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.

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!

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!

Vista 64 bit works perfect, except one problem, after return from standby also forgots about the fan:). M$ - nothing can be done about it:)

Also as probable problem place I see boot.c at same location ...

Also as probable problem place I see boot.c at the same location ...

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. 

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!

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!

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.

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.

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

Created attachment 14182 [details]
Ivo Sabev's files

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

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?

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.

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....

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.

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

(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.

(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!

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?

Created attachment 14378 [details]
Working .config for kernel 2.6.23 (gentoo-r3) 32bit

(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.

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

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.

Could anybody try git-bisect to narrow down the problem on 64 bit please?

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.

Hi agree with Stephane. As far as i experienced no 64bit kernel is working.

My kernel version is 2.6.23.9
I am attaching the requested outputs + additional

Created attachment 14411 [details]
My kernel config

Created attachment 14412 [details]
dmesg, lspci, dmidecode outputs

I also have this problem with my Acer Aspire 5720. 64bit linux. Have just upgraded BIOS to v1.21 and problem remains.

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?

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)!

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?

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.

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.
> 

does boot parameter "ec_intr=0" help?

Nops rui.
Here a video that show this:
http://www.youtube.com/watch?v=QX9t0u6-rfU

Thanks!

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.

some news????

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.

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).

- 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 ...)

What did you do to this??? I need to use my notebook :((((

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?

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.

How did you do this?
Thanks!

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!

I have the same system and BIOs that you.
Can you send me this?

Thanks.

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.

This works for me too.
Thanks David Edwards, you are the guy! :D

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.

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.

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.

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.

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.

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.

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.

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?

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.

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!

FYI, on a machine with 1GiB of memory, the address is x3F6BCEAF.

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

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.

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.

(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.

(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'.

(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.

(In reply to comment #85)

Does the script (with the corrected address) help in this case?

(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.

(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,

> 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...)

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.

(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 ...

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!

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.