Re: [PATCH] drm/amdgpu: fix a kcq hang issue for SRIOV

From: "Christian König" <christian.koenig-5C7GfCeVMHo@public.gmane.org>
To: Alex Deucher <alexdeucher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Emily Deng <Emily.Deng-5C7GfCeVMHo@public.gmane.org>,
	amd-gfx list
	<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	Monk Liu <Monk.Liu-5C7GfCeVMHo@public.gmane.org>
Subject: Re: [PATCH] drm/amdgpu: fix a kcq hang issue for SRIOV
Date: Tue, 27 Mar 2018 18:30:15 +0200	[thread overview]
Message-ID: <97d802df-4563-7a6a-eae4-d14313762015@amd.com> (raw)
In-Reply-To: <CADnq5_MPtDiJ3vx-yqWfa65xb3etO-e1xRuiM9mJR1bON=5Ecw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Am 27.03.2018 um 17:52 schrieb Alex Deucher:
> [SNIP]
>>> 2. add the new callback implementation to gfx9 and gfx8 (I think gfx8
>>> will need this as well since we support sr-iov there too)
>>
>> gfx8 doesn't have the hardware bug which seems to make this necessary, not
>> does it have the same VMHUB design as gfx9.
> Oh, right, in this case it's the req/ack engines which were new for
> soc15.  We may want the same fix for sdma4 though.

And exactly that is one of the reasons why this workaround doesn't work 
correctly.

The SDMA is not directly connected to the GFXHUB, so even if the SDMA 
would provide a single command for this the write/wait would still be 
executed as two operations.

In other words we can again run into the problem and the same thing 
applies for CPU based updates.

The only real workaround would be to write the request, read the 
register back and if the write didn't succeeded write it again.

But seriously remember that this issue is not limited to the VMHUB 
registers. Do you want to write and read back every register to make 
sure the write succeeded?

Regards,
Christian.
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx