Bug 86104 - ati radeon mobility 9000 fails to recover from normal blanking
Summary: ati radeon mobility 9000 fails to recover from normal blanking
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: XFree86
Version: phoebe
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2003-03-14 00:06 UTC by Eric Bourque
Modified: 2007-04-18 16:52 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-03-16 21:52:42 UTC

Attachments (Terms of Use)
XF86Config file (3.26 KB, text/plain)
2003-03-14 00:07 UTC, Eric Bourque
no flags Details
xdpyinfo output (4.01 KB, text/plain)
2003-03-14 00:09 UTC, Eric Bourque
no flags Details
XFree86 log (42.78 KB, text/plain)
2003-03-14 05:15 UTC, Eric Bourque
no flags Details

Description Eric Bourque 2003-03-14 00:06:11 UTC
I have a radeon mobility 9000 and 4.3.0-2.1. The radeon driver doesn't seem
to recover properly from screen blanking (there are several horizontal
white bars with spurious activity around them). It recovers fine from a
suspend however, so I find this strange.

This is on a Dell Inspiron 8200, so after going to a console, and using
Fn-D (blank screen) and waking it up a few times (almost always twice), the
display recovers, and I can go back into X.

I'm not using DRI if it makes a difference.

Comment 1 Eric Bourque 2003-03-14 00:07:44 UTC
Created attachment 90588 [details]
XF86Config file

Comment 2 Eric Bourque 2003-03-14 00:09:24 UTC
Created attachment 90589 [details]
xdpyinfo output

Comment 3 Mike A. Harris 2003-03-14 04:11:51 UTC
Please attach X log file from a problem run.

Comment 4 Eric Bourque 2003-03-14 05:15:48 UTC
Created attachment 90595 [details]
XFree86 log

During the run represented in this log, there were several suspend/resume
cycles which went fine and seem to be in the log, but I don't see anything from
when the screen blanks due to a (hardware) timeout. I believe the blank is
triggered from BIOS, not from dpms. In fact, I just tried 'xset dpms force off'
and it was fine.

Oddly, when I was running the vesa driver with 4.2.x in RH8, this problem
didn't exist.

Comment 5 Eric Bourque 2003-03-16 20:41:03 UTC
I tried a boot without apmd, acpi, or bios related blanking, and there were no
problems. It really seems that this is a problem when recovering from a bios
blanking since dpms blanking works fine, as does a recover from suspend.

Comment 6 Mike A. Harris 2003-03-16 21:52:42 UTC
Closing bug as NOTABUG, problem resolved as hardware having a buggy BIOS.

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