On Tue, Aug 7, 2018 at 6:22 AM, Emily Deng <Emily.Deng at amd.com> wrote: > Under runtime, the wait fence time could be quite long when > other VFs are in exclusive mode. > > SWDEV-161490 > > Change-Id: Ifc32d56ca7fde01b1f4fe2b0db6959b51909008a > Signed-off-by: Monk Liu <Monk.Liu at amd.com> > Signed-off-by: Emily Deng <Emily.Deng at amd.com> Seems pretty long. Is this value based on any evidence (e.g., worse case length of time slices, etc.) or just a long value that happens to work? Might be nice to provide a bit more context in the commit message. E.g., extend the timeout for recovering vram bos from shadows on sr-iov to cover the worst case scenario for timeslices and VFs. Alex > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c > index 1d933db..ef82ad1 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c > @@ -3124,7 +3124,7 @@ static int amdgpu_device_handle_vram_lost(struct amdgpu_device *adev) > long tmo; > > if (amdgpu_sriov_runtime(adev)) > - tmo = msecs_to_jiffies(amdgpu_lockup_timeout); > + tmo = msecs_to_jiffies(8000); > else > tmo = msecs_to_jiffies(100); > > -- > 2.7.4 > > _______________________________________________ > amd-gfx mailing list > amd-gfx at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
