Bug 476946

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 2.6.27.9-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.

mgl,

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 :
http://koji.fedoraproject.org/koji/buildinfo?buildID=80819

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

Thanks

fdc

Created attachment 330690 [details]
Log from booting current kernel/driver without the 'nomodeset' option

Kernel version: 2.6.27.12-170.2.5.fc10.x86_64
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.

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.

OK...
Can you confirm that 2.6.27.5-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 2.6.27.5-117 is the one that came on the install CD.

Current kernel from fedora's updates repo is 2.6.27.12-170.2.5.

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

So don't close this one yet.  :)

mgl,

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

Thanks in advance

Created attachment 330817 [details]
dmesg for 2.6.27.5-117

Created attachment 330818 [details]
lspci for 2.6.27.5-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, 2.6.27.12-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 2.6.27.12-170.2.5.fc10.x86_64.

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 !

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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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.