Summary: | 3DMark2003 crashes radeon with wine 1.7.26 + gallium nine | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | darkbasic <darkbasic> | ||||||
Component: | DRM/Radeon | Assignee: | Default DRI bug account <dri-devel> | ||||||
Status: | RESOLVED MOVED | QA Contact: | |||||||
Severity: | normal | ||||||||
Priority: | medium | CC: | david | ||||||
Version: | XOrg git | ||||||||
Hardware: | Other | ||||||||
OS: | All | ||||||||
Whiteboard: | |||||||||
i915 platform: | i915 features: | ||||||||
Attachments: |
|
Description
darkbasic
2014-09-12 14:00:22 UTC
Created attachment 106183 [details]
dmesg
Created attachment 106184 [details]
Xorg.0.log
This is 100% reproducible: just start 3DMark2003 with a gallium nine enabled wine (and mesa of course) and it will crash your whole system. (In reply to comment #3) > This is 100% reproducible: just start 3DMark2003 with a gallium nine enabled > wine (and mesa of course) and it will crash your whole system. ^^ very interesting. Would it be possible that I get SSH access to the crashed system? Of course, just give me a few days to setup a test system on another hard disk ;) HD 6550D (r600g) Linux 3.16.1 llvm 3.5 git xorg-server-git mesa git + gallium nine wine 1.7.26 + gallium nine just getting spammed by ... EE r600_state_common.c:751 r600_shader_select - Failed to build shader variant (type=0) -22 EE r600_shader.c:2293 tgsi_unsupported - CLAMP tgsi opcode unsupported EE r600_shader.c:157 r600_pipe_shader_create - translation from TGSI failed ! EE r600_state_common.c:751 r600_shader_select - Failed to build shader variant (type=0) -22 EE r600_shader.c:2293 tgsi_unsupported - CLAMP tgsi opcode unsupported EE r600_shader.c:157 r600_pipe_shader_create - translation from TGSI failed ! ... otherwise OK, i'll try investigate but maybe it's somehow not handled on radeonsi. Does it always happen at the same point in 3DMark2003, or randomly? If the former, can you create an apitrace reproducing the crash? I tried but I get no traces from apitrace 5 and I can't find apitrace 4 binaries anymore: wine ~/Downloads/apitrace-msvc/x86/bin/apitrace.exe trace --api=d3d9 "C:\Program Files (x86)\Futuremark\3DMark03\3DMark03.exe" -nosysteminfo Do you have apitrace 4 for windows? You'd have to use Linux apitrace to trace the Wine process. Even if Windows apitrace can trace Direct3D, the resulting traces wouldn't be useful for the purpose of this bug report. Hmm, of course Linux apitrace won't work either with the nine state tracker... Even if I use linux apitrace and vanilla wine (not nine) it doesn't work: apitrace trace wine Tropics.exe -video_app opengl -sound_app openal -video_fullscreen 1 -video_mode -1 -video_width 1280 -video_height 1024 -data_path ./ -engine_config data/unigine.cfg -system_script tropics/unigine.cpp -extern_define RELEASE On the contrary if I use apitrace with a native app (for example apitrace trace xonotic-sdl) it works flawlessly. Any idea? Christian I sent you and e-mail: if you're still interested I finally managed to setup a testbox and I can give you ssh access to the crashed system as you previously asked. (In reply to darkbasic from comment #12) > Christian I sent you and e-mail: if you're still interested I finally > managed to setup a testbox and I can give you ssh access to the crashed > system as you previously asked. Mhm, looks like that mail neaver reached me. Going to send you a mail back, maybe my spam filter is more graceful to you then. (In reply to Michel Dänzer from comment #10) > Hmm, of course Linux apitrace won't work either with the nine state > tracker... FWIW, I've documented how to obtain D3D9 traces inside WINE on https://github.com/apitrace/apitrace/wiki/WINE#windows-native Fixed in nine state tracker. Probably the crash still happens with old nine. Sorry guys, I forgot to enable nine in my previous test: it still hangs the whole system. By the way I already narrowed this issue down to the 3D engine with Christian Koenig, so no VM or DMA problem here. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/532. |
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.