Bug 35051 - [RADEON:KMS:R600G] wine Counter Strike Source Crashes at Startup
Summary: [RADEON:KMS:R600G] wine Counter Strike Source Crashes at Startup
Status: RESOLVED WORKSFORME
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r600 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-05 20:39 UTC by Brian Paterni
Modified: 2011-06-23 02:47 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
wine output (10.84 KB, application/octet-stream)
2011-03-05 20:39 UTC, Brian Paterni
Details
css kernel backtraces (51.78 KB, text/x-log)
2011-05-15 14:13 UTC, Brian Paterni
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Brian Paterni 2011-03-05 20:39:12 UTC
Created attachment 44162 [details]
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)
Comment 1 Henri Verbeet 2011-03-08 05:02:19 UTC
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.
Comment 2 Tobias Jakobi 2011-03-08 07:06:25 UTC
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.
Comment 3 Henri Verbeet 2011-03-08 12:56:10 UTC
(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.
Comment 4 Tobias Jakobi 2011-03-09 01:56:45 UTC
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)?
Comment 5 Henri Verbeet 2011-03-09 13:20:36 UTC
(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?
Comment 6 Tobias Jakobi 2011-03-10 00:37:09 UTC
Radeon HD 4770 [RV740] with the latest d-r-t
Comment 7 Brian Paterni 2011-03-11 17:59:30 UTC
(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?
Comment 8 Brian Paterni 2011-05-15 14:10:45 UTC
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.
Comment 9 Brian Paterni 2011-05-15 14:13:49 UTC
Created attachment 46749 [details]
css kernel backtraces
Comment 10 Tobias Jakobi 2011-05-16 05:54:40 UTC
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.
Comment 11 Brian Paterni 2011-05-16 09:15:04 UTC
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. :)
Comment 12 Brian Paterni 2011-06-22 17:47:29 UTC
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
Comment 13 Tobias Jakobi 2011-06-23 02:47:10 UTC
I presume this was fixed by:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=04554c7d3a3b28e8103e50ed54f1ac57c6c11017


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.