From: Pierre-Eric Pelloux-Prayer <pierre-eric@damsy.net>
To: Alex Deucher <alexdeucher@gmail.com>,
Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Cc: "Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 6/6] drm/amdgpu: dump job ibs in the devcoredump
Date: Tue, 17 Feb 2026 17:38:08 +0100 [thread overview]
Message-ID: <78b10f62-60d1-4dee-94a0-fa2eaf139cb6@damsy.net> (raw)
In-Reply-To: <CADnq5_Ndh2zaQ5VcoA1jNjAohkurqofd5_TweCfX+iaKz9h+vA@mail.gmail.com>
Le 17/02/2026 à 17:20, Alex Deucher a écrit :
> On Wed, Feb 11, 2026 at 6:07 AM Pierre-Eric Pelloux-Prayer
> <pierre-eric.pelloux-prayer@amd.com> wrote:
>>
>> Now that we have a worker thread, we can try to access the
>> IBs of the job. The process is:
>> * get the VM from the PASID
>> * get the BO from its VA and the VM
>> * map the BO for CPU access
>> * copy everything, then add it to the dump
>> Each step can fail so we have to be cautious.
>> These operations can be slow so when amdgpu_devcoredump_format
>> is called only to determine the size of the buffer we skip all
>> of them and assume they will succeed.
>>
>> Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
>> ---
>> .../gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c | 84 ++++++++++++++++++-
>> 1 file changed, 83 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c
>> index d0af8a294abf..d576518c212d 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c
>> @@ -200,12 +200,20 @@ static void amdgpu_devcoredump_fw_info(struct amdgpu_device *adev,
>> static ssize_t
>> amdgpu_devcoredump_format(char *buffer, size_t count, struct amdgpu_coredump_info *coredump)
>> {
>> + struct amdgpu_device *adev = coredump->adev;
>> struct drm_printer p;
>> struct drm_print_iterator iter;
>> struct amdgpu_vm_fault_info *fault_info;
>> + struct amdgpu_bo_va_mapping *mapping;
>> struct amdgpu_ip_block *ip_block;
>> + struct amdgpu_res_cursor cursor;
>> + struct amdgpu_bo *abo, *root;
>> + uint64_t va_start, offset;
>> struct amdgpu_ring *ring;
>> - int ver, i, j;
>> + struct amdgpu_vm *vm;
>> + u32 *ib_content;
>> + uint8_t *kptr;
>> + int ver, i, j, r;
>> u32 ring_idx, off;
>>
>> iter.data = buffer;
>> @@ -323,6 +331,80 @@ amdgpu_devcoredump_format(char *buffer, size_t count, struct amdgpu_coredump_inf
>> else if (coredump->reset_vram_lost)
>> drm_printf(&p, "VRAM is lost due to GPU reset!\n");
>>
>> + if (coredump->num_ibs) {
>> + if (buffer)
>> + vm = amdgpu_vm_lock_by_pasid(adev, &root, coredump->pasid);
>> + else
>> + vm = NULL;
>
> Is there any point in doing the loop if the vm is NULL?
Yes : when doing the first pass to size the final buffer I skip the
buffers mapping + read operations that might be slow and instead just
account for the outputting of ib_size_dw dwords.
>
>> +
>> + for (int i = 0; i < coredump->num_ibs && (!buffer || vm); i++) {
>> + ib_content = kvmalloc_array(coredump->ibs[i].ib_size_dw, 4,
>> + GFP_KERNEL);
>
> Shouldn't this be GFP_NOWAIT?
This is executed by a worker so GFP_KERNEL should be ok?
Pierre-Eric
>
> Alex
>
>> + if (!ib_content)
>> + continue;
>> +
>> + if (!vm)
>> + goto output_ib_content;
>> +
>> + va_start = coredump->ibs[i].gpu_addr & AMDGPU_GMC_HOLE_MASK;
>> + mapping = amdgpu_vm_bo_lookup_mapping(vm, va_start / AMDGPU_GPU_PAGE_SIZE);
>> + if (!mapping)
>> + goto free_ib_content;
>> +
>> + offset = va_start - (mapping->start * AMDGPU_GPU_PAGE_SIZE);
>> + abo = amdgpu_bo_ref(mapping->bo_va->base.bo);
>> + r = amdgpu_bo_reserve(abo, false);
>> + if (r)
>> + goto free_ib_content;
>> +
>> + if (abo->flags & AMDGPU_GEM_CREATE_NO_CPU_ACCESS) {
>> + off = 0;
>> +
>> + if (abo->tbo.resource->mem_type != TTM_PL_VRAM)
>> + goto unreserve_abo;
>> +
>> + amdgpu_res_first(abo->tbo.resource, offset,
>> + coredump->ibs[i].ib_size_dw * 4,
>> + &cursor);
>> + while (cursor.remaining) {
>> + amdgpu_device_mm_access(adev, cursor.start / 4,
>> + &ib_content[off], cursor.size / 4,
>> + false);
>> + off += cursor.size;
>> + amdgpu_res_next(&cursor, cursor.size);
>> + }
>> + } else {
>> + r = ttm_bo_kmap(&abo->tbo, 0,
>> + PFN_UP(abo->tbo.base.size),
>> + &abo->kmap);
>> + if (r)
>> + goto unreserve_abo;
>> +
>> + kptr = amdgpu_bo_kptr(abo);
>> + kptr += offset;
>> + memcpy(ib_content, kptr,
>> + coredump->ibs[i].ib_size_dw * 4);
>> +
>> + amdgpu_bo_kunmap(abo);
>> + }
>> +
>> +output_ib_content:
>> + drm_printf(&p, "\nIB #%d 0x%llx %d dw\n",
>> + i, coredump->ibs[i].gpu_addr, coredump->ibs[i].ib_size_dw);
>> + for (int j = 0; j < coredump->ibs[i].ib_size_dw; j++)
>> + drm_printf(&p, "0x%08x\n", ib_content[j]);
>> +unreserve_abo:
>> + if (vm)
>> + amdgpu_bo_unreserve(abo);
>> +free_ib_content:
>> + kfree(ib_content);
>> + }
>> + if (vm) {
>> + amdgpu_bo_unreserve(root);
>> + amdgpu_bo_unref(&root);
>> + }
>> + }
>> +
>> return count - iter.remain;
>> }
>>
>> --
>> 2.43.0
>>
next prev parent reply other threads:[~2026-02-17 16:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-11 10:26 [PATCH v1 1/6] drm/amdgpu: include ip discovery data in devcoredump Pierre-Eric Pelloux-Prayer
2026-02-11 10:26 ` [PATCH v1 2/6] drm/amdgpu: move devcoredump generation to a worker Pierre-Eric Pelloux-Prayer
2026-02-17 16:02 ` Alex Deucher
2026-02-11 10:26 ` [PATCH v1 3/6] drm/amdgpu: save ring content before resetting the device Pierre-Eric Pelloux-Prayer
2026-02-17 16:11 ` Alex Deucher
2026-02-11 10:26 ` [PATCH v1 4/6] drm/amdgpu: extract amdgpu_vm_lock_by_pasid from amdgpu_vm_handle_fault Pierre-Eric Pelloux-Prayer
2026-02-17 16:21 ` Alex Deucher
2026-02-11 10:26 ` [PATCH v1 5/6] drm/amdgpu: store ib info for devcoredump Pierre-Eric Pelloux-Prayer
2026-02-17 16:21 ` Alex Deucher
2026-02-11 10:26 ` [PATCH v1 6/6] drm/amdgpu: dump job ibs in the devcoredump Pierre-Eric Pelloux-Prayer
2026-02-17 16:20 ` Alex Deucher
2026-02-17 16:38 ` Pierre-Eric Pelloux-Prayer [this message]
2026-02-17 16:47 ` Alex Deucher
2026-02-23 15:03 ` Pierre-Eric Pelloux-Prayer
2026-02-17 16:02 ` [PATCH v1 1/6] drm/amdgpu: include ip discovery data in devcoredump Alex Deucher
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=78b10f62-60d1-4dee-94a0-fa2eaf139cb6@damsy.net \
--to=pierre-eric@damsy.net \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=alexdeucher@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pierre-eric.pelloux-prayer@amd.com \
--cc=simona@ffwll.ch \
/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®