Bug 9754

Both suspend and hibernate show the same stopped-fan-on-resume symptom?
If that is true, it sounds more like we are restoring state when
the system doesn't want us to.

What happens on Windows when the platform-specific tool
is not present or disabled -- does the fan
behave the same way as on Linux?  What if the tool
is started only after the resume, does the system get better,
or is it necessary for it to be running before suspend?
How about if the tool is stopped after resume, does
the system continue to update temperature without it?
The more you can tell us about how the tool works
the better chance we have of figuring out exactly
why it is needed and what Linux can do about it.
 
Obviously it would be best if Acer supported Linux
running on this system, and provided the necessary
life-support to make the OS run.  But maybe we can
find out enough about how it works to make use
of this un-supported product...

Please attach the output from acpidump.
I'm wondering if there are WMI hooks in this box
that can be used to bring it to life.

I could just try with hibernate because of a bug when returning from suspend, but on the forum it was told that suspend was leading to the same problem.

I don't have any Windows on my computer so I can't test what occurs on Windows. I've asked on he Ubuntu forums for people that could do these checks and I'll give you the answers when I get them.

This behavior is clearly an ugly failure from Acer and not a hardware standard in any way. I really don't favor these choices but this laptop is really common because it's very cheap.

I attach the output of acpidump.

erratum: the tool is named ePower Management

Created attachment 14468 [details]
acpidump output on an Acer Aspire 5315

1) Can you test the current mainline kernel?

2) If the problem is still present in it, can you hibernate and pass "acpi=off" to the boot kernel (ie. the one used for loading the image) and see if that helps?

> Device (WMID) {
>    Name (_HID, "PNP0C14")

/me wonders if "ePower Management" uses these WMI hooks...

ACPI does not control the fans on the Acer 5315.
 There are no active cooling trip points under
 the _TZ/_TZ01 -- the only ACPI thermal zone on the system.
 And there are no PNP0C0B fan devices.

Re: the temperature reported by the ACPI thermal zone:

            Method (_TMP, 0, Serialized)
            {
                If (ECON)
                {
                    If (DTSE)
                    {
                        Store (DTS2, Local1)
                        If (LGreaterEqual (DTS1, DTS2))
                        {
                            Store (DTS1, Local1)
                        }

                        Store (Local1, \_SB.PCI0.LPC.EC0.SKTA)
                        Return (Add (0x0AAC, Multiply (Local1, 0x0A)))
                    }
                }

                Return (0x0BB8)
            }

if (!ECON) you would get a constant reading:
0xBB8 = 3000 -> 300.0K -> 27C
Hmmm, but you're seeing 55C after resume -- is that always
true no matter what temperature was upon suspend?

also, if !ECON, a lot of things in the DSDT would go away....
eg. does /proc/acpi/battery/*/* still make sense after resume?

Perhaps you are open to some debugging with a modified DSDT?
http://www.lesswatts.org/projects/acpi/overridingDSDT.php
Might be non-trivial, because past experience suggests
that nobody at Acer has ever run their ASL through
http://linuxfirmwarekit.org/ etc.

but first, perhaps you can poke some easy to turn knobs.
any difference booting with
acpi_osi=
or
acpi_osi="!Windows 2006"
(this may effect other things, such as HPET, or video display events)

BTW, here is yet another platform-specific item in this system
that Linux doesn't know about:

            Device (MIR)
            {
                Name (_HID, EisaId ("ENE0100"))

I have no idea what it is, but in Windows you'll see this device
on IRQ 4.

About the temperature of TZ01: it is not always at 55°C, I could also get 45 and 50. I believe (just a guess) the temperature is only got once at start since it is always inferior to the one I see when I launch the hibernation, even with my CPU working hard. I could get 55°C as the higher value (60°C is the max the fan accepts when it is working); I've never seen 27°C.

/proc/acpi/battery is always updated and sensical (for example the charge).

acpi_osi= and acpi_osi="!Windows 2006" did not have any effect (I gave these options to grub twice for each, once on the fresh boot and once when returning from hibernate, hope it is right).

Concerning custom DSDT, I'd rather not try that until we've done all needed checks (this computer is not mine and would take me too much time on it). Still if this is eventually the only thing to do, I'll be able to look into it. What tweaks should I use anyway?
As for linuxfirmware, do you want me to try it?

Again, I don't have Windows but I hope someone will answer me soon and I'll be able to give you these infos (eg about the IRQ 4 device).

I'll try the 2.6.24 kernel from Ubuntu Hardy when (and if) I can. Is that right?

Thanks for your help

Hi,

I have the same problem with the same hardware. I'm running Gentoo, so I think it is not distribution-related. The problem is still there with the 2.6.24 kernel.

I have something more: my acpi -V (launched in a shell) reports temperature, but it does not report battery status. I don't know how, but Gnome knows the battery charge. Before sleep/hibernate, this tool is accurate, but after it always gives the charge before sleeping/hibernating. So for me, the problem is the same with battery and temperature. Maybe !ECON...

The problem is really annoying and I'm quite motivated to resolve the problem, even if I have to hack 2 or 3 lines in the kernel. I'll give you some news if I find something...

(In reply to comment #6)
Hi,

> ACPI does not control the fans on the Acer 5315.
>  There are no active cooling trip points under
>  the _TZ/_TZ01 -- the only ACPI thermal zone on the system.
>  And there are no PNP0C0B fan devices.

I'm not sure to understand. There is no direct control of the fans by ACPI, but when I rmmod the ACPI thermal module, the fans keep the state before removing it (they stay on if they were on, off if they were off) whatever the real CPU temperature. So yes, there is no direct control of the fans, but without ACPI the fans don't work at all. Did I miss something?

> if (!ECON) you would get a constant reading:
> 0xBB8 = 3000 -> 300.0K -> 27C
> Hmmm, but you're seeing 55C after resume -- is that always
> true no matter what temperature was upon suspend?
> 
> also, if !ECON, a lot of things in the DSDT would go away....
> eg. does /proc/acpi/battery/*/* still make sense after resume?

I have a funny behaviour (hm... not really funny, just strange). Under 2.6.24, I use the new ACPI API, in /sys not in /proc. The file /sys/bus/acpi/drivers/battery/PNP0C0A:00/power_supply/BAT0/charge_now makes sense, before and after sleeping/hibernating. But the new API is labelled "*Future* power /sys interface" and everything is not finished: some features are still in /proc, for example thermal. /proc/acpi/thermal_zone/TZ01/temperature makes sense before sleeping/hibernating, but not after.

Maybe is the new ACPI API updating the infos after sleeping in /sys but not those in /proc. Maybe it's just a coincidence, because Milan seems to be using the old API and /proc/acpi/battery is updated.

Moreover, before or after sleeping, HAL is not updating my battery charge even if /sys/bus/.../battery/.../charge is updated. Gnome seems to use value, because it does not update the charge neither. If I restart HAL, the charge is updated once but never updated after. It seems to be a HAL bug, but... At least, I answered the questions I asked in #8.

Well, I'm not pessimistic but it seems to be a complex problem... If anyone needs informations, I'm ready to test, report or compile anything useful, just ask.

Thanks...

Nice to find another person with the same bug and willing to solve it. ;-) Your install can be helpful to perform tests... Maybe if you have Windows, you could try the checks about ePower Manager that I could not do.

Little news for you!

I tried two options when booting the kernel:
 -noapic does not seem to change anything,
 -nolapic disables my keyboard/mice :).

I tried this because I've found something: dmesg gives me a line often repeated:
APIC error on CPU0: 40(40)

First I thought this line was added randomly, but I finally found that it happens when the temperature given by the ACPI thermal_zone changes! Since the fans use this value, it is easy to detect: when the fans status changes, a new line appears.

Is APIC involved in our problem?

I'm trying to understand the ACPI sources, but I'm not the best kernel hacker of the universe... Something tells me that the solution is the /usr/src/linux/drivers/acpi/sleep directory and is connected to interrupts. ACPI is well known for keeping USB or Ethernet ports down after sleeping, so...

If anyone is interested, I would be glad to have your dmesg before and after sleeping, to see if the APIC error happens for everyone.

If anyone has Windows installed, it would be great too to discover what this famous "Empowering management" does. We could directly ask Acer, but I'm not sure they would give us any clue :p.

Perhaps the Acer ePower software is switching the processor fan to an ON state before suspend/hibernate, in which case the BIOS or some other preboot process is picking up and thus allowing it to function correctly.

For what it's worth, When running ePower software(an earlier revision... 1.64/1.65(?) under windows XP and rebooting/hibernating/suspending/shutdown sometimes turns the WIFI(perhaps only the radio transmitter) device off(ar5007eg) and you will need to hit the wifi button on the keypad to reactivate it.. however trying this in Linux will not reactivate it - you will need to boot into xp/ enable then pull the battery/get lucky with the power button and have it not do it.. BUT without the epower software installed in XP the wifi device wont switch to an off state when shutting down - suggesting that the epower software is infact changing some hardware level/firmware level registers switching certain channels on/off

It would make sense to switch the wifi radio off to save power in suspend/hibernate mode(these are elevated stages of the power management mode are they not? - eg the laptop is not 100.00000% shut down) - maybe the fan is disabled for the same reason

Hi,

Good news! There is an interesting line in the last (1.25) BIOS for Acer 5315 : "update new solution for Penryn CPU.(Processor May Unexpectedly Assert False THERMTRIP# After Receiving a Warm Reset)".

Bad news! It does not work with me, the problem is still there...

If you feel lucky, try and give us your experience...

I see the same issue for Aser Aspire 5720G.

P.S. It looks like bug 9167 "No TZ.temp update, no fan control (64-bit only) - Acer Aspire 5720, 7720Z - Santa Rosa, T7300" is somehow related to the issue.

(In reply to comment #14)
> I see the same issue for Aser Aspire 5720G.
> 
> P.S. It looks like bug 9167 "No TZ.temp update, no fan control (64-bit only)
> -
> Acer Aspire 5720, 7720Z - Santa Rosa, T7300" is somehow related to the issue.
> 

It seems to be related, but the bug with the 5315 is not 64-bit only. The bug appears even with Windows XP/Vista if the ACER tools are not installed. The problem seems to come from a non-standard hardware and is NOT a bug in the 64-bit linux kernel.

I tried to hack some code in the ACPI module, I tried to update my BIOS, I tried to play with the DSTD. No luck...

*sigh*

Reply-To: lida.21.84@hotmail.com

I have exactly the same problem on Acer Aspire 5720.
Sensors are not updated. In my case sensors are not updated even when i  just start the laptop. Seems the sensors are updated once at boot time. Then they show always the same temp.
Ex cat temperature
Always  40 degree
any solution for that<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=koi8-r">
<META content="MSHTML 6.00.2900.3243" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>I have exactly the same problem on Acer Aspire 
5720.</FONT></DIV>
<DIV><FONT face=Arial size=2>Sensors are not updated. In my case sensors are not 
updated even when i&nbsp; just start the laptop. Seems the sensors are updated 
once at boot time. Then&nbsp;they show always the same temp.</FONT></DIV>
<DIV><FONT face=Arial size=2>Ex cat temperature</FONT></DIV>
<DIV><FONT face=Arial size=2>Always</FONT>&nbsp;<FONT face=Arial size=2> 40 
degree</FONT></DIV>
<DIV><FONT face=Arial size=2>any solution for that</FONT></DIV></BODY></HTML>

Hi,

i have posted some info here:

http://ubuntuforums.org/showpost.php?p=4305576&postcount=69

It seems that the are different versions of 5315, on 5315-050508Mi, on 64-bit the sensor is either not updated at all or after a while, but 32-bit somewhat works (at least, it doesn't shut down, but suspend doesn't work at all)

Has anyone contacted the lm-sensors developers? The sensor doesn't seem to be recognized by lm-sensors-detect although the southbridge is supported.

Also, if anyone has some information on DSDT fixing, please post it. Although, i doubt we'll be able to fix the warnings without help from Intel engineers (i read somewhere that some of them are subscribed the Linux-ACPI mailing list)

Perhaps the old "exposing ACPI objects in sysfs" patch might help us? It might be possible to switch the fan on manually.
  

A notebook behaves the same way under Vista without ePower Management software installed. It looks like ePower software does only some WMI work. Tracing IRP flow (with the tools like IRP Traker) can show what it actually does. Also there is a file "acpimof.mof" with a list of WMI requests that are used (as I think).

From the user point of view ePower sofware just sets CPU throttling, LCD brightness and Wireless/Bluetooth power state.

Maybe that can help.

New BIOS (1.29a), README has lines such as :
 * Update Tj85 cpu fan-table for Thermal request.
 * Update new Thermal Control Table.
As usual, it seems good. As usual, it does not change anything (at least for me -- Aspire 5315 32bit).

No news from the ubuntu forum for a long time (http://ubuntuforums.org/showthread.php?t=604158).

Can anyone (Stanislav?) try tracing the ePower activity and give us some cluesthe results? Does anyone know an ACER-tweaked-CPUs-specialist-Intel-engineer? Is anybody crazy enough to fix the DSDT?

Thanks...

I spent two or three hours playing with the DSDT, thanks to http://gentoo-wiki.com/HOWTO_Fix_Common_ACPI_Problems. Here is what I've tried and understood:

The thermal zone stuff is done by the code in Scope(_TZ).

The Method(_TMP) updates the temperature given by "acpi -t" and the temperature used to control the fan.

Modifying the value in "Return(Add (0x0AAC, Multiply (Local1, 0x0A)))" changes the value given by "acpi -t" but it doesn't change the fan behaviour -> this value is just for display purpose. I tried to change it by "Return(Add (0x0AAC, Multiply (Local1, 0x0D)))" and nothing changed but the "acpi -t" value.

Commenting "Store (Local1, \_SB.PCI0.LPC.EC0.SKTA)" make the fan always on after booting, and always off after sleep/hibernate -> this value is used to control the fan and is changed before sleep/hibernate.

The battery charge is updated after sleep/hibernate. The code updating this value seems to be in Method(_BIF) in Device(BAT0). So I tried to copy the code in Method(_TMP) into Method(_BIF). It works before sleep/hibernate but not after.

The value Local1 is a simple combination of registers DST1 and DST2, that must be two "hardware temperature sensors". I think that Method(_TMP) is still called after sleep/hibernate, and so that Local1 is still stored. So, the problem is, as far as I can understand, that DST1 and DST2 are not updated after sleep/hibernate. These values are only used in Method(_TMP), so the code that updates them is not in the DSDT.

If you need more, just ask!

Hello,
I'm using an Acer Aspire 5315-101G08Mi (BIOS version 1.23), with an Intel Celeron 540 (32 bits) and have experienced the same problems: the fan does not start when resumed from hibernation, leading to overheat.

After trying some random solutions, I found that adding "noapic nolapic acpi_osi=!Linux" to the kernel parameters solves the problem completely, with no keyboard/mouse problems. Moreover, there aren't APIC errors anymore.

I hope this will be useful for you.

Reply-To: juga@miljakovac.co.yu

 

 

 

 

 

                                                                          

 


------------------------------------- 
Ova Poruka je skenirana i nema VIRUSE
Skenirano sa MailScanner
www.miljakovac.co.yu
-------------------------------------

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-AU link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

</body>

<br />------------------------------------------- 
<br />Ova Poruka je skenirana i nema VIRUSE
<br />Skenirano sa <a href="http://www.mailscanner.info/"><b>MailScanner</b></a>
<br /><a href="http://www.miljakovac.co.yu/">www.miljakovac.co.yu</a>
</html>

Hi,
sorry for the delay,
by reading the acpidump attached,
the ACPI fan control is not available, and the ACPI thermal control is useless on this laptop.
So "cat /proc/acpi/thermal_zone/TZ01/temperature always returns 55°C" has no effects to this problem.

Will you please _CLEAR_ CONFIG_ACPI_THERMAL, set CONFIG_HWMON and see if there is any difference? 
And as someone mentioned that even windows XP/Vista has the same problem without some ACER tools, I think this is rather a platform specific problem that we can not fix in ACPI genenric code. Maybe a acer platform driver is needed to make the fan/thermal work correctly, just like the thinkpad_acpi, asus_laptop, sony_laptop etc.

(In reply to comment #23)
> Hi,
> sorry for the delay,
> by reading the acpidump attached,
> the ACPI fan control is not available, and the ACPI thermal control is
> useless
> on this laptop.
> So "cat /proc/acpi/thermal_zone/TZ01/temperature always returns 55°C" has no
> effects to this problem.
> 
> Will you please _CLEAR_ CONFIG_ACPI_THERMAL, set CONFIG_HWMON and see if
> there
> is any difference? 
> And as someone mentioned that even windows XP/Vista has the same problem
> without some ACER tools, I think this is rather a platform specific problem
> that we can not fix in ACPI genenric code. Maybe a acer platform driver is
> needed to make the fan/thermal work correctly, just like the thinkpad_acpi,
> asus_laptop, sony_laptop etc.
> 

http://ubuntuforums.org/showpost.php?p=4702613&postcount=108 - there is a hack for this, but non-official, non-opensource. Read the thread about David Edward's patch: http://bugzilla.kernel.org/show_bug.cgi?id=9167
He made a version that works in 32bit environment, I use that.

Aspire 9813WKMi
On cold boot fan stop ~1-2 seconds after Grub and after that start(~54°C) and stop(~42°C) OK. After suspend to ram fan spin full speed all the time.

After boot:
TZ00 = 42°C (fan off) or 54°C (fan on).
TZ01 = 41...51°C.

After suspend:
TZ00 = 27°C.
TZ01 = ~35...40°C.

acpi_osi="!Windows 2006|Windows 2001 SP2|Windows 2001 SP2|Windows 2001 SP1|Windows 2001" no effect.

Does not effect if CONFIG_ACPI_THERMAL or CONFIG_ACPI_FAN is set or not.

Workaround

Original DSDT > http://aceracpi.googlecode.com/svn/trunk/dsdt/acer/aspire/9810.dsl

Normalize behavior of fan on cold boot and wakeup:
Store (0x46, SMIF)
Store (0x00, TRP0)
But in _WAK is:
If (LAnd (DTSE, MPEN))
and that is not true.

--- a/dsdt.dsl
+++ b/dsdt.dsl
@@ -462,11 +462,11 @@
         Store (0x00, PO80)
         If (LEqual (Arg0, 0x03))
         {
-            If (LAnd (DTSE, MPEN))
-            {
+            // If (LAnd (DTSE, MPEN))
+            // {
                 Store (0x46, SMIF)
                 Store (0x00, TRP0)
-            }
+            // }
         }
 
         If (LOr (LEqual (Arg0, 0x03), LEqual (Arg0, 0x04)))

But if the temperature falls below 40°C before wakeup:
TZ00 > 65°C.
TZ01 = ~35-40°C.
and fan spin full speed.
If TZ01 now reaches 54-degree temperature:
TZ00 is the same as after boot (42°C or 54°C).
Fan behaviour will be normal.

EmbeddedController
acer_ec.pl > http://aceracpi.googlecode.com/svn/trunk/acer_ec/acer_ec.pl

# ./acer_ec.pl ?= 9C		same as TZ01.
# ./acer_ec.pl ?= CE		NVIDIA ambient temperature (maybe).
# ./acer_ec.pl ?= 9F		NVIDIA critical temperature (108°C).
# ./acer_ec.pl := 9F 0x00	immediately shutdown (S5).
# ./acer_ec.pl := CE 0x6c	immediately shutdown (S5).
# ./acer_ec.pl := 9C 0x6d	immediately shutdown (S5).

Apparently, Acer has released a BIOS update that should solve this problem. I have not tested myself, though. See ftp://ftp.support.acer-euro.com/notebook/aspire_5315/vista/Bios/

Is it still necessary to work on this?

The BIOS updates work for me (and for everybody using a 5315, according to some forums) and I need no more grub options. I think that this bug could be closed safely.

good news.
close this bug.

please re-open it if the problem still exists with the latest BIOS.

La casella email kastel88@email.it non è più controllata. Si prega di reinviare a dc.kastel@gmail.com

Mailbox kastel88@email.it isn't used anymore. Please resend messages to dc.kastel@gmail.com