[PATCH v1 2/2] drm/amdgpu: adding device coredump support
Somalapuram, Amaranath
asomalap at amd.com
Tue May 24 12:10:37 UTC 2022
On 5/24/2022 3:23 PM, Sharma, Shashank wrote:
>
>
> On 5/24/2022 8:42 AM, Somalapuram, Amaranath wrote:
>>
>> On 5/20/2022 7:52 PM, Sharma, Shashank wrote:
>>>
>>>
>>> On 5/20/2022 3:49 PM, Somalapuram Amaranath wrote:
>>>> Added device coredump information:
>>>> - Kernel version
>>>> - Module
>>>> - Time
>>>> - VRAM status
>>>> - Guilty process name and PID
>>>> - GPU register dumps
>>>>
>>>> Signed-off-by: Somalapuram Amaranath <Amaranath.Somalapuram at amd.com>
>>>> ---
>>>> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 ++
>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 59
>>>> ++++++++++++++++++++++
>>>> 2 files changed, 62 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>>> index c79d9992b113..f28d9c563f74 100644
>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>>> @@ -1044,6 +1044,9 @@ struct amdgpu_device {
>>>> uint32_t *reset_dump_reg_list;
>>>> uint32_t *reset_dump_reg_value;
>>>> int num_regs;
>>>> + struct amdgpu_task_info reset_context_task_info;
>>>> + bool reset_context_vram_lost;
>>>
>>> How about drop the 'context' from name and just reset_task_info and
>>> reset_vram_lost ?
>> OK.
>>>
>>>> + struct timespec64 reset_time;
>>>> struct amdgpu_reset_domain *reset_domain;
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>>> index 963c897a76e6..f9b710e741a7 100644
>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>>> @@ -32,6 +32,8 @@
>>>> #include <linux/slab.h>
>>>> #include <linux/iommu.h>
>>>> #include <linux/pci.h>
>>>> +#include <linux/devcoredump.h>
>>>> +#include <generated/utsrelease.h>
>>>> #include <drm/drm_atomic_helper.h>
>>>> #include <drm/drm_probe_helper.h>
>>>> @@ -4733,6 +4735,55 @@ static int amdgpu_reset_reg_dumps(struct
>>>> amdgpu_device *adev)
>>>> return 0;
>>>> }
>>>> +#ifdef CONFIG_DEV_COREDUMP
>>>> +static ssize_t amdgpu_devcoredump_read(char *buffer, loff_t offset,
>>>> + size_t count, void *data, size_t datalen)
>>>> +{
>>>> + struct drm_printer p;
>>>> + struct amdgpu_device *adev = data;
>>>> + struct drm_print_iterator iter;
>>>> + int i;
>>>> +
>>>
>>> A NULL check for 'buffer' here could prevent a segfault later.
>>>
>> Agreed.
>>>> + iter.data = buffer;
>>>> + iter.offset = 0;
>>>> + iter.start = offset;
>>>> + iter.remain = count;
>>>> +
>>>> + p = drm_coredump_printer(&iter);
>>>> +
>>>> + drm_printf(&p, "**** AMDGPU Device Coredump ****\n");
>>>> + drm_printf(&p, "kernel: " UTS_RELEASE "\n");
>>>> + drm_printf(&p, "module: " KBUILD_MODNAME "\n");
>>>> + drm_printf(&p, "time: %lld.%09ld\n", adev->reset_time.tv_sec,
>>>> adev->reset_time.tv_nsec);
>>>> + if (adev->reset_context_task_info.pid)
>>>> + drm_printf(&p, "process_name: %s PID: %d\n",
>>>> + adev->reset_context_task_info.process_name,
>>>> + adev->reset_context_task_info.pid);
>>> Please fix the alignment of print variables.
>>>
>> I will cross check this.
>>>> +
>>>> + if (adev->reset_context_vram_lost)
>>>> + drm_printf(&p, "VRAM is lost due to GPU reset!\n");
>>>> + if (adev->num_regs) {
>>>> + drm_printf(&p, "AMDGPU register dumps:\nOffset: Value:\n");
>>>> +
>>>> + for (i = 0; i < adev->num_regs; i++)
>>>> + drm_printf(&p, "0x%08x: 0x%08x\n",
>>>> + adev->reset_dump_reg_list[i],
>>>> + adev->reset_dump_reg_value[i]);
>>>> + }
>>>> +
>>>> + return count - iter.remain;
>>>> +}
>>>> +
>>>> +static void amdgpu_reset_capture_coredumpm(struct amdgpu_device
>>>> *adev)
>>>> +{
>>>> + struct drm_device *dev = adev_to_drm(adev);
>>>> +
>>>> + ktime_get_ts64(&adev->reset_time);
>>>> + dev_coredumpm(dev->dev, THIS_MODULE, adev, 0, GFP_KERNEL,
>>>> + amdgpu_devcoredump_read, NULL);
>>> instead of registering NULL as free function, I would prefer you to
>>> have a dummy no_op free function registered, which we can consume if
>>> something changes.
>> you mean something like this (function without any code):
>> staticvoidamdgpu_devcoredump_free(void*data)
>> {
>> }
>
> Yes, precisely.
>
>>>> +}
>>>> +#endif
>>>> +
>>>> int amdgpu_do_asic_reset(struct list_head *device_list_handle,
>>>> struct amdgpu_reset_context *reset_context)
>>>> {
>>>> @@ -4817,6 +4868,14 @@ int amdgpu_do_asic_reset(struct list_head
>>>> *device_list_handle,
>>>> goto out;
>>>> vram_lost =
>>>> amdgpu_device_check_vram_lost(tmp_adev);
>>>> +#ifdef CONFIG_DEV_COREDUMP
>>>> + tmp_adev->reset_context_vram_lost = vram_lost;
>>>> + tmp_adev->reset_context_task_info.pid = 0;
>>> why is the PID hardcoded to 0 ?
>> in case of reset context reset_context->job->vm is null (possibility
>> that reset can be non VM related).
>> If we don't set tmp_adev->reset_context_task_info.pid = 0, it will
>> show previous reset valid PID.
>>
>
> But when the VM is not NULL, are we updating this PID somewhere ? I
> did not see that happening in this series.
This is the only place where PID get updated.
For example sequence of operation like:
1st reset:
-valid VM and tmp_adev->reset_context_task_info.pid is set to some valid PID
2nd reset:
-invalid VM
-tmp_adev context will remain same (adev context will be same after
successful GPU reset sequence).
-tmp_adev->reset_context_task_info.pid will be holding 1st reset PID value
if we don't set it 0, it can give wrong PID.
Regards,
S.Amarnath
>
> - Shashank
>
>>
>> Regards,
>> S.Amarnath
>>>> + if (reset_context->job && reset_context->job->vm)
>>>> + tmp_adev->reset_context_task_info =
>>>> + reset_context->job->vm->task_info;
>>>> + amdgpu_reset_capture_coredumpm(tmp_adev);
>>>> +#endif
>>>> if (vram_lost) {
>>>> DRM_INFO("VRAM is lost due to GPU reset!\n");
>>>>
>>> - Shashank
>>> amdgpu_inc_vram_lost(tmp_adev);
More information about the amd-gfx
mailing list