Summary: | [r600] on new campaign, Vegastrike crashes or freezes Xorg | ||
---|---|---|---|
Product: | Mesa | Reporter: | Nicolas Kaiser <nikai> |
Component: | Drivers/DRI/R600 | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Backtrace
xorg.conf Xorg.0.log PATCH for crash after "valide" dmesg of GPU lockup with shaders dmesg of GPU lockup without shaders |
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.
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.