https://bugs.freedesktop.org/show_bug.cgi?id=35051
Summary: [r600g, Wine, Counter Strike Source] Crashes at Startup Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: bpaterni@gmail.com
Created an attachment (id=44162) --> (https://bugs.freedesktop.org/attachment.cgi?id=44162) wine output
I have a similar bug to this one at the winehq bugtracker, but I think it pertains more to mesa now.
As the title states, counter strike source crashes at start up for me. A full log of wine's output will be attached.
I think this bug is related to the r600 gallium driver because the game does load, play, and display with gallium's softpipe driving it, although it is painfully slow.
Also I believe the critical section of the log is the following:
trace:dbghelp:get_wine_loader_name returning L"wine" trace:dbghelp:elf_load_file Processing elf file 'L"wine"' at 00000000 trace:dbghelp:elf_load_file Processing elf file 'L".//wine"' at 00000000 trace:dbghelp:elf_load_file Processing elf file 'L"/home/bpaterni/bin/wine"' at 00000000 trace:dbghelp:elf_load_file Processing elf file 'L"/usr/local/bin/wine"' at 00000000 trace:dbghelp:SymFromName (0xffffffff, libwine.so.1!__wine_main_environ, 0xffed654) trace:dbghelp:SymFromName null process fixme:dbghelp:elf_search_auxv can't find symbol in module Inconsistency detected by ld.so: dl-deps.c: 626: _dl_map_object_deps: Assertion `nlist > 1' failed!
I've looked through wine's source and elf_search_auxv is being called from MiniDumpWriteDump in dlls/dbghelp/minidump.c which apparently is being called from within steam/counter strike. Because of this, I'm not sure how to proceed in debugging since steam/counter strike are both closed. Hopefully someone here has a clever idea on getting to the bottom of this...
environment: Linux kernel (git master, linus' tree -- although I have tried drm-next + s3tc, same result)
Debian unstable/experimental mesa (git master @ f95892b46a9a6b5d90437998ef9a3babd55e9c7d) wine (git master)
https://bugs.freedesktop.org/show_bug.cgi?id=35051
--- Comment #1 from Henri Verbeet hverbeet@gmail.com 2011-03-08 05:02:19 PST --- I'm able to at least run the CS:S stress tests with current git versions of Wine and r600g on Evergreen, although rendering correctness and performance still have some way to go. The "Inconsistency detected by ld.so: ..." line in the log looks suspicious, although it's unclear to me if it's related to the cause of the crash. Normally when source engine games crash they write a minidump in "dumps" in your Steam directory, you can open those with winedbg to get a backtrace. The dbghelp FIXME and ld.so message make me suspect it might have failed to produce a usable minidump this time though.
https://bugs.freedesktop.org/show_bug.cgi?id=35051
--- Comment #2 from Tobias Jakobi liquid.acid@gmx.net 2011-03-08 07:06:25 PST --- Hmm, I have a similar problem will all Steam games (which are mostly HL2-engine based). After starting a game, when the loading process finishes, the game immediately exits.
@Henri: Does starting a new game in HL2 work for you? Maybe also with forcing dxlevel 8.
https://bugs.freedesktop.org/show_bug.cgi?id=35051
Jerome Glisse glisse@freedesktop.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|[r600g, Wine, Counter |[RADEON:KMS:R600G] wine |Strike Source] Crashes at |Counter Strike Source |Startup |Crashes at Startup
https://bugs.freedesktop.org/show_bug.cgi?id=35051
--- Comment #3 from Henri Verbeet hverbeet@gmail.com 2011-03-08 12:56:10 PST --- (In reply to comment #2)
@Henri: Does starting a new game in HL2 work for you? Maybe also with forcing dxlevel 8.
It does, though I haven't tried with dxlevel 8. If you're running into winehq bug 24064 that's a different issue though.
https://bugs.freedesktop.org/show_bug.cgi?id=35051
--- Comment #4 from Tobias Jakobi liquid.acid@gmx.net 2011-03-09 01:56:45 PST --- Yes, I was hitting the GameOverlayRenderer bug. However after hotfixing this, dxlevel 81 is still the farthest I can go. All DX9 render paths either cause GPu resets or crash the kernel.
@Henri: Which dxlevel have you selected (what does mat_dxlevel say)?
https://bugs.freedesktop.org/show_bug.cgi?id=35051
--- Comment #5 from Henri Verbeet hverbeet@gmail.com 2011-03-09 13:20:36 PST --- (In reply to comment #4)
Yes, I was hitting the GameOverlayRenderer bug. However after hotfixing this, dxlevel 81 is still the farthest I can go. All DX9 render paths either cause GPu resets or crash the kernel.
@Henri: Which dxlevel have you selected (what does mat_dxlevel say)?
I didn't explicitly select anything, but mat_dxlevel is at 95. For reference, what kernel and hardware are you using?
https://bugs.freedesktop.org/show_bug.cgi?id=35051
--- Comment #6 from Tobias Jakobi liquid.acid@gmx.net 2011-03-10 00:37:09 PST --- Radeon HD 4770 [RV740] with the latest d-r-t
https://bugs.freedesktop.org/show_bug.cgi?id=35051
--- Comment #7 from Brian Paterni bpaterni@gmail.com 2011-03-11 17:59:30 PST --- (In reply to comment #1)
The "Inconsistency detected by ld.so: ..." line in the log looks suspicious, although it's unclear to me if it's related to the cause of the crash.
I wonder if that line has something to do with the libc6 (2.13-0exp3) I have installed from Debian's experimental repos...
Normally when source engine games crash they write a minidump in "dumps" in your Steam directory, you can open those with winedbg to get a backtrace. The dbghelp FIXME and ld.so message make me suspect it might have failed to produce a usable minidump this time though.
I believe you are correct, Steam is writing minidumps in dumps/, but winedbg doesn't appear to be of any help. Though 'bt' does report "Exception c0000005" if that is of any significance?
https://bugs.freedesktop.org/show_bug.cgi?id=35051
--- Comment #8 from Brian Paterni bpaterni@gmail.com 2011-05-15 14:10:45 PDT --- Update: CS: Source now successfully boots up to the menu! However I'm unsure whether this is due to fix in mesa, wine, or libc6.
Though now if I attempt to start and load a game from the menu, everything appears to go though smoothly until the last few bits are initialized. From there I'm put into a loop of GPU lockups and GPU resets. Therefore this bug may be related to #36421 now. The game still renders the match welcome screen throughout these GPU lockup/reset cycles though, and I am able to eventually switch to different workspace to kill the cstrike process.
Additionally, the in game stress test renders reasonably well until the camera begins to enter the room with the transparent player model with flames behind it (forgive me if I'm not using the correct terminology). At this point (before the flames "turn on") the stress test freezes and goes into the gpu reset loop described above.
https://bugs.freedesktop.org/show_bug.cgi?id=35051
--- Comment #9 from Brian Paterni bpaterni@gmail.com 2011-05-15 14:13:49 PDT --- Created an attachment (id=46749) --> (https://bugs.freedesktop.org/attachment.cgi?id=46749) css kernel backtraces
https://bugs.freedesktop.org/show_bug.cgi?id=35051
--- Comment #10 from Tobias Jakobi liquid.acid@gmx.net 2011-05-16 05:54:40 PDT --- I'm pretty sure you're seeing the common GPU reset problems when using the HL2 engine DX9 renderpath. So yes, that's the bug #36421 you already mentioned.
https://bugs.freedesktop.org/show_bug.cgi?id=35051
--- Comment #11 from Brian Paterni bpaterni@gmail.com 2011-05-16 09:15:04 PDT --- Thanks for the confirmation there.
I did end up running Steam/CS: Source through zach rusin's apitrace tool, getting the following trace:
http://uploading.com/files/1213aed2/css.glapi.trace/
the erroneous call seems to be
235567 glDrawBuffer(mode = GL_BACK) 235567: warning: glGetError(glDrawBuffer) = GL_INVALID_OPERATION Mesa: User error: GL_INVALID_OPERATION in glDrawBuffer(buffer=0x405)
Hopefully this helps greatly in the debugging process. :)
https://bugs.freedesktop.org/show_bug.cgi?id=35051
Brian Paterni bpaterni@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME
--- Comment #12 from Brian Paterni bpaterni@gmail.com 2011-06-22 17:47:29 PDT --- I'm going to go ahead and close this bug since it is no longer reproducible on my system.
The issue for me now is bug 38581
https://bugs.freedesktop.org/show_bug.cgi?id=35051
--- Comment #13 from Tobias Jakobi liquid.acid@gmx.net 2011-06-23 02:47:10 PDT --- I presume this was fixed by: http://cgit.freedesktop.org/mesa/mesa/commit/?id=04554c7d3a3b28e8103e50ed54f...
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org