Created attachment 385730 [details] Xorg.0.log without nomodeset. Note "leaking dma buffer" near end. Description of problem: The newest ati xorg driver: xorg-x11-drv-ati-6.13.0-0.20.20091221git4b05c47ac.fc12.i686 causes X to freeze when NOT using nomodeset. (This did not happen with a prior ati xorg driver: org-x11-drv-ati-6.13.0-0.11.20091119git437113124.fc12.i686 which worked whehter or not the kernel boot line had nomodeset.) Version-Release number of selected component (if applicable): xorg-x11-drv-ati-6.13.0-0.20.20091221git4b05c47ac.fc12.i686 How reproducible: Always Steps to Reproduce: 1. Boot without nomodeset in kernel line 2. Open many windows, switch between them. Run glxgears in one of them. 3. Wait for a few minutes Actual results: X freezes, will not respond to any mouse clicks, and the cursor changes to a multi-colored blob when hovered over windows which are not in focus. Expected results: No freeeze. Additional info: My smolt info is here: http://www.smolts.org/client/show/pub_70e31f89-d08e-4eee-9f8d-164205b08716 # lspci | grep -i vga 01:00.0 VGA compatible controller: ATI Technologies Inc RV610 video device [Radeon HD 2400 PRO] # uname -a Linux DD.EckhardtTrading.local 2.6.31.9-174.fc12.i686.PAE #1 SMP Mon Dec 21 06:04:56 UTC 2009 i686 i686 i386 GNU/Linux # rpm -qa | grep xorg-x11-drv-ati xorg-x11-drv-ati-6.13.0-0.20.20091221git4b05c47ac.fc12.i686 I've attached two Xorg logs. The first is the one without nomodeset. I was able to stop X using ctrl-alt-backspace. The second is with nomodeset, as I'm running now.
Created attachment 385731 [details] Xorg.0.log with nomodeset, as I'm running now.
Please attach full dmesg when booting without nomodeset and after the bug happen.
Created attachment 385768 [details] dmesg with nomodeset
Created attachment 385770 [details] dmesg withour nomodeset This time, instead of just an X freeze, X crashed and the system would not respond to any input, mouse nor keyboard. I had to turn it off. When I rebooted, I took this attachment from /var/log/dmesg.old Note the "Kernel command line:" shows that nomodeset is NOT present.
If your /proc/cmdline does not contain nomodeset option, you did not pass it to the kernel properly (do not suspend/resume the system).
This bug may be similar to bug #557805.
$ cat /proc/cmdline ro root=/dev/mapper/vg_dd-lv_root nomodeset LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us As you can see, nomodeset is there. It was passed properly.
(In reply to comment #6) > This bug may be similar to bug #557805. Why do you think so? I don't see any crashes in Xorg.0.log nor errors in dmesg.
Moreover, reporter, what is the version of libdrm on your system, please? Thank you
$ rpm -qa | grep libdrm libdrm-2.4.17-1.fc12.i686 Please note: I'm the original poster, not the one who posted comment 5 or 6.
I wrote "may be" because I had crashes without traces in the log too.
...I meant crashes with this ATI driver and libdrm updates.
Yes, but there are clear and nice errors in the other bug. Anyway, assigning to developers to do their best.
Created attachment 398578 [details] Xorg.0.log, 20100308, new kernel and ati driver, X still doesn't work without nomodeset Today's yum update installed a new kernel and updated the xorg-x11-drv-ati driver. I decided to try X without nomodeset again. So after the update, I rebooted and deleted nomodeset. $ uname -a Linux DD.EckhardtTrading.local 2.6.32.9-67.fc12.i686.PAE #1 SMP Sat Feb 27 09:42:55 UTC 2010 i686 i686 i386 GNU/Linux dale@DD ~ $ rpm -qa | grep xorg-x11-drv-ati xorg-x11-drv-ati-firmware-6.13.0-0.21.20100219gite68d3a389.fc12.i686 xorg-x11-drv-ati-6.13.0-0.21.20100219gite68d3a389.fc12.i686 X worked for about an hour, then the screen went black. The system was hung. From another system in the lan, I couldn't ping or ssh to it. I've attached the Xorg.0.log (Xorg-0-log-20100308). I'll also attach the dmesg (dmesg-old-20100308). No obvious errors in either.
Created attachment 398579 [details] dmesg, 20100308, new kernel and ati driver, X still doesn't work without nomodeset This is the promised dmesg.
Created attachment 401796 [details] F13 Live CD, ati driver works without nomodeset, Xorg.0.log I downloaded and tested the F13-Alpha-i686-Live CD. This ati driver works without nomodeset. [root@localhost ~]# uname -a Linux localhost.localdomain 2.6.33-0.52.rc8.git6.fc13.i686 #1 SMP Tue Feb 23 05:11:28 UTC 2010 i686 i686 i386 GNU/Linux [root@localhost ~]# cat /proc/cmdline initrd=initrd0.img root=live:CDLABEL=F13-Alpha-i686-Live rootfstype=auto ro liveimg quiet rhgb rd_NO_LUKS rd_NO_MD noiswmd BOOT_IMAGE=vmlinuz0 [root@localhost ~]# rpm -qa | grep xorg | egrep "server"\|"-ati" xorg-x11-server-utils-7.4-15.fc13.i686 xorg-x11-drv-ati-6.13.0-0.22.20100208git4f9d1714a.fc13.i686 xorg-x11-server-Xorg-1.7.99.901-8.20100223.fc13.i686 xorg-x11-server-common-1.7.99.901-8.20100223.fc13.i686 I tested it by opening many windows, and running things simultaneously for over an hour. I downloaded and localinstall'ed the latest flash plugin, then opened a firefox window and ran a youtube video (Janacek Sinfonietta final movement) while also running glxgears from a terminal window and playing games. I'm now entering this report from F13 firefox. Is there any chance of backporting the F13 ati driver to F12?
Created attachment 401797 [details] F13 Live CD, ati driver works without nomodeset, dmesg Here's the corresponding dmesg for F13 Live CD.
Please ignore comments 16 and 17. I just re-tested F13 Live CD and I was able to make it fail by setting the power management to put the display to sleep after 1 minute idle, then letting it cycle a few times. The third time, I couldn't bring it back again. The system hung, would not come back, and I couldn't ping it from another system in the lan. So apparently, the ati driver with F13 Live CD does not solve the problem.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. 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 '12'. 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 12'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 12 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