<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="#0563C1" vlink="purple" style="word-wrap:break-word"> <div class="WordSection1"> [AMD Official Use Only - General]<o:p></o:p> <o:p> </o:p> Hi Jack,<o:p></o:p> <o:p> </o:p> Are you trying to fix the call trace popped up on resuming below?<o:p></o:p> It seems mes created some bo for its self test and freed it up later at the final stage of the resuming process. <o:p></o:p> All these happened before the in_suspend flag cleared. And that triggered the call trace.<o:p></o:p> Is my understanding correct?<o:p></o:p> <o:p> </o:p> [74084.799260] WARNING: CPU: 2 PID: 2891 at drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:425 amdgpu_bo_free_kernel+0xfc/0x110 [amdgpu]<o:p></o:p> [74084.811019] Modules linked in: nls_iso8859_1 amdgpu(OE) iommu_v2 gpu_sched drm_buddy drm_ttm_helper ttm drm_display_helper drm_kms_helper i2c_algo_bit fb_sys_fops syscopyarea sysfillrect sysimgblt snd_sm<o:p></o:p> [74084.811042] ip_tables x_tables autofs4 hid_logitech_hidpp hid_logitech_dj hid_generic e1000e usbhid ptp uas hid video i2c_i801 ahci pps_core crc32_pclmul i2c_smbus usb_storage libahci wmi<o:p></o:p> [74084.914519] CPU: 2 PID: 2891 Comm: kworker/u16:38 Tainted: G W IOE 6.0.0-custom #1<o:p></o:p> [74084.923146] Hardware name: ASUS System Product Name/PRIME Z390-A, BIOS 2004 11/02/2021<o:p></o:p> [74084.931074] Workqueue: events_unbound async_run_entry_fn<o:p></o:p> [74084.936393] RIP: 0010:amdgpu_bo_free_kernel+0xfc/0x110 [amdgpu]<o:p></o:p> [74084.942422] Code: 00 4d 85 ed 74 08 49 c7 45 00 00 00 00 00 4d 85 e4 74 08 49 c7 04 24 00 00 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc <0f> 0b e9 39 ff ff ff 3d 00 fe ff ff 0f 85 75 96 47 00 ebf<o:p></o:p> [74084.961199] RSP: 0000:ffffbed6812ebb90 EFLAGS: 00010202<o:p></o:p> [74084.966435] RAX: 0000000000000000 RBX: ffffbed6812ebc50 RCX: 0000000000000000<o:p></o:p> [74084.973578] RDX: ffffbed6812ebc70 RSI: ffffbed6812ebc60 RDI: ffffbed6812ebc50<o:p></o:p> [74084.980725] RBP: ffffbed6812ebbb8 R08: 0000000000000000 R09: 00000000000001ff<o:p></o:p> [74084.987869] R10: ffffbed6812ebb40 R11: 0000000000000000 R12: ffffbed6812ebc70<o:p></o:p> [74084.995015] R13: ffffbed6812ebc60 R14: ffff963a2945cc00 R15: ffff9639c7da5630<o:p></o:p> [74085.002160] FS: 0000000000000000(0000) GS:ffff963d1dc80000(0000) knlGS:0000000000000000<o:p></o:p> [74085.010262] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<o:p></o:p> [74085.016016] CR2: 0000000000000000 CR3: 0000000377c0a001 CR4: 00000000003706e0<o:p></o:p> [74085.023164] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<o:p></o:p> [74085.030307] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<o:p></o:p> [74085.037453] Call Trace:<o:p></o:p> [74085.039911] <TASK><o:p></o:p> [74085.042023] amdgpu_mes_self_test+0x385/0x460 [amdgpu]<o:p></o:p> [74085.047293] mes_v11_0_late_init+0x44/0x50 [amdgpu]<o:p></o:p> [74085.052291] amdgpu_device_ip_late_init+0x50/0x270 [amdgpu]<o:p></o:p> [74085.058032] amdgpu_device_resume+0xb0/0x2d0 [amdgpu]<o:p></o:p> [74085.063187] amdgpu_pmops_resume+0x37/0x70 [amdgpu]<o:p></o:p> [74085.068162] pci_pm_resume+0x68/0x100<o:p></o:p> [74085.071836] ? pci_legacy_resume+0x80/0x80<o:p></o:p> [74085.075943] dpm_run_callback+0x4c/0x160<o:p></o:p> [74085.079873] device_resume+0xad/0x210<o:p></o:p> [74085.083546] async_resume+0x1e/0x40<o:p></o:p> [74085.087046] async_run_entry_fn+0x30/0x120<o:p></o:p> [74085.091152] process_one_work+0x21a/0x3f0<o:p></o:p> [74085.095173] worker_thread+0x50/0x3e0<o:p></o:p> [74085.098845] ? process_one_work+0x3f0/0x3f0<o:p></o:p> [74085.103039] kthread+0xfa/0x130<o:p></o:p> [74085.106189] ? kthread_complete_and_exit+0x20/0x20<o:p></o:p> [74085.110993] ret_from_fork+0x1f/0x30<o:p></o:p> [74085.114576] </TASK><o:p></o:p> [74085.116773] ---[ end trace 0000000000000000 ]---<o:p></o:p> <o:p> </o:p> BR<o:p></o:p> Evan<o:p></o:p> <div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> On Behalf Of Christian König Sent: Monday, February 6, 2023 5:00 PM To: Xiao, Jack <Jack.Xiao@amd.com>; Koenig, Christian <Christian.Koenig@amd.com>; amd-gfx@lists.freedesktop.org; Deucher, Alexander <Alexander.Deucher@amd.com> Subject: Re: [PATCH] drm/amdgpu: only WARN freeing buffers when DMA is unavailable<o:p></o:p> </div> </div> <o:p> </o:p> Am 06.02.23 um 09:28 schrieb Xiao, Jack:<o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> [AMD Official Use Only - General]<o:p></o:p> <o:p></o:p> >> >> It's simply not allowed to free up resources during suspend since those can't be acquired again during resume.<o:p></o:p> >> The in_suspend flag is set at the beginning of suspend and unset at the end of resume. It can’t filter the case you mentioned.<o:p></o:p> Why not? This is exactly what it should do.<o:p></o:p> <o:p></o:p> [Jack] If freeing up resources during resume, it should not hit the issue you described. But only checking in_suspend flag would take these cases as warning.<o:p></o:p> </blockquote> No, once more: Freeing up or allocating resources between suspend and resume is illegal! If you free up a resource during resume you should absolutely hit that, this is intentional! Regards, Christian. <o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <o:p></o:p> Regards,<o:p></o:p> Jack<o:p></o:p> <o:p></o:p> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> From: Koenig, Christian <a href="mailto:Christian.Koenig@amd.com"> <Christian.Koenig@amd.com></a> Sent: Monday, February 6, 2023 4:06 PM To: Xiao, Jack <a href="mailto:Jack.Xiao@amd.com"><Jack.Xiao@amd.com></a>; Christian König <a href="mailto:ckoenig.leichtzumerken@gmail.com"><ckoenig.leichtzumerken@gmail.com></a>; <a href="mailto:amd-gfx@lists.freedesktop.org">amd-gfx@lists.freedesktop.org</a>; Deucher, Alexander <a href="mailto:Alexander.Deucher@amd.com"><Alexander.Deucher@amd.com></a> Subject: Re: [PATCH] drm/amdgpu: only WARN freeing buffers when DMA is unavailable<o:p></o:p> </div> </div> <o:p></o:p> Am 06.02.23 um 08:23 schrieb Xiao, Jack:<o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> [AMD Official Use Only - General]<o:p></o:p> <o:p></o:p> >> Nope, that is not related to any hw state.<o:p></o:p> <o:p></o:p> can use other flag.<o:p></o:p> <o:p></o:p> >> It's simply not allowed to free up resources during suspend since those can't be acquired again during resume.<o:p></o:p> The in_suspend flag is set at the beginning of suspend and unset at the end of resume. It can’t filter the case you mentioned.<o:p></o:p> </blockquote> Why not? This is exactly what it should do. <o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> Do you know the root cause of these cases hitting the issue? So that we can get an exact point to warn the freeing up behavior.<o:p></o:p> </blockquote> Well the root cause are programming errors. See between suspending and resuming you should not allocate nor free memory. Otherwise we can run into trouble. And this check here is one part of that, we should probably add another warning during allocation of memory. But this here is certainly correct. Regards, Christian. <o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <o:p></o:p> Thanks,<o:p></o:p> Jack<o:p></o:p> <o:p></o:p> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> From: Christian König <a href="mailto:ckoenig.leichtzumerken@gmail.com"> <ckoenig.leichtzumerken@gmail.com></a> Sent: Friday, February 3, 2023 9:20 PM To: Xiao, Jack <a href="mailto:Jack.Xiao@amd.com"><Jack.Xiao@amd.com></a>; Koenig, Christian <a href="mailto:Christian.Koenig@amd.com"><Christian.Koenig@amd.com></a>; <a href="mailto:amd-gfx@lists.freedesktop.org"> amd-gfx@lists.freedesktop.org</a>; Deucher, Alexander <a href="mailto:Alexander.Deucher@amd.com"> <Alexander.Deucher@amd.com></a> Subject: Re: [PATCH] drm/amdgpu: only WARN freeing buffers when DMA is unavailable<o:p></o:p> </div> </div> <o:p></o:p> Nope, that is not related to any hw state. It's simply not allowed to free up resources during suspend since those can't be acquired again during resume. We had a couple of cases now where this was wrong. If you get a warning from that please fix the code which tried to free something during suspend instead. Regards, Christian.<o:p></o:p> <div> Am 03.02.23 um 07:04 schrieb Xiao, Jack:<o:p></o:p> </div> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> [AMD Official Use Only - General]<o:p></o:p> <o:p></o:p> >> It's simply illegal to free up memory during suspend.<o:p></o:p> Why? In my understanding, the limit was caused by DMA shutdown.<o:p></o:p> <o:p></o:p> Regards,<o:p></o:p> Jack<o:p></o:p> <o:p></o:p> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> From: Koenig, Christian <a href="mailto:Christian.Koenig@amd.com"> <Christian.Koenig@amd.com></a> Sent: Thursday, February 2, 2023 7:43 PM To: Xiao, Jack <a href="mailto:Jack.Xiao@amd.com"><Jack.Xiao@amd.com></a>; <a href="mailto:amd-gfx@lists.freedesktop.org">amd-gfx@lists.freedesktop.org</a>; Deucher, Alexander <a href="mailto:Alexander.Deucher@amd.com"><Alexander.Deucher@amd.com></a> Subject: AW: [PATCH] drm/amdgpu: only WARN freeing buffers when DMA is unavailable<o:p></o:p> </div> </div> <o:p></o:p> <div> Big NAK to this! This warning is not related in any way to the hw state.<o:p></o:p> </div> <div> <o:p></o:p> </div> <div> It's simply illegal to free up memory during suspend.<o:p></o:p> </div> <div> <o:p></o:p> </div> <div> Regards,<o:p></o:p> </div> <div> Christian.<o:p></o:p> </div> <o:p></o:p> <div class="MsoNormal" align="center" style="text-align:center"> <hr size="2" width="98%" align="center"> </div> <div id="divRplyFwdMsg"> Von: Xiao, Jack <<a href="mailto:Jack.Xiao@amd.com">Jack.Xiao@amd.com</a>> Gesendet: Donnerstag, 2. Februar 2023 10:54 An: <a href="mailto:amd-gfx@lists.freedesktop.org">amd-gfx@lists.freedesktop.org</a> <<a href="mailto:amd-gfx@lists.freedesktop.org">amd-gfx@lists.freedesktop.org</a>>; Deucher, Alexander <<a href="mailto:Alexander.Deucher@amd.com">Alexander.Deucher@amd.com</a>>; Koenig, Christian <<a href="mailto:Christian.Koenig@amd.com">Christian.Koenig@amd.com</a>> Cc: Xiao, Jack <<a href="mailto:Jack.Xiao@amd.com">Jack.Xiao@amd.com</a>> Betreff: [PATCH] drm/amdgpu: only WARN freeing buffers when DMA is unavailable <o:p></o:p> <div> <o:p></o:p> </div> </div> <div> <div> Reduce waringings, only warn when DMA is unavailable. Signed-off-by: Jack Xiao <<a href="mailto:Jack.Xiao@amd.com">Jack.Xiao@amd.com</a>> --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index 2d237f3d3a2e..e3e3764ea697 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -422,7 +422,8 @@ void amdgpu_bo_free_kernel(struct amdgpu_bo **bo, u64 *gpu_addr, if (*bo == NULL) return; - WARN_ON(amdgpu_ttm_adev((*bo)->tbo.bdev)->in_suspend); + WARN_ON(amdgpu_ttm_adev((*bo)->tbo.bdev)->in_suspend && + !amdgpu_ttm_adev((*bo)->tbo.bdev)->ip_blocks[AMD_IP_BLOCK_TYPE_SDMA].status.hw); if (likely(amdgpu_bo_reserve(*bo, true) == 0)) { if (cpu_addr) -- 2.37.3<o:p></o:p> </div> </div> </blockquote> <o:p></o:p> </blockquote> <o:p></o:p> </blockquote> <o:p> </o:p> </div> </div> </body> </html>