<html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> <div class="moz-cite-prefix">On 2021-03-18 6:41 a.m., Zhang, Jack (Jian) wrote: </div> <blockquote type="cite" cite="mid:DM5PR1201MB02041495067BD0C46A8840B0BB699@DM5PR1201MB0204.namprd12.prod.outlook.com"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)">  <style>@font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face {font-family:DengXian; panose-1:2 1 6 0 3 1 1 1 1 1;}@font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face {font-family:"\@DengXian"; panose-1:2 1 6 0 3 1 1 1 1 1;}@font-face {font-family:"Microsoft YaHei"; panose-1:2 11 5 3 2 2 4 2 2 4;}@font-face {font-family:"\@Microsoft YaHei";}p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; font-size:11.0pt; font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;}p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; font-size:11.0pt; font-family:"Calibri",sans-serif;}.MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;}div.WordSection1 {page:WordSection1;}ol {margin-bottom:0in;}ul {margin-bottom:0in;}</style> [AMD Official Use Only - Internal Distribution Only] <div> <div class="WordSection1"> Hi, Andrey<o:p></o:p> <o:p> </o:p> Let me summarize the background of this patch:<o:p></o:p> <o:p> </o:p> In TDR resubmit step “amdgpu_device_recheck_guilty_jobs,<o:p></o:p> It will submit first jobs of each ring and do guilty job re-check. <o:p></o:p> At that point, We had to make sure each job is in the mirror list(or re-inserted back already).<o:p></o:p> <o:p> </o:p> But we found the current code never re-insert the job to mirror list in the 2nd, 3rd job_timeout thread(Bailing TDR thread).<o:p></o:p> This not only will cause memleak of the bailing jobs. What’s more important, the 1st tdr thread can never iterate the bailing job and set its guilty status to a correct status.<o:p></o:p> <o:p> </o:p> Therefore, we had to re-insert the job(or even not delete node) for bailing job.<o:p></o:p> <o:p> </o:p> For the above V3 patch, the racing condition in my mind is:<o:p></o:p> we cannot make sure all bailing jobs are finished before we do amdgpu_device_recheck_guilty_jobs. </div> </div> </blockquote> Yes,that race i missed - so you say that for 2nd, baling thread who extracted the job, even if he reinsert it right away back after driver callback return DRM_GPU_SCHED_STAT_BAILING, there is small time slot where the job is not in mirror list and so the 1st TDR might miss it and not find that 2nd job is the actual guilty job, right ? But, still this job will get back into mirror list, and since it's really the bad job, it will never signal completion and so on the next timeout cycle it will be caught (of course there is a starvation scenario here if more TDRs kick in and it bails out again but this is really unlikely). <blockquote type="cite" cite="mid:DM5PR1201MB02041495067BD0C46A8840B0BB699@DM5PR1201MB0204.namprd12.prod.outlook.com"> <div> <div class="WordSection1"> <o:p></o:p> <o:p> </o:p> Based on this insight, I think we have two options to solve this issue:<o:p></o:p> <ol style="margin-top:0in" type="1" start="1"> <li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">Skip delete node in tdr thread2, thread3, 4 … (using mutex or atomic variable)<o:p></o:p></li> <li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">Re-insert back bailing job, and meanwhile use semaphore in each tdr thread to keep the sequence as expected and ensure each job is in the mirror list when do resubmit step.<o:p></o:p></li> </ol> <o:p> </o:p> For Option1, logic is simpler and we need only one global atomic variable:<o:p></o:p> What do you think about this plan?<o:p></o:p> <o:p> </o:p> Option1 should look like the following logic:<o:p></o:p> <o:p> </o:p> <o:p> </o:p> +static atomic_t in_reset; //a global atomic var for synchronization<o:p></o:p> static void drm_sched_process_job(struct dma_fence *f, struct dma_fence_cb *cb);<o:p></o:p> <o:p></o:p> /**<o:p></o:p> @@ -295,6 +296,12 @@ static void drm_sched_job_timedout(struct work_struct *work)<o:p></o:p> * drm_sched_cleanup_jobs. It will be reinserted back after sched->thread<o:p></o:p> * is parked at which point it's safe.<o:p></o:p> */<o:p></o:p> + if (atomic_cmpxchg(&in_reset, 0, 1) != 0) { //skip delete node if it’s thead1,2,3,….<o:p></o:p> + spin_unlock(&sched->job_list_lock);<o:p></o:p> + drm_sched_start_timeout(sched);<o:p></o:p> + return;<o:p></o:p> + }<o:p></o:p> +<o:p></o:p> list_del_init(&job->node);<o:p></o:p> spin_unlock(&sched->job_list_lock);<o:p></o:p> <o:p></o:p> @@ -320,6 +327,7 @@ static void drm_sched_job_timedout(struct work_struct *work)<o:p></o:p> spin_lock(&sched->job_list_lock);<o:p></o:p> drm_sched_start_timeout(sched);<o:p></o:p> spin_unlock(&sched->job_list_lock);<o:p></o:p> + atomic_set(&in_reset, 0); //reset in_reset when the first thread finished tdr<o:p></o:p> } </div> </div> </blockquote> Technically looks like it should work as you don't access the job pointer any longer and so no risk that if signaled it will be freed by drm_sched_get_cleanup_job but,you can't just use one global variable an by this bailing from TDR when different drivers run their TDR threads in parallel, and even for amdgpu, if devices in different XGMI hives or 2 independent devices in non XGMI setup. There should be defined some kind of GPU reset group structure on drm_scheduler level for which this variable would be used. P.S I wonder why we can't just ref-count the job so that even if drm_sched_get_cleanup_job would delete it before we had a chance to stop the scheduler thread, we wouldn't crash. This would avoid all the dance with deletion and reinsertion. Andrey <blockquote type="cite" cite="mid:DM5PR1201MB02041495067BD0C46A8840B0BB699@DM5PR1201MB0204.namprd12.prod.outlook.com"> <div> <div class="WordSection1"> <o:p></o:p> <o:p> </o:p> <o:p> </o:p> Thanks,<o:p></o:p> Jack<o:p></o:p> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> From: amd-gfx <a class="moz-txt-link-rfc2396E" href="mailto:amd-gfx-bounces@lists.freedesktop.org"><amd-gfx-bounces@lists.freedesktop.org></a> On Behalf Of Zhang, Jack (Jian) Sent: Wednesday, March 17, 2021 11:11 PM To: Christian König <a class="moz-txt-link-rfc2396E" href="mailto:ckoenig.leichtzumerken@gmail.com"><ckoenig.leichtzumerken@gmail.com></a>; <a class="moz-txt-link-abbreviated" href="mailto:dri-devel@lists.freedesktop.org">dri-devel@lists.freedesktop.org</a>; <a class="moz-txt-link-abbreviated" href="mailto:amd-gfx@lists.freedesktop.org">amd-gfx@lists.freedesktop.org</a>; Koenig, Christian <a class="moz-txt-link-rfc2396E" href="mailto:Christian.Koenig@amd.com"><Christian.Koenig@amd.com></a>; Liu, Monk <a class="moz-txt-link-rfc2396E" href="mailto:Monk.Liu@amd.com"><Monk.Liu@amd.com></a>; Deng, Emily <a class="moz-txt-link-rfc2396E" href="mailto:Emily.Deng@amd.com"><Emily.Deng@amd.com></a>; Rob Herring <a class="moz-txt-link-rfc2396E" href="mailto:robh@kernel.org"><robh@kernel.org></a>; Tomeu Vizoso <a class="moz-txt-link-rfc2396E" href="mailto:tomeu.vizoso@collabora.com"><tomeu.vizoso@collabora.com></a>; Steven Price <a class="moz-txt-link-rfc2396E" href="mailto:steven.price@arm.com"><steven.price@arm.com></a>; Grodzovsky, Andrey <a class="moz-txt-link-rfc2396E" href="mailto:Andrey.Grodzovsky@amd.com"><Andrey.Grodzovsky@amd.com></a> Subject: Re: [PATCH v3] drm/scheduler re-insert Bailing job to avoid memleak<o:p></o:p> </div> </div> <o:p> </o:p> [AMD Official Use Only - Internal Distribution Only]<o:p></o:p> <o:p> </o:p> <div> [AMD Official Use Only - Internal Distribution Only]<o:p></o:p> <o:p> </o:p> <div> Hi，Andrey，<o:p></o:p> <div> <o:p> </o:p> </div> <div> Good catch，I will expore this corner case and give feedback soon～<o:p></o:p> </div> <div> Best，<o:p></o:p> </div> Jack<o:p></o:p> <div> <o:p> </o:p> </div> <div class="MsoNormal" style="text-align:center" align="center"> <hr width="98%" size="2" align="center"> </div> <div id="divRplyFwdMsg"> From: Grodzovsky, Andrey <<a href="mailto:Andrey.Grodzovsky@amd.com" moz-do-not-send="true">Andrey.Grodzovsky@amd.com</a>> Sent: Wednesday, March 17, 2021 10:50:59 PM To: Christian König <<a href="mailto:ckoenig.leichtzumerken@gmail.com" moz-do-not-send="true">ckoenig.leichtzumerken@gmail.com</a>>; Zhang, Jack (Jian) <<a href="mailto:Jack.Zhang1@amd.com" moz-do-not-send="true">Jack.Zhang1@amd.com</a>>; <a href="mailto:dri-devel@lists.freedesktop.org" moz-do-not-send="true">dri-devel@lists.freedesktop.org</a> <<a href="mailto:dri-devel@lists.freedesktop.org" moz-do-not-send="true">dri-devel@lists.freedesktop.org</a>>; <a href="mailto:amd-gfx@lists.freedesktop.org" moz-do-not-send="true">amd-gfx@lists.freedesktop.org</a> <<a href="mailto:amd-gfx@lists.freedesktop.org" moz-do-not-send="true">amd-gfx@lists.freedesktop.org</a>>; Koenig, Christian <<a href="mailto:Christian.Koenig@amd.com" moz-do-not-send="true">Christian.Koenig@amd.com</a>>; Liu, Monk <<a href="mailto:Monk.Liu@amd.com" moz-do-not-send="true">Monk.Liu@amd.com</a>>; Deng, Emily <<a href="mailto:Emily.Deng@amd.com" moz-do-not-send="true">Emily.Deng@amd.com</a>>; Rob Herring <<a href="mailto:robh@kernel.org" moz-do-not-send="true">robh@kernel.org</a>>; Tomeu Vizoso <<a href="mailto:tomeu.vizoso@collabora.com" moz-do-not-send="true">tomeu.vizoso@collabora.com</a>>; Steven Price <<a href="mailto:steven.price@arm.com" moz-do-not-send="true">steven.price@arm.com</a>> Subject: Re: [PATCH v3] drm/scheduler re-insert Bailing job to avoid memleak <o:p></o:p> <div> <o:p></o:p> </div> </div> <div> <div> I actually have a race condition concern here - see bellow - On 2021-03-17 3:43 a.m., Christian König wrote: > I was hoping Andrey would take a look since I'm really busy with other > work right now. > > Regards, > Christian. > > Am 17.03.21 um 07:46 schrieb Zhang, Jack (Jian): >> Hi, Andrey/Crhistian and Team, >> >> I didn't receive the reviewer's message from maintainers on panfrost >> driver for several days. >> Due to this patch is urgent for my current working project. >> Would you please help to give some review ideas? >> >> Many Thanks, >> Jack >> -----Original Message----- >> From: Zhang, Jack (Jian) >> Sent: Tuesday, March 16, 2021 3:20 PM >> To: <a href="mailto:dri-devel@lists.freedesktop.org" moz-do-not-send="true">dri-devel@lists.freedesktop.org</a>; <a href="mailto:amd-gfx@lists.freedesktop.org" moz-do-not-send="true">amd-gfx@lists.freedesktop.org</a>; >> Koenig, Christian <<a href="mailto:Christian.Koenig@amd.com" moz-do-not-send="true">Christian.Koenig@amd.com</a>>; Grodzovsky, Andrey >> <<a href="mailto:Andrey.Grodzovsky@amd.com" moz-do-not-send="true">Andrey.Grodzovsky@amd.com</a>>; Liu, Monk <<a href="mailto:Monk.Liu@amd.com" moz-do-not-send="true">Monk.Liu@amd.com</a>>; Deng, >> Emily <<a href="mailto:Emily.Deng@amd.com" moz-do-not-send="true">Emily.Deng@amd.com</a>>; Rob Herring <<a href="mailto:robh@kernel.org" moz-do-not-send="true">robh@kernel.org</a>>; Tomeu >> Vizoso <<a href="mailto:tomeu.vizoso@collabora.com" moz-do-not-send="true">tomeu.vizoso@collabora.com</a>>; Steven Price <<a href="mailto:steven.price@arm.com" moz-do-not-send="true">steven.price@arm.com</a>> >> Subject: RE: [PATCH v3] drm/scheduler re-insert Bailing job to avoid >> memleak >> >> [AMD Public Use] >> >> Ping >> >> -----Original Message----- >> From: Zhang, Jack (Jian) >> Sent: Monday, March 15, 2021 1:24 PM >> To: Jack Zhang <<a href="mailto:Jack.Zhang1@amd.com" moz-do-not-send="true">Jack.Zhang1@amd.com</a>>; >> <a href="mailto:dri-devel@lists.freedesktop.org" moz-do-not-send="true">dri-devel@lists.freedesktop.org</a>; <a href="mailto:amd-gfx@lists.freedesktop.org" moz-do-not-send="true">amd-gfx@lists.freedesktop.org</a>; >> Koenig, Christian <<a href="mailto:Christian.Koenig@amd.com" moz-do-not-send="true">Christian.Koenig@amd.com</a>>; Grodzovsky, Andrey >> <<a href="mailto:Andrey.Grodzovsky@amd.com" moz-do-not-send="true">Andrey.Grodzovsky@amd.com</a>>; Liu, Monk <<a href="mailto:Monk.Liu@amd.com" moz-do-not-send="true">Monk.Liu@amd.com</a>>; Deng, >> Emily <<a href="mailto:Emily.Deng@amd.com" moz-do-not-send="true">Emily.Deng@amd.com</a>>; Rob Herring <<a href="mailto:robh@kernel.org" moz-do-not-send="true">robh@kernel.org</a>>; Tomeu >> Vizoso <<a href="mailto:tomeu.vizoso@collabora.com" moz-do-not-send="true">tomeu.vizoso@collabora.com</a>>; Steven Price <<a href="mailto:steven.price@arm.com" moz-do-not-send="true">steven.price@arm.com</a>> >> Subject: RE: [PATCH v3] drm/scheduler re-insert Bailing job to avoid >> memleak >> >> [AMD Public Use] >> >> Hi, Rob/Tomeu/Steven, >> >> Would you please help to review this patch for panfrost driver? >> >> Thanks, >> Jack Zhang >> >> -----Original Message----- >> From: Jack Zhang <<a href="mailto:Jack.Zhang1@amd.com" moz-do-not-send="true">Jack.Zhang1@amd.com</a>> >> Sent: Monday, March 15, 2021 1:21 PM >> To: <a href="mailto:dri-devel@lists.freedesktop.org" moz-do-not-send="true">dri-devel@lists.freedesktop.org</a>; <a href="mailto:amd-gfx@lists.freedesktop.org" moz-do-not-send="true">amd-gfx@lists.freedesktop.org</a>; >> Koenig, Christian <<a href="mailto:Christian.Koenig@amd.com" moz-do-not-send="true">Christian.Koenig@amd.com</a>>; Grodzovsky, Andrey >> <<a href="mailto:Andrey.Grodzovsky@amd.com" moz-do-not-send="true">Andrey.Grodzovsky@amd.com</a>>; Liu, Monk <<a href="mailto:Monk.Liu@amd.com" moz-do-not-send="true">Monk.Liu@amd.com</a>>; Deng, >> Emily <<a href="mailto:Emily.Deng@amd.com" moz-do-not-send="true">Emily.Deng@amd.com</a>> >> Cc: Zhang, Jack (Jian) <<a href="mailto:Jack.Zhang1@amd.com" moz-do-not-send="true">Jack.Zhang1@amd.com</a>> >> Subject: [PATCH v3] drm/scheduler re-insert Bailing job to avoid memleak >> >> re-insert Bailing jobs to avoid memory leak. >> >> V2: move re-insert step to drm/scheduler logic >> V3: add panfrost's return value for bailing jobs in case it hits the >> memleak issue. >> >> Signed-off-by: Jack Zhang <<a href="mailto:Jack.Zhang1@amd.com" moz-do-not-send="true">Jack.Zhang1@amd.com</a>> >> --- >> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +++- >> drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 8 ++++++-- >> drivers/gpu/drm/panfrost/panfrost_job.c | 4 ++-- >> drivers/gpu/drm/scheduler/sched_main.c | 8 +++++++- >> include/drm/gpu_scheduler.h | 1 + >> 5 files changed, 19 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c >> index 79b9cc73763f..86463b0f936e 100644 >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c >> @@ -4815,8 +4815,10 @@ int amdgpu_device_gpu_recover(struct >> amdgpu_device *adev, >> job ? job->base.id : -1); >> /* even we skipped this reset, still need to set the job >> to guilty */ >> - if (job) >> + if (job) { >> drm_sched_increase_karma(&job->base); >> + r = DRM_GPU_SCHED_STAT_BAILING; >> + } >> goto skip_recovery; >> } >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c >> index 759b34799221..41390bdacd9e 100644 >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c >> @@ -34,6 +34,7 @@ static enum drm_gpu_sched_stat >> amdgpu_job_timedout(struct drm_sched_job *s_job) >> struct amdgpu_job *job = to_amdgpu_job(s_job); >> struct amdgpu_task_info ti; >> struct amdgpu_device *adev = ring->adev; >> + int ret; >> memset(&ti, 0, sizeof(struct amdgpu_task_info)); >> @@ -52,8 +53,11 @@ static enum drm_gpu_sched_stat >> amdgpu_job_timedout(struct drm_sched_job *s_job) >> ti.process_name, ti.tgid, ti.task_name, ti.pid); >> if (amdgpu_device_should_recover_gpu(ring->adev)) { >> - amdgpu_device_gpu_recover(ring->adev, job); >> - return DRM_GPU_SCHED_STAT_NOMINAL; >> + ret = amdgpu_device_gpu_recover(ring->adev, job); >> + if (ret == DRM_GPU_SCHED_STAT_BAILING) >> + return DRM_GPU_SCHED_STAT_BAILING; >> + else >> + return DRM_GPU_SCHED_STAT_NOMINAL; >> } else { >> drm_sched_suspend_timeout(&ring->sched); >> if (amdgpu_sriov_vf(adev)) >> diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c >> b/drivers/gpu/drm/panfrost/panfrost_job.c >> index 6003cfeb1322..e2cb4f32dae1 100644 >> --- a/drivers/gpu/drm/panfrost/panfrost_job.c >> +++ b/drivers/gpu/drm/panfrost/panfrost_job.c >> @@ -444,7 +444,7 @@ static enum drm_gpu_sched_stat >> panfrost_job_timedout(struct drm_sched_job >> * spurious. Bail out. >> */ >> if (dma_fence_is_signaled(job->done_fence)) >> - return DRM_GPU_SCHED_STAT_NOMINAL; >> + return DRM_GPU_SCHED_STAT_BAILING; >> dev_err(pfdev->dev, "gpu sched timeout, js=%d, config=0x%x, >> status=0x%x, head=0x%x, tail=0x%x, sched_job=%p", >> js, >> @@ -456,7 +456,7 @@ static enum drm_gpu_sched_stat >> panfrost_job_timedout(struct drm_sched_job >> /* Scheduler is already stopped, nothing to do. */ >> if (!panfrost_scheduler_stop(&pfdev->js->queue[js], sched_job)) >> - return DRM_GPU_SCHED_STAT_NOMINAL; >> + return DRM_GPU_SCHED_STAT_BAILING; >> /* Schedule a reset if there's no reset in progress. */ >> if (!atomic_xchg(&pfdev->reset.pending, 1)) diff --git >> a/drivers/gpu/drm/scheduler/sched_main.c >> b/drivers/gpu/drm/scheduler/sched_main.c >> index 92d8de24d0a1..a44f621fb5c4 100644 >> --- a/drivers/gpu/drm/scheduler/sched_main.c >> +++ b/drivers/gpu/drm/scheduler/sched_main.c >> @@ -314,6 +314,7 @@ static void drm_sched_job_timedout(struct >> work_struct *work) { >> struct drm_gpu_scheduler *sched; >> struct drm_sched_job *job; >> + int ret; >> sched = container_of(work, struct drm_gpu_scheduler, >> work_tdr.work); >> @@ -331,8 +332,13 @@ static void drm_sched_job_timedout(struct >> work_struct *work) >> list_del_init(&job->list); >> spin_unlock(&sched->job_list_lock); >> - job->sched->ops->timedout_job(job); >> + ret = job->sched->ops->timedout_job(job); >> + if (ret == DRM_GPU_SCHED_STAT_BAILING) { >> + spin_lock(&sched->job_list_lock); >> + list_add(&job->node, &sched->ring_mirror_list); >> + spin_unlock(&sched->job_list_lock); >> + } At this point we don't hold GPU reset locks anymore, and so we could be racing against another TDR thread from another scheduler ring of same device or another XGMI hive member. The other thread might be in the middle of luckless iteration of mirror list (drm_sched_stop, drm_sched_start and drm_sched_resubmit) and so locking job_list_lock will not help. Looks like it's required to take all GPU rest locks here. Andrey >> /* >> * Guilty job did complete and hence needs to be manually >> removed >> * See drm_sched_stop doc. >> diff --git a/include/drm/gpu_scheduler.h >> b/include/drm/gpu_scheduler.h index 4ea8606d91fe..8093ac2427ef 100644 >> --- a/include/drm/gpu_scheduler.h >> +++ b/include/drm/gpu_scheduler.h >> @@ -210,6 +210,7 @@ enum drm_gpu_sched_stat { >> DRM_GPU_SCHED_STAT_NONE, /* Reserve 0 */ >> DRM_GPU_SCHED_STAT_NOMINAL, >> DRM_GPU_SCHED_STAT_ENODEV, >> + DRM_GPU_SCHED_STAT_BAILING, >> }; >> /** >> -- >> 2.25.1 >> _______________________________________________ >> amd-gfx mailing list >> <a href="mailto:amd-gfx@lists.freedesktop.org" moz-do-not-send="true">amd-gfx@lists.freedesktop.org</a> >> <a href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7CJack.Zhang1%40amd.com%7C95b2ff206ee74bbe520a08d8e956f5dd%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637515907000888939%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=BGoSfOYiDar8SrpMx%2BsOMWpaMr87bxB%2F9ycu0FhhipA%3D&reserved=0" moz-do-not-send="true"> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7Ce90f30af0f43444c6aea08d8e91860c4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637515638213180413%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NnLqtz%2BZ8%2BweYwCqRinrfkqmhzibNAF6CYSdVqL6xi0%3D&reserved=0</a> >> ><o:p></o:p> </div> </div> </div> </div> </div> </div> </blockquote> </body> </html>