[PATCH] drm/amdgpu: fix the ib test hang when gfx is in "idle" state

Koenig, Christian Christian.Koenig at amd.com
Mon Apr 23 09:57:06 UTC 2018


Hi Ray,

Am 23.04.2018 11:47 schrieb Huang Rui <ray.huang at amd.com>:
On Fri, Apr 20, 2018 at 05:59:16PM +0800, Koenig, Christian wrote:
> Am 20.04.2018 um 11:40 schrieb Huang Rui:
> > "aaabaf4   drm/amdgpu: defer test IBs on the rings at boot (V3)"
> > Above patch defers the execution of gfx/compute ib tests. However, at that time,
> > the gfx may already go into idle state. If "idle" gfx receives command
> > submission, it will get hang in the system. So we must add is_gfx_on checking at
> > start of ib tests.
>
> Do I see that right that you just skip the IB test when the GFX block is
> already turned of? In this case that would be a clear NAK.
>
> BTW: How do you detect that we need to turn GFX on again?

Christian, I know point. But there is a hang issue if we would like try to
disable/enable gfxoff with SMC message at runtime. Actually, I am trying to
find a good sequence to fix it. After that, I can even expose an debugfs
interface to configure that. So I have to skip the test for the moment when
gfx is in "idle".

Working around that issue for the moment is ok, but please note that explicitly in both the commit message and a code comment.

But don't you run into the same problem when the UMD starts to submit commands?

I mean the idea of the IB test is that you "simulate" an userspace command submission and see if it works.

Regards,
Christian.


Thanks,
Ray

On Fri, Apr 20, 2018 at 05:59:16PM +0800, Koenig, Christian wrote:
> Am 20.04.2018 um 11:40 schrieb Huang Rui:
> > "aaabaf4   drm/amdgpu: defer test IBs on the rings at boot (V3)"
> > Above patch defers the execution of gfx/compute ib tests. However, at that time,
> > the gfx may already go into idle state. If "idle" gfx receives command
> > submission, it will get hang in the system. So we must add is_gfx_on checking at
> > start of ib tests.
>
> Do I see that right that you just skip the IB test when the GFX block is
> already turned of? In this case that would be a clear NAK.
>
> BTW: How do you detect that we need to turn GFX on again?

Christian, I know point. But there is a hang issue if we would like try to
disable/enable gfxoff with SMC message at runtime. Actually, I am trying to
find a good sequence to fix it. After that, I can even expose an debugfs
interface to configure that. So I have to skip the test for the moment when
gfx is in "idle".

Thanks,
Ray
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20180423/5af0cef3/attachment.html>


More information about the amd-gfx mailing list