5.4.18 - GPU HANG

Fist time - work in vscode + firefox
Second time - Work in OBS - while configuration wizard making some fps tests

OS: Clear Linux OS x86_64
Host: HP Spectre x360 Convertible 15-bl1XX
Kernel: 5.4.18-902.native
CPU: Intel i7-8550U (8) @ 4.000GHz
GPU: Intel UHD Graphics 620
GPU: NVIDIA GeForce MX150

demicode
dmesg
/sys/class/drm/card0/error

mentioned in issue #1150 (closed)

marked #1152 (closed) as a duplicate of this issue

marked #1150 (closed) as a duplicate of this issue

marked #1153 (closed) as a duplicate of this issue

marked #1076 (closed) as a duplicate of this issue

marked #1003 (closed) as a duplicate of this issue

marked #1000 (closed) as a duplicate of this issue

Residual bug in timeslicing preemption for 5.4+:

commit 5ba32c7be81e53ea8a27190b0f6be98e6c6779af (HEAD -> drm-intel-next-queued, drm-intel/drm-intel-next-queued)
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Feb 7 21:14:52 2020 +0000

    drm/i915/execlists: Always force a context reload when rewinding RING_TAIL
    
    If we rewind the RING_TAIL on a context, due to a preemption event, we
    must force the context restore for the RING_TAIL update to be properly
    handled. Rather than note which preemption events may cause us to rewind
    the tail, compare the new request's tail with the previously submitted
    RING_TAIL, as it turns out that timeslicing was causing unexpected
    rewinds.
    
       <idle>-0       0d.s2 1280851190us : __execlists_submission_tasklet: 0000:00:02.0 rcs0: expired last=130:4698, prio=3, hint=3
       <idle>-0       0d.s2 1280851192us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 66:119966, current 119964
       <idle>-0       0d.s2 1280851195us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 130:4698, current 4695
       <idle>-0       0d.s2 1280851198us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 130:4696, current 4695
    ^----  Note we unwind 2 requests from the same context
    
       <idle>-0       0d.s2 1280851208us : __i915_request_submit: 0000:00:02.0 rcs0: fence 130:4696, current 4695
       <idle>-0       0d.s2 1280851213us : __i915_request_submit: 0000:00:02.0 rcs0: fence 134:1508, current 1506
    ^---- But to apply the new timeslice, we have to replay the first request
          before the new client can start -- the unexpected RING_TAIL rewind
    
       <idle>-0       0d.s2 1280851219us : trace_ports: 0000:00:02.0 rcs0: submit { 130:4696*, 134:1508 }
     synmark2-5425    2..s. 1280851239us : process_csb: 0000:00:02.0 rcs0: cs-irq head=5, tail=0
     synmark2-5425    2..s. 1280851240us : process_csb: 0000:00:02.0 rcs0: csb[0]: status=0x00008002:0x00000000
    ^---- Preemption event for the ELSP update; note the lite-restore
    
     synmark2-5425    2..s. 1280851243us : trace_ports: 0000:00:02.0 rcs0: preempted { 130:4698, 66:119966 }
     synmark2-5425    2..s. 1280851246us : trace_ports: 0000:00:02.0 rcs0: promote { 130:4696*, 134:1508 }
     synmark2-5425    2.... 1280851462us : __i915_request_commit: 0000:00:02.0 rcs0: fence 130:4700, current 4695
     synmark2-5425    2.... 1280852111us : __i915_request_commit: 0000:00:02.0 rcs0: fence 130:4702, current 4695
     synmark2-5425    2.Ns1 1280852296us : process_csb: 0000:00:02.0 rcs0: cs-irq head=0, tail=2
     synmark2-5425    2.Ns1 1280852297us : process_csb: 0000:00:02.0 rcs0: csb[1]: status=0x00000814:0x00000000
     synmark2-5425    2.Ns1 1280852299us : trace_ports: 0000:00:02.0 rcs0: completed { 130:4696!, 134:1508 }
     synmark2-5425    2.Ns1 1280852301us : process_csb: 0000:00:02.0 rcs0: csb[2]: status=0x00000818:0x00000040
     synmark2-5425    2.Ns1 1280852302us : trace_ports: 0000:00:02.0 rcs0: completed { 134:1508, 0:0 }
     synmark2-5425    2.Ns1 1280852313us : process_csb: process_csb:2336 GEM_BUG_ON(!i915_request_completed(*execlists->active) && !reset_in_progress(execlists))
    
    Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
    Referenecs: 82c69bf58650 ("drm/i915/gt: Detect if we miss WaIdleLiteRestore")
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
    Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
    Cc: <stable@vger.kernel.org> # v5.4+
    Link: https://patchwork.freedesktop.org/patch/msgid/20200207211452.2860634-1-chris@chris-wilson.co.uk

closed

that commit doesn't apply to 5.4, which is probably why it isn't in stable yet

mentioned in issue #673 (closed)

that commit doesn't apply to 5.4, which is probably why it isn't in stable yet

There's also another race found after above one, with this fix: #487 (comment 407774)