Bug 473525 - X driver for radeon X800XL regression
X driver for radeon X800XL regression
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2008-11-28 22:40 EST by Michael Wiktowy
Modified: 2009-12-18 02:01 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-12-18 02:01:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
An exerpt from the Xorg.0.log (4.12 KB, text/plain)
2008-11-28 22:40 EST, Michael Wiktowy
no flags Details
Stdout and stderr during 'X -configure' (1.77 KB, text/plain)
2008-11-28 22:43 EST, Michael Wiktowy
no flags Details
Stdout and stderr during 'X -config /root/xorg.conf.new' (1.21 KB, text/plain)
2008-11-28 22:44 EST, Michael Wiktowy
no flags Details
Autogenerated xorg.conf for Ati Radeon X800 XL (4.44 KB, text/plain)
2008-11-28 22:46 EST, Michael Wiktowy
no flags Details
Image of screen corruption at X startup (222.28 KB, image/jpeg)
2008-11-29 15:11 EST, Michael Wiktowy
no flags Details

  None (edit)
Description Michael Wiktowy 2008-11-28 22:40:29 EST
Created attachment 325062 [details]
An exerpt from the Xorg.0.log

Description of problem:
The radeon driver included in the release of Fedora 10 does not work correctly for the ATI Radeon X800 XL video card. When X starts up with a freshly autogenerated xorg.conf, A garbled screen with green horizontal stripes is displayed with a properly rendered and functional cursor on top and you are left with a semi-frozen system (can move the cursor around but cannot reboot with ctrl-alt-del or switch to a different terminal)

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

How reproducible:

Steps to Reproduce:
1. Use old xorg.conf from a working Fedora 9 or generate a new one using 'X -configure'
2. start X
Actual results:
unusable garbled screen with green horizonal stripes

Expected results:
normal desktop

Additional info:
Was able to get at least a 1600x1200 display using the vesa driver but not the full 1920x1200 resolution of the monitor.
Comment 1 Michael Wiktowy 2008-11-28 22:43:37 EST
Created attachment 325063 [details]
Stdout and stderr during 'X -configure'
Comment 2 Michael Wiktowy 2008-11-28 22:44:56 EST
Created attachment 325064 [details]
Stdout and stderr during 'X -config /root/xorg.conf.new'
Comment 3 Michael Wiktowy 2008-11-28 22:46:07 EST
Created attachment 325065 [details]
Autogenerated xorg.conf for Ati Radeon X800 XL
Comment 4 Michael Wiktowy 2008-11-28 23:22:55 EST
Further reading of the release notes and linked common bugs gave me the proper kernel parameter to use to disable the kernel mode setting.

Adding nomodeset to the kernel line in grub made X start up properly using radeon driver.
Comment 5 Warren Togami 2008-11-29 01:35:57 EST
Try the latest builds of the drivers and kernels.
Comment 6 Michael Wiktowy 2008-11-29 15:11:06 EST
Created attachment 325102 [details]
Image of screen corruption at X startup
Comment 7 Michael Wiktowy 2008-11-29 15:13:02 EST
I installed the latest available at koji:
(and the required dep kernel-firmware- )

kernel modesetting still does not work properly for this card.
The text-based startup displaying all the deamons coming up shifts to a much
higher resolution that before but the start of X just displays stripes like
before. The only way I can get out of that mode it to press and hold the power

Will attach a photo of the screen to give you an idea of the degree of screen

The good news is that nomodeset still works as a workaround. Let me know if
there are any other versions that I should try.
Comment 8 Michael Wiktowy 2008-12-01 16:00:39 EST
Just read this post on Planet Fedora:


Looks relevant to this bug so I will try out that new kernel as soon as I can.
Comment 9 Michael Wiktowy 2008-12-02 09:16:06 EST
Tried kernel- but no joy. Still the same green lines.

Looked at things a little further. It appears that I can get the spiffy new bubbling solar flares by adding 'rhgb' to the grub kernel line (I suspect that I could do that with the original kernel + Radeon driver included with F10 but did not check) but as soon as all the daemons start up and it switches to login screen, the screen gets corrupted and I have to press and hold the power button to recover.

I see there is a 134 build of the kernel now. Will try that when I get a chance.
Comment 10 Michael Wiktowy 2008-12-02 18:21:55 EST
Good news, everyone!

Kernel Build 134 works like a charm wrt KMS for this video card. Both rhgb and regular new and improved widescreen console startup transitions to the graphical login smoothly. It is a bit weird to see the login box over top of the console text startup messages and then having the background fade in. But very slick looking.

Thank you for all your efforts and responsiveness.
Comment 11 Michael Wiktowy 2008-12-04 13:18:28 EST
Not so great news.

Further testing reveals that while KSM works, performance of playing video streams is terrible. The compressed video file starts stuttering and heavily desyncing with the audio almost immediately and then the video grinds to a halt taking any mouse responsiveness with it. During the whole time, the audio plays normally.

Going back to build 130 fixed the video but it does not work for KMS.
Comment 12 Michael Wiktowy 2008-12-08 18:49:42 EST
Installed latest x ati driver and kernel

kernel.i686                                 installed
kernel-firmware.noarch                      installed
xorg-x11-drv-ati.i386                   6.9.0-61.fc10                  installed

Still video stream stuttering as per Comment #11 but discovered this occurs only when KMS is enabled. When kernel is booted with nomodeset, there is no fancy graphical boot but the video plays properly.
Comment 13 François Cami 2009-02-04 02:52:00 EST
Does modesetting work with current F10 or do you still need nomodeset to avoid a crash ?
Is performance the only problem now ?
Comment 14 Michael Wiktowy 2009-02-12 21:42:18 EST
I can confirm that current kernel (kernel.i686 plus current ATI/AMD open source X driver (xorg-x11-drv-ati.i386 6.10.0-1.fc10) is stable but performance when playing video is poor (but improving since last time I checked). Video no longer skips frames and locks up when played in full screen. However, there is still a significant amount of tearing that occurs. There is a very distinct *diagonal* tearing line (running from the lower left to the upper right corner) where on one side it plays the video a few frames behind. When the video is not full screen, the more typical horizontal tear line shows up. Video is playing in Totem (the other players, including mplayer, do a worse job).
Comment 15 Michael Wiktowy 2009-02-12 21:44:22 EST
To be clear, Comment #14 is *without* nomodeset. With nomodeset, video plays smoothly but get no rhgb/plymouth candy.
Comment 16 Michael Wiktowy 2009-02-12 22:08:03 EST
Another observation:
With nomodeset: switching to 3D desktop works ... but it is really slow.

Without nomodeset: switching to 3D desktop locks X up solid as soon as the window frames are loaded again.
Comment 17 Bug Zapper 2009-11-18 03:00:09 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 18 Bug Zapper 2009-12-18 02:01:14 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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