Difference between revisions of "Installing Mandriva 2008 x86-64 Powerpack on a Thinkpad T61"
m (→Suspend to RAM) |
(→Suspend to RAM) |
||
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
− | + | Mandriva Powerpack x86-64 installs successfully on Lenovo Thinkpad T61. | |
− | + | == Suspend to RAM == | |
− | + | If suspend to RAM does not work out of the box, then you need to install the pm-utils package if it wasn't already installed. | |
− | * | + | |
− | + | To resolve the annoying issue of not being able to see the X session on VT 7 after a resume, Update the following file {{path|/usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-lenovo.fdi}} | |
+ | <pre> | ||
+ | <!-- T60*, T61*, Z61* --> | ||
+ | <match key="system.hardware.version" prefix="ThinkPad "> | ||
+ | <match key="system.hardware.version" suffix="T60"> | ||
+ | <merge key="power_management.quirk.s3_bios" type="bool">true</merge> | ||
+ | <merge key="power_management.quirk.s3_mode" type="bool">true</merge> | ||
+ | </match> | ||
+ | <match key="system.hardware.version" contains_outof="T60p;T61;Z61m;Z61t;Z60m"> | ||
+ | <merge key="power_management.quirk.s3_bios" type="bool">true</merge> | ||
+ | <merge key="power_management.quirk.s3_mode" type="bool">true</merge> | ||
+ | </match> | ||
+ | </match> | ||
+ | |||
+ | </pre> | ||
+ | |||
+ | And restart HAL daemon to pick up the new configuration changes: | ||
+ | {{cmdroot|service haldaemon restart}} | ||
+ | |||
+ | You can also query the HAL daemon to get more info about your system: | ||
+ | <pre> | ||
+ | lshal -l | grep system.hardware.vendor | ||
+ | system.hardware.vendor = 'LENOVO' (string) | ||
+ | lshal -l | grep system.hardware.version | ||
+ | system.hardware.version = 'ThinkPad T61' (string) | ||
+ | lshal -l | grep system.hardware.product | ||
+ | system.hardware.product = '6465CTO' (string) | ||
+ | </pre> | ||
+ | |||
+ | My system was taking forever to boot at startup and also resume from a suspend. In both cases, the culprit seemed to be the service 'network-up'. It looks for several keys in the network configuration files {{path|/etc/sysconfig/network-scripts/ifcfg-*}}. Update these as follows to speed things up and prevent seeing the "Waiting for network to be up [FAILED]" message: | ||
− | + | <pre>MII_NOT_SUPPORTED=no to MII_NOT_SUPPORTED=yes</pre> | |
− | + | I always wondered how Microsoft Windows could quickly suspend and resume instantaneously as I opened the laptop lid! Make the following change to {{path|/usr/share/pm-utils/functions}} to be able to resume just as quick in Linux. | |
− | |||
− | |||
− | |||
<pre> | <pre> | ||
− | + | pm_main() | |
− | + | { | |
− | + | if [ -n "$PM_LOGFILE" ]; then | |
+ | [ -f "$PM_LOGFILE" ] && rm -f "$PM_LOGFILE" | ||
+ | exec > "$PM_LOGFILE" 2>&1 | ||
+ | fi | ||
+ | take_suspend_lock || exit 1 | ||
+ | |||
+ | rm -f "$INHIBIT" | ||
+ | |||
+ | run_hooks "$1" | ||
+ | |||
+ | if [ ! -e "$INHIBIT" -a "$(type -t "do_$1")" == "function" ]; then | ||
+ | sync ; sync ; sync | ||
+ | "do_$1" | ||
+ | fi | ||
+ | remove_suspend_lock 200 | ||
+ | run_hooks "$2" reverse | ||
+ | |||
+ | # remove_suspend_lock 200 | ||
+ | |||
+ | return 0 | ||
+ | } | ||
</pre> | </pre> | ||
− | |||
− | + | Notice that we are removing the suspend lock well before we run the suspend/resume scripts from {{path|/usr/share/pm-utils/sleep.d}} | |
− | + | ||
+ | ---- | ||
+ | |||
+ | The following is written by:--Gslt 17:37, 13 January 2008 (CET) | ||
We also tried to use {{bootparm|key|power_management.quirk.s3_mode}} but then the the backlight would be set to zero (0) when resuming from suspend. | We also tried to use {{bootparm|key|power_management.quirk.s3_mode}} but then the the backlight would be set to zero (0) when resuming from suspend. | ||
Latest revision as of 13:49, 28 April 2008
Mandriva Powerpack x86-64 installs successfully on Lenovo Thinkpad T61.
Suspend to RAM
If suspend to RAM does not work out of the box, then you need to install the pm-utils package if it wasn't already installed.
To resolve the annoying issue of not being able to see the X session on VT 7 after a resume, Update the following file /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-lenovo.fdi
<!-- T60*, T61*, Z61* --> <match key="system.hardware.version" prefix="ThinkPad "> <match key="system.hardware.version" suffix="T60"> <merge key="power_management.quirk.s3_bios" type="bool">true</merge> <merge key="power_management.quirk.s3_mode" type="bool">true</merge> </match> <match key="system.hardware.version" contains_outof="T60p;T61;Z61m;Z61t;Z60m"> <merge key="power_management.quirk.s3_bios" type="bool">true</merge> <merge key="power_management.quirk.s3_mode" type="bool">true</merge> </match> </match>
And restart HAL daemon to pick up the new configuration changes:
# service haldaemon restart
You can also query the HAL daemon to get more info about your system:
lshal -l | grep system.hardware.vendor system.hardware.vendor = 'LENOVO' (string) lshal -l | grep system.hardware.version system.hardware.version = 'ThinkPad T61' (string) lshal -l | grep system.hardware.product system.hardware.product = '6465CTO' (string)
My system was taking forever to boot at startup and also resume from a suspend. In both cases, the culprit seemed to be the service 'network-up'. It looks for several keys in the network configuration files /etc/sysconfig/network-scripts/ifcfg-*. Update these as follows to speed things up and prevent seeing the "Waiting for network to be up [FAILED]" message:
MII_NOT_SUPPORTED=no to MII_NOT_SUPPORTED=yes
I always wondered how Microsoft Windows could quickly suspend and resume instantaneously as I opened the laptop lid! Make the following change to /usr/share/pm-utils/functions to be able to resume just as quick in Linux.
pm_main() { if [ -n "$PM_LOGFILE" ]; then [ -f "$PM_LOGFILE" ] && rm -f "$PM_LOGFILE" exec > "$PM_LOGFILE" 2>&1 fi take_suspend_lock || exit 1 rm -f "$INHIBIT" run_hooks "$1" if [ ! -e "$INHIBIT" -a "$(type -t "do_$1")" == "function" ]; then sync ; sync ; sync "do_$1" fi remove_suspend_lock 200 run_hooks "$2" reverse # remove_suspend_lock 200 return 0 }
Notice that we are removing the suspend lock well before we run the suspend/resume scripts from /usr/share/pm-utils/sleep.d
The following is written by:--Gslt 17:37, 13 January 2008 (CET)
We also tried to use key=power_management.quirk.s3_mode
but then the the backlight would be set to zero (0) when resuming from suspend.
A crude way to fix the backlight issue is to create a file /etc/pm/sleep.d/00crudebacklightfix with the following
#!/bin/bash case $1 in hibernate) ;; suspend) ;; thaw) /usr/bin/chvt 1 sleep 1 /usr/bin/chvt 7 ;; resume) /usr/bin/chvt 1 sleep 1 /usr/bin/chvt 7 ;; *) echo "somebody is calling me totally wrong." ;; esac
# chmod +x /etc/pm/sleep.d/00crudebacklightfix