From: Matthew Brost <matthew.brost@intel.com>
To: <John.C.Harrison@intel.com>
Cc: <Intel-Xe@lists.freedesktop.org>
Subject: Re: [PATCH v6 2/9] drm/xe: Add ASCII85 dump helper function
Date: Fri, 30 Aug 2024 21:56:27 +0000 [thread overview]
Message-ID: <ZtJAC9l/gaCnBPdA@DUT025-TGLU.fm.intel.com> (raw)
In-Reply-To: <20240830062310.3450387-3-John.C.Harrison@Intel.com>
On Thu, Aug 29, 2024 at 11:23:03PM -0700, John.C.Harrison@Intel.com wrote:
> From: John Harrison <John.C.Harrison@Intel.com>
>
> There is a need to include the GuC log and other large binary objects
> in core dumps and via dmesg. So add a helper for dumping to a printer
> function via conversion to ASCII85 encoding.
>
> Another issue with dumping such a large buffer is that it can be slow,
> especially if dumping to dmesg over a serial port. So add a yield to
> prevent the 'task has been stuck for 120s' kernel hang check feature
> from firing.
>
> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> ---
> drivers/gpu/drm/xe/xe_devcoredump.c | 76 +++++++++++++++++++++++++++++
> drivers/gpu/drm/xe/xe_devcoredump.h | 5 ++
> 2 files changed, 81 insertions(+)
>
> diff --git a/drivers/gpu/drm/xe/xe_devcoredump.c b/drivers/gpu/drm/xe/xe_devcoredump.c
> index bdb76e834e4c..eec7b89ab48b 100644
> --- a/drivers/gpu/drm/xe/xe_devcoredump.c
> +++ b/drivers/gpu/drm/xe/xe_devcoredump.c
> @@ -6,6 +6,7 @@
> #include "xe_devcoredump.h"
> #include "xe_devcoredump_types.h"
>
> +#include <linux/ascii85.h>
> #include <linux/devcoredump.h>
> #include <generated/utsrelease.h>
>
> @@ -310,3 +311,78 @@ int xe_devcoredump_init(struct xe_device *xe)
> }
>
> #endif
> +
> +/**
> + * xe_print_blob_ascii85 - print a BLOB to some useful location in ASCII85
> + *
> + * The output is split to multiple lines because some print targets, e.g. dmesg
> + * cannot handle arbitrarily long lines. Note also that printing to dmesg in
> + * piece-meal fashion is not possible, each separate call to drm_puts() has a
> + * line-feed automatically added! Therefore, the entire output line must be
> + * constructed in a local buffer first, then printed in one atomic output call.
> + *
> + * There is also a scheduler yield call to prevent the 'task has been stuck for
> + * 120s' kernel hang check feature from firing when printing to a slow target
> + * such as dmesg over a serial port.
> + *
> + * TODO: Add compression prior to the ASCII85 encoding to shrink huge buffers down.
> + *
> + * @p: the printer object to output to
> + * @blob: the Binary Large OBject to dump out
> + * @offset: offset in bytes to skip from the front of the BLOB, must be a multiple of sizeof(u32)
> + * @size: the size in bytes of the BLOB, must be a multiple of sizeof(u32)
> + */
> +void xe_print_blob_ascii85(struct drm_printer *p, const void *blob, size_t offset, size_t size)
> +{
> + const u32 *blob32 = (const u32 *)blob;
> + char buff[ASCII85_BUFSZ], *line_buff;
> + size_t line_pos = 0;
> +
> +#define DMESG_MAX_LINE_LEN 800
> +#define MIN_SPACE (ASCII85_BUFSZ + 2) /* 85 + "\n\0" */
> +
> + if (size & 3)
> + drm_printf(p, "Size not word aligned: %zu", size);
> + if (offset & 3)
> + drm_printf(p, "Offset not word aligned: %zu", size);
> +
> + line_buff = kzalloc(sizeof(DMESG_MAX_LINE_LEN), GFP_KERNEL);
> + if (IS_ERR(line_buff)) {
> + drm_printf(p, "Failed to allocate line buffer: %pe", line_buff);
> + return;
> + }
> +
> + blob32 += offset / sizeof(*blob32);
> + size /= sizeof(*blob32);
> +
> + while (size--) {
> + u32 val = *(blob32++);
> +
> + strscpy(line_buff + line_pos, ascii85_encode(val, buff),
> + DMESG_MAX_LINE_LEN - line_pos);
> + line_pos += strlen(line_buff + line_pos);
> +
> + if ((line_pos + MIN_SPACE) >= DMESG_MAX_LINE_LEN) {
> + line_buff[line_pos++] = '\n';
> + line_buff[line_pos++] = 0;
> +
> + drm_puts(p, line_buff);
> +
> + line_pos = 0;
> +
> + /* Prevent 'stuck thread' time out errors */
> + cond_resched();
> + }
> + }
> +
> + if (line_pos) {
> + line_buff[line_pos++] = '\n';
> + line_buff[line_pos++] = 0;
> +
> + drm_puts(p, line_buff);
> + }
> +
> + kfree(line_buff);
Dive by comment kvfree per CI. Will try to plan sometime soon to give
this series a thorough look as it has been around and definitely is
something we need.
Matt
> +
> +#undef MIN_SPACE
> +}
> diff --git a/drivers/gpu/drm/xe/xe_devcoredump.h b/drivers/gpu/drm/xe/xe_devcoredump.h
> index e2fa65ce0932..3f82188590ac 100644
> --- a/drivers/gpu/drm/xe/xe_devcoredump.h
> +++ b/drivers/gpu/drm/xe/xe_devcoredump.h
> @@ -6,6 +6,9 @@
> #ifndef _XE_DEVCOREDUMP_H_
> #define _XE_DEVCOREDUMP_H_
>
> +#include <linux/types.h>
> +
> +struct drm_printer;
> struct xe_device;
> struct xe_sched_job;
>
> @@ -23,4 +26,6 @@ static inline int xe_devcoredump_init(struct xe_device *xe)
> }
> #endif
>
> +void xe_print_blob_ascii85(struct drm_printer *p, const void *blob, size_t offset, size_t size);
> +
> #endif
> --
> 2.46.0
>
next prev parent reply other threads:[~2024-08-30 21:58 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-30 6:23 [PATCH v6 0/9] drm/xe/guc: Improve GuC log dumping and add to devcoredump John.C.Harrison
2024-08-30 6:23 ` [PATCH v6 1/9] drm/xe/guc: Remove spurious line feed in debug print John.C.Harrison
2024-08-30 6:23 ` [PATCH v6 2/9] drm/xe: Add ASCII85 dump helper function John.C.Harrison
2024-08-30 17:29 ` John Harrison
2024-08-30 17:31 ` John Harrison
2024-08-30 21:56 ` Matthew Brost [this message]
2024-08-30 23:33 ` John Harrison
2024-08-31 1:18 ` John Harrison
2024-08-30 6:23 ` [PATCH v6 3/9] drm/xe/guc: Copy GuC log prior to dumping John.C.Harrison
2024-08-30 6:23 ` [PATCH v6 4/9] drm/xe/guc: Use a two stage dump for GuC logs and add more info John.C.Harrison
2024-08-30 6:23 ` [PATCH v6 5/9] drm/print: Introduce drm_line_printer John.C.Harrison
2024-08-30 6:23 ` [PATCH v6 6/9] drm/xe/guc: Dead CT helper John.C.Harrison
2024-08-30 6:23 ` [PATCH v6 7/9] drm/xe/guc: Dump entire CTB on errors John.C.Harrison
2024-08-30 6:23 ` [PATCH v6 8/9] drm/xe/guc: Add GuC log to devcoredump captures John.C.Harrison
2024-08-30 6:23 ` [PATCH v6 9/9] drm/xe/guc: Add a helper function for dumping GuC log to dmesg John.C.Harrison
2024-08-30 6:59 ` ✓ CI.Patch_applied: success for drm/xe/guc: Improve GuC log dumping and add to devcoredump Patchwork
2024-08-30 6:59 ` ✗ CI.checkpatch: warning " Patchwork
2024-08-30 7:00 ` ✓ CI.KUnit: success " Patchwork
2024-08-30 7:16 ` ✓ CI.Build: " Patchwork
2024-08-30 7:23 ` ✓ CI.Hooks: " Patchwork
2024-08-30 7:25 ` ✗ CI.checksparse: warning " Patchwork
2024-08-30 19:10 ` ✗ CI.FULL: failure " Patchwork
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=ZtJAC9l/gaCnBPdA@DUT025-TGLU.fm.intel.com \
--to=matthew.brost@intel.com \
--cc=Intel-Xe@lists.freedesktop.org \
--cc=John.C.Harrison@intel.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