Bug 189536

Summary:	Suspend on Thinkpad R52 Laptop Type 1859-4AU : Video doesn't resume
Product:	[Fedora] Fedora	Reporter:	P V <pv+redhat>
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	CLOSED ERRATA	QA Contact:	Brian Brock <bbrock>
Severity:	high	Docs Contact:
Priority:	medium
Version:	5	CC:	ncunning, runge, wtogami
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:	NeedsRetesting
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-03-14 15:42:50 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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: 
http://thinkwiki.org/wiki/Problem_with_display_remaining_black_after_resume 
 
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.

#!/bin/bash
# change to console 6
FGCONSOLE=`fgconsole`
chvt 6

# sync filesystem
sync

# 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
chvt $FGCONSOLE

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
FGCONSOLE=`fgconsole`
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)
chvt $FGCONSOLE

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?