[Bug 107762] [Intel GFX CI] *ERROR* ring sdma0 timeout, signaled seq=137, emitted seq=137

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=107762

--- Comment #4 from Martin Peres <martin.peres at free.fr> ---
(In reply to Michel Dänzer from comment #2)
> (In reply to Martin Peres from comment #0)
> > [  358.292609] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout, signaled seq=137, emitted seq=137
> > [  358.292635] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma1 timeout, signaled seq=145, emitted seq=145
> 
> (In reply to Martin Peres from comment #1)
> > [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout, signaled seq=137, emitted seq=137
> > [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout, signaled seq=147, emitted seq=147
> 
> Hmm, signalled and emitted sequence numbers are always the same, meaning the
> hardware hasn't actually timed out?
> 
> I can think of two possibilities:
> 
> * A GPU scheduler bug causing the job timeout handling to be triggered
> spuriously. (Could something be stalling the system work queue, so the items
> scheduled by drm_sched_job_finish_cb can't call drm_sched_job_finish in
> time?)
> 
> * A problem with the handling of the GPU's interrupts. Do the numbers on the
> amdgpu line in /proc/interrupts still increase after these messages
> appeared, or at least in the ten seconds before they appear?

Here is the IGT run log:

[283/301] skip: 65, pass: 218 -
running: igt/amdgpu/amd_cs_nop/sync-fork-gfx0

[283/301] skip: 65, pass: 218 \              
dmesg-warn: igt/amdgpu/amd_cs_nop/sync-fork-gfx0

[284/301] skip: 65, pass: 218, dmesg-warn: 1 \
running: igt/amdgpu/amd_prime/i915-to-amd     

[284/301] skip: 65, pass: 218, dmesg-warn: 1 |
pass: igt/amdgpu/amd_prime/i915-to-amd        

[285/301] skip: 65, pass: 219, dmesg-warn: 1 |
running: igt/amdgpu/amd_prime/amd-to-i915     

[285/301] skip: 65, pass: 219, dmesg-warn: 1 /
dmesg-fail: igt/amdgpu/amd_prime/amd-to-i915  

It shows that both the tests #283 and #285 generated the timeout, yet the seqno
has increased by 10 between the two tests, suggesting that the GPU is not hung.

I can't easily check if interrupts in /proc/interrupts are still increasing on
a machine that is part of our CI, but I guess if this is what it takes to get
this bug forward, I will try to get my hands on a KBLg platform and help you
trigger.

However, if it is scheduler bug, I would assume this issue to be reproducible
on any AMD GPU. Can you try running igt at amdgpu/amd_cs_nop at sync-fork-gfx0 in a
loop for an hour or so?

Your second proposal would point at a KBLg-specific bug, but let's first rule
out the scheduler as being part of the problem.

In any case, thanks for your answer :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20180906/1f8ea8f8/attachment.html>