Created attachment 35318 [details] Backtrace While other OpenGL applications are running without problem (extreme-tuxracer, emilia-pinball, xscreensaver), Vegastrike will either crash or freeze Xorg when starting a new campaign. When Xorg freezes it becomes unkillable, with Vegastrike and Xorg at 100% CPU, and I need to ssh into to restart. Gentoo Linux, amd64, ATI HD3200 (780G) xorg-server-1.7.6 x11-libs/libdrm-2.4.18_pre20100211-r1 xf86-video-ati-6.13.0 mesa-7.7.1 vegastrike svn The same happens with vegastrike-0.5.0. Backtrace of crash, xorg.conf, Xorg log attached.
Created attachment 35319 [details] xorg.conf
Created attachment 35320 [details] Xorg.0.log
Current status: Upgrading from UMS with 2.6.33.2 to KMS with 2.6.33.3, along with rebuilding sound library dependencies with alsa support only (along the lines of https://bugzilla.redhat.com/show_bug.cgi?id=522677 ) drastically reduced my problems. * With shaders disabled and KMS, I don't experience any problems. (Hooray!) * With shaders disabled and UMS, I had been able to run the game for a short while before crashing. Once I got a bo(0x7f8e3e129fc0, 65536) is mapped (-1) can't valide it. invalid bo(0x7f8e3e129fc0) [0xD0890000, 0xD0891000] Btw, I guess that should be /valide/validate/ in radeon_bo_legacy.c * With any shader enabled, the machine will completely lock up with KMS, while with UMS Xorg had frozen.
Created attachment 35497 [details] [review] PATCH for crash after "valide" PATCH: I have run into a crash after a "cannot valide it" warning. The unmap function in radeon_bo_legacy is called sometimes when the memory is no longer mapped. The radeon_bo_legacy->map_count goes negative which means statements like if (radeon_bo_legacy->map_count) ... will return true. The attached patch prevents the count from going negative and fixes the crash for me. Crash was with the r200 driver (Radeon 9250SE) playing UrbanTerror using UMS. I made the patch using the Ubuntu Lucid 10.04 source package. Bobby
Created attachment 37242 [details] dmesg of GPU lockup with shaders KMS r600 classic: GPU lockup on new campaign with "simplest shader" support. Call Trace: [<ffffffff810317d3>] ? warn_slowpath_common+0x78/0x8c [<ffffffff81031886>] ? warn_slowpath_fmt+0x45/0x4a [<ffffffffa00a67b1>] ? r100_gpu_cp_is_lockup+0x8c/0x96 [radeon] [<ffffffffa008d705>] ? radeon_fence_wait+0x235/0x2d3 [radeon] [<ffffffff81044861>] ? autoremove_wake_function+0x0/0x2a [<ffffffffa009e600>] ? radeon_gem_set_tiling_ioctl+0x77/0x78 [radeon] [<ffffffffa005669c>] ? ttm_bo_wait+0xc7/0x16e [ttm] [<ffffffffa009e601>] ? radeon_gem_wait_idle_ioctl+0x0/0x103 [radeon] [<ffffffffa009e6b7>] ? radeon_gem_wait_idle_ioctl+0xb6/0x103 [radeon] [<ffffffffa001c4eb>] ? drm_ioctl+0x211/0x2f2 [drm] [<ffffffff811d9017>] ? prio_tree_remove+0xb7/0xbf [<ffffffff810248b3>] ? flush_tlb_others_ipi+0xab/0xe1 [<ffffffff81088553>] ? free_pages_and_swap_cache+0x1e/0xa4 [<ffffffff810a43e6>] ? vfs_ioctl+0x23/0x93 [<ffffffff810a48a8>] ? do_vfs_ioctl+0x3e0/0x417 [<ffffffff8107fd83>] ? remove_vma+0x64/0x6c [<ffffffff81080f41>] ? do_munmap+0x2d9/0x2fb [<ffffffff810a491b>] ? sys_ioctl+0x3c/0x5c [<ffffffff81001e6b>] ? system_call_fastpath+0x16/0x1b System environment: -- system architecture: amd64 -- Linux distribution: Gentoo -- GPU: RS780G -- Model: ATI Radeon HD 3200 -- Display connector: VGA -- xf86-video-ati: 06691376b1ee963c711420edaf5a03eab6f5658f -- xserver: 1.7.6 -- mesa: 41bcd8cb1ee93209d38af7b47a158d20a6c5ae11 -- drm: b803918f3f77c62edf22e78cb2095be399753423 -- kernel: 2.6.35-rc5-00076-gd0c6f62
Created attachment 37243 [details] dmesg of GPU lockup without shaders KMS r600 classic: Without shaders, the game is playable at up to 30fps, until the GPU locks up - either approaching a mining base ('Serenity'), [see dmesg] - or when the ship gets destroyed. Call Trace: [<ffffffff810317d3>] ? warn_slowpath_common+0x78/0x8c [<ffffffff81031886>] ? warn_slowpath_fmt+0x45/0x4a [<ffffffffa00a67b1>] ? r100_gpu_cp_is_lockup+0x8c/0x96 [radeon] [<ffffffffa008d705>] ? radeon_fence_wait+0x235/0x2d3 [radeon] [<ffffffff81044861>] ? autoremove_wake_function+0x0/0x2a [<ffffffffa009f528>] ? radeon_ib_get+0x130/0x20d [radeon] [<ffffffffa00a01ff>] ? radeon_cs_ioctl+0x0/0x191 [radeon] [<ffffffffa00a0280>] ? radeon_cs_ioctl+0x81/0x191 [radeon] [<ffffffffa001c4eb>] ? drm_ioctl+0x211/0x2f2 [drm] [<ffffffff81021011>] ? do_page_fault+0x2b5/0x2ee [<ffffffff810a43e6>] ? vfs_ioctl+0x23/0x93 [<ffffffff810a48a8>] ? do_vfs_ioctl+0x3e0/0x417 [<ffffffff810a491b>] ? sys_ioctl+0x3c/0x5c [<ffffffff81001e6b>] ? system_call_fastpath+0x16/0x1b System environment: -- system architecture: amd64 -- Linux distribution: Gentoo -- GPU: RS780G -- Model: ATI Radeon HD 3200 -- Display connector: VGA -- xf86-video-ati: 06691376b1ee963c711420edaf5a03eab6f5658f -- xserver: 1.7.6 -- mesa: 41bcd8cb1ee93209d38af7b47a158d20a6c5ae11 -- drm: b803918f3f77c62edf22e78cb2095be399753423 -- kernel: 2.6.35-rc5-00076-gd0c6f62
Benchmark 2 of progs/demos/gltestperf locks up my RS780G with a quite similar dump, which might make these lockups a potential duplicate of bug 25717.
Increasing the timeout values for GPU lockups didn't have an effect on these lockups. In comparison, I noticed that by increasing the timeout values in radeon/r100.c, r100_gpu_cp_is_lockup from 3 and 1 seconds to 10 and 8 seconds, gltestperf completed successfully without lockup. With mesa-git (plus color field patch set by Luca Barbieri, for bug 29644), the gpu lockups have disappeared since GLSL2. Now instead I'm merely receiving warnings, and lots of them: radeon 0000:01:05.0: vbo resource seems too big for the bo Other issues I see neither segfault, nor lock up the GPU. They might warrant filing separate bugs, but appear not to be related to the initial scope of this bug report.
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.