5.4-stable review patch. If anyone has any objections, please let me know.
--
From: Jani Nikula
[ Upstream commit d8db0b36d888b6a5eb392f112dc156e694de2369 ]
Allow better abstraction of the drm_debug global variable in the
future. No functional changes.
v2: Move unlikely() to
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Jani Nikula
[ Upstream commit d8db0b36d888b6a5eb392f112dc156e694de2369 ]
Allow better abstraction of the drm_debug global variable in the
future. No functional changes.
v2: Move unlikely() to
There is another cause for soft lock-up of GPU in empty ring-buffer:
race between GPU executing last commands and CPU checking ring for
emptiness. On GPU side IRQ for retire is triggered by CACHE_FLUSH_TS
event and RPTR shadow (which is used to check ring emptiness) is updated
a bit later from CP_C
On A5XX GPUs when preemption is used it's invietable to enter a soft
lock-up state in which GPU is stuck at empty ring-buffer doing nothing.
This appears as full UI lockup and not detected as GPU hang (because
it's not). This happens due to not triggering preemption when it was
needed. Sometimes th
Two fields of preempt_record which are used by CP aren't reset on
resume: "data" and "info". This is the reason behind faults which happen
when we try to switch to the ring that was active last before suspend.
In addition those faults can't be recovered from because we use suspend
and resume to do
Fine grain preemption (switching from/to points within submits)
requires extra handling in command stream of those submits, especially
when rendering with tiling (using GMEM). However this handling is
missing at this point in mesa (and always was). For this reason we get
random GPU faults and hangs
There are several issues with preemption on Adreno A5XX GPUs which
render system unusable if more than one priority level is used. Those
issues include persistent GPU faults and hangs, full UI lockups with
idling GPU.
---
Changes in v2:
- Use spinlock to serialize preemption initiation in patch 3
Dear Leonard,
Do you observe this issue on every suspend-resume cycle?
I just did 10 suspend/resume cycles in a row to double check, and
without this patch the screen never comes back (always have to switch VT
back-and-forth to bring it back). The
[dpu error]connector not connected 3
[drm:
Dear Leonard,
I installed KDE. First, I ran it with the my regular kernel without this
patch. The first interesting thing I notice is that the screen *does*
come back after resume. (The error messages are still present though.)
Ack. Do you mean that Rob Clark also uses Yoga Slim 7x but does
Dear Dmitry,
For context, I have a Lenovo Yoga Slim 7x laptop, and was having issues
with the display staying black after sleep. As a workaround, I could
switch to a different VT and back.
[ 1185.831970] [dpu error]connector not connected 3
I can confirm that I was seeing this exact error
10 matches
Mail list logo
