From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: "André Almeida" <andrealmeid@igalia.com>,
dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
linux-kernel@vger.kernel.org
Cc: pierre-eric.pelloux-prayer@amd.com,
"'Marek Olšák'" <maraeo@gmail.com>,
michel.daenzer@mailbox.org,
"Timur Kristóf" <timur.kristof@gmail.com>,
"Samuel Pitoiset" <samuel.pitoiset@gmail.com>,
kernel-dev@igalia.com,
"Bas Nieuwenhuizen" <bas@basnieuwenhuizen.nl>,
alexander.deucher@amd.com, christian.koenig@amd.com
Subject: Re: [PATCH v2 5/6] drm/amdgpu: Log IBs and ring name at coredump
Date: Fri, 14 Jul 2023 09:57:39 +0200 [thread overview]
Message-ID: <6485568b-da41-b549-f6bd-36139df59215@gmail.com> (raw)
In-Reply-To: <20230713213242.680944-6-andrealmeid@igalia.com>
Am 13.07.23 um 23:32 schrieb André Almeida:
> Log the IB addresses used by the hung job along with the stuck ring
> name. Note that due to nested IBs, the one that caused the reset itself
> may be in not listed address.
>
> Signed-off-by: André Almeida <andrealmeid@igalia.com>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 +++
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 31 +++++++++++++++++++++-
> 2 files changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index e1cc83a89d46..cfeaf93934fd 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1086,6 +1086,9 @@ struct amdgpu_coredump_info {
> struct amdgpu_task_info reset_task_info;
> struct timespec64 reset_time;
> bool reset_vram_lost;
> + u64 *ibs;
> + u32 num_ibs;
> + char ring_name[16];
> };
> #endif
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 07546781b8b8..431ccc3d7857 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -5008,12 +5008,24 @@ static ssize_t amdgpu_devcoredump_read(char *buffer, loff_t offset,
> coredump->adev->reset_dump_reg_value[i]);
> }
>
> + if (coredump->num_ibs) {
> + drm_printf(&p, "IBs:\n");
> + for (i = 0; i < coredump->num_ibs; i++)
> + drm_printf(&p, "\t[%d] 0x%llx\n", i, coredump->ibs[i]);
> + }
> +
> + if (coredump->ring_name[0] != '\0')
> + drm_printf(&p, "ring name: %s\n", coredump->ring_name);
> +
> return count - iter.remain;
> }
>
> static void amdgpu_devcoredump_free(void *data)
> {
> - kfree(data);
> + struct amdgpu_coredump_info *coredump = data;
> +
> + kfree(coredump->ibs);
> + kfree(coredump);
> }
>
> static void amdgpu_coredump(struct amdgpu_device *adev, bool vram_lost,
> @@ -5021,6 +5033,8 @@ static void amdgpu_coredump(struct amdgpu_device *adev, bool vram_lost,
> {
> struct amdgpu_coredump_info *coredump;
> struct drm_device *dev = adev_to_drm(adev);
> + struct amdgpu_job *job = reset_context->job;
> + int i;
>
> coredump = kmalloc(sizeof(*coredump), GFP_NOWAIT);
>
> @@ -5038,6 +5052,21 @@ static void amdgpu_coredump(struct amdgpu_device *adev, bool vram_lost,
>
> coredump->adev = adev;
>
> + if (job && job->num_ibs) {
I really really really don't want any dependency of the core dump
feature towards the job.
What we could do is to record the first executed IB VAs in the hw fence,
but I'm not sure how useful this is in the first place.
We have some internal feature in progress to query the VA of the draw
command which cause the waves currently executing in the SQ to be retrieved.
> + struct amdgpu_ring *ring = to_amdgpu_ring(job->base.sched);
> + u32 num_ibs = job->num_ibs;
> +
> + coredump->ibs = kmalloc_array(num_ibs, sizeof(coredump->ibs), GFP_NOWAIT);
This can fail pretty easily.
Christian.
> + if (coredump->ibs)
> + coredump->num_ibs = num_ibs;
> +
> + for (i = 0; i < coredump->num_ibs; i++)
> + coredump->ibs[i] = job->ibs[i].gpu_addr;
> +
> + if (ring)
> + strncpy(coredump->ring_name, ring->name, 16);
> + }
> +
> ktime_get_ts64(&coredump->reset_time);
>
> dev_coredumpm(dev->dev, THIS_MODULE, coredump, 0, GFP_NOWAIT,
next prev parent reply other threads:[~2023-07-14 7:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-13 21:32 [PATCH v2 0/6] drm/amdgpu: Add new reset option and rework coredump André Almeida
2023-07-13 21:32 ` [PATCH v2 1/6] drm/amdgpu: Create a module param to disable soft recovery André Almeida
2023-07-13 21:32 ` [PATCH v2 2/6] drm/amdgpu: Allocate coredump memory in a nonblocking way André Almeida
2023-07-14 6:59 ` Christian König
2023-07-13 21:32 ` [PATCH v2 3/6] drm/amdgpu: Rework coredump to use memory dynamically André Almeida
2023-07-14 7:50 ` Christian König
2023-07-13 21:32 ` [PATCH v2 4/6] drm/amdgpu: Limit info in coredump for kernel threads André Almeida
2023-07-14 7:52 ` Christian König
2023-07-14 12:18 ` André Almeida
2023-07-13 21:32 ` [PATCH v2 5/6] drm/amdgpu: Log IBs and ring name at coredump André Almeida
2023-07-14 7:57 ` Christian König [this message]
2023-07-14 12:23 ` André Almeida
2023-07-13 21:32 ` [PATCH v2 6/6] drm/amdgpu: Create version number for coredumps André Almeida
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=6485568b-da41-b549-f6bd-36139df59215@gmail.com \
--to=ckoenig.leichtzumerken@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=andrealmeid@igalia.com \
--cc=bas@basnieuwenhuizen.nl \
--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=michel.daenzer@mailbox.org \
--cc=pierre-eric.pelloux-prayer@amd.com \
--cc=samuel.pitoiset@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox