From: "André Almeida" <andrealmeid@igalia.com>
To: "Christian König" <christian.koenig@amd.com>
Cc: kernel-dev@igalia.com, alexander.deucher@amd.com,
pierre-eric.pelloux-prayer@amd.com,
"'Marek Olšák'" <maraeo@gmail.com>,
linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, "Tuikov,
Luben" <Luben.Tuikov@amd.com>
Subject: Re: [PATCH] drm/amdgpu: Mark contexts guilty for any reset type
Date: Mon, 24 Apr 2023 10:26:33 -0300 [thread overview]
Message-ID: <717b333b-7af6-063e-d50d-bb2b3bbcecb4@igalia.com> (raw)
In-Reply-To: <d7264c5a-29b4-0fb3-153b-673a8a73d635@amd.com>
Hi Christian, thank you for your comments.
Em 24/04/2023 04:03, Christian König escreveu:
> Am 24.04.23 um 03:43 schrieb André Almeida:
>> When a DRM job timeout, the GPU is probably hang and amdgpu have some
>> ways to deal with that, ranging from soft recoveries to full device
>> reset. Anyway, when userspace ask the kernel the state of the context
>> (via AMDGPU_CTX_OP_QUERY_STATE), the kernel reports that the device was
>> reset, regardless if a full reset happened or not.
>>
>> However, amdgpu only marks a context guilty in the ASIC reset path. This
>> makes the userspace report incomplete, given that on soft recovery path
>> the guilty context is not told that it's the guilty one.
>>
>> Fix this by marking the context guilty for every type of reset when a
>> job timeouts.
>
> The guilty handling is pretty much broken by design and only works
> because we go through multiple hops of validating the entity after the
> job has already been pushed to the hw.
I see, thanks.
>
> I think we should probably just remove that completely and use an
> approach where we check the in flight submissions in the query state
> IOCTL.
Like the DRM_IOCTL_I915_GET_RESET_STATS approach?
> See my other patch on the mailing list regarding that.
Which one, the "[PATCH 1/8] drm/scheduler: properly forward fence
errors" series?
>
> Additional to that I currently didn't considered soft-recovered
> submissions as fatal and continue accepting submissions from that
> context, but already wanted to talk with Marek about that behavior.
>
Interesting. I will try to test and validate this approach to see if the
contexts keep working as expected on soft-resets.
> Regards,
> Christian.
next prev parent reply other threads:[~2023-04-24 13:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-24 1:43 André Almeida
2023-04-24 5:11 ` kernel test robot
2023-04-24 7:03 ` Christian König
2023-04-24 13:26 ` André Almeida [this message]
2023-04-24 15:27 ` Michel Dänzer
[not found] ` <CAAxE2A6Soq28ACV-m1OzG8CA-_VWp+N2wapsABzm2Nda=Qe+yA@mail.gmail.com>
2023-04-25 10:27 ` Michel Dänzer
[not found] ` <CAAxE2A6iuuVA7zjHM8YcTGMpEWuYV=hGRR1YW6W-qXHwAg9w7w@mail.gmail.com>
[not found] ` <19406ec5-79d6-e9e6-fbdd-eb2f4a872fc4@amd.com>
2023-04-25 12:14 ` Michel Dänzer
2023-04-25 12:44 ` Christian König
[not found] ` <CAAxE2A4capwpc40F49cgZBC9jJisODqNjTe0cM_pS7si5EkW3g@mail.gmail.com>
2023-04-26 9:51 ` Michel Dänzer
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=717b333b-7af6-063e-d50d-bb2b3bbcecb4@igalia.com \
--to=andrealmeid@igalia.com \
--cc=Luben.Tuikov@amd.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=kernel-dev@igalia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maraeo@gmail.com \
--cc=pierre-eric.pelloux-prayer@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®