Bug 506364 - frezze with xorg-x11-drv-ati and my radeon 2100
frezze with xorg-x11-drv-ati and my radeon 2100
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
All Linux
low Severity urgent
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Fedora Extras Quality Assurance
: 487268 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2009-06-16 17:25 EDT by antoine
Modified: 2009-09-06 02:09 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-06 02:05:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description antoine 2009-06-16 17:25:57 EDT
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):

thank's you
Comment 1 Andy Lutomirski 2009-06-20 10:59:17 EDT
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 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.
Comment 2 Andy Lutomirski 2009-06-20 12:50:20 EDT
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.
Comment 3 Andy Lutomirski 2009-07-19 12:27:52 EDT
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 :)
Comment 4 Vedran Miletić 2009-09-06 02:05:43 EDT
Closing per comment #3.
Comment 5 Vedran Miletić 2009-09-06 02:09:09 EDT
*** Bug 487268 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.