Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 466437

Summary: radeon redraw errors - block graphics like in the 80ies
Product: [Fedora] Fedora Reporter: Mads Kiilerich <mads>
Component: xorg-x11-drv-atiAssignee: X/OpenGL Maintenance List <xgl-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: ajax, rhbugs, xgl-maint, yaneti
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-10-14 11:23:11 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:
Attachments:
Description Flags
Xorg.0.log to show version of hardware and driver
none
photo of screen with redraw errors
none
photo of same part of screen after it has been redrawn none

Description Mads Kiilerich 2008-10-10 09:48:35 UTC
Created attachment 319990 [details]
Xorg.0.log to show version of hardware and driver

Description of problem:
X sometimes shows small areas with "noise". When screen is redrawn - perhaps in other areas - then it is shown correctly. Even trying to take a screenshot (in gnome) fixes it.

I have taken some screen shots with a camera and will attach them.

nomodeline seems to make no difference.

Version-Release number of selected component (if applicable):
xorg-x11-drv-radeonhd-1.2.1-3.9.20080917git.fc10.i386
But I think problem has been seen with all radeon drivers since I began testing f10 beta.

Nothing in /var/log/messages.

How reproducible:
occasionally, several times an hour

Comment 1 Mads Kiilerich 2008-10-10 09:53:21 UTC
Created attachment 319992 [details]
photo of screen with redraw errors

Comment 2 Mads Kiilerich 2008-10-10 09:54:19 UTC
Created attachment 319993 [details]
photo of same part of screen after it has been redrawn

Comment 3 Hans Ulrich Niedermann 2008-10-10 21:12:32 UTC
Are you booting your system with or without using kernel modesetting?

On my system with a mobile X1400 chipset, kernel modesetting messes up the display so much on F10beta that I would not trust a system wrt graphics errors until the next cold boot.

Are you booting with the kernel parameter "nomodeset"? If not, is the issue reproducible after booting with "nomodeset"?

Comment 4 Mads Kiilerich 2008-10-10 21:28:32 UTC
Until a couple of days ago I had the same experience as you and had to use nomodeset, but with recent updates I haven't seen any problems with correlation to nomodeset.

Right now I am not using nomodeset (double negation - so to make it clear: I _do_ get plymouth highres progress bar).

But I get the same behaviour when _not_ using nomodeset. I will verify in a moment.

Comment 5 Mads Kiilerich 2008-10-10 22:02:24 UTC
Hmm. It seems like you are right.

Without nomodeset I can reproduce it with a maximized gnometerminal matrix-like text flying by - with 
while true; do cat /var/log/messages; done
Staring deeply into the screen I see the drawing error several times a minute.

With nomodeset I couldn't provoke the error.

Next week I will continue running with nomodeset and see if that keeps the problem away.

Comment 6 Yanko Kaneti 2008-10-14 10:39:53 UTC
This is a duplicate of bug 466663 , which is kms + xorg-x11-drv-ati bug. Your logs show you are using it, rather than radeonhd.

Comment 7 Hans Ulrich Niedermann 2008-10-14 11:23:11 UTC
(In reply to comment #6)
> This is a duplicate of bug 466663 , which is kms + xorg-x11-drv-ati bug. Your
> logs show you are using it, rather than radeonhd.

Very much so indeed.

However, I can confirm that radeonhd did have similar issues on my mobile X1400 in conjunction with KMS - and those issues are fixed in xorg-x11-drv-radeonhd-1.2.3-1.2.20081014git.fc10 :-)

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

Comment 8 Mads Kiilerich 2008-10-14 12:14:37 UTC
You are right. I am sorry for having provided wrong information. But _now_ I am running radeonhd. I'm quite sure ... Compiz doesn't work, but otherwise it is ok ...

What happened?

In my Xorg.0.log I saw '(II) LoadModule: "radeon"' '(II) Loading /usr/lib/xorg/modules/drivers//radeon_drv.so' and concluded that the radeon driver was used. When entering an bugzilla bug there was only one package mentioning radeon, and I thought that was the right one to choose, hd or not.

When I can get it wrong then other users might get it wrong too. Not to blame others, but please take this as constructive feedback to avoid similar problems, some for radeonhd, some for xorg in general:

* It is not obvious from looking at an Xorg.0.log which driver is used. Could it be made more explicit?

* Xorg.0.log is hard to read; apparently the blank line after '(II) LoadModule: "radeon"' should be before it?

* 3 different X drivers supporting my card is confusing. Choice is good, but for Fedora end users there should be only one that works. Apparently "ati" and "radeon" is 100% the same?

* Yes, radeonhd is experimental and I am glad to test it. Please put "experimental" in the package name, and make it clear in the X logs that the experimental driver is used. That will distinguish it more from the spurious "radeon" driver.