Bug 2974 - Corrupt display after firmware 'display sleep'
Summary: Corrupt display after firmware 'display sleep'
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: 6.8.2
Hardware: x86 (IA32) Linux (All)
: high major
Assignee: Xorg Project Team
QA Contact:
URL:
Whiteboard:
Keywords:
: 2975 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-04-11 09:20 UTC by Andrew D. Stadler
Modified: 2007-02-22 14:27 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew D. Stadler 2005-04-11 09:20:08 UTC
The Thinkpad T30 BIOS includes a 'display sleep' setting to save battery life & screen backlight life.  
This appears to be independent of the X screensaver settings.

Unfortunately if this display sleep kicks in, X does not recover properly.  When you click any key (e.g. 
SHIFT) to 'wake up' the screen, it comes up in a scrambled, jumpy, unuseable condition.  I have found 
that logging out and logging in X do not fix it.  The only solution that appears to fix it (other than a 
reboot) is to blindly type /usr/bin/apm -s

The only way I have found to avoid this problem is to use BIOS settings to disable sleep entirely.  But 
this has the unfortunate side effect of losing a useful feature, and it impacts other setups (e.g. on a 
dual-boot machine).  I have set the severity of this bug to "major" because the system suffers this 
condition "as installed" and it can very easily cause data loss.

Version-Release number of selected component (if applicable):
xorg-x11-6.8.2-1.FC3.13   & IBM BIOS 2.08

How reproducible:
Always

Steps to Reproduce:
1.  Boot laptop into BIOS setup screen
2.  Adjust display sleep (both AC and battery) to short but different durations (e.g. 1 minute and 3 
minutes)
3.  Save settings and boot into Linux
4.  Wait with AC power until display sleeps, hit shift to wake up, notice scrambling
5.  Recover using sleep or reboot
6.  Repeat 4 with battery power
  

Actual Results:  Display wakes up in a scrambled, unuseable mode

Expected Results:  Display wakes up normally

Additional info:

Note, this problem also seems to be affected by the existence of a 2nd monitor in dual-head mode.  I 
have not seen the problem when I have two monitors plugged in - for some reason, in this 
configuration, the LCD does sleep, and it does wake, properly.  

I always see the problem when I only have the internal laptop monitor.

My system is a ThinkPad T30 running FC3, pretty much up-to-date.  It
has a radeon 7500 and the displays are the internal 1400x1050 and an
external VGA dell 2000fp (1600x1200).

I originally filed this bug as <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=153744>
Comment 1 Andrew D. Stadler 2005-04-11 09:26:22 UTC
*** Bug 2975 has been marked as a duplicate of this bug. ***
Comment 2 T. Hood 2005-09-26 03:57:25 UTC
The 'display sleep' is presumably an ACPI function.  I am not sure that xorg
supports ACPI sedation.
Comment 3 T. Hood 2005-09-26 04:03:09 UTC
*** Bug 4436 has been marked as a duplicate of this bug. ***
Comment 4 T. Hood 2005-09-26 07:57:46 UTC
*** Bug 3844 has been marked as a duplicate of this bug. ***
Comment 5 Andrew D. Stadler 2005-09-26 10:39:20 UTC
FWIW, I'm not sure if those other two bugs are duplicates.

4436 refers to an X crash after the laptop sleeps (or perhaps hibernates).

In this bug, X is not crashed;  You can move the mouse around, type, etc. and see things going on 
(through the garbled display).

3844 refers to a problem with dynamic clocks after suspend.

In this bug, the system has not slept, suspended, or hibernated.  The system is awake, it's just that the 
screen has been disabled (by the bios) to save energy.


Please don't get me wrong, I'm glad to see that the radeon 7500 issues are getting some attention.  Just 
want to make sure that distinct issues aren't getting mixed together.
Comment 6 Erik Andren 2005-09-26 12:25:43 UTC
I totally agree on Stadler on this one. 
Firstly I don't use ACPI 
Secondly I don't experience any garbled screen just a xorg crash the moment I
open the lid.

(In reply to comment #5)
> FWIW, I'm not sure if those other two bugs are duplicates.
> 
> 4436 refers to an X crash after the laptop sleeps (or perhaps hibernates).
> 
> In this bug, X is not crashed;  You can move the mouse around, type, etc. and
see things going on 
> (through the garbled display).
> 
> 3844 refers to a problem with dynamic clocks after suspend.
> 
> In this bug, the system has not slept, suspended, or hibernated.  The system
is awake, it's just that the 
> screen has been disabled (by the bios) to save energy.
> 
> 
> Please don't get me wrong, I'm glad to see that the radeon 7500 issues are
getting some attention.  Just 
> want to make sure that distinct issues aren't getting mixed together.

Comment 7 Erik Andren 2006-05-10 06:52:48 UTC
Bug submitter, any improvements using a current version of xorg? 
Are you using the radeon framebuffer at the same time?  
Comment 8 Andrew D. Stadler 2006-05-10 10:17:47 UTC
> Bug submitter, any improvements using a current version of xorg? 

I'm afraid I have not upgraded past FC3 so I am still using the same versions of
everything.  I will update this bug when I upgrade to FC5 (soon).

> Are you using the radeon framebuffer at the same time?  

I'm not sure what you mean, can you clarify this question please?
Comment 9 Erik Andren 2006-05-10 16:01:45 UTC
(In reply to comment #8)
> > Bug submitter, any improvements using a current version of xorg? 
> 
> I'm afraid I have not upgraded past FC3 so I am still using the same versions of
> everything.  I will update this bug when I upgrade to FC5 (soon).
> 
> > Are you using the radeon framebuffer at the same time?  
> 
> I'm not sure what you mean, can you clarify this question please?

Of course. Normally you can choose in the linux kernel which framebuffer that is
to drive the screen. In your case you have the choice of a standard vesa
framebuffer or the radeon framebuffer. Using the radeon framebuffer gives better
performance in consolemode _but_ may introduce bugs when running X as the
framebuffer and the X driver may change hardware states behind each others backs. 

I had a similar problem before where resuming caused a garbled screen. Disabling
the radeon framebuffer resolved this issue for me and might do the same for you.
 
Comment 10 Thomas M Steenholdt 2006-05-19 02:01:47 UTC
I'm seeing what appears to be the same issue, but slightly different on my IBM
ThinkPad T42, using X.org 7 (Fedora Core 5).
I'm using gnome power manager to suspend system to ram, but on resume - although
the system is up, i'm getting a blank black screen with a few pitches of "noise
like lines" on the screen every now and again (twice a sec perhaps).
In order for me to regain control of the system, I need to blindly ctrl-alt-f1,
login and reboot.

I'm using radeonfb on my console, but tried without it, with same result.

I had a T30 before where this actually worked perfectly.

The chipset in my T42 is:
VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]

Let me know what you need me to provide to narrow this down
Comment 11 Timo Jyrinki 2007-02-22 14:27:08 UTC
Marking broken (status null/blank) bugs in xorg with no activity in a long time as fixed. Please reopen if you think it's necessary, but first do a search if a similar bug report is already filed and in a NEW/ASSIGNED state. These bugs do not currently show in most search results as they do not have any status.

Sorry for this janitorial spam, you know where to send hate mails to when your inbox gets full of bugs you're subscribed to.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.