Bug 105288 - [snb] hanging in Shadow Warrior Classic Redux
Summary: [snb] hanging in Shadow Warrior Classic Redux
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-28 10:53 UTC by gwaewion
Modified: 2019-09-25 19:09 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
from /sys/class/drm/card0/error (40.22 KB, text/plain)
2018-02-28 10:53 UTC, gwaewion
Details

Description gwaewion 2018-02-28 10:53:01 UTC
Created attachment 137685 [details]
from /sys/class/drm/card0/error

random hanging in SW. laptop lenovo x220. os - arch linux.

dmesg output:

[ 1494.760722] [drm] GPU HANG: ecode 6:0:0x85fffffc, in sw [3344], reason: Hang on rcs0, action: reset
[ 1494.760725] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.
[ 1494.760725] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel
[ 1494.760726] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue.
[ 1494.760726] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it.
[ 1494.760727] [drm] GPU crash dump saved to /sys/class/drm/card0/error
[ 1494.760770] i915 0000:00:02.0: Resetting chip after gpu hang
[ 1502.755940] i915 0000:00:02.0: Resetting chip after gpu hang
[ 1510.755941] i915 0000:00:02.0: Resetting chip after gpu hang
[ 1518.755951] i915 0000:00:02.0: Resetting chip after gpu hang
[ 1708.771958] i915 0000:00:02.0: Resetting chip after gpu hang
[ 1716.771942] i915 0000:00:02.0: Resetting chip after gpu hang
[ 1724.771935] i915 0000:00:02.0: Resetting chip after gpu hang
[ 1732.707964] i915 0000:00:02.0: Resetting chip after gpu hang
[ 1747.982140] perf: interrupt took too long (2541 > 2500), lowering kernel.perf_event_max_sample_rate to 78000
[ 1756.044265] iwlwifi 0000:03:00.0: Radio type=0x1-0x2-0x0
[ 1756.329393] iwlwifi 0000:03:00.0: Radio type=0x1-0x2-0x0
[ 1756.407757] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[ 1758.755945] i915 0000:00:02.0: Resetting chip after gpu hang
[ 1766.755957] i915 0000:00:02.0: Resetting chip after gpu hang
[ 1774.755935] i915 0000:00:02.0: Resetting chip after gpu hang
[ 1782.755940] i915 0000:00:02.0: Resetting chip after gpu hang
Comment 1 Elizabeth 2018-02-28 22:31:53 UTC
Hi, which mesa version are you using? Thanks.
Comment 2 gwaewion 2018-03-01 06:16:49 UTC
(In reply to Elizabeth from comment #1)
> Hi, which mesa version are you using? Thanks.

mesa 17.3.5-1
Comment 3 Elizabeth 2018-03-01 16:19:01 UTC
Could you try latest release 17.3.6 https://www.mesa3d.org? It has some fixes for games and hangs reported with emacs. 
And if still reproducible could you try to find a way to reproduce it reliable? Thank you.
Comment 4 gwaewion 2018-03-04 06:39:10 UTC
(In reply to Elizabeth from comment #3)
> Could you try latest release 17.3.6 https://www.mesa3d.org? It has some
> fixes for games and hangs reported with emacs. 
> And if still reproducible could you try to find a way to reproduce it
> reliable? Thank you.

Updated to latest mesa from arch repos. Hangs still here.
Comment 5 Elizabeth 2018-03-05 15:23:37 UTC
Which version is it?(In reply to gwaewion from comment #4)
> (In reply to Elizabeth from comment #3)
> >...
> ...Updated to latest mesa from arch repos. Hangs still here.
Which version is it?
Comment 6 gwaewion 2018-03-06 06:49:09 UTC
(In reply to Elizabeth from comment #5)
> Which version is it?(In reply to gwaewion from comment #4)
> > (In reply to Elizabeth from comment #3)
> > >...
> > ...Updated to latest mesa from arch repos. Hangs still here.
> Which version is it?

17.3.6-1
Comment 7 Elizabeth 2018-03-06 17:26:38 UTC
Can you find a mesa version where this game worked properly in that machine? Also what cpu model do you have? Thanks.
Comment 8 gwaewion 2018-03-12 18:17:54 UTC
(In reply to Elizabeth from comment #7)
> Can you find a mesa version where this game worked properly in that machine?

specified above versions of mesa is only which i have tested with this game. or i should downgrade to any possible package version?

> Also what cpu model do you have? Thanks.

cpu model - i5-2520M.
Comment 9 Danylo 2018-06-11 14:42:23 UTC
Hello, I was not able to reproduce the issue on Sandy Bridge with mesa versions: latest, 17.3.5 and 17.3.6. I used Manjaro linux 17.1.10 (it is arch based distro) and Fedora 27. I didn't experience any GPU hangs but the game itself hanged several times in its code unrelated to Mesa.
Comment 10 Vitalii Para 2018-06-23 08:49:00 UTC
try add in .drirc (it fix for me):
<driconf>
    <device screen="0" driver="i965">
        <application name="java" executable="java">
            <option name="mesa_no_error" value="true" />
            <option name="always_flush_batch" value="true" />
        </application>
    </device>
</driconf>

In my case it was an error in Batch Buffer.

Mesa 17.3.9
Linux localhost 4.14.44-desktop-2.mga6 #1 SMP Mon May 28 22:35:45 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
Comment 11 Vitalii Para 2018-06-23 08:54:31 UTC
where java write your application name
Comment 12 GitLab Migration User 2019-09-25 19:09:57 UTC
-- 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/mesa/mesa/issues/1701.


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.