ThinkWiki - User contributions [en]

Talk:Ipw3945

2007-11-16T15:10:38Z

Trogdor282:

* [[Kubuntu Feisty]]
** I can only get the adapter to make one wireless connection per boot. If I get kicked off wireless or I try to change AP's I have to reboot. The restricted IPW driver tends to destabalize the system. The IWL driver is much more stable but still has the same connection problem. Any thoughts?? Lenovo R61i.

--[[User:Trogdor282|Trogdor282]] 15:10, 16 November 2007 (UTC)

* [[Ubuntu]]
** [quote]Works out of the box in edgy. Requires restricted repository.[/quote]
Are you sure? I installed Networkmanager (from main - I have a WPA enabled router) and WiFi worked immediately. No need for any additional tasks.

--[[User:Ro|Ro]] 08:37, 7 December 2006 (CET)

* [[Ubuntu]]
** With Edgy, all you have to do is install the linux-restricted-modules-generic package.
It works out-of the box in edgy (on a {{Z61m}}) without the need to install any additional packages, so I changed this info.

--[[User:Ro|Ro]] 17:19, 27 November 2006 (CET)

*{{Ubuntu}}
** Ubuntu Dapper has already built in this drivers; it works out from the box.

Ubuntu (neither Dapper nor Edgy) have the ipw3945 drivers, so I've deleted the info.
--[[User:Zhenech|Zhenech]] 15:19, 27 September 2006 (CEST)

According to this:
http://www.digitalvampire.org/blog/articles/2006/09/29/ubuntu-edgy-eft-on-a-thinkpad-x60s-how-to-make-ipw3945-work

All you have to do is to install the linux-restricted-modules-generic package. I've tested this using Edgy - it worked out of the box on a T60.

Talk:How to make use of Dynamic Frequency Scaling

2007-09-28T16:03:27Z

Trogdor282:

== Sleep kills second CPU (sorry for the bump) ==

I have an R61i, and when I resume from sleep the second CPU is disabled. Kubuntu Feisty (with Gutsy kernel) Any ideas?

<tt>root@lappy:/# echo 1 > /sys/devices/system/cpu/cpu1/online
bash: echo: write error: Invalid argument
1</tt>

== CPUfreq "stuck" ==
Using the "acpi-cpufreq" and "processor" modules, I can use the performance and ondemand governor with great success on a T43, and it switches between 2.1 GHz and ~700 MHz without incident. However, sometimes the processor becomes "stuck" at ~700 MHz, and when I switch to the performance governor "cat /proc/cpuinfo" notes it is still at ~700 MHz.

I have not been able to precisely reproduce these conditions, but they have happened several times. It is cured by a reboot. I'm not running any userspace frequency governers. Anybody else experienced this peculiar behavior? [[User:gsmenden|gsmenden]] 11:20, 10 JAN 2006 (CEST)

----

I had something similar on my T43. It seems that BIOS interfers with cpufreqd's operation. In the end I set BIOS to "maximum performance" when the laptop is on AC, and let cpufreqd keep track of the speed. It seems to work for me (T43, 2669, 2.6.15-kernel)

----
Verfied for my T43. Article amended.
----
Note that this problem seems to disappear completely when using the speedstep-centrino module instead of acpi-cpufreq in a T43p. [[User:gsmenden|gsmenden]] 21:24 2 MAR 2006 (EST)
----
On T60p with Core 2 Duo 2Gz CPU gets "stuck" at the lowest possible setting (1Gz) after mache wakes up from sleep (standby). I have tried all possible options but nothing seems to be working right now.

== CPU Speedstep management activation ==
I could not find the "processor" and "acpi-cpufreq" modules, thus leading to an empty /sys/devices/system/cpu/cpu0/ and preventing to set cpu throttling.
I found the speedstep-centrino module which enables the feature.
Environment : X41 (Pentium M), Debian Sid with custom 2.6.12 kernel.
Is the Debian part of the article outdated ?
Hope this helps,
Vincent

== speedstep-smi for T22 ==
I had to use the speedstep-smi driver for my T22, not the speedstep-ich driver as stated in the how-to.
Thomas
----
Yes, it was a mistake. Thanks for the note. [[User:Wyrfel|Wyrfel]] 21:49, 27 Oct 2005 (CEST)
----

== Extremely low freq on a T22 ==

About an hour ago I made Speedstep work on a T22 running Ubuntu Breezy (5.10). Before that I had the machine randomly boot at 700MHz or 900MHz. That is nothing special. But, earlier today, when I booted it, it was running at 187MHz, according to both /proc/cpuinfo and Gnome's CPU frequency applet. It also took about 4 times as long to do some CPU-intensive processing than usually (grepping and sorting a known amount of text), so I'm still thinking that my Thinkpad really was running at 187MHz until I rebooted it.

Has anyone else noticed anything like this? Is there a way to replicate this behavior? Is there a way to "enable" this "step"?

-- _sd
----
Yes, i brought my X20 down to similarly low frequencies also with Ubuntu. I think it's possible through ACPI throttling, but I'm not sure if that was actually how i did it.

[[User:Wyrfel|Wyrfel]] 23:51, 9 Jan 2006 (CET)
----
This is a BIOS problem. Disable any Powermanagment in BIOS, else it will boot with lower frequencies if your on battery or any other reason if didnt figure out.
ACPI-Throttling does not change the frequency (read mhz) but something else.
echo 4:0 >/proc/acpi/processor/CPU/throttling
This will not change the mhz but will make it slower. I didnt understand how to make any use of it as it does not give more battery.

[[User:nusse|nusse]] Tue Mar 21 06:26:31 CET 2006

== Obsolete daemons ==
Removed the note about daemons being obsolete. Using ondemand/conservate is *not* a replacement for daemons, they are generally smarter than a fixed governor and can adapt to different situations better.
----
I reinserted the note, but changed it a little. The point about that note is that most users get good results and less confusion with those two governors. Feel free to extend the section by some remarks about why one might want to use a deamon instead.

[[User:Wyrfel|Wyrfel]] 10:40, 16 January 2006 (CET)
----
Elaborated a bit on it.

--[[User:Earthwings|Earthwings]] 23:15, 17 January 2006 (CET)
----
Thx, reads good.

[[User:Wyrfel|Wyrfel]] 23:25, 17 January 2006 (CET)
----

== Throttling useless? ==

I just removed the following comment:

:==A note about CPU throttling==
:On a modern CPU, throttling is useless, even it can increase power consumption instead of decreasing it. By forcing the CPU to sleep using throttling the CPU will reach a state higher as C2 less often. On a T43 it is a difference of more then 100mW.

I don't know what counts as a "modern CPU" but my desktop Athlon 64 3000+ 768 and my laptop 1.1GHz Pentium M both run *much* cooler at low frequencies than at high frequencies; it is just indisputable that they are using considerably less energy when throttled than before. So I think the above statement needs to be at the very least clarified before it goes into the main article. [[User:Ciphergoth|Ciphergoth]] 11:06, 20 June 2006 (CEST)

----

You seem to be very confused about this issue. CPU throttling does '''not''' change the clock, as it has nothing to do with clock speed. I will readd the comment, with some extra explanations to avoid the confusion. Downclocking a CPU will '''definately''' cause it to consume less power, that's the whole point of the governors.

--[[User:Hmh|hmh]] 03:48, 27 October 2006 (CEST)

== Turn off one Core (Core Duo on T60, Debian SID) ==

Is it possible to disable one core of the dual core processor? --[[User:Matsch|Matsch]] 23:36, 18 January 2007 (CET)

Yes. If you have CONFIG_HOTPLUG_CPU=y, CONFIG_HOTPLUG=y, CONFIG_ACPI_HOTPLUG_CPU=y in kernel config. You can disable the second CPU with this command: echo 0 > /sys/devices/system/cpu/cpu1/online and enable it with echo 1 > /sys/devices/system/cpu/cpu1/online.

What the above commentator said is correct. However when I played with this on my T60p w/ T7600 core2 duo, both core thermal sensors reported an increase in temperature even with the machine idle. Re-enabling the second core eventually reduced the overall temperature of the processor. I didn't measure to see if there was any decrease in watts consumed.

:Disabling one core with the suggested method makes the remaining core jump to 99-100% usage constantly without any other processes actually consuming more cpu. this is really strange and could explain the above observation. (Debian Linux 2.6.22-2-686 #1 SMP). --[[User:Matsch|Matsch]] 21:33, 25 September 2007 (UTC)

----

Related question: I have an R61i and when I resume from sleep the second CPU is disabled. I tried enabling it manually:

<tt>root@lappy:/# echo 1 > /sys/devices/system/cpu/cpu1/online
bash: echo: write error: Invalid argument
1</tt>

I haven't checked the temps but it definitely drains my battery faster with one cpu disabled, which would support the above observation.--[[User:Trogdor282|Trogdor282]] 16:56, 9 September 2007 (UTC)

== BIOS powersave disable/enable ==

This is for those who, like me, had earlier read that disabling powersave in the BIOS was a good thing. That worked on a stock Debian kernel 2.6.18-4-686. Doing this with the latest and greatest 2.6.22-1-686 made the entire cpufreq interface in /sys/devices/system/cpu/cpu0(1) disappear. (Re-) enabling the powersave in the BIOS solved this. Note: Thinkpad Z61m

--[[User:Gijs|Gijs]] 09:30, 17 August 2007 (CEST)

Talk:How to make use of Dynamic Frequency Scaling

2007-09-09T16:58:28Z

Trogdor282: /* Turn off one Core (Core Duo on T60, Debian SID) */

== CPUfreq "stuck" ==
Using the "acpi-cpufreq" and "processor" modules, I can use the performance and ondemand governor with great success on a T43, and it switches between 2.1 GHz and ~700 MHz without incident. However, sometimes the processor becomes "stuck" at ~700 MHz, and when I switch to the performance governor "cat /proc/cpuinfo" notes it is still at ~700 MHz.

I have not been able to precisely reproduce these conditions, but they have happened several times. It is cured by a reboot. I'm not running any userspace frequency governers. Anybody else experienced this peculiar behavior? [[User:gsmenden|gsmenden]] 11:20, 10 JAN 2006 (CEST)

----

I had something similar on my T43. It seems that BIOS interfers with cpufreqd's operation. In the end I set BIOS to "maximum performance" when the laptop is on AC, and let cpufreqd keep track of the speed. It seems to work for me (T43, 2669, 2.6.15-kernel)

----
Verfied for my T43. Article amended.
----
Note that this problem seems to disappear completely when using the speedstep-centrino module instead of acpi-cpufreq in a T43p. [[User:gsmenden|gsmenden]] 21:24 2 MAR 2006 (EST)

== CPU Speedstep management activation ==
I could not find the "processor" and "acpi-cpufreq" modules, thus leading to an empty /sys/devices/system/cpu/cpu0/ and preventing to set cpu throttling.
I found the speedstep-centrino module which enables the feature.
Environment : X41 (Pentium M), Debian Sid with custom 2.6.12 kernel.
Is the Debian part of the article outdated ?
Hope this helps,
Vincent

== speedstep-smi for T22 ==
I had to use the speedstep-smi driver for my T22, not the speedstep-ich driver as stated in the how-to.
Thomas
----
Yes, it was a mistake. Thanks for the note. [[User:Wyrfel|Wyrfel]] 21:49, 27 Oct 2005 (CEST)
----

== Extremely low freq on a T22 ==

About an hour ago I made Speedstep work on a T22 running Ubuntu Breezy (5.10). Before that I had the machine randomly boot at 700MHz or 900MHz. That is nothing special. But, earlier today, when I booted it, it was running at 187MHz, according to both /proc/cpuinfo and Gnome's CPU frequency applet. It also took about 4 times as long to do some CPU-intensive processing than usually (grepping and sorting a known amount of text), so I'm still thinking that my Thinkpad really was running at 187MHz until I rebooted it.

Has anyone else noticed anything like this? Is there a way to replicate this behavior? Is there a way to "enable" this "step"?

-- _sd
----
Yes, i brought my X20 down to similarly low frequencies also with Ubuntu. I think it's possible through ACPI throttling, but I'm not sure if that was actually how i did it.

[[User:Wyrfel|Wyrfel]] 23:51, 9 Jan 2006 (CET)
----
This is a BIOS problem. Disable any Powermanagment in BIOS, else it will boot with lower frequencies if your on battery or any other reason if didnt figure out.
ACPI-Throttling does not change the frequency (read mhz) but something else.
echo 4:0 >/proc/acpi/processor/CPU/throttling
This will not change the mhz but will make it slower. I didnt understand how to make any use of it as it does not give more battery.

[[User:nusse|nusse]] Tue Mar 21 06:26:31 CET 2006

== Obsolete daemons ==
Removed the note about daemons being obsolete. Using ondemand/conservate is *not* a replacement for daemons, they are generally smarter than a fixed governor and can adapt to different situations better.
----
I reinserted the note, but changed it a little. The point about that note is that most users get good results and less confusion with those two governors. Feel free to extend the section by some remarks about why one might want to use a deamon instead.

[[User:Wyrfel|Wyrfel]] 10:40, 16 January 2006 (CET)
----
Elaborated a bit on it.

--[[User:Earthwings|Earthwings]] 23:15, 17 January 2006 (CET)
----
Thx, reads good.

[[User:Wyrfel|Wyrfel]] 23:25, 17 January 2006 (CET)
----

== Throttling useless? ==

I just removed the following comment:

:==A note about CPU throttling==
:On a modern CPU, throttling is useless, even it can increase power consumption instead of decreasing it. By forcing the CPU to sleep using throttling the CPU will reach a state higher as C2 less often. On a T43 it is a difference of more then 100mW.

I don't know what counts as a "modern CPU" but my desktop Athlon 64 3000+ 768 and my laptop 1.1GHz Pentium M both run *much* cooler at low frequencies than at high frequencies; it is just indisputable that they are using considerably less energy when throttled than before. So I think the above statement needs to be at the very least clarified before it goes into the main article. [[User:Ciphergoth|Ciphergoth]] 11:06, 20 June 2006 (CEST)

----

You seem to be very confused about this issue. CPU throttling does '''not''' change the clock, as it has nothing to do with clock speed. I will readd the comment, with some extra explanations to avoid the confusion. Downclocking a CPU will '''definately''' cause it to consume less power, that's the whole point of the governors.

--[[User:Hmh|hmh]] 03:48, 27 October 2006 (CEST)

== Turn off one Core (Core Duo on T60, Debian SID) ==

Is it possible to disable one core of the dual core processor? --[[User:Matsch|Matsch]] 23:36, 18 January 2007 (CET)

Yes. If you have CONFIG_HOTPLUG_CPU=y, CONFIG_HOTPLUG=y, CONFIG_ACPI_HOTPLUG_CPU=y in kernel config. You can disable the second CPU with this command: echo 0 > /sys/devices/system/cpu/cpu1/online and enable it with echo 1 > /sys/devices/system/cpu/cpu1/online.

What the above commentator said is correct. However when I played with this on my T60p w/ T7600 core2 duo, both core thermal sensors reported an increase in temperature even with the machine idle. Re-enabling the second core eventually reduced the overall temperature of the processor. I didn't measure to see if there was any decrease in watts consumed.

----

Related question: I have an R61i and when I resume from sleep the second CPU is disabled. I tried enabling it manually:

<tt>root@lappy:/# echo 1 > /sys/devices/system/cpu/cpu1/online
bash: echo: write error: Invalid argument
1</tt>

I haven't checked the temps but it definitely drains my battery faster with one cpu disabled, which would support the above observation.--[[User:Trogdor282|Trogdor282]] 16:56, 9 September 2007 (UTC)

== BIOS powersave disable/enable ==

This is for those who, like me, had earlier read that disabling powersave in the BIOS was a good thing. That worked on a stock Debian kernel 2.6.18-4-686. Doing this with the latest and greatest 2.6.22-1-686 made the entire cpufreq interface in /sys/devices/system/cpu/cpu0(1) disappear. (Re-) enabling the powersave in the BIOS solved this. Note: Thinkpad Z61m

--[[User:Gijs|Gijs]] 09:30, 17 August 2007 (CEST)

Talk:How to make use of Dynamic Frequency Scaling

2007-09-09T16:56:09Z

Trogdor282: /* Turn off one Core (Core Duo on T60, Debian SID) */

== CPUfreq "stuck" ==
Using the "acpi-cpufreq" and "processor" modules, I can use the performance and ondemand governor with great success on a T43, and it switches between 2.1 GHz and ~700 MHz without incident. However, sometimes the processor becomes "stuck" at ~700 MHz, and when I switch to the performance governor "cat /proc/cpuinfo" notes it is still at ~700 MHz.

I have not been able to precisely reproduce these conditions, but they have happened several times. It is cured by a reboot. I'm not running any userspace frequency governers. Anybody else experienced this peculiar behavior? [[User:gsmenden|gsmenden]] 11:20, 10 JAN 2006 (CEST)

----

I had something similar on my T43. It seems that BIOS interfers with cpufreqd's operation. In the end I set BIOS to "maximum performance" when the laptop is on AC, and let cpufreqd keep track of the speed. It seems to work for me (T43, 2669, 2.6.15-kernel)

----
Verfied for my T43. Article amended.
----
Note that this problem seems to disappear completely when using the speedstep-centrino module instead of acpi-cpufreq in a T43p. [[User:gsmenden|gsmenden]] 21:24 2 MAR 2006 (EST)

== CPU Speedstep management activation ==
I could not find the "processor" and "acpi-cpufreq" modules, thus leading to an empty /sys/devices/system/cpu/cpu0/ and preventing to set cpu throttling.
I found the speedstep-centrino module which enables the feature.
Environment : X41 (Pentium M), Debian Sid with custom 2.6.12 kernel.
Is the Debian part of the article outdated ?
Hope this helps,
Vincent

== speedstep-smi for T22 ==
I had to use the speedstep-smi driver for my T22, not the speedstep-ich driver as stated in the how-to.
Thomas
----
Yes, it was a mistake. Thanks for the note. [[User:Wyrfel|Wyrfel]] 21:49, 27 Oct 2005 (CEST)
----

== Extremely low freq on a T22 ==

About an hour ago I made Speedstep work on a T22 running Ubuntu Breezy (5.10). Before that I had the machine randomly boot at 700MHz or 900MHz. That is nothing special. But, earlier today, when I booted it, it was running at 187MHz, according to both /proc/cpuinfo and Gnome's CPU frequency applet. It also took about 4 times as long to do some CPU-intensive processing than usually (grepping and sorting a known amount of text), so I'm still thinking that my Thinkpad really was running at 187MHz until I rebooted it.

Has anyone else noticed anything like this? Is there a way to replicate this behavior? Is there a way to "enable" this "step"?

-- _sd
----
Yes, i brought my X20 down to similarly low frequencies also with Ubuntu. I think it's possible through ACPI throttling, but I'm not sure if that was actually how i did it.

[[User:Wyrfel|Wyrfel]] 23:51, 9 Jan 2006 (CET)
----
This is a BIOS problem. Disable any Powermanagment in BIOS, else it will boot with lower frequencies if your on battery or any other reason if didnt figure out.
ACPI-Throttling does not change the frequency (read mhz) but something else.
echo 4:0 >/proc/acpi/processor/CPU/throttling
This will not change the mhz but will make it slower. I didnt understand how to make any use of it as it does not give more battery.

[[User:nusse|nusse]] Tue Mar 21 06:26:31 CET 2006

== Obsolete daemons ==
Removed the note about daemons being obsolete. Using ondemand/conservate is *not* a replacement for daemons, they are generally smarter than a fixed governor and can adapt to different situations better.
----
I reinserted the note, but changed it a little. The point about that note is that most users get good results and less confusion with those two governors. Feel free to extend the section by some remarks about why one might want to use a deamon instead.

[[User:Wyrfel|Wyrfel]] 10:40, 16 January 2006 (CET)
----
Elaborated a bit on it.

--[[User:Earthwings|Earthwings]] 23:15, 17 January 2006 (CET)
----
Thx, reads good.

[[User:Wyrfel|Wyrfel]] 23:25, 17 January 2006 (CET)
----

== Throttling useless? ==

I just removed the following comment:

:==A note about CPU throttling==
:On a modern CPU, throttling is useless, even it can increase power consumption instead of decreasing it. By forcing the CPU to sleep using throttling the CPU will reach a state higher as C2 less often. On a T43 it is a difference of more then 100mW.

I don't know what counts as a "modern CPU" but my desktop Athlon 64 3000+ 768 and my laptop 1.1GHz Pentium M both run *much* cooler at low frequencies than at high frequencies; it is just indisputable that they are using considerably less energy when throttled than before. So I think the above statement needs to be at the very least clarified before it goes into the main article. [[User:Ciphergoth|Ciphergoth]] 11:06, 20 June 2006 (CEST)

----

You seem to be very confused about this issue. CPU throttling does '''not''' change the clock, as it has nothing to do with clock speed. I will readd the comment, with some extra explanations to avoid the confusion. Downclocking a CPU will '''definately''' cause it to consume less power, that's the whole point of the governors.

--[[User:Hmh|hmh]] 03:48, 27 October 2006 (CEST)

== Turn off one Core (Core Duo on T60, Debian SID) ==

Is it possible to disable one core of the dual core processor? --[[User:Matsch|Matsch]] 23:36, 18 January 2007 (CET)

Yes. If you have CONFIG_HOTPLUG_CPU=y, CONFIG_HOTPLUG=y, CONFIG_ACPI_HOTPLUG_CPU=y in kernel config. You can disable the second CPU with this command: echo 0 > /sys/devices/system/cpu/cpu1/online and enable it with echo 1 > /sys/devices/system/cpu/cpu1/online.

What the above commentator said is correct. However when I played with this on my T60p w/ T7600 core2 duo, both core thermal sensors reported an increase in temperature even with the machine idle. Re-enabling the second core eventually reduced the overall temperature of the processor. I didn't measure to see if there was any decrease in watts consumed.

Related question: I have an R61i and when I resume from sleep the second CPU is disabled. I tried enabling it manually:

<tt>root@lappy:/# echo 1 > /sys/devices/system/cpu/cpu1/online
bash: echo: write error: Invalid argument
1</tt>

I haven't checked the temps but it definitely drains my battery faster with one cpu disabled, which would support the above observation.--[[User:Trogdor282|Trogdor282]] 16:56, 9 September 2007 (UTC)

== BIOS powersave disable/enable ==

This is for those who, like me, had earlier read that disabling powersave in the BIOS was a good thing. That worked on a stock Debian kernel 2.6.18-4-686. Doing this with the latest and greatest 2.6.22-1-686 made the entire cpufreq interface in /sys/devices/system/cpu/cpu0(1) disappear. (Re-) enabling the powersave in the BIOS solved this. Note: Thinkpad Z61m

--[[User:Gijs|Gijs]] 09:30, 17 August 2007 (CEST)

Problem with display remaining black after resume

2007-09-09T16:42:10Z

Trogdor282: /* Solutions */

There has been a problem encountered where the display stays black on resuming from suspend.

The symptom might have you think first that your system hang up, but you will realize that your ThinkPad works and you can even reset it via {{key|Ctrl}}{{key|Alt}}{{key|Del}}.

==Affected Models==
*ThinkPad {{T41p}}, {{T42}}, {{T42p}}, {{T43}}, {{T43p}}, {{T60}}, {{T60p}}
*Thinkpad {{T23}}
*ThinkPad {{X21}}, {{X30}}, {{X31}}, {{X40}}, {{X41}}
*ThinkPad {{R31}}, {{R50e}}{{footnote|1}}, {{R50p}}, {{R51}} (with BIOS 1.11), {{R52}}, {{R60}}, {{R61}}
*ThinkPad {{A30p}}
*ThinkPad {{390X}} (doesn't wake up; LCD backlight on, harddrive light remains on)
*ThinkPad {{Z60t}}, {{Z60m}}, {{Z61m}}, {{Z61e}}
*ThinkPad {{X60s}}, {{X60}}

==Affected Operating Systems==
*Linux (it's a kernel issue)
*FreeBSD (6.x at least)

==Solutions==
===Quick workaround for R61i, maybe others===
Try pressing CTRL+ALT+F1 to switch to text console. The backlight should come on normally. Press CTRL+ALT+F7 to return to X.
===Semi-Solution for ThinkPad X60 with damaged system after s2ram usage===
It happend when restarting a s2ram-session.

'''Symptom:''' Black screen with blinking "_" sign remaind. (without the ")

'''System status:''' HDD idle, fan running, everything else looks to wait for something to happen.

'''Semi-Solution:''' Booting with DVD-ROM and going through the installations menu,
where you choose "other" and "boot a installed system" (something like that). Gladly it works,
and OpenSuSE 10.1 comes up with 50% "failed" messages! I than shutdown properly, rebooted again
and had 100% "done" again, with no other things affected.

'''Further:''' Repairing with the DVD-ROM crashed massivly(!), so I selected "boot a installed system" as final
solution and it worked!

'''Unknown:''' Maybe the Solution for ThinkPads with 1400x1050 internal LCD and Intel 915GM will help,
because X60s and X60 are very familiar. (Not tested so far.)

(If this Problem is not right here, please edit and move.)

===Solution for ThinkPads with 1400x1050 internal LCD and Intel 915GM ===
see [[1400x1050 on Intel 915GM]].
===Solution for ThinkPads with ATI graphic chips and Intel 915/945GM ===

Affected models include {{X60s}}, {{R60}} and {{T60}}.

This soluton also applies to T42 with Intel 855 and ATI 9600 M10.

One solution may be to provide the {{bootparm|acpi_sleep|s3_bios}} kernel parameter in your kernel parameter line.

For grub this would look like this:

title Linux, kernel 2.6.11-1-686
root (hd0,0)
kernel /boot/vmlinuz-2.6.11-1-686 root=/dev/hda1 ro acpi_sleep=s3_bios
initrd /boot/initrd.img-2.6.11-1-686
savedefault
boot

For lilo it would look like this:

image=/boot/vmlinuz
append="acpi_sleep=s3_bios"

The actual process of going to sleep is then managed through a sleep script; as a start, see the {{path|sleep.sh}} script in the Extreme Graphics 2 section below, but note the following comments:

In [[:Category:OpenSUSE|OpenSUSE]] 10.1 (at least on a T43p), it's necessary to override the default options for s2ram if you're using the newer ATI driver. This can be done putting {{bootparm|SUSPEND2RAM_FORCE|"yes"}} and {{bootparm|SUSPEND2RAM_ACPI_SLEEP|"3"}} in {{path|/etc/powersave/sleep}}.

In {{Ubuntu}} or {{Kubuntu}}, it may be necessary to modify {{path|/etc/default/acpi-support}}. In that file, make sure that {{path|ACPI_SLEEP}} is uncommented and set to true. With ATI chips, also make sure that {{path|SAVE_VBE_STATE}} is uncommented and set to true; with Intel chips, on the other hand, ensure that nothing is done with respect to VBE--no reposts, no state saves. Also commenting POST_VIDEO may help.

In {{Fedora}}, it may be necessary with the Intel chips to edit the {{path|resume_video()}} function in {{path|/etc/pm/functions-intel}} to comment out the VBE post and restore. (As of FC6 these seem to be pre-commented out.) Also, the laptop, after waking up, may go back to sleep immediately or whenever the AC adapter is disconnected. When this happens, it's caused by a bug in the HAL daemon that incorrectly reports certain ACPI events. This is a known problem and a simple workaround is described [http://live.gnome.org/GnomePowerManager/Faq#head-b8b1280115b0a51c2cc27b13a57121130ebf36cb here].

{{NOTE|It is possible this method will not work if the laptop is docked. It is also possible that the cited workaround for the HAL daemon bug will not work on some machines. A kludgier workaround in this event is to kill the HAL daemon on suspend. This necessitates the resuscitation of GPM upon resume.}}

Another solution is to use vbetool. If you are using {{Debian}} with the hibernate package, uncomment "EnableVbetool yes" in {{path|/etc/hibernate/hibernate.conf}} (or {{path|/etc/hibernate/ram.conf}}).

----

On '''T60 2007-CTO''' (Core2Duo 2Ghz, 2GB Ram, ATI X1400) the screen stayed blank after suspend-to-ram until I set '''vga=0''' in lilo.conf.

Working config:
Linux 2.6.21.5
fglrx 8.37.6
debian etch:
powersaved 0.14.0-5:
UNLOAD_MODULES_BEFORE_SUSPEND2DISK="usb_storage ohci_hcd uhci_hcd ehci_hcd ipw3945 pcmcia yenta_socket rsrc_nonstatic pcmcia_core"
UNLOAD_MODULES_BEFORE_SUSPEND2RAM="usb_storage ohci_hcd uhci_hcd ehci_hcd ipw3945 pcmcia yenta_socket rsrc_nonstatic pcmcia_core"
hibernate:
SwitchToTextMode yes
lilo.conf:
vga=0

"EnableVbetool yes" and other suggestions didn't work for me.

For suspend-to-disk, don't load fglrx in initrd.

----

===Solution for ThinkPads with Intel Extreme Graphics 2===
{{NOTE|
On [[:Category:X40|X40]]s/[[:Category:X41|X41]]s - even with Intel Extreme Graphics - and for [[:Category:R52|R52]]s with Intel Graphics Media Accelerator 900 the [[Problem with display remaining black after resume#Solution for ThinkPads with ATI graphic chips|solution for ATI graphics chips]] above is reported to work. In this case, make sure no changes to VBE are made, especially no state saves and no reposts.}}

The following solution should work on 865G, 865GV, 855GM, 855GME, 852GME chipsets.
*First of all, '''do not''' use the {{bootparm|acpi_sleep|s3_bios}} kernel parameter.
*Second, completely remove framebuffer support from your kernel. If it's built as modules, it is important that they do not get loaded at all.
*Before suspending, change to a console and safe the video state with {{cmdroot|cat /proc/bus/pci/00/02.0 > /tmp/video_state}}.
*On resume, restore the video state with {{cmdroot|cat /tmp/video_state > /proc/bus/pci/00/02.0}} and change back to X.
*For Debian Etch 4.0 on R50e just make following changes to /etc/default/acpi-support:
#SAVE_VBE_STATE=true
#VBESTATE=/var/lib/acpi-support/vbestate
#POST_VIDEO=true
SAVE_VIDEO_PCI_STATE=true

*For a R50e the only thing needed to make suspend to ram work in Ubuntu 6.06 is adding
Option "VBERestore" "yes"
to the <tt>Device</tt> section in your {{path|/etc/X11/xorg.conf}}, and the example script below.

The following example {{path|/etc/acpi/actions/sleep.sh}} script shows how to integrate the according lines.

#!/bin/bash

# change to console 1
FGCONSOLE=`fgconsole`
chvt 6

# safe video state
cat /proc/bus/pci/00/02.0 > /tmp/video_state

# sync filesystem
sync

# sync hardware clock with system time
hwclock --systohc

# go to sleep
echo -n 3 > /proc/acpi/sleep

# waking up
# restore system clock
hwclock --hctosys

# restore video state
cat /tmp/video_state > /proc/bus/pci/00/02.0

# change back to X
chvt $FGCONSOLE

# clean up behind us
rm /tmp/video_state

With Ubuntu 6.10 on a [[:Category:R51|R51 (2887-32G)]] I ''just'' (as none of the other tricks above) had to add {{bootparm|fb|false}} to the kernel line in {{path|/etc/grub/menu.lst}} and edit {{path|/etc/defaults/acpi-support}} this way:

SAVE_VBE_STATE=false
POST_VIDEO=false
SAVE_VIDEO_PCI_STATE=true
USE_DPMS=false
DOUBLE_CONSOLE_SWITCH=false

===Solution for ThinkPads with Intel I830 Chipset===
The following solution worked for me on an X30 with I830M chipset with kernel >= 2.6.16.
*this works with vesafb and also with intelfb frambuffer support.
The following example {{path|/etc/acpi/actions/sleep.sh}} script shows how to integrate the according lines.

#!/bin/bash

FGCONSOLE=`fgconsole`
chvt 8
sync
hwclock --systohc

echo -n "mem" > /sys/power/state

hwclock --hctosys
vbetool post

if [ "$FGCONSOLE" -ge "7" ] ; then
chvt $FGCONSOLE
else
chvt 7
chvt $FGCONSOLE
fi
===Solution for ThinkPads with ATI graphic (and possibly other) chips and FreeBSD===

The FreeBSD acpi(4) manpage mentions a tunable parameter, "hw.acpi.reset_video":

hw.acpi.reset_video
Reset the video adapter from real mode during the resume path.
Some systems need this help, others have display problems if it
is enabled. Default is 0 (disabled).

This tunable can be set by adding the following line to your FreeBSD machine's /boot/loader.conf file:

hw.acpi.reset_video="1"

And rebooting your machine. Hopefully, the next time you resume from a suspend, you'll see your video again. This solution doesn't appear to be specific to ATI hardware in any way, so I presume it would be helpful for video chipsets other than ATI, as well.

If this entry doesn't help you, you might consider searching in the [http://lists.freebsd.org/pipermail/freebsd-mobile/ FreeBSD-Mobile email-list archive] for more insight.

{{footnotes|
#If you have this problem with R50e and the above solution doesn't work, try switching to console first. An example sleep script can be found [[How to configure acpid|here]].
}}

===Solution using s2ram for Intel 915/945GM===

Just using the "s2ram -f -p" command from the uswsusp package will work from within X, at least on a {{Z61e}}. On {{X60s}} it is enough to issue the "s2ram" command and it works.

Problem with display remaining black after resume

2007-09-09T16:39:30Z

Trogdor282: /* Affected Models */

There has been a problem encountered where the display stays black on resuming from suspend.

The symptom might have you think first that your system hang up, but you will realize that your ThinkPad works and you can even reset it via {{key|Ctrl}}{{key|Alt}}{{key|Del}}.

==Affected Models==
*ThinkPad {{T41p}}, {{T42}}, {{T42p}}, {{T43}}, {{T43p}}, {{T60}}, {{T60p}}
*Thinkpad {{T23}}
*ThinkPad {{X21}}, {{X30}}, {{X31}}, {{X40}}, {{X41}}
*ThinkPad {{R31}}, {{R50e}}{{footnote|1}}, {{R50p}}, {{R51}} (with BIOS 1.11), {{R52}}, {{R60}}, {{R61}}
*ThinkPad {{A30p}}
*ThinkPad {{390X}} (doesn't wake up; LCD backlight on, harddrive light remains on)
*ThinkPad {{Z60t}}, {{Z60m}}, {{Z61m}}, {{Z61e}}
*ThinkPad {{X60s}}, {{X60}}

==Affected Operating Systems==
*Linux (it's a kernel issue)
*FreeBSD (6.x at least)

==Solutions==
===Semi-Solution for ThinkPad X60 with damaged system after s2ram usage===
It happend when restarting a s2ram-session.

'''Symptom:''' Black screen with blinking "_" sign remaind. (without the ")

'''System status:''' HDD idle, fan running, everything else looks to wait for something to happen.

'''Semi-Solution:''' Booting with DVD-ROM and going through the installations menu,
where you choose "other" and "boot a installed system" (something like that). Gladly it works,
and OpenSuSE 10.1 comes up with 50% "failed" messages! I than shutdown properly, rebooted again
and had 100% "done" again, with no other things affected.

'''Further:''' Repairing with the DVD-ROM crashed massivly(!), so I selected "boot a installed system" as final
solution and it worked!

'''Unknown:''' Maybe the Solution for ThinkPads with 1400x1050 internal LCD and Intel 915GM will help,
because X60s and X60 are very familiar. (Not tested so far.)

(If this Problem is not right here, please edit and move.)

===Solution for ThinkPads with 1400x1050 internal LCD and Intel 915GM ===
see [[1400x1050 on Intel 915GM]].
===Solution for ThinkPads with ATI graphic chips and Intel 915/945GM ===

Affected models include {{X60s}}, {{R60}} and {{T60}}.

This soluton also applies to T42 with Intel 855 and ATI 9600 M10.

One solution may be to provide the {{bootparm|acpi_sleep|s3_bios}} kernel parameter in your kernel parameter line.

For grub this would look like this:

title Linux, kernel 2.6.11-1-686
root (hd0,0)
kernel /boot/vmlinuz-2.6.11-1-686 root=/dev/hda1 ro acpi_sleep=s3_bios
initrd /boot/initrd.img-2.6.11-1-686
savedefault
boot

For lilo it would look like this:

image=/boot/vmlinuz
append="acpi_sleep=s3_bios"

The actual process of going to sleep is then managed through a sleep script; as a start, see the {{path|sleep.sh}} script in the Extreme Graphics 2 section below, but note the following comments:

In [[:Category:OpenSUSE|OpenSUSE]] 10.1 (at least on a T43p), it's necessary to override the default options for s2ram if you're using the newer ATI driver. This can be done putting {{bootparm|SUSPEND2RAM_FORCE|"yes"}} and {{bootparm|SUSPEND2RAM_ACPI_SLEEP|"3"}} in {{path|/etc/powersave/sleep}}.

In {{Ubuntu}} or {{Kubuntu}}, it may be necessary to modify {{path|/etc/default/acpi-support}}. In that file, make sure that {{path|ACPI_SLEEP}} is uncommented and set to true. With ATI chips, also make sure that {{path|SAVE_VBE_STATE}} is uncommented and set to true; with Intel chips, on the other hand, ensure that nothing is done with respect to VBE--no reposts, no state saves. Also commenting POST_VIDEO may help.

In {{Fedora}}, it may be necessary with the Intel chips to edit the {{path|resume_video()}} function in {{path|/etc/pm/functions-intel}} to comment out the VBE post and restore. (As of FC6 these seem to be pre-commented out.) Also, the laptop, after waking up, may go back to sleep immediately or whenever the AC adapter is disconnected. When this happens, it's caused by a bug in the HAL daemon that incorrectly reports certain ACPI events. This is a known problem and a simple workaround is described [http://live.gnome.org/GnomePowerManager/Faq#head-b8b1280115b0a51c2cc27b13a57121130ebf36cb here].

{{NOTE|It is possible this method will not work if the laptop is docked. It is also possible that the cited workaround for the HAL daemon bug will not work on some machines. A kludgier workaround in this event is to kill the HAL daemon on suspend. This necessitates the resuscitation of GPM upon resume.}}

Another solution is to use vbetool. If you are using {{Debian}} with the hibernate package, uncomment "EnableVbetool yes" in {{path|/etc/hibernate/hibernate.conf}} (or {{path|/etc/hibernate/ram.conf}}).

----

On '''T60 2007-CTO''' (Core2Duo 2Ghz, 2GB Ram, ATI X1400) the screen stayed blank after suspend-to-ram until I set '''vga=0''' in lilo.conf.

Working config:
Linux 2.6.21.5
fglrx 8.37.6
debian etch:
powersaved 0.14.0-5:
UNLOAD_MODULES_BEFORE_SUSPEND2DISK="usb_storage ohci_hcd uhci_hcd ehci_hcd ipw3945 pcmcia yenta_socket rsrc_nonstatic pcmcia_core"
UNLOAD_MODULES_BEFORE_SUSPEND2RAM="usb_storage ohci_hcd uhci_hcd ehci_hcd ipw3945 pcmcia yenta_socket rsrc_nonstatic pcmcia_core"
hibernate:
SwitchToTextMode yes
lilo.conf:
vga=0

"EnableVbetool yes" and other suggestions didn't work for me.

For suspend-to-disk, don't load fglrx in initrd.

----

===Solution for ThinkPads with Intel Extreme Graphics 2===
{{NOTE|
On [[:Category:X40|X40]]s/[[:Category:X41|X41]]s - even with Intel Extreme Graphics - and for [[:Category:R52|R52]]s with Intel Graphics Media Accelerator 900 the [[Problem with display remaining black after resume#Solution for ThinkPads with ATI graphic chips|solution for ATI graphics chips]] above is reported to work. In this case, make sure no changes to VBE are made, especially no state saves and no reposts.}}

The following solution should work on 865G, 865GV, 855GM, 855GME, 852GME chipsets.
*First of all, '''do not''' use the {{bootparm|acpi_sleep|s3_bios}} kernel parameter.
*Second, completely remove framebuffer support from your kernel. If it's built as modules, it is important that they do not get loaded at all.
*Before suspending, change to a console and safe the video state with {{cmdroot|cat /proc/bus/pci/00/02.0 > /tmp/video_state}}.
*On resume, restore the video state with {{cmdroot|cat /tmp/video_state > /proc/bus/pci/00/02.0}} and change back to X.
*For Debian Etch 4.0 on R50e just make following changes to /etc/default/acpi-support:
#SAVE_VBE_STATE=true
#VBESTATE=/var/lib/acpi-support/vbestate
#POST_VIDEO=true
SAVE_VIDEO_PCI_STATE=true

*For a R50e the only thing needed to make suspend to ram work in Ubuntu 6.06 is adding
Option "VBERestore" "yes"
to the <tt>Device</tt> section in your {{path|/etc/X11/xorg.conf}}, and the example script below.

The following example {{path|/etc/acpi/actions/sleep.sh}} script shows how to integrate the according lines.

#!/bin/bash

# change to console 1
FGCONSOLE=`fgconsole`
chvt 6

# safe video state
cat /proc/bus/pci/00/02.0 > /tmp/video_state

# sync filesystem
sync

# sync hardware clock with system time
hwclock --systohc

# go to sleep
echo -n 3 > /proc/acpi/sleep

# waking up
# restore system clock
hwclock --hctosys

# restore video state
cat /tmp/video_state > /proc/bus/pci/00/02.0

# change back to X
chvt $FGCONSOLE

# clean up behind us
rm /tmp/video_state

With Ubuntu 6.10 on a [[:Category:R51|R51 (2887-32G)]] I ''just'' (as none of the other tricks above) had to add {{bootparm|fb|false}} to the kernel line in {{path|/etc/grub/menu.lst}} and edit {{path|/etc/defaults/acpi-support}} this way:

SAVE_VBE_STATE=false
POST_VIDEO=false
SAVE_VIDEO_PCI_STATE=true
USE_DPMS=false
DOUBLE_CONSOLE_SWITCH=false

===Solution for ThinkPads with Intel I830 Chipset===
The following solution worked for me on an X30 with I830M chipset with kernel >= 2.6.16.
*this works with vesafb and also with intelfb frambuffer support.
The following example {{path|/etc/acpi/actions/sleep.sh}} script shows how to integrate the according lines.

#!/bin/bash

FGCONSOLE=`fgconsole`
chvt 8
sync
hwclock --systohc

echo -n "mem" > /sys/power/state

hwclock --hctosys
vbetool post

if [ "$FGCONSOLE" -ge "7" ] ; then
chvt $FGCONSOLE
else
chvt 7
chvt $FGCONSOLE
fi
===Solution for ThinkPads with ATI graphic (and possibly other) chips and FreeBSD===

The FreeBSD acpi(4) manpage mentions a tunable parameter, "hw.acpi.reset_video":

hw.acpi.reset_video
Reset the video adapter from real mode during the resume path.
Some systems need this help, others have display problems if it
is enabled. Default is 0 (disabled).

This tunable can be set by adding the following line to your FreeBSD machine's /boot/loader.conf file:

hw.acpi.reset_video="1"

And rebooting your machine. Hopefully, the next time you resume from a suspend, you'll see your video again. This solution doesn't appear to be specific to ATI hardware in any way, so I presume it would be helpful for video chipsets other than ATI, as well.

If this entry doesn't help you, you might consider searching in the [http://lists.freebsd.org/pipermail/freebsd-mobile/ FreeBSD-Mobile email-list archive] for more insight.

{{footnotes|
#If you have this problem with R50e and the above solution doesn't work, try switching to console first. An example sleep script can be found [[How to configure acpid|here]].
}}

===Solution using s2ram for Intel 915/945GM===

Just using the "s2ram -f -p" command from the uswsusp package will work from within X, at least on a {{Z61e}}. On {{X60s}} it is enough to issue the "s2ram" command and it works.