Bug 189536 - Suspend on Thinkpad R52 Laptop Type 1859-4AU : Video doesn't resume
Summary: Suspend on Thinkpad R52 Laptop Type 1859-4AU : Video doesn't resume
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
(Show other bugs)
Version: 5
Hardware: i686 Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
Whiteboard: NeedsRetesting
Depends On:
TreeView+ depends on / blocked
Reported: 2006-04-20 19:53 UTC by P V
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-03-14 15:42:50 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description P V 2006-04-20 19:53:31 UTC
Description of problem: Suspend worked, more or less, in FC4. However, in FC5, 
Screen remains blank on resume from suspend. 
This includes suspend called from: 
 - gnome menu, and the various  
 - suspend scripts found at: 
Hardware: Thinkpad R52 Laptop Type 1859-4AU 
 Original description: P M 740(1.7GHz), 512MB RAM, 60GB 4200rpm HDD, 15in 
1400x1050 LCD, Intel 915, 24x24x24x/8x CD-RW/DVD, Intel 802.11abg 
wireless(MPCI), Modem(CDC), 1Gb Ethernet(LOM) 
Version-Release number of selected component (if applicable): 
FC5 kernel 2.6.16-2096 with all yum updates as of 2006.04.19 
How reproducible: 100% 
Steps to Reproduce: 
1. call suspend (menu or script) 
2. wake from suspend by Fn key 
3. wait  
Actual results: 
laptop LCD backlight turns back on, but nothing is displayed 
Ctl-Alt-Del usually works to restart the system 
Fn-F7 to toggle the display from internal to external and back (hardware 
hacking magic that in some other situations would help reset the display) 
doesn't shake any more goodness out. On returning there are some random lit 
pixels on the upper tenth of the screen, but no more. 
Expected results: 
Previously visible desktop or console text, visible again. 
Additional info: 
This worked, more or less, in FC4. (Sometimes would get wedged, but worked 
>90% of the time.)

Comment 1 P V 2006-04-20 20:02:30 UTC
I'm near RTP, NC so if access to the hardware would be helpful, perhaps that 
could be arranged. 

Comment 2 P V 2006-05-26 13:50:43 UTC
Where would be the most natural place to insert the following commands?
(which seem to work, most of the time)
I'd like them to be run whether the hardware or the operating system or 
desktop initiates the sleep/resume sequence.

# change to console 6
chvt 6

# sync filesystem

# sync hardware clock with system time
hwclock --systohc

echo -n "mem">/sys/power/state
915resolution 3c 1400 1050 > /home/pv/sysop/915res-after-resume2.txt

# waking up
# restore system clock
hwclock --hctosys

# change back to X

Comment 3 P V 2006-05-26 14:24:00 UTC
Is there is a single place to inform Fedora Core of the right way to go to 
sleep? I have not found it in the documentation.
I already have the above as a script in /etc/acpi/actions, and it works when 
called explicitly. I already have the following as /usr/sbin/pm-suspend,
BUT resume initiated by the gnome power manager hangs (the display backlight 
turns on, but no foreground), and seems unresponsive to keyboard actions.

export PM_MODE="sleep"
[ -f /sys/power/state ] || exit 1
. /etc/pm/functions
take_suspend_lock || exit 1
run_hooks suspend
sync ; sync ; sync

# I added this line to change to console 6
chvt 6

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

# I added these lines
915resolution 3c 1400 1050 > /home/pv/sysop/915res-after-resume2.txt
# change back to X (or whatever console we left)

run_hooks resume reverse
remove_suspend_lock 200

Comment 4 Matthias Runge 2006-07-11 07:02:48 UTC
I can confirm this bug for T43, too. My graphics card is an ATI X300. (no ATI
drivers loaded. X runs fine with the supplied X.org server.

2.6.16 kernels from redhat are working as expected, 2.6.17 kernels do not.

Comment 5 Dave Jones 2006-10-16 18:36:54 UTC
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.

Comment 6 Matthias Runge 2007-03-14 15:37:49 UTC
The new kernel fixed that problem for me. I think, we can close this bug?

Note You need to log in before you can comment on or make changes to this bug.