All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: "Timur Kristóf" <timur.kristof@gmail.com>,
	alexander.deucher@amd.com, amd-gfx@lists.freedesktop.org
Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH] drm/amdgpu: skip the VMID 0 flush for VRAM clear-on-release
Date: Mon, 31 Aug 2026 19:38:15 +0200	[thread overview]
Message-ID: <4c038fea-910b-4b7d-b0ca-2b6775d778ee@amd.com> (raw)
In-Reply-To: <UJ9MXKXkSh6txd43wHcgSg@gmail.com>

On 8/31/26 14:30, Timur Kristóf wrote:
...
>>>> only flush when a GART window is actually used.
>>>
>>> Does that mean that there is still a risk of the wedge when the GART
>>> windows are used?
>>
>> Yes, and that is actually not limited to the GART windows. It looks like
>> every time we map something into any VM it can happen that the SDMA crashes
>> when there are concurrent operations ongoing.
> 
> Would it help to set
> adev->vm_manager.concurrent_flush = false
> until the problem is figured out?

That came to my mind as well, but I don't think that this would help in this situation.

> Or can the crash also happen when the VM is not concurrently flushed?

As far as we understand now that problem can happen whenever any VMID is flushed and the SDMA not idle.

> By the way, is this the same issue as the Navi 1 sdma_invalidation_workaround 
> or is that completely different?

It indeed looks very similar to me as well. Maybe the fix they came up with for Navi 1x was never 100% correct and now instead of accessing random addresses the SDMA just hangs.

Anyway this is a serious HW problem and we need a proper fix ASAP.

Regards,
Christian.

> 
>> It's just that the GART flushes triggered by the SDMA made that scenario
>> much more likely than anything else.
>>> Can you remind me when/why we need the GART windows exactly?
>>
>> Basically every time we want to copy something from system memory to VRAM
>> with the kernel.
> 
> Understood. Thanks for explaining!
> 
> Best regards,
> Tim

      reply	other threads:[~2026-08-31 17:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-28  4:47 [PATCH] drm/amdgpu: skip the VMID 0 flush for VRAM clear-on-release Arunpravin Paneer Selvam
2026-08-28  8:07 ` Christian König
2026-08-31 11:39 ` Timur Kristóf
2026-08-31 12:13   ` Christian König
2026-08-31 12:30     ` Timur Kristóf
2026-08-31 17:38       ` Christian König [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4c038fea-910b-4b7d-b0ca-2b6775d778ee@amd.com \
    --to=christian.koenig@amd.com \
    --cc=Arunpravin.PaneerSelvam@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=stable@vger.kernel.org \
    --cc=timur.kristof@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.