Bug 77189 - Screen corruption after screen blank with ATI Radeon m7
Summary: Screen corruption after screen blank with ATI Radeon m7
Status: CLOSED DUPLICATE of bug 63509
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 7.3
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
Blocks: 82776
TreeView+ depends on / blocked
Reported: 2002-11-02 17:26 UTC by keithu@parl.clemson.edu
Modified: 2007-04-18 16:48 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-02-21 18:50:05 UTC

Attachments (Terms of Use)
My X log (27.49 KB, text/plain)
2002-11-03 17:09 UTC, keithu@parl.clemson.edu
no flags Details
My X config file (3.68 KB, text/plain)
2002-11-03 17:10 UTC, keithu@parl.clemson.edu
no flags Details

Description keithu@parl.clemson.edu 2002-11-02 17:26:57 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
I have an IBM Thinkpad T30 model 2366-51U with an ATI Radeon M7 LW chipset.  The
display is 1400x1050. When the display returns after a screen blank, it is
corrupted.  Switch VTs does not help.  Restarting X does not help.  Screen is
corrupted in X and in text VTs.  Suspending and resuming clears the problem.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Start X
2.blank the screen (either FN-F3 or wait for power management to blank the screen)
3.Unblank the screen (move the mouse, press a key, etc.)

Actual Results:  Screen is corrupted

Expected Results:  Screen should look the same as it did before blanking.

Additional info:

Comment 1 Mike A. Harris 2002-11-03 08:46:53 UTC
Hmm.  I don't have Radeon mobility hardware with which to try and
reproduce.  Does this problem also occur in Red Hat Linux 8.0?  If not,
I can backport the new driver to 7.3 and release it in the next

There are a few other things we can do to troubleshoot this as well.
Since I don't have the hardware though, I'll need you to try some things.
If the above doesn't work, then we might be able to narrow down the
problem at least to a certain area of code.

Please attach your X server log and config file.


Comment 2 keithu@parl.clemson.edu 2002-11-03 17:09:02 UTC
Created attachment 83345 [details]
My X log

Comment 3 keithu@parl.clemson.edu 2002-11-03 17:10:02 UTC
Created attachment 83346 [details]
My X config file

Comment 4 keithu@parl.clemson.edu 2002-11-03 17:13:06 UTC
Unfortunately, I have no clean path to test RH 8.0.  I can't migrate right now
(this is a work laptop).  I have provided my config file and log file.  I hope
that helps.  I am willing to try other experiments that do not involve a
migration to 8.0 (or other things that risk breaking compatibility with 7.3).

Comment 5 Chris Runge 2002-11-23 19:49:51 UTC
For what it is worth, I see a similar problem on my T30 under 8.0. The problem
is that after the screen suspends in X, trying to resume fails to actually
resume the screen--it remains blacked out. The only way I've been able to resume
the screen is to switch to another virtual terminal, then Fn-F7 to switch the
display to external and back (which then resumes the screen on the console). At
that point I can then switch back to X.

Comment 6 Mike A. Harris 2002-12-19 11:11:06 UTC
This is the same issue as 63509.  Please try the fix posted there, and report
back in that bug

Comment 7 Mike A. Harris 2002-12-19 11:11:56 UTC

*** This bug has been marked as a duplicate of 63509 ***

Comment 8 keithu@parl.clemson.edu 2002-12-19 11:32:19 UTC
Well, I hate to reopen this, but: 1) I can't test an X-server fix that isn't
available for 7.3 yet ;-), and 2) the problem they describe doesn't seem to be
my problem.  I resume from suspend just fine.  It is screenblanking that hoses
my display.  In fact, after the display is hosed, suspending and resuming FIXES
the problem.  The work-around posted by Chris Runge in this bug report works for
me as well (it's really annoying, but it works ;-)

Comment 9 Mike A. Harris 2003-01-26 09:34:25 UTC
Your inability to be unable to test the fix for this does not constitute
the problem not being fixed.  This bug is a duplicate of the one I closed
it as a duplicate of, and is confirmed fixed by other people.  If at some
point down the road you test the fixed packages and the problem persists,
*then* reopen this report.

Until then, this bug is considered resolved, and is a duplicate of #63509.
Bugzilla exists for Red Hat to track unresolved defects, and we have no
use to track bugs that are fixed.

*** This bug has been marked as a duplicate of 63509 ***

Comment 12 Mike A. Harris 2003-01-28 00:19:19 UTC
I'm not interested in arguing with anyone.  You have reported an issue,
and it is noted here in the bug tracker.  If there is still a problem
when the packages that I state fix the issue are actually tested, then
things are different, and this issue can be considered separate.

If that does become the case, it does not indicate an XFree86 problem,
but it indicates *some* problem.  It could be X, kernel, apmd, or BIOS
APM/ACPI related, or a BIOS bug or hardware bug, or any number of other

These types of bug reports are notoriously difficult to even investigate
let alone to determine the problem, resolve the issue - especially without
having the hardware.  Having to argue with the person reporting the
problem doesn't help to find a solution either.

I need confirmation that a bug fix works in the LATEST release before I
will remotely consider spending 10 seconds of time backporting a fix to
older releases.

Comment 13 Red Hat Bugzilla 2006-02-21 18:50:05 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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