Red Hat Bugzilla – Bug 476946
Kernel 18.104.22.168-134 (now 22.214.171.124-159) crashes with radeon driver
Last modified: 2009-12-18 02:19:30 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): 126.96.36.199-134
How reproducible: very
Steps to Reproduce:
1. Install Fedora 10 on a system with a radeon video chipset
2. Update kernel to 188.8.131.52-134
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., 184.108.40.206-117)
A visible/usable login screen.
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
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)
Is there an rpm for this still available somewhere, and/or is it likely to be fixed in the near future?
For i386: http://dev.wwg.lv/swt/xorg-x11-drv-ati-6.9.0-61.fc10.i386.rpm
How about x86_64?
My x86_64 box has nvidia, no ati driver here, sorry =(
This same problem persists with kernel 220.127.116.11-159 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.
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 ?
Created attachment 330690 [details]
Log from booting current kernel/driver without the 'nomodeset' option
Kernel version: 18.104.22.168-170.2.5.fc10.x86_64
I will try again shortly with: xorg-x11-drv-ati.x86_64-6.10.0-1.fc10 from updates-testing repo.
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?
Please try xorg-x11-drv-ati-6.10.0-2.fc10 from Koji first.
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.
Can you confirm that 22.214.171.124-117 make the problem disappear ?
Yep...had to reinstall (yum removed it on the last kernel update), but it works without the nomodeset option.
(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.
Kernel 126.96.36.199-117 is the one that came on the install CD.
Current kernel from fedora's updates repo is 188.8.131.52-170.2.5.
This bug started after the first kernel update that I received (I think that's 184.108.40.206-134), and has persisted since.
So don't close this one yet. :)
Could you post the output of dmesg and lspci as uncompressed attachments to this bug, for both 220.127.116.11-117 and the first kernel that fails ?
Thanks in advance
Created attachment 330817 [details]
dmesg for 18.104.22.168-117
Created attachment 330818 [details]
lspci for 22.214.171.124-117
Created attachment 330819 [details]
dmeg for 2.6.27-134
Created attachment 330820 [details]
lspci for 2.6.27-134
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.
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, 126.96.36.199-170.2.5.fc10 ) with radeon.no_wb=1 in the kernel command line ?
I got a warning that that is an unknown kernel option, and it had no effect.
Using kernel 188.8.131.52-170.2.5.fc10.x86_64.
Fun, radeon.no_wb=1 should work, AFAIK.
Could you try booting in runlevel 3, then :
modprobe radeon no_wb=1
and report ?
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.
Not reproducible on rawhide with kernel-2.6.29-0.258.2.3.rc8.git2.fc11.i586 - KMS works, 3D works as usual (unacceptably slow)
Can you test with fedora 12 livecd and report if it works with it.
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.