Created attachment 138782 [details] /sys/class/drm/card0/error [15146.471169] [drm] GPU HANG: ecode 9:2:0xa8dfbffd, in mpv/vo [18693], reason: Hang on vcs0, action: reset [15146.471173] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. [15146.471176] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel [15146.471178] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. [15146.471180] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. [15146.471182] [drm] GPU crash dump saved to /sys/class/drm/card0/error [15146.471566] i915 0000:00:02.0: Resetting vcs0 after gpu hang [15159.422798] i915 0000:00:02.0: Resetting vcs0 after gpu hang [15168.414948] i915 0000:00:02.0: Resetting vcs0 after gpu hang
Created attachment 138783 [details] dmesg
Sigh, libva left the bugs.fd.o collective.
Chris, is this valid issue for i915?
It's unfortunate that the batchbuffers are not flagged by userspace so that we could look at what caused the hang. The instruction on which the command streamer hanged (MI_FLUSH_DW) doesn't appear to be something that would be emitted by intel-vaapi-driver (difference in the set bits). It looks more like something from gen6_bsd_ring_flush(). Though that's really confusing because I wouldn't expect anybody to run with legacy submission on SKL & 4.16.
Jiri, is this still valid on latest drm-tip?
Jiri, ping?
I don't think I saw it recently.
I assume this issue has been fixed. Closing now. Feel free to reopen if you still have the issue with latest drm-tip (https://cgit.freedesktop.org/drm-tip). If the problem persists attach the full dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M.
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.