Talk:Problem with display remaining black after resume

2006-03-05T01:45:55Z

Robert-qfh:

== T43 with Intel Graphics Media Accelerator ==

My T43 (1871-FYG) with Intel 915GM is also affected by the problem and the 'ATI' sollution with
acpi_sleep=s3_bios works. Please consider updating the page (I don't dare to do it myself).

== From my experience, this does not work with TP R50e. ==

If you want to be able to resume, you need :
* To start from a VT
* No option acpi_sleep
* to save the PCI state like:
cat /proc/bus/pci/00/02.0 > /var/cache/video.config
* Once you get back, restore it:
cat /var/cache/video.config > /proc/bus/pci/00/02.0

However, the X screen is not clean after the restore, so this is not very useable...

== The comment on R50e ==

There is a comment at the end of the page on R50e, saying that you should switch to console first, and look at a page to learn how to do this.

However. it seems to me that the given script already does it. Should the comment be removed?
----
The scripts are different. However, if you can approve that the solution provided on this page resolves the problem, please remove the footnote.

[[User:Wyrfel|Wyrfel]] 14:46, 17 Oct 2005 (CEST)
----
On my R50e, the script on this page works fine, while the one linked in the footnote quickly wakes up from sleep.

[[User:Thisnukes4u|Thisnukes4u]] 19:39, 1 Jan 2006 (CET)

== Problems with R51 and Intel Graphics ==

The problems described on the page occur intermittently
with an Intel Graphics card on an R51. Here is what happens:

1. One some occassions everything seems to work fine.

2. On other occassions the screen looks OK but the some plane seems to have vanished. New text on the screen overwrites instead of replaces prior text. The "standard" pattern disappears from the X background.

3. On yet other occassions the X server dies and comes out "blank" in the mode (2) above.

4. The above problems appear only with the "i810" driver. The "vesa" driver works fine. Moreover, if the machine is "suspend-to-disk"ed then the problem disappears on resumption once the X server is killed and re-started.

But for 1 and 4 above I would have given up and either avoided suspend to ram altogether or used vesa mode---as it stands the problem is tantalising.

Kapil kapil at imsc dot res dot in

== X40 with an Intel 855GM Integrated Graphics Device ==

I used the {{bootparm|acpi_sleep|s3_bios}} boot parameter and the following ACPI script:

#!/bin/sh
set -e

vt=`fgconsole`
chvt 12
echo mem >/sys/power/state
vbetool post
chvt $vt

The {{bootparm|acpi_sleep|s3_bios}} boot parameter alone did not fix things, and neither did saving and restoring the information from {{path|/proc/bus/pci/00/02.0}}.

== X41 with an Intel 915GM Integrated Graphics Device ==

It works with the {{bootparm|acpi_sleep|s3_bios,s3_mode}} boot parameter. Resume works great, both on the VESA console and in X.

Talk:Problem with fan noise

2006-03-02T19:30:32Z

Robert-qfh: /* X41 */

== Problem with fan noise on R51 1829 L7G (ATI M9) ==

On my R51 the fan is behaving like this:

* > 45C -> fan on;
* < 38C -> fan off.

By using cpufreq + laptop_mode + Xorg DynamicClocks + WiFi power management, I get the fan stopped time to time, but only for 3 minutes time (transition from 38 C -> 45 C). The cooling down cycle is taking 20 minutes in the best case.

I knew about the 'ibm_acpi experimental=1' trick, but in my opinion this is not very useful since nobody can guarantee that a temperature greater then 45 C will not damage the laptop and in the same time the transition time is very short (the laptop gets hot fast without fan).

== Thinkpad T42 Radeon Mobility M7 ==

When Xorg is running, the fan is always on and pretty loud !
Setting DynamicClocks does not help

it's clear that the GPU is the problem on the thinkpad :

after 10minutes with the fan off
temperatures: 44 47 33 52 32 -128 24 -128

1: CPU
2: Mini PCI Module
3: HDD
4: GPU
5: Battery
6: N/A
7: Battery
8: N/A

Controlling the fan speed would be really cool !

What is the maximum temperature not to cross ?
----
Word on the 'net is that 85 degrees is the max operating temp for most of the Intel chips. I've seen some high 70's all the time (just put it on carpet for awhile and play some quake3 :). I wouldn't let your processor get much higher than 85...
----
"Word on the net" is usually synonym to bullshit. The datasheets are available for download at Intel's site, go read them. For the P4, 80C is the absolute maximum limit, and in the newer Pentiums, the chip itself will MCE and enable clock modulation if you try to make it exceed 80C. I didn't read the new Pentium-M's datasheet yet.

Letting the machine run hot is not a good idea, anyway. It shortens its lifespan considerably, especially the harddrive's. Don't play games with this.
----
Older versions of xorg (i.e. 6.7.0) don't seem to be able to use the DynamicClocks option although it's set in the xorg.conf. Search the log to find out if it's really used.

== Thinkpad R32 with Radeon Mobility M6 ==

Updating xorg-x11 from 6.7.0 to 6.8.2 and using Speedstep (with the ondemand module in this case) helped cooling the system down significantly:

* before updating the CPU was ~62 C in idle state, and got very near the critical temperature (72 C) during heavy load - I even got some freezes because of the heat ;)
* after the update the CPU is ~54 C in idle state, and still gets to about 68 C while under heavy load

The second sensor (which may be the GPU) is somehow fixed to 50 C (maybe a bug?)

The fan on the R32 is behaving like this:

* > 61 -> fan in state 2 (quite noisy)
* < 55 -> fan in state 1 (less noisy :) )

But I remember using my old SuSE distribution with kernel 2.4.16, apm and some old x11 version the fan actually stopped completely from time to time.

Concerning the maximum temperature of the CPU, I found that the critical temperature on the R32 for the CPU sensor is 72 C
(using {{cmdroot|cat /proc/acpi/thermal_zone/THM0/trip_points }} )

== Fan Control script: more safe version ==

ibm_acpi works well on my R50 and R51. But to rely on it completely, I modified the script in two ways:

1. It catches verious signals and turns the fan on before it quits

2. It turns off the fan under very strict conditions, leaving it on when unexpected errors occur.

Here is my script:

#!/bin/sh

# july 2005 Erik Groeneveld, erik@cq2.nl
# More conservatiev and saver version
# It make sure the fan is on in case of errors
# and only turns it off when all temps are ok.

IBM_ACPI=/proc/acpi/ibm
THERMOMETER=$IBM_ACPI/thermal
FAN=$IBM_ACPI/fan
MAXTRIPPOINT=65
MINTRIPPOINT=60
TRIPPOINT=$MINTRIPPOINT

echo fancontrol: Thermometer: $THERMOMETER, Fan: $FAN
echo fancontrol: Current `cat $THERMOMETER`
echo fancontrol: Controlling temperatures between $MINTRIPPOINT and $MAXTRIPPOINT degrees.

# Make sure the fan is turned on when the script crashes or is killed
trap "echo enable > $FAN; exit 0" HUP KILL INT ABRT STOP QUIT SEGV TERM

while [ 1 ];
do
command=enable
temperatures=`sed s/temperatures:// < $THERMOMETER`
result=
for temp in $temperatures
do
test $temp -le $TRIPPOINT && result=$result.Ok
done
if [ "$result" = ".Ok.Ok.Ok.Ok.Ok.Ok.Ok.Ok" ]; then
command=disable
TRIPPOINT=$MAXTRIPPOINT
else
command=enable
TRIPPOINT=$MINTRIPPOINT
fi
echo $command > $FAN
# Temperature ramps up quickly, so pick this not too large:
sleep 5
done

----
I added this script to the other ones. Don't wander about my talk edits, i didn't realize i was on the talk page. [[User:Wyrfel|Wyrfel]] 01:48, 13 Aug 2005 (CEST)
----

== X41 ==

Same fan problem here on the X41. Once it starts it won't stop (unless it is _very_ cold outside). Undervolting the CPU doesn't help - still the same problem.

On my machine this seems to be related to the third temperature in /proc/acpi/ibm/thermal. The fan will be started whenever this value climbs to 46 degrees. It won't be stopped once the value drops to 45, of course. But if you detach/attach AC supply, this somehow resets the control logic and the fan will stop if the value is <=45. Unfortunately, it will quickly increase to 46, and the fan will start again.

The threshold temperature for stopping the fan seems to be 41 degrees, but the fan running at its default speed of ~4500 will only keep it around 44-46.

It would be quite interesting to know where that sensor No. 3 is located on the X41.

--[[User:Robert-qfh|Robert-qfh]] 20:11, 02 Mar 2006 (CET)

== Fan speed control? ==

Only the X31 and X40 have an ACPI method for controlling the FAN speed (this is why ibm_acpi provides this functionality just for these models).

What will happen if we take the "FANS" method from the [http://acpi.sourceforge.net/dsdt/view.php?id=219 X40 DSDT], paste it into a iasl-disassembled DSDT of (say) a T43, recompile it and [http://gaugusch.at/kernel.shtml tell the kernel] to use the patched DSDT? ibm_acpi will present the functionality, but it may or may not work.

--[[User:Thinker|Thinker]] 16:16, 28 Sep 2005 (CEST)

Any risk of damaging the hardware when doing this? E.g. what does occur if the system overheats - will the CPU be destroyed are does it automatically switch of? As I've just bought a new X41 I don't want to take any stupid risks - but otherwise I'd say let's try it out.

--gst Thu Sep 29 18:14:13 CEST 2005

I think Intel CPUs have some built-in thermal protection, but I'd hate to test it. And of course, any fiddling with the hardware at this level might damage it. That said, when the CPU is mostly idle it keeps a reasonable temperature even when the fan is disabled, so as long as you keep an eye on both the CPU usage meter and /proc/acpi/ibm/thermal, things should be pretty safe temperature-wise. For extra safety you can force the CPU to its lowest speed via {{path|/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq}}.
--[[User:Thinker|Thinker]] 18:33, 29 Sep 2005 (CEST)

----

Anybody tried to slow down the fan and have it running at ~1000-1500rpm? That would make it almost silent and you could have it always running (like Apple does on Macs).

--[[User:Micampe|Micampe]] 12:56, 7 Dec 2005 (CET)
----

Goot question. The embedded controller [[patch_for_controlling_fan_speed|interface]] we have discovered allows only for setting a fan level between 0 and 7, not the actual RPM. And IBM has been ramping up the RPM assignment of each fan level (look at the model-specific data there), so that on the T43, even the lowest accessible level is at a pretty fast 3300RPM. The following ''might'' provide a way around this, if the hardware is capable of generating lower speeds:
* Patch the embedded controller firmware. You will need the information in [http://forum.thinkpads.com/viewtopic.php?p=113904#113904 this post] and the following one, a lot of patience, and an active warranty.
* Find out how the embedded controller is setting the speed (maybe by disassembling it as above, but at least you don't need to load patched firmware). Maybe the EC is changing the speed by instructing ''another'' component over an interface (SMBus?) that can also be accessed directly by the CPU. In this case, maybe you can put the embedded controller in disengaged mode and control that component directly.

Then, there's the soldering-iron approach. Assuming the fan uses the standard wiring and that its speed determined by the provided voltage, you can make all speeds somewhat slower simply by putting a resistor in series with the fan. You can do that by splicing one of the wires or, to avoid voiding your warranty, just build an extension cable like this:

fan cable extension
#------- Vfan --------#> >#---~~R~~---#> >#SYSTEM
FAN#------- SENSE -------#> >#-----------#> >#BOARD
#------- GND ---------#> >#-----------#> >#CONNECTOR

Use an appropriate resistor R, and make sure it doesn't get too hot (if it does, attach it to the fan's cooling assembly). Worked nicely for me a few years ago on some desktop motherboard. If you're into that kind of stuff, you can also use fancier electronics instead of the resistor to avoid the (minor) power waste.

It would be useful to have some pictures of the fan cable connector so we can get a matching pair (it's above the rear right corner of the PCMCIA slot, under the palmrest but maybe visible with just the keyboard removed).

--[[User:Thinker|Thinker]] 14:36, 7 Dec 2005 (CET)
----

== Further discussion ==

I've just found a very interesting thread regarding the same issue on HP notebooks. IMO it provides many insight information about heat/fan problems in general, the URL is: http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=853249
Especially the posts by the HP engineer "Andy Fisher" are very interesting. IBM should be able to provide the same BIOS fix as HP did (maybe I should have bought an HP notebook instead of a Thinkpad?).

I've also contacted IBM/Lenovo support via the website about the fan issue. Maybe it helps when others do this as well (especially people who bought larger quantities) so that this issue is taken serious by Lenovo. Is there already any official response to this problem?

--gst Thu Sep 29 19:40:34 CEST 2005
----

Two of the changes mentioned by the HP engineer make perfect sense here: raise the low trip points and make speed transition gradual. Oh, and get rid of the annoying beat pattern (a brief speed pulse every few seconds) it sometimes gets into!

But from our perspective, what would probably be best is to do the whole thing in software, providing the flexibility for personal preferences and smart decisions. The hardware would only enforce emergency override or throttle/shutdown for extreme temperatures. Then we could do cute things like having a software daemon lower the thresholds in a noisy environment (as judged using the built-in microphone) or when the laptop is on the user's lap (as judged by the built-in accelometers).

--[[User:Thinker|Thinker]] 18:47, 30 Sep 2005 (CEST)

I noticed that on my T43 the fan is usually in one of two modes, low speed (around 3300 RPM, triggered around CPU=47deg) and medium speed (around 4100 RPM, can't figure out the trip condition). The former is nearly inaudible, but the latter is quite noticable in the absense of strong background noises.

Now, the problem is that once it has tripped into medium speed, it usually never comes back to low speed until the next reboot. So once it happens, to quiet things down I can only run one of the fan-disabling scripts given here. But with a disabled fan the T43 is not thermally stable, so it will spend its time moving back and forth between the hysteresis thresholds, i.e., toggling between 4100 RPM and 0 RPM every few minutes. This is quite silly and annoying, when staying at low speed would be both more stable and more quiet.

I hope someone will find a way to control the fan speed, or at least to reset the embedded controller's hysteresis state.

--[[User:Thinker|Thinker]] 10:29, 6 Oct 2005 (CEST)

When you do changes to e.g. the Energy Schema in Windows or you eject the Thinkpad of the Docking Station it seems that the controllers state is rest. At least on the X41 the fan does stop until it reaches the threshold to start some minutes later. So it should be doable. --85.124.171.70

That's good. But just like a bunch of other functions (e.g., controlling the battery charge threshold), it probably uses low-level undocumented proprietary interfaces which are very hard to figure out without the help of IBM/Lenovo, who are in denial about the whole thing. --[[User:Thinker|Thinker]] 01:40, 16 Oct 2005 (CEST)

----

== Works fine with APM instead of ACPI? ==

On my X41 the fan starts after about 10 minutes of use and doesn't stop (until it is rather cold in my room - and even then it runs most of the time ;) A friend of mine who has a X41 too (though another model) and who does use NetBSD and APM doesn't experience this problem. He claims that the fan only comes up if the system is not idle. So either it is colder in his room, the X41 model which he has doesn't have this flaw or APM does use different tresholds than ACPI.

* Then why not just try the {{bootparm|acpi|off}} kernel parameter and see what happens? --[[User:Thinker|Thinker]] 18:14, 30 Sep 2005 (CEST)

I currently don't have physical access to the X41. Will try in a few days.

== Rewiring the fan? ==

Since IBM/Lenovo shows no intention of fixing their embedded controller firmware or releasing its specs, how about getting the embedded controller out of the loop? I'd be happy as a clam if my fan was hard-wired to work at a constant 3000RPM, with temperatures kept at bay in software through CPU frequenty control.

Assuming the fan has the standard 3-wire connector, we can probaby keep the sensor and ground wires untouched, and rewire the positive wire to some nearby current source of appropriate voltage (through a resistor, for fine-tuning). The trick would be to find an easily tappable source that can handle an extra 2W and has the appropriate voltage (i.e., just slightly higher than what the fan needs to rotate at that RPM, so we don't waste too much energy in the resistor). Any idea what are the typical fan voltages and what would be an appropriate hookup point?

--[[User:Thinker|Thinker]] 01:59, 16 Oct 2005 (CEST)
----

== Secret sensor and the cause of fan always on ==

This discussion was moved to [[Talk:Thermal sensors]].

== X21 overacceleration problem ==

On my X21 2662-66U, the fan runs all the time. That's not an issue, because of how hot my laptop runs.

However, at load, it runs really hot. I can hear the fan attempt to accelerate past the maximum speed, click three times, and drop back down to the max. It's not the same as the pulsing problem, yet similar.

New fan, ordered direct from IBM, due to my old fan running WAY too hot, even underclocked. As it is, I'm running underclocked because 95 C at full load is just NOT my cup of tea. 40 C idle temps at 500MHz, around 60 at 700MHz. 70 C load at 500, 95 C load at 700.

== Startup noise ==

My T43 accelerates the fan to very high speed twice during startup: immediately after power-on, and during the bootloader prompt (i.e., after the BIOS but before Linux loads). This is independent of the unit's temperature, and is loud enough to cause some ugly stares when sitting in a lecture. Is this a universal phenomenon, worth mentioning in the article page?

Potential solutions: the first fan acceleration can't be fixed by anything but an EC firmware update. For the second acceleration (after BIOS), a workaround can be implemented by adding basic fan control code (i.e., a few accesses to I/O ports 0x62 and 0x66 as explained in the [[Patch_for_controlling_fan_speed#Hardware_specs|fan control specs]] and Linux's {{path|drivers/acpi/ec.c}}) to the bootloader. GRUB 2 has a module infrastructure that should make this pretty easy, and other boot loaders can also be patched.

--[[User:Thinker|Thinker]] 20:36, 27 Dec 2005 (CET)
----

== Leftover bits ==

The following data didn't belong where it was posted, and was deleted when the containing section swre moved to [[How to control fan speed]]:

* On my T41 (gentoo-sources-2.6.11.11 ) I noticed that after unloading the fan module the fan noise stopped. With the module loaded the fan was working even at very low cpu temperatures, without the module it's ok so far.

* On a 770X the fan can be fully controlled through ACPI. Thermal Zone THM5 (possibly the battery/charging circuit, it's definitely warmer when using 5v PCMCIA cards and AC) triggers it to turn on and not ever off by design. Can be solved by a custom DSDT, which also makes use of the variable-speed features of the fan (will release this once I've finished tweaking and testing it).

--[[User:Thinker|Thinker]] 20:48, 20 January 2006 (CET)
----

== Embedded controller firmware disassembly ==

[http://forum.thinkpads.com/viewtopic.php?t=20958 This thread] points to, and discusses, a commented (partial) disassembly of the embedded controller. Following this lead, it may be possible to patch the firmware (perhaps transiently) to change the fan level selection algorithm and/or the RPMs.

--[[User:Thinker|Thinker]] 07:10, 24 February 2006 (CET)
----

== R50e with CELERON M: fan for life ==

I am such a loser. I bought a R50e with CELERON M CPU, and thus will
never get longer than 90 seconds of peace before the next 62 to 54
degree fan cycle. --jidanni

ThinkWiki - User contributions [en]

Talk:Problem with display remaining black after resume

Talk:Problem with fan noise