X windows freezes. Sometimes the screen goes blank, and then returns, repeatedly, with the monitor indicating loss of video signal. The system works to some extent, but doing something as simple as dragging the scrollbar up and down in Firefox ends up making the system completely unresponsive. The message "GPU lockup CP stall for more than 10000msec" is logged. glxgears runs for a second or two, but screen then is drawn with random pixels, and system locks up. The same behavior occurs with Ubuntu 11.04 and Fedora 15. The Catalyst driver (11.6) does not have the problem, except fgl_glxgears produces a very jerky rendering of the gears, and the window takes a second or two to even get painted (tried this on Ubuntu only). Example from /var/log/messages: Jul 25 14:11:19 funky kernel: [ 28.625730] radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec Jul 25 14:11:19 funky kernel: [ 28.625735] ------------[ cut here ]------------ Jul 25 14:11:19 funky kernel: [ 28.625764] WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:269 radeon_fence_wait+0x2a8/0x325 [radeon]() Jul 25 14:11:19 funky kernel: [ 28.625767] Hardware name: h8-1070t Jul 25 14:11:19 funky kernel: [ 28.625769] GPU lockup (waiting for 0x0000008D last fence id 0x00000089) Jul 25 14:11:19 funky kernel: [ 28.625771] Modules linked in: 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf sco bnep l2cap bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm microcode joydev iTCO_wdt serio_raw i2c_i801 iTCO_vendor_support snd_timer snd r8169 xhci_hcd soundcore snd_page_alloc mii ipv6 usb_storage uas radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan] Jul 25 14:11:19 funky kernel: [ 28.625809] Pid: 1181, comm: Xorg Not tainted 2.6.38.8-35.fc15.x86_64 #1 Jul 25 14:11:19 funky kernel: [ 28.625812] Call Trace: Jul 25 14:11:19 funky kernel: [ 28.625820] [<ffffffff8105511a>] warn_slowpath_common+0x83/0x9b Jul 25 14:11:19 funky kernel: [ 28.625824] [<ffffffff810551d5>] warn_slowpath_fmt+0x46/0x48 Jul 25 14:11:19 funky kernel: [ 28.625850] [<ffffffffa00d86c5>] ? evergreen_gpu_is_lockup+0xba/0xc2 [radeon] Jul 25 14:11:19 funky kernel: [ 28.625870] [<ffffffffa009fdff>] radeon_fence_wait+0x2a8/0x325 [radeon] Jul 25 14:11:19 funky kernel: [ 28.625875] [<ffffffff8106f26e>] ? autoremove_wake_function+0x0/0x3d Jul 25 14:11:19 funky kernel: [ 28.625893] [<ffffffffa00a03b9>] radeon_sync_obj_wait+0x11/0x13 [radeon] Jul 25 14:11:19 funky kernel: [ 28.625901] [<ffffffffa00655da>] ttm_bo_wait+0xbf/0x17a [ttm] Jul 25 14:11:19 funky kernel: [ 28.625908] [<ffffffffa0066002>] ? ttm_bo_list_ref_sub+0x29/0x2b [ttm] Jul 25 14:11:19 funky kernel: [ 28.625931] [<ffffffffa00b006b>] radeon_bo_wait+0x7b/0x9f [radeon] Jul 25 14:11:19 funky kernel: [ 28.625953] [<ffffffffa00b05dd>] radeon_gem_wait_idle_ioctl+0x3d/0x74 [radeon] Jul 25 14:11:19 funky kernel: [ 28.625964] [<ffffffffa0019861>] drm_ioctl+0x29e/0x37b [drm] Jul 25 14:11:19 funky kernel: [ 28.625969] [<ffffffff811eb0f7>] ? inode_has_perm+0x76/0x8c Jul 25 14:11:19 funky kernel: [ 28.625990] [<ffffffffa00b05a0>] ? radeon_gem_wait_idle_ioctl+0x0/0x74 [radeon] Jul 25 14:11:19 funky kernel: [ 28.625996] [<ffffffff81476e98>] ? _cond_resched+0xe/0x22 Jul 25 14:11:19 funky kernel: [ 28.626001] [<ffffffff8104127e>] ? should_resched+0xe/0x2d Jul 25 14:11:19 funky kernel: [ 28.626005] [<ffffffff8104127e>] ? should_resched+0xe/0x2d Jul 25 14:11:19 funky kernel: [ 28.626009] [<ffffffff811eb1b1>] ? file_has_perm+0xa4/0xc6 Jul 25 14:11:19 funky kernel: [ 28.626013] [<ffffffff8112f3ac>] do_vfs_ioctl+0x47e/0x4bf Jul 25 14:11:19 funky kernel: [ 28.626018] [<ffffffff8109fc99>] ? audit_syscall_exit+0x12d/0x148 Jul 25 14:11:19 funky kernel: [ 28.626021] [<ffffffff8112f443>] sys_ioctl+0x56/0x7b Jul 25 14:11:19 funky kernel: [ 28.626026] [<ffffffff81009e75>] ? int_check_syscall_exit_work+0x34/0x3d Jul 25 14:11:19 funky kernel: [ 28.626030] [<ffffffff81009bc2>] system_call_fastpath+0x16/0x1b Jul 25 14:11:19 funky kernel: [ 28.626033] ---[ end trace e3b1afa8f60cb0a1 ]--- Jul 25 14:11:19 funky kernel: [ 28.627143] radeon 0000:01:00.0: GPU softreset Jul 25 14:11:19 funky kernel: [ 28.627147] radeon 0000:01:00.0: GRBM_STATUS=0xF5701828 Jul 25 14:11:19 funky kernel: [ 28.627150] radeon 0000:01:00.0: GRBM_STATUS_SE0=0xFC000003 Jul 25 14:11:19 funky kernel: [ 28.627152] radeon 0000:01:00.0: GRBM_STATUS_SE1=0x00000003 Jul 25 14:11:19 funky kernel: [ 28.627155] radeon 0000:01:00.0: SRBM_STATUS=0x200006C0 Jul 25 14:11:20 funky kernel: [ 28.781777] radeon 0000:01:00.0: Wait for MC idle timedout ! Jul 25 14:11:20 funky kernel: [ 28.781781] radeon 0000:01:00.0: GRBM_SOFT_RESET=0x00007F6B Jul 25 14:11:20 funky kernel: [ 28.781885] radeon 0000:01:00.0: GRBM_STATUS=0x00003828 Jul 25 14:11:20 funky kernel: [ 28.781888] radeon 0000:01:00.0: GRBM_STATUS_SE0=0x00000007 Jul 25 14:11:20 funky kernel: [ 28.781891] radeon 0000:01:00.0: GRBM_STATUS_SE1=0x00000007 Jul 25 14:11:20 funky kernel: [ 28.781893] radeon 0000:01:00.0: SRBM_STATUS=0x200006C0 Jul 25 14:11:20 funky kernel: [ 28.782897] radeon 0000:01:00.0: GPU reset succeed Jul 25 14:11:20 funky kernel: [ 28.990212] radeon 0000:01:00.0: Wait for MC idle timedout ! Jul 25 14:11:20 funky kernel: [ 29.174553] radeon 0000:01:00.0: Wait for MC idle timedout ! Jul 25 14:11:20 funky kernel: [ 29.176759] radeon 0000:01:00.0: WB enabled Jul 25 14:11:20 funky kernel: [ 29.193106] [drm] ring test succeeded in 2 usecs Jul 25 14:11:20 funky kernel: [ 29.193120] [drm] ib test succeeded in 3 usecs
Please try a 3.0 kernel. If that doesn't help, try this patch as well: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=4639dd21e759e32125adc7171abf6cb8140d54cf
Created attachment 49628 [details] kern.log with 3.0 kernel Same behavior with the 3.0 kernel. Will try 3.0 plus patch next. Attachment shows messages. The last series of messages repeated indefinitely with display hung...
Does upgrading the ddx (xf86-video-ati) as well help?
A custom 3.0 kernel with the small patch does not change the problem. Will try building the ddx from git.
I built xf86-video-ati from the git sources. This introduced a new problem in X windows where the pixels are offset so that the display looks like very out of focus (fonts are not readable). Basically just built the driver with a --prefix option. It seems it may take a bit more effort to induce the problem with the 3.0 kernel, but it is a bit inconsistent, so presumably there is an asynchronous aspect to this problem. Happy to try more, but I need a bit of guidance.
You might try an updated mesa as well.
r600g being the relevant 3D driver for your card.
Built mesa from git. Required several other updates as well. Ubuntu would not start unity (just reverted to login screen). Ubuntu classic (no effects) did start. glxgears ran at 2500 frame rate, whereas before it ran at vertical sync. But at least the screen was painted correctly with the new mesa. But eventually screen froze as before. Not sure I can do anymore -- just not experienced enough with this system stuff to have any confidence that I characterize the problem any better ;(
For confirmation sake, this is the identical issue I am having (exact same system - mobo, gpu, etc)
Just wanted to add another +1, here with a radeon hd 6870. The symptoms and the logs are very similar, including the video signal going away and then coming back. I've experienced the problem with the latest stable mesa/xf86-video-ati/xorg-server verions and on both kernels 3.0 and 3.1-rc4. I'm available to try patches, git snapshots etc. as needed.
A very similar problem I've been having on HD6850 since last spring seems to have been fixed somewhere around kernel 3.0.7, mesa 7.11, video-ati 6.14.2 and xorg-server 1.11.1.901. Previously running Blender would always cause a lockup in under half a minute but for a couple of days I haven't been able to induce a lockup in any way.
Closing reopen if it's still an issue with kernel 3.2 or newer and with mesa 8.0 or newer
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.