escription of problem: 5 min after pc boot my fedora freez. Xorg use 100% of processor my dmesg http://dev.ati06.com/log/dmesg.txt my messages http://dev.ati06.com/log/messages.txt and my Xorg.0.log http://dev.ati06.com/log/Xorg.0.log Version-Release number of selected component (if applicable): xorg-x11-drv-ati-6.12.2-14.fc11.x86_64 thank's you
Here's a "me too" with more details. I have a radeon 2100, which is the internal graphics chip on on RS690, on a Gigabyte GA-MA74GM-S2 (note that the mobo is a piece of junk, and I'm running old BIOS which can't even reliably boot an operating system. I'll try a BIOS upgrade later, but last time I tried a newer BIOS it didn't help the graphics situation and it broke my MAC address.) If I boot with modesetting on, everything works until I start X. Then I get a screen full of garbage -- it looks like the Fedora 11 splash screen with all the pixels in the wrong place, and the mouse will work for a few seconds and then freeze. At this point the only way to recover is to kill -9 X, which works, but after a few cycles of that the system dies. If I boot with nomodeset, X starts, but it's very unreliable. No matter what I do, X takes 100% CPU. If I enable compositing (using kwin) or change any compositing setting, everything except the desktop background vanishes and will not come back (100% reproducible). Ctrl-alt-backspace and vt switching stop working, and the kernel starts spewing locking errors. If I kill -9 X and restart it, compositing works until I change any compositing-related setting, and then it dies again. With compositing off, it worked for awhile, and then X froze and the mouse started stuttering. When this happened, systemsettings and X were both unkillable and taking 100% CPU. Sysrq-t said: systemsetting R running task 0 11921 1 00000000000007da ffffffffffffff10 ffffffff8101780e 0000000000000010 0000000000000206 ffff8800cc4e9a58 0000000000000018 ffff8800cc4e9a78 ffffffff811b90ae ffff880124db8800 00000000000036aa ffff8801252b4000 Call Trace: [<ffffffff8101780e>] ? native_read_tsc+0x15/0x16 [<ffffffff811b90ae>] ? delay_tsc+0x28/0x5a [<ffffffff811b900f>] ? __delay+0xf/0x11 [<ffffffff811b9059>] ? __const_udelay+0x48/0x4a [<ffffffffa004a4bb>] ? radeon_do_wait_for_idle+0x46/0x109 [radeon] [<ffffffffa004ae07>] ? radeon_do_cp_idle+0x12d/0x131 [radeon] [<ffffffffa004d472>] ? radeon_do_release+0xa9/0x1bf [radeon] [<ffffffffa00546d5>] ? radeon_driver_lastclose+0x52/0x5b [radeon] [<ffffffffa0012dd0>] ? drm_lastclose+0x4c/0x2b4 [drm] [<ffffffffa00134da>] ? drm_release+0x495/0x4d0 [drm] [<ffffffff810d61c4>] ? __fput+0xf9/0x1a0 [<ffffffff810d6285>] ? fput+0x1a/0x1c [<ffffffff810d35c5>] ? filp_close+0x68/0x72 [<ffffffff8104a5f9>] ? put_files_struct+0x6c/0xc3 [<ffffffff8104a692>] ? exit_files+0x42/0x47 [<ffffffff8104c050>] ? do_exit+0x210/0x834 [<ffffffff8104c702>] ? do_group_exit+0x8e/0xbe [<ffffffff81055dab>] ? get_signal_to_deliver+0x35f/0x38b [<ffffffff810104b2>] ? do_notify_resume+0x94/0x92a [<ffffffff810d5137>] ? do_sync_read+0xe8/0x125 [<ffffffff8105ca4b>] ? autoremove_wake_function+0x0/0x39 [<ffffffff81062f7c>] ? clocksource_read+0xc/0xe [<ffffffff81063208>] ? getnstimeofday+0x5f/0xb3 [<ffffffff8105facc>] ? ktime_get_ts+0x4e/0x53 [<ffffffff810dca60>] ? path_put+0x22/0x26 [<ffffffff81011492>] ? sysret_signal+0x9b/0x109 X R running task 0 12734 3929 ffff88010519fdd8 0000000000000082 ffffffff810177ff 0000000000000010 0000000000000246 ffffffff81782300 ffff8800845f8368 ffff8800845f8370 ffffffff81782300 0000000024db8800 ffff8800adcd4500 ffff8800845f8000 Call Trace: [<ffffffff810177ff>] ? native_read_tsc+0x6/0x16 [<ffffffff811b900f>] ? __delay+0xf/0x11 [<ffffffff811b9059>] ? __const_udelay+0x48/0x4a [<ffffffffa004a4bb>] ? radeon_do_wait_for_idle+0x46/0x109 [radeon] [<ffffffffa004d46a>] radeon_do_release+0xa1/0x1bf [radeon] [<ffffffffa00546d5>] radeon_driver_lastclose+0x52/0x5b [radeon] [<ffffffffa0012dd0>] drm_lastclose+0x4c/0x2b4 [drm] [<ffffffffa00134da>] drm_release+0x495/0x4d0 [drm] [<ffffffff810d61c4>] __fput+0xf9/0x1a0 [<ffffffff810d6285>] fput+0x1a/0x1c [<ffffffff810d35c5>] filp_close+0x68/0x72 [<ffffffff810d367b>] sys_close+0xac/0xea [<ffffffff8101133a>] system_call_fastpath+0x16/0x1b After awhile, I got a kernel message telling me that I had a recursive fault and I should reboot. This is kernel 2.6.29.4-167.fc11.x86_64 with xorg-x11-drv-ati-6.12.2-17.fc11.x86_64 (koji, I think). The modesetting situation is vastly improved from F10 -- in F10, modesetting would hang hard immediately after the kernel got far enough to try to set a mode. Sounds like a kernel drm bug to me.
2.6.31-0.11.rc0.git13.fc12.x86_64 from rawhide fails to boot. The kernel reports a bad page table for plymouthd. I'm building a mainline modesetting kernel from git now.
All stability issues seem to be fixed in a recent kernel.org (2.6.31 from git) build. As far as I'm concerned, this bug can be closed now (if no F11 backport is planned) or whenever the 2.6.31 radeon driver gets backported (otherwise). Thanks everyone for your hard work :)
Closing per comment #3.
*** Bug 487268 has been marked as a duplicate of this bug. ***