Bug 98907 - commit bf75ef3 causes Xorg lock-up
Summary: commit bf75ef3 causes Xorg lock-up
Status: RESOLVED INVALID
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium critical
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-29 22:09 UTC by Hleb Valoshka
Modified: 2016-12-04 22:41 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Hleb Valoshka 2016-11-29 22:09:18 UTC
I had Mesa snapshot from 2016/11/09 running fine but with one from 2016/11/25 I have Xorg lock-up.

 5248 tty7     Dsl+   0:06 /usr/lib/xorg/Xorg -nolisten tcp -auth /var/run/slim.auth vt07

All other processes run fine, I can connect pc using ssh, but Xorg does not react to keyboard (C+A+F1, C+A+Bs), so the only way to restore system is REISUB, even after reboot command the system doesn't reboot, the screen is blanked so I don't see what's going with it.

I tested this issue only with Black Mesa game from steam.

I can provide the last 20 lines of strace -p <Xorg's pid>, but they look useless.

After git bisect and patch -R I've found a commit causing this issue:

bf75ef3f9201e11bb08a4d03dab20d5ff86f1ebc

Author: Marek Olšák <marek.olsak@amd.com>  2016-11-15 23:15:55
Committer: Marek Olšák <marek.olsak@amd.com>  2016-11-21 23:44:35
Parent: ef6c84b301ce15022d4907dfb0db5764e31e68f5 (radeonsi: eliminate VS outputs that aren't used by PS at run
time)
Child:  c5a654786b5b68c5c215e3bd1bc83b02d7e2a0e9 (swr: [rasterizer memory] minify original sizes for block for
mats)
Branches: debian, master, remotes/origin/master
Follows: 13.0-branchpoint
Precedes: 

    radeonsi: remove all varyings for depth-only rendering or rasterization off
    
    Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com>
    Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Comment 1 Hleb Valoshka 2016-11-29 22:12:17 UTC
My X.org is 1.19.0, my kernel and X11 drivers tested are: 4.9-rc4 + modesetting/amdgpu 1.2.0, 4.9-rc7 + amdgpu 1.2.0. My videocard is HD7750. Dmesg and Xorg.0.log are clean.
Comment 2 Marek Olšák 2016-11-30 00:10:50 UTC
Hi,

Would it be possible to run the game with "GALLIUM_DDEBUG=2000" set, wait for the hang, and attach the file created in ~/ddebug_dumps/ ?
Comment 3 Hleb Valoshka 2016-12-04 20:07:05 UTC
(In reply to Marek Olšák from comment #2)
> Would it be possible to run the game with "GALLIUM_DDEBUG=2000" set, wait
> for the hang, and attach the file created in ~/ddebug_dumps/ ?

When I had run it as "GALLIUM_DDEBUG=2000 ./bms.sh" it started like for the 1st time and now I'm not able to reproduce this issue. Maybe it caches compiled resources? Anyway I've tried 2 other Source powered games and they run without issues as well. So it seems that you can close this ticket as unreproducible.
Comment 4 Marek Olšák 2016-12-04 22:41:24 UTC
Thanks. You can always re-open this if you want.


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.