Yes, that is actually desired. We should not flush the system VM just because we do some clearing command submission. Christian. Am 11.09.2018 15:54 schrieb "Grodzovsky, Andrey" <Andrey.Grodzovsky at amd.com>: 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<mailto: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/39a6a3a0/attachment.html>
