Bug 476946 - Kernel (now crashes with radeon driver
Kernel (now crashes with radeon driver
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2008-12-18 03:43 EST by mgl
Modified: 2009-12-18 02:19 EST (History)
5 users (show)

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

Attachments (Terms of Use)
Log from booting current kernel/driver without the 'nomodeset' option (37.36 KB, text/plain)
2009-02-02 18:16 EST, mgl
no flags Details
Xorg log after updating to xorg-x11-drv-ati.x86_64-6.10.0-1.fc10, and booting without 'nomodeset' option (41.20 KB, text/plain)
2009-02-02 18:31 EST, mgl
no flags Details
Xorg log after updating to xorg-x11-drv-ati.x86_64-6.10.0-2.fc10, and booting without 'nomodeset' option (37.92 KB, text/plain)
2009-02-02 18:46 EST, mgl
no flags Details
dmesg for (32.76 KB, text/plain)
2009-02-04 00:50 EST, mgl
no flags Details
lspci for (1.86 KB, text/plain)
2009-02-04 00:51 EST, mgl
no flags Details
dmeg for 2.6.27-134 (32.72 KB, text/plain)
2009-02-04 00:51 EST, mgl
no flags Details
lspci for 2.6.27-134 (1.86 KB, text/plain)
2009-02-04 00:52 EST, mgl
no flags Details

  None (edit)
Description mgl 2008-12-18 03:43:44 EST
Description of problem:

After updating the kernel, systems with radeon drivers cannot load the desktop manager.

This problem has been described at fedoraforum.org:


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

How reproducible: very

Steps to Reproduce:
1. Install Fedora 10 on a system with a radeon video chipset
2. Update kernel to
3. Reboot
Actual results:

After the system boots, and attempts to load gdm, the screen freezes with a distorted image of the background and the mouse cursor on top.  No login is visible.  With some luck, you might be able to access a console with Ctrl+Alt+F2, reboot, and select a previous kernel (e.g.,

Expected results:

A visible/usable login screen.
Comment 1 mgl 2008-12-19 14:53:43 EST
It seems this problem is sort-of fixed.  I still need to use the nomodeset kernel option with the latest kernel, but after the updates listed below were installed, I could at least login to the desktop:

Dec 19 11:13:06 Updated: bash-3.2-30.fc10.x86_64
Dec 19 11:13:08 Updated: freetype-2.3.7-2.fc10.x86_64
Dec 19 11:13:13 Updated: gtk2-2.14.5-3.fc10.x86_64
Dec 19 11:13:14 Updated: mesa-dri-drivers-7.2-0.15.fc10.x86_64
Dec 19 11:13:15 Updated: mesa-libGL-7.2-0.15.fc10.x86_64
Dec 19 11:13:15 Updated: mesa-libGLU-7.2-0.15.fc10.x86_64
Dec 19 11:13:16 Updated: 12:libdhcp4client-4.0.0-33.fc10.x86_64
Dec 19 11:13:16 Updated: libical-0.41-1.fc10.x86_64
Dec 19 11:13:16 Updated: glx-utils-7.2-0.15.fc10.x86_64
Dec 19 11:13:20 Updated: shared-mime-info-0.51-5.fc10.x86_64
Dec 19 11:13:21 Updated: 12:dhclient-4.0.0-33.fc10.x86_64
Dec 19 11:13:21 Updated: xorg-x11-server-common-1.5.3-6.fc10.x86_64
Dec 19 11:13:47 Updated: selinux-policy-3.5.13-34.fc10.noarch
Dec 19 11:14:23 Updated: selinux-policy-targeted-3.5.13-34.fc10.noarch
Dec 19 11:14:26 Updated: yum-3.2.20-5.fc10.noarch
Dec 19 11:14:26 Updated: mesa-libGL-7.2-0.15.fc10.i386
Dec 19 11:14:27 Updated: mesa-libGLU-7.2-0.15.fc10.i386
Dec 19 11:14:27 Updated: freetype-2.3.7-2.fc10.i386
Dec 19 11:14:28 Updated: 1:dbus-libs-1.2.4-2.fc10.x86_64
Dec 19 11:14:28 Updated: 1:dbus-1.2.4-2.fc10.x86_64
Dec 19 11:15:39 Updated: evolution-2.24.2-2.fc10.x86_64
Dec 19 11:15:40 Updated: xorg-x11-server-Xorg-1.5.3-6.fc10.x86_64
Dec 19 11:15:41 Updated: PolicyKit-0.9-4.fc10.x86_64
Dec 19 11:15:44 Updated: xorg-x11-drv-ati-6.9.0-62.fc10.x86_64
Dec 19 11:15:44 Updated: 1:dbus-x11-1.2.4-2.fc10.x86_64
Dec 19 11:15:45 Updated: 1:dbus-libs-1.2.4-2.fc10.i386
Dec 19 11:15:45 Updated: evolution-perl-2.24.2-2.fc10.x86_64
Dec 19 11:16:00 Updated: evolution-help-2.24.2-2.fc10.x86_64
Comment 2 Pavel Shevchuk 2008-12-22 09:12:50 EST
The problem is xorg-x11-drv-ati-6.9.0-62. 

Reverting to xorg-x11-drv-ati-6.9.0-61 fixes the problem

My card: 02:00.1 Display controller: ATI Technologies Inc RV350 AP [Radeon 9600] (Secondary)
Comment 3 mgl 2008-12-22 23:20:23 EST
Is there an rpm for this still available somewhere, and/or is it likely to be fixed in the near future?
Comment 4 Pavel Shevchuk 2008-12-23 05:56:37 EST
For i386: http://dev.wwg.lv/swt/xorg-x11-drv-ati-6.9.0-61.fc10.i386.rpm
Comment 5 mgl 2008-12-23 15:47:51 EST
How about x86_64?
Comment 6 Pavel Shevchuk 2008-12-23 17:38:50 EST
My x86_64 box has nvidia, no ati driver here, sorry =(
Comment 7 mgl 2008-12-25 22:29:00 EST
This same problem persists with kernel and xorg-x11-drv-ati 6.9.0-63.

It's not a show stopper, but I also find that if I do anything that requires special rendering effects (e.g., compiz/fusion), things start going bad, and I ultimately have to reboot.
Comment 8 François Cami 2009-02-02 17:15:16 EST

Could you confirm that the problem still exists with current kernel and xorg-x11-drv-ati ? (with / without nomodeset)

Alternatively, could you try the latest xorg-x11-drv-ati from Koji :

Could you also post /var/log/Xorg.0.log as uncompressed attachment to this bug ?


Comment 9 mgl 2009-02-02 18:16:54 EST
Created attachment 330690 [details]
Log from booting current kernel/driver without the 'nomodeset' option

Kernel version:
Driver: xorg-x11-drv-ati.x86_64-6.9.0-63.fc10

I will try again shortly with: xorg-x11-drv-ati.x86_64-6.10.0-1.fc10 from updates-testing repo.
Comment 10 mgl 2009-02-02 18:31:37 EST
Created attachment 330692 [details]
Xorg log after updating to xorg-x11-drv-ati.x86_64-6.10.0-1.fc10, and booting without 'nomodeset' option

Same result - worse actually, since I couldn't even switch to a terminal with Ctrl+Alt+F2.

Do I also need to update to a newer kernel?
Comment 11 François Cami 2009-02-02 18:45:18 EST
Please try xorg-x11-drv-ati-6.10.0-2.fc10 from Koji first.
Comment 12 mgl 2009-02-02 18:46:55 EST
Created attachment 330694 [details]
Xorg log after updating to xorg-x11-drv-ati.x86_64-6.10.0-2.fc10, and booting without 'nomodeset' option

Sorry...I didn't realize the driver version on the website you pointed to was different from updates-testing.  At any rate...3rd time wasn't the charm in this case.  Same result again.
Comment 13 François Cami 2009-02-02 19:01:00 EST
Can you confirm that make the problem disappear ?
Comment 14 mgl 2009-02-02 19:32:16 EST
Yep...had to reinstall (yum removed it on the last kernel update), but it works without the nomodeset option.
Comment 15 Matěj Cepl 2009-02-03 08:56:08 EST
(In reply to comment #14)
> Yep...had to reinstall (yum removed it on the last kernel update), but it works
> without the nomodeset option.

yum removed it? So, what's your current kernel and does it work? Just to be sure that I am not closing incomplete bug.
Comment 16 mgl 2009-02-03 14:59:37 EST
Kernel is the one that came on the install CD.

Current kernel from fedora's updates repo is

This bug started after the first kernel update that I received (I think that's, and has persisted since.

So don't close this one yet.  :)
Comment 17 François Cami 2009-02-03 22:51:55 EST

Could you post the output of dmesg and lspci as uncompressed attachments to this bug, for both and the first kernel that fails ?

Thanks in advance
Comment 18 mgl 2009-02-04 00:50:42 EST
Created attachment 330817 [details]
dmesg for
Comment 19 mgl 2009-02-04 00:51:07 EST
Created attachment 330818 [details]
lspci for
Comment 20 mgl 2009-02-04 00:51:44 EST
Created attachment 330819 [details]
dmeg for 2.6.27-134
Comment 21 mgl 2009-02-04 00:52:31 EST
Created attachment 330820 [details]
lspci for 2.6.27-134
Comment 22 mgl 2009-02-04 01:01:11 EST
I can post more from the more recent kernels.  Does it matter whether I boot with/without nomodeset?  I did both without nomodeset in this case.

An interesting note is that this time I could clearly see the login (though at the wrong resolution).  That didn't stop things from becoming non-responsive after I switched to tty2 to get the lspci/dmesg data, then switched back.

As an aside, I've noticed a similar pattern of crashing/freezing when I load Google Earth 5.0.  When booted in the latest kernel (using the nomodeset option of course), if I start Google Earth, things seem to be fine at first (but sluggish), until after about 5 seconds after the globe in GE starts rotating/zooming.  At that point the whole system grinds to a halt.  I can't do anything but move the mouse (like when I get to the login screen after booting without the nomodeset option).  I can, however, login remotely via SSH and kill googleearth-bin - but the X process remains locked at 100% and I can't kill it or do much of anything else other than power down the system.  I suspect this is something to do with Google Earth's use of 3d drivers...and may be related to this bug.  At least it seems that things freeze up in a similar way.  I'll boot into the older kernel and see what happens.
Comment 23 François Cami 2009-02-05 18:37:13 EST
ASSIGNING to kernel.

This change in dmesg worries me the most :
-[drm] writeback test succeeded in 1 usecs
+[drm] writeback test failed

mgl, could you boot a recent kernel (preferably the one in updates, ) with radeon.no_wb=1 in the kernel command line ?
Comment 24 mgl 2009-02-05 19:45:51 EST
I got a warning that that is an unknown kernel option, and it had no effect.

Using kernel
Comment 25 François Cami 2009-02-05 20:19:26 EST
Fun, radeon.no_wb=1 should work, AFAIK.
Could you try booting in runlevel 3, then :
rmmod radeon
modprobe radeon no_wb=1
init 5
and report ?
Thanks !
Comment 26 mgl 2009-02-05 21:19:22 EST
If I boot to runlevel 3 /without/ the nomodeset option, I get an error when I try to rmmod radeon, saying the module is in use.  With nomodeset, everything works fine...but it already worked in that context anyway.
Comment 27 Pavel Shevchuk 2009-03-27 14:03:26 EDT
Not reproducible on rawhide with kernel-2.6.29- - KMS works, 3D works as usual (unacceptably slow)
Comment 28 Jérôme Glisse 2009-10-14 06:43:55 EDT
Can you test with fedora 12 livecd and report if it works with it.
Comment 29 Bug Zapper 2009-11-18 04:41:52 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 30 Bug Zapper 2009-12-18 02:19:30 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.