By current code logic job->vm_pd_addr is never going to be set unless the job is created for user SC or for buffer copy in amdgpu_copy_buffer So in any other case we are going to skip VM flush. But amdgpu_vm_flush wants a flush to happen in case GPU reset just happend (amdgpu_vmid_had_gpu_reset is true) so we will be skipping that VM flush (as in my case with amdgpu_driver_open_kms->amdgpu_vm_init->amdgpu_vm_clear_bo right after GPU reset occured) Is it safe ? Andrey On 09/11/2018 07:46 AM, Christian König wrote: > It would probably be better to initialize job->vm_pd_addr with > AMDGPU_BO_INVALID_OFFSET. > > And then just drop the vm flush alltogether when the vm_pd_addr isn't > set to something sane. > > Thanks, > Christian. > > Am 11.09.2018 um 00:52 schrieb Andrey Grodzovsky: >> Attached patch fixes SDMA TO after GPU reset, it's a regression >> caused by cbd5285 drm/amdgpu: move setting the GART addr into TTM. >> >> But to me it looks safer just to revert the original patch all >> together since we never can predict for sure if VM flush will take >> place and so it's safer to just always assign job->vm_pd_addr. >> >> Andrey >> >> >> >> _______________________________________________ >> amd-gfx mailing list >> amd-gfx at lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20180911/7ae0ac36/attachment-0001.html>
