Bug 108645 - Kernel and display crash when playing Dolphin
Summary: Kernel and display crash when playing Dolphin
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-11-03 15:37 UTC by Link Mauve
Modified: 2019-02-19 08:38 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
i915 logs during this issue, which were repeating every two minutes. (7.79 KB, text/x-log)
2018-11-03 15:37 UTC, Link Mauve
no flags Details

Description Link Mauve 2018-11-03 15:37:11 UTC
Created attachment 142357 [details]
i915 logs during this issue, which were repeating every two minutes.

I was playing a game in Dolphin, configured to use Vulkan as its renderer backend, and suddenly it stopped refreshing the display, I could still ssh to the computer, but no matter which program I would stop, be it Dolphin or Sway, and no matter which sysrq I pressed, the same image was still displayed.

This is using Mesa 18.2.4 and Linux 4.18.16 from ArchLinux, using Dolphin 5.0-r8983.
Comment 1 Denis 2018-11-05 10:14:09 UTC
Hi, provide please also information about your HW, CPU/GPU info.
Comment 2 Link Mauve 2018-12-21 15:57:37 UTC
Hi, my CPU is an i5-3210m as found in the Lenovo Thinkpad X230, and my GPU is the HD4000 found on this CPU.
Comment 3 Chris Wilson 2019-01-15 17:19:36 UTC
commit 484d9a844d0d0aeaa4cd3cec20885b7de9986a55 (HEAD -> drm-intel-next-queued, drm-intel/for-linux-next, drm-intel/drm-intel-next-queued)
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Jan 15 12:44:42 2019 +0000

    drm/i915/userptr: Avoid struct_mutex recursion for mmu_invalidate_range_start
    
    Since commit 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
    notifiers") we have been able to report failure from
    mmu_invalidate_range_start which allows us to use a trylock on the
    struct_mutex to avoid potential recursion and report -EBUSY instead.
    Furthermore, this allows us to pull the work into the main callback and
    avoid the sleight-of-hand in using a workqueue to avoid lockdep.
    
    However, not all paths to mmu_invalidate_range_start are prepared to
    handle failure, so instead of reporting the recursion, deal with it by
    propagating the failure upwards, who can decide themselves to handle it
    or report it.
    
    v2: Mark up the recursive lock behaviour and comment on the various weak
    points.
    
    v3: Follow commit 3824e41975ae ("drm/i915: Use mutex_lock_killable() from
    inside the shrinker") and also use mutex_lock_killable().
    v3.1: No leak on EINTR.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108375
    References: 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu notifiers")
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190115124442.3500-1-chris@chris-wilson.co.uk
Comment 4 Lakshmi 2019-02-19 08:38:38 UTC
Link, if the issue doesn't appear again for the same reason, I can close this bug.


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.