Bug 466437 - radeon redraw errors - block graphics like in the 80ies
radeon redraw errors - block graphics like in the 80ies
Status: CLOSED DUPLICATE of bug 466663
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-10 05:48 EDT by Mads Kiilerich
Modified: 2008-10-14 08:14 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-14 07:23:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xorg.0.log to show version of hardware and driver (97.15 KB, application/octet-stream)
2008-10-10 05:48 EDT, Mads Kiilerich
no flags Details
photo of screen with redraw errors (305.57 KB, image/jpeg)
2008-10-10 05:53 EDT, Mads Kiilerich
no flags Details
photo of same part of screen after it has been redrawn (370.79 KB, image/jpeg)
2008-10-10 05:54 EDT, Mads Kiilerich
no flags Details

  None (edit)
Description Mads Kiilerich 2008-10-10 05:48:35 EDT
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 05:53:21 EDT
Created attachment 319992 [details]
photo of screen with redraw errors
Comment 2 Mads Kiilerich 2008-10-10 05:54:19 EDT
Created attachment 319993 [details]
photo of same part of screen after it has been redrawn
Comment 3 Hans Ulrich Niedermann 2008-10-10 17:12:32 EDT
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 17:28:32 EDT
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 18:02:24 EDT
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 06:39:53 EDT
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 07:23:11 EDT
(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 08:14:37 EDT
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.

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