Bug 77189

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
erratum.

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.

Thanks.

Created attachment 83345 [details]
My X log

Created attachment 83346 [details]
My X config file

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).

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.

This is the same issue as 63509.  Please try the fix posted there, and report
back in that bug

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

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 ;-)

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 ***

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
issues.

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.

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.