diff options
| author | Jesse Zhang <Jesse.Zhang@amd.com> | 2026-08-13 12:27:53 +0800 |
|---|---|---|
| committer | Alex Deucher <alexander.deucher@amd.com> | 2026-08-19 10:06:23 -0400 |
| commit | 48dc279c3010ac8f91b1845b2abb3a1e9943a0f5 (patch) | |
| tree | b768f04161510bc6edc2c4b1ac528af76bfa91ec /scripts/const_structs.checkpatch | |
| parent | 59db985bc99e0589536a2116b93b0a6c45df41ab (diff) | |
| download | linux-48dc279c3010ac8f91b1845b2abb3a1e9943a0f5.tar.gz linux-48dc279c3010ac8f91b1845b2abb3a1e9943a0f5.zip | |
drm/amdgpu: force complete the MES ring fences on reset
The MES scheduler ring has no drm scheduler (no_scheduler = true), so it is
skipped by the force-completion loop in amdgpu_device_pre_asic_reset(). It uses
a polling fence whose hw value lives in wb (GTT) memory and survives a MODE1
reset, while fence_drv.sync_seq keeps advancing for every packet.
When the reset is triggered because MES itself stopped responding, the
timed-out packets advance sync_seq past the last hw fence value MES wrote.
After resume the first MES submission polls forever on a seq that is never
written back, failing the resume and wedging the box on a second reset:
amdgpu: MES ring buffer is full.
amdgpu: *ERROR* ring gfx_0.0.0 test failed (-110)
amdgpu: resume of IP block <gfx_v11_0> failed -110
amdgpu: GPU reset end with ret = -110
Force complete the MES scheduler ring fences together with the scheduler rings
so their hw fence is realigned to sync_seq.
v2: cover all XCCs (one scheduler ring each), not just mes.ring[0].
Cc: stable@vger.kernel.org
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Diffstat (limited to 'scripts/const_structs.checkpatch')
0 files changed, 0 insertions, 0 deletions
