Bug 90523 - Easily reproducible GPU lockup (verde) with any mesa 10.5.x
Summary: Easily reproducible GPU lockup (verde) with any mesa 10.5.x
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: 10.5
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-19 19:12 UTC by acab
Modified: 2015-05-22 21:41 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
dmesg (19.77 KB, application/gzip)
2015-05-19 19:58 UTC, acab
Details
xorg.log (6.79 KB, application/gzip)
2015-05-19 19:59 UTC, acab
Details

Note You need to log in before you can comment on or make changes to this bug.
Description acab 2015-05-19 19:12:13 UTC
A few seconds into certain games the GPU locks up and X crashes.
The same happens (albeit not as quickly) under other circumstances like playing a video in a browser.
Last known good configuration is mesa 10.4.6.
Known bad configurations: 10.5.1, 10.5.2, 10.5.4, 10.5.5.

Are there any steps to follow to help diagnose the issue?
Comment 1 Alex Deucher 2015-05-19 19:20:10 UTC
Please attach your xorg log and dmesg output.
Comment 2 acab 2015-05-19 19:56:40 UTC
I am sorry, but while trying to get a crash I've realized it's not mesa.
The culprit appears to be llvm.

In short:
llvm 3.5.2 + mesa 10.5.5 -> ok
llvm 3.6.0 + mesa 10.5.5 -> lockup

I'm going to attach the logs anyway.
Feel free to close this bug if it doesn't belong in here.
Comment 3 acab 2015-05-19 19:58:13 UTC
Created attachment 115900 [details]
dmesg
Comment 4 acab 2015-05-19 19:59:01 UTC
Created attachment 115901 [details]
xorg.log
Comment 5 Michel Dänzer 2015-05-20 01:17:54 UTC
Can you try isolating the LLVM change introducing it with git bisect? Note that this might require some tweaking because current Mesa might fail to build against some development snapshots of LLVM.
Comment 6 acab 2015-05-20 13:51:25 UTC
(In reply to Michel Dänzer from comment #5)
> Can you try isolating the LLVM change introducing it with git bisect? Note
> that this might require some tweaking because current Mesa might fail to
> build against some development snapshots of LLVM.

Yes I could, however upsteam appears to maintain llvm in svn.
There is a git repository as well but it lacks branches and tags.

Additionally the branch history doesn't look very linear and so far i've failed to match the proper commit from the branch in master.
For example the top commit in http://llvm.org/svn/llvm-project/llvm/tags/RELEASE_352/final is:
------------------------------------------------------------------------
r214336 | rafael.espindola | 2014-07-30 17:04:00 -0400 (Wed, 30 Jul 2014) | 9 lines

SimplifyCFG: Avoid miscompilations due to removed lifetime intrinsics.

Which appears to match commit 7fef5a3d1907c813712fcb2a44d8187a65ba08cd:
Author: Rafael Espindola <rafael.espindola@gmail.com>
Date:   Wed Jul 30 21:04:00 2014 +0000

    SimplifyCFG: Avoid miscompilations due to removed lifetime intrinsics.


However mesa 10.5.5 doesn't build against that llvm (doesn't like TM->getSubtargetImpl()->getInstrInfo() in lp_bld_debug.cpp), but it does build against 3.5.2.


Can you suggest some commit ids i could use as good and bad markers?
Comment 7 Michel Dänzer 2015-05-21 02:23:02 UTC
(In reply to acab from comment #6)
> Yes I could, however upsteam appears to maintain llvm in svn.
> There is a git repository as well but it lacks branches and tags.

The Git repository at http://llvm.org/git/llvm.git does have the release branches. Also, the SVN revision number is included in the Git commit log, so it's easy to find the Git commit corresponding to a given SVN revision e.g. in gitk.


> r214336 | rafael.espindola | 2014-07-30 17:04:00 -0400 (Wed, 30 Jul 2014) |
> 9 lines
> 
> SimplifyCFG: Avoid miscompilations due to removed lifetime intrinsics.
> 
> Which appears to match commit 7fef5a3d1907c813712fcb2a44d8187a65ba08cd:
> [...]
> However mesa 10.5.5 doesn't build against that llvm (doesn't like
> TM->getSubtargetImpl()->getInstrInfo() in lp_bld_debug.cpp), but it does
> build against 3.5.2.

7fef5a3d1907c813712fcb2a44d8187a65ba08cd is on the master branch. The corresponding commit on the release_35 branch is a4cf325e41fca33c7ce7deef39a7bcf25fb38266.

However, as I mentioned before, you most likely will run into more similar issues during the bisection, because Mesa can only test for minor versions of LLVM, not for individual revisions. You may need to tweak the Mesa code to make it build in some cases.
Comment 8 acab 2015-05-22 20:33:06 UTC
Bisecting across llvm major releases was a total pain in the arse, but then I've realized that the bug was fixed recently in the 3.6 branch so I've given up.

If it helps, i can tell you that the bug was fixed here (mind you good and bad are reversed):
$ git bisect good
b5344bfff41583c00026e321d6831d4e8790b309 is the first bad commit
commit b5344bfff41583c00026e321d6831d4e8790b309
Author: Tom Stellard <thomas.stellard@amd.com>
Date:   Mon May 4 19:50:17 2015 +0000

    Merging r236307:
    
    ------------------------------------------------------------------------
    r236307 | thomas.stellard | 2015-04-30 23:44:09 -0400 (Thu, 30 Apr 2015) | 4 lines
    
    R600/SI: Add VCC as an implict def of SI_KILL
    
    When SI_KILL has a register operand, its lowered form writes to vcc.
    
    ------------------------------------------------------------------------

Feel free to close the bug.
Thanks.


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.