Red Hat Bugzilla – Bug 473525
X driver for radeon X800XL regression
Last modified: 2009-12-18 02:01:14 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):
Steps to Reproduce:
1. Use old xorg.conf from a working Fedora 9 or generate a new one using 'X -configure'
2. start X
unusable garbled screen with green horizonal stripes
Was able to get at least a 1600x1200 display using the vesa driver but not the full 1920x1200 resolution of the monitor.
Created attachment 325063 [details]
Stdout and stderr during 'X -configure'
Created attachment 325064 [details]
Stdout and stderr during 'X -config /root/xorg.conf.new'
Created attachment 325065 [details]
Autogenerated xorg.conf for Ati Radeon X800 XL
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.
Try the latest builds of the drivers and kernels.
Created attachment 325102 [details]
Image of screen corruption at X startup
I installed the latest available at koji:
(and the required dep kernel-firmware-22.214.171.124-130.fc10.noarch.rpm )
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.
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.
Tried kernel-126.96.36.199-132.fc10.i686.rpm 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.
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.
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.
Installed latest x ati driver and kernel
kernel.i686 188.8.131.52-137.fc10 installed
kernel-firmware.noarch 184.108.40.206-137.fc10 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.
Does modesetting work with current F10 or do you still need nomodeset to avoid a crash ?
Is performance the only problem now ?
I can confirm that current kernel (kernel.i686 220.127.116.11-170.2.5.fc10) 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).
To be clear, Comment #14 is *without* nomodeset. With nomodeset, video plays smoothly but get no rhgb/plymouth candy.
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.
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:
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.