* [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump
@ 2024-09-05 20:50 John.C.Harrison
2024-09-05 20:50 ` [PATCH v7 01/10] drm/xe/guc: Remove spurious line feed in debug print John.C.Harrison
` (18 more replies)
0 siblings, 19 replies; 54+ messages in thread
From: John.C.Harrison @ 2024-09-05 20:50 UTC (permalink / raw)
To: Intel-Xe; +Cc: John Harrison
From: John Harrison <John.C.Harrison@Intel.com>
There is a debug mechanism for dumping the GuC log as an ASCII hex
stream via dmesg. This is extremely useful for situations where it is
not possibe to query the log from debugfs (self tests, bugs that cause
the driver to fail to load, system hangs, etc.). However, dumping via
dmesg is not the most reliable. The dmesg buffer is limited in size,
can be rate limited and a simple hex stream is hard to parse by tools.
So add extra information to the dump to make it more robust and
parsable. This includes adding start and end tags to delimit the dump,
using longer lines to reduce the per line overhead, adding a rolling
count to check for missing lines and interleaved concurrent dumps and
adding other important information such as the GuC version number and
timestamp offset. Also, switch to using the much more compact ASCII85
encoding rather than 0x%08X hexdumping.
There are various internal error states that the CTB code can check
for. These should never happen but when they do (driver bug, firmware
bug or even hardware bug), they can be a nightmare to debug. So add in
a capture of the GuC log and CT state at the point of error and
subsequent dump from a worker thread.
Finally, include the GuC log and full CTBs in a devcoredump capture.
Note that the ultimate aim is to then provide a mechanism for
generating a devcoredump at an arbitrary point (such as dead CTB or
failed selftest) and dumping that to dmesg. There are still a few
issues with doing that, but this is all good steps along the way.
v2: Remove pm get/put as unnecessary (review feedback from Matthew B).
v3: Add firmware filename and 'wanted' version number.
v4: Use DRM level line printer wrapper from Michal W. Add 'dead CTB'
dump support. Lots of restructuring of capture vs dump for both GuC
log and CTB capture for both the dead CTB dump and for future
inclusion in devcoredump.
v5: Add missing kerneldocs and other review feedback from Michal W.
Fix printf of size_t, clean up re-arming of dead CTBs, add GuC log to
devcoredump captures.
v6: Replace hexdumps with much more compact ascii85 encoding, drop
module parameter (review feedback from Matthew B). Fix potential
use-after-free bug.
v7: Couple of bug fixes and a bunch of changes to improve
readability/parsablility of the core dump file, debugfs file and dead
CTB dmesg dump.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
John Harrison (9):
drm/xe/guc: Remove spurious line feed in debug print
drm/xe/devcoredump: Add a section heading for the submission backend
drm/xe/devcoredump: Add ASCII85 dump helper function
drm/xe/guc: Copy GuC log prior to dumping
drm/xe/guc: Use a two stage dump for GuC logs and add more info
drm/xe/guc: Dead CT helper
drm/xe/guc: Dump entire CTB on errors
drm/xe/guc: Add GuC log to devcoredump captures
drm/xe/guc: Add a helper function for dumping GuC log to dmesg
Michal Wajdeczko (1):
drm/print: Introduce drm_line_printer
drivers/gpu/drm/drm_print.c | 14 +
.../drm/xe/abi/guc_communication_ctb_abi.h | 1 +
drivers/gpu/drm/xe/regs/xe_guc_regs.h | 1 +
drivers/gpu/drm/xe/xe_devcoredump.c | 104 ++++-
drivers/gpu/drm/xe/xe_devcoredump.h | 6 +
drivers/gpu/drm/xe/xe_devcoredump_types.h | 13 +-
drivers/gpu/drm/xe/xe_guc.c | 2 +-
drivers/gpu/drm/xe/xe_guc_ct.c | 375 ++++++++++++++----
drivers/gpu/drm/xe/xe_guc_ct.h | 10 +-
drivers/gpu/drm/xe/xe_guc_ct_types.h | 29 +-
drivers/gpu/drm/xe/xe_guc_log.c | 208 +++++++++-
drivers/gpu/drm/xe/xe_guc_log.h | 5 +
drivers/gpu/drm/xe/xe_guc_log_types.h | 27 ++
drivers/gpu/drm/xe/xe_guc_submit.c | 2 +-
include/drm/drm_print.h | 64 +++
15 files changed, 738 insertions(+), 123 deletions(-)
--
2.46.0
^ permalink raw reply [flat|nested] 54+ messages in thread
* [PATCH v7 01/10] drm/xe/guc: Remove spurious line feed in debug print
2024-09-05 20:50 [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump John.C.Harrison
@ 2024-09-05 20:50 ` John.C.Harrison
2024-09-10 19:32 ` Julia Filipchuk
2024-09-05 20:50 ` [PATCH v7 02/10] drm/xe/devcoredump: Add a section heading for the submission backend John.C.Harrison
` (17 subsequent siblings)
18 siblings, 1 reply; 54+ messages in thread
From: John.C.Harrison @ 2024-09-05 20:50 UTC (permalink / raw)
To: Intel-Xe; +Cc: John Harrison, Michal Wajdeczko
From: John Harrison <John.C.Harrison@Intel.com>
Including line feeds at the start of a debug print messes up the
output when sent to dmesg. The break appears between all the useful
prefix information and the actual string being printed. In this case,
each block of data has a very clear start line and an extra delimeter
is really not necessary. So don't do it.
v2: Fix typo in commit message (review feedback from Michal W.)
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
---
drivers/gpu/drm/xe/xe_guc_ct.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c
index 4b95f75b1546..a63fe0a9077a 100644
--- a/drivers/gpu/drm/xe/xe_guc_ct.c
+++ b/drivers/gpu/drm/xe/xe_guc_ct.c
@@ -1523,7 +1523,7 @@ void xe_guc_ct_snapshot_print(struct xe_guc_ct_snapshot *snapshot,
drm_puts(p, "H2G CTB (all sizes in DW):\n");
guc_ctb_snapshot_print(&snapshot->h2g, p);
- drm_puts(p, "\nG2H CTB (all sizes in DW):\n");
+ drm_puts(p, "G2H CTB (all sizes in DW):\n");
guc_ctb_snapshot_print(&snapshot->g2h, p);
drm_printf(p, "\tg2h outstanding: %d\n",
--
2.46.0
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v7 02/10] drm/xe/devcoredump: Add a section heading for the submission backend
2024-09-05 20:50 [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump John.C.Harrison
2024-09-05 20:50 ` [PATCH v7 01/10] drm/xe/guc: Remove spurious line feed in debug print John.C.Harrison
@ 2024-09-05 20:50 ` John.C.Harrison
2024-09-10 19:33 ` Julia Filipchuk
2024-09-05 20:50 ` [PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function John.C.Harrison
` (16 subsequent siblings)
18 siblings, 1 reply; 54+ messages in thread
From: John.C.Harrison @ 2024-09-05 20:50 UTC (permalink / raw)
To: Intel-Xe; +Cc: John Harrison
From: John Harrison <John.C.Harrison@Intel.com>
The xe_guc_exec_queue_snapshot is not really a GuC internal thing and
is definitely not a GuC CT thing. So give it its own section heading.
The snapshot itself is really a capture of the submission backend's
internal state. Although all it currently prints out is the submission
contexts. So label it as 'Contexts'. If more general state is added
later then it could be change to 'Submission backend' or some such.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
---
drivers/gpu/drm/xe/xe_devcoredump.c | 2 ++
drivers/gpu/drm/xe/xe_devcoredump_types.h | 3 ++-
drivers/gpu/drm/xe/xe_guc_submit.c | 2 +-
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_devcoredump.c b/drivers/gpu/drm/xe/xe_devcoredump.c
index bdb76e834e4c..c4c656dee18e 100644
--- a/drivers/gpu/drm/xe/xe_devcoredump.c
+++ b/drivers/gpu/drm/xe/xe_devcoredump.c
@@ -98,6 +98,8 @@ static ssize_t __xe_devcoredump_read(char *buffer, size_t count,
drm_printf(&p, "\n**** GuC CT ****\n");
xe_guc_ct_snapshot_print(coredump->snapshot.ct, &p);
+
+ drm_printf(&p, "\n**** Contexts ****\n");
xe_guc_exec_queue_snapshot_print(coredump->snapshot.ge, &p);
drm_printf(&p, "\n**** Job ****\n");
diff --git a/drivers/gpu/drm/xe/xe_devcoredump_types.h b/drivers/gpu/drm/xe/xe_devcoredump_types.h
index 440d05d77a5a..3cc2f095fdfb 100644
--- a/drivers/gpu/drm/xe/xe_devcoredump_types.h
+++ b/drivers/gpu/drm/xe/xe_devcoredump_types.h
@@ -37,7 +37,8 @@ struct xe_devcoredump_snapshot {
/* GuC snapshots */
/** @ct: GuC CT snapshot */
struct xe_guc_ct_snapshot *ct;
- /** @ge: Guc Engine snapshot */
+
+ /** @ge: GuC Submission Engine snapshot */
struct xe_guc_submit_exec_queue_snapshot *ge;
/** @hwe: HW Engine snapshot array */
diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c b/drivers/gpu/drm/xe/xe_guc_submit.c
index fbbe6a487bbb..41442aac348d 100644
--- a/drivers/gpu/drm/xe/xe_guc_submit.c
+++ b/drivers/gpu/drm/xe/xe_guc_submit.c
@@ -2209,7 +2209,7 @@ xe_guc_exec_queue_snapshot_print(struct xe_guc_submit_exec_queue_snapshot *snaps
if (!snapshot)
return;
- drm_printf(p, "\nGuC ID: %d\n", snapshot->guc.id);
+ drm_printf(p, "GuC ID: %d\n", snapshot->guc.id);
drm_printf(p, "\tName: %s\n", snapshot->name);
drm_printf(p, "\tClass: %d\n", snapshot->class);
drm_printf(p, "\tLogical mask: 0x%x\n", snapshot->logical_mask);
--
2.46.0
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function
2024-09-05 20:50 [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump John.C.Harrison
2024-09-05 20:50 ` [PATCH v7 01/10] drm/xe/guc: Remove spurious line feed in debug print John.C.Harrison
2024-09-05 20:50 ` [PATCH v7 02/10] drm/xe/devcoredump: Add a section heading for the submission backend John.C.Harrison
@ 2024-09-05 20:50 ` John.C.Harrison
2024-09-06 1:54 ` Lucas De Marchi
2024-09-10 19:33 ` Julia Filipchuk
2024-09-05 20:50 ` [PATCH v7 04/10] drm/xe/guc: Copy GuC log prior to dumping John.C.Harrison
` (15 subsequent siblings)
18 siblings, 2 replies; 54+ messages in thread
From: John.C.Harrison @ 2024-09-05 20:50 UTC (permalink / raw)
To: Intel-Xe; +Cc: John Harrison
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.
v2: Add a prefix to the output string. Fix memory allocation bug.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
---
drivers/gpu/drm/xe/xe_devcoredump.c | 86 +++++++++++++++++++++++++++++
drivers/gpu/drm/xe/xe_devcoredump.h | 6 ++
2 files changed, 92 insertions(+)
diff --git a/drivers/gpu/drm/xe/xe_devcoredump.c b/drivers/gpu/drm/xe/xe_devcoredump.c
index c4c656dee18e..5e2e93ad773c 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>
@@ -312,3 +313,88 @@ 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
+ * @prefix: optional prefix to add to output string
+ * @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 char *prefix,
+ 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(DMESG_MAX_LINE_LEN, GFP_KERNEL);
+ if (IS_ERR_OR_NULL(line_buff)) {
+ drm_printf(p, "Failed to allocate line buffer: %pe", line_buff);
+ return;
+ }
+
+ blob32 += offset / sizeof(*blob32);
+ size /= sizeof(*blob32);
+
+ if (prefix) {
+ strscpy(line_buff, prefix, DMESG_MAX_LINE_LEN - MIN_SPACE - 3);
+ line_pos = strlen(line_buff);
+
+ line_buff[line_pos++] = ':';
+ line_buff[line_pos++] = ' ';
+ }
+
+ 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);
+
+#undef MIN_SPACE
+}
diff --git a/drivers/gpu/drm/xe/xe_devcoredump.h b/drivers/gpu/drm/xe/xe_devcoredump.h
index e2fa65ce0932..a4eebc285fc8 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,7 @@ static inline int xe_devcoredump_init(struct xe_device *xe)
}
#endif
+void xe_print_blob_ascii85(struct drm_printer *p, const char *prefix,
+ const void *blob, size_t offset, size_t size);
+
#endif
--
2.46.0
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v7 04/10] drm/xe/guc: Copy GuC log prior to dumping
2024-09-05 20:50 [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump John.C.Harrison
` (2 preceding siblings ...)
2024-09-05 20:50 ` [PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function John.C.Harrison
@ 2024-09-05 20:50 ` John.C.Harrison
2024-09-11 0:48 ` Julia Filipchuk
2024-09-05 20:51 ` [PATCH v7 05/10] drm/xe/guc: Use a two stage dump for GuC logs and add more info John.C.Harrison
` (14 subsequent siblings)
18 siblings, 1 reply; 54+ messages in thread
From: John.C.Harrison @ 2024-09-05 20:50 UTC (permalink / raw)
To: Intel-Xe; +Cc: John Harrison
From: John Harrison <John.C.Harrison@Intel.com>
Add an extra stage to the GuC log print to copy the log buffer into
regular host memory first, rather than printing the live GPU buffer
object directly. Doing so helps prevent inconsistencies due to the log
being updated as it is being dumped. It also allows the use of the
ASCII85 helper function for printing the log in a more compact form
than a straight hex dump.
v2: Use %zx instead of %lx for size_t prints.
v3: Replace hexdump code with ascii85 call (review feedback from
Matthew B). Move chunking code into next patch as that reduces the
deltas of both.
v4: Add a prefix to the ASCII85 output to aid tool parsing.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
---
drivers/gpu/drm/xe/xe_guc_log.c | 40 +++++++++++++++++++--------------
1 file changed, 23 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_guc_log.c b/drivers/gpu/drm/xe/xe_guc_log.c
index a37ee3419428..be47780ec2a7 100644
--- a/drivers/gpu/drm/xe/xe_guc_log.c
+++ b/drivers/gpu/drm/xe/xe_guc_log.c
@@ -6,9 +6,12 @@
#include "xe_guc_log.h"
#include <drm/drm_managed.h>
+#include <linux/vmalloc.h>
#include "xe_bo.h"
+#include "xe_devcoredump.h"
#include "xe_gt.h"
+#include "xe_gt_printk.h"
#include "xe_map.h"
#include "xe_module.h"
@@ -49,32 +52,35 @@ static size_t guc_log_size(void)
CAPTURE_BUFFER_SIZE;
}
+/**
+ * xe_guc_log_print - dump a copy of the GuC log to some useful location
+ * @log: GuC log structure
+ * @p: the printer object to output to
+ */
void xe_guc_log_print(struct xe_guc_log *log, struct drm_printer *p)
{
struct xe_device *xe = log_to_xe(log);
size_t size;
- int i, j;
+ void *copy;
- xe_assert(xe, log->bo);
+ if (!log->bo) {
+ drm_puts(p, "GuC log buffer not allocated");
+ return;
+ }
size = log->bo->size;
-#define DW_PER_READ 128
- xe_assert(xe, !(size % (DW_PER_READ * sizeof(u32))));
- for (i = 0; i < size / sizeof(u32); i += DW_PER_READ) {
- u32 read[DW_PER_READ];
-
- xe_map_memcpy_from(xe, read, &log->bo->vmap, i * sizeof(u32),
- DW_PER_READ * sizeof(u32));
-#define DW_PER_PRINT 4
- for (j = 0; j < DW_PER_READ / DW_PER_PRINT; ++j) {
- u32 *print = read + j * DW_PER_PRINT;
-
- drm_printf(p, "0x%08x 0x%08x 0x%08x 0x%08x\n",
- *(print + 0), *(print + 1),
- *(print + 2), *(print + 3));
- }
+ copy = vmalloc(size);
+ if (!copy) {
+ drm_printf(p, "Failed to allocate %zu", size);
+ return;
}
+
+ xe_map_memcpy_from(xe, copy, &log->bo->vmap, 0, size);
+
+ xe_print_blob_ascii85(p, "Log data", copy, 0, size);
+
+ vfree(copy);
}
int xe_guc_log_init(struct xe_guc_log *log)
--
2.46.0
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v7 05/10] drm/xe/guc: Use a two stage dump for GuC logs and add more info
2024-09-05 20:50 [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump John.C.Harrison
` (3 preceding siblings ...)
2024-09-05 20:50 ` [PATCH v7 04/10] drm/xe/guc: Copy GuC log prior to dumping John.C.Harrison
@ 2024-09-05 20:51 ` John.C.Harrison
2024-09-11 0:48 ` Julia Filipchuk
2024-09-05 20:51 ` [PATCH v7 06/10] drm/print: Introduce drm_line_printer John.C.Harrison
` (13 subsequent siblings)
18 siblings, 1 reply; 54+ messages in thread
From: John.C.Harrison @ 2024-09-05 20:51 UTC (permalink / raw)
To: Intel-Xe; +Cc: John Harrison
From: John Harrison <John.C.Harrison@Intel.com>
Split the GuC log dump into a two stage snapshot and print mechanism.
This allows the log to be captured at the point of an error (which may
be in a restricted context) and then dump it out later (from a regular
context such as a worker function or a sysfs file handler).
Also add a bunch of other useful pieces of information that can help
(or are fundamentally required!) to decode and parse the log.
v2: Add kerneldoc and fix a couple of comment typos - review feedback
from Michal W.
v3: Move chunking code to this patch as it makes the deltas simpler.
Fix a bunch of kerneldoc issues.
v4: Move the CS frequency out of the coredump snapshot function into
the debugfs only code (as that info is already part of the main
devcoredump). Add a header to the debugfs log to match the one in the
devcoredump to aid processing by a unified tool. Add forcewake to the
GuC timestamp read so it actually works.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
---
drivers/gpu/drm/xe/regs/xe_guc_regs.h | 1 +
drivers/gpu/drm/xe/xe_guc_log.c | 178 +++++++++++++++++++++++---
drivers/gpu/drm/xe/xe_guc_log.h | 4 +
drivers/gpu/drm/xe/xe_guc_log_types.h | 27 ++++
4 files changed, 195 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/xe/regs/xe_guc_regs.h b/drivers/gpu/drm/xe/regs/xe_guc_regs.h
index a5fd14307f94..b27b73680c12 100644
--- a/drivers/gpu/drm/xe/regs/xe_guc_regs.h
+++ b/drivers/gpu/drm/xe/regs/xe_guc_regs.h
@@ -84,6 +84,7 @@
#define HUC_LOADING_AGENT_GUC REG_BIT(1)
#define GUC_WOPCM_OFFSET_VALID REG_BIT(0)
#define GUC_MAX_IDLE_COUNT XE_REG(0xc3e4)
+#define GUC_PMTIMESTAMP XE_REG(0xc3e8)
#define GUC_SEND_INTERRUPT XE_REG(0xc4c8)
#define GUC_SEND_TRIGGER REG_BIT(0)
diff --git a/drivers/gpu/drm/xe/xe_guc_log.c b/drivers/gpu/drm/xe/xe_guc_log.c
index be47780ec2a7..0777ffbd14d5 100644
--- a/drivers/gpu/drm/xe/xe_guc_log.c
+++ b/drivers/gpu/drm/xe/xe_guc_log.c
@@ -6,15 +6,23 @@
#include "xe_guc_log.h"
#include <drm/drm_managed.h>
-#include <linux/vmalloc.h>
+#include "regs/xe_guc_regs.h"
#include "xe_bo.h"
#include "xe_devcoredump.h"
+#include "xe_force_wake.h"
#include "xe_gt.h"
#include "xe_gt_printk.h"
#include "xe_map.h"
+#include "xe_mmio.h"
#include "xe_module.h"
+static struct xe_guc *
+log_to_guc(struct xe_guc_log *log)
+{
+ return container_of(log, struct xe_guc, log);
+}
+
static struct xe_gt *
log_to_gt(struct xe_guc_log *log)
{
@@ -52,35 +60,175 @@ static size_t guc_log_size(void)
CAPTURE_BUFFER_SIZE;
}
+#define GUC_LOG_CHUNK_SIZE SZ_2M
+
+static struct xe_guc_log_snapshot *xe_guc_log_snapshot_alloc(struct xe_guc_log *log, bool atomic)
+{
+ struct xe_guc_log_snapshot *snapshot;
+ size_t remain;
+ int i;
+
+ snapshot = kzalloc(sizeof(*snapshot), atomic ? GFP_ATOMIC : GFP_KERNEL);
+ if (!snapshot)
+ return NULL;
+
+ /*
+ * NB: kmalloc has a hard limit well below the maximum GuC log buffer size.
+ * Also, can't use vmalloc as might be called from atomic context. So need
+ * to break the buffer up into smaller chunks that can be allocated.
+ */
+ snapshot->size = log->bo->size;
+ snapshot->num_chunks = DIV_ROUND_UP(snapshot->size, GUC_LOG_CHUNK_SIZE);
+
+ snapshot->copy = kcalloc(snapshot->num_chunks, sizeof(*snapshot->copy),
+ atomic ? GFP_ATOMIC : GFP_KERNEL);
+ if (!snapshot->copy)
+ goto fail_snap;
+
+ remain = snapshot->size;
+ for (i = 0; i < snapshot->num_chunks; i++) {
+ size_t size = min(GUC_LOG_CHUNK_SIZE, remain);
+
+ snapshot->copy[i] = kmalloc(size, atomic ? GFP_ATOMIC : GFP_KERNEL);
+ if (!snapshot->copy[i])
+ goto fail_copy;
+ remain -= size;
+ }
+
+ return snapshot;
+
+fail_copy:
+ for (i = 0; i < snapshot->num_chunks; i++)
+ kfree(snapshot->copy[i]);
+ kfree(snapshot->copy);
+fail_snap:
+ kfree(snapshot);
+ return NULL;
+}
+
/**
- * xe_guc_log_print - dump a copy of the GuC log to some useful location
+ * xe_guc_log_snapshot_free - free a previously captured GuC log snapshot
+ * @snapshot: GuC log snapshot structure
+ *
+ * Return: pointer to a newly allocated snapshot object or null if out of memory. Caller is
+ * responsible for calling xe_guc_log_snapshot_free when done with the snapshot.
+ */
+void xe_guc_log_snapshot_free(struct xe_guc_log_snapshot *snapshot)
+{
+ int i;
+
+ if (!snapshot)
+ return;
+
+ if (!snapshot->copy) {
+ for (i = 0; i < snapshot->num_chunks; i++)
+ kfree(snapshot->copy[i]);
+ kfree(snapshot->copy);
+ }
+
+ kfree(snapshot);
+}
+
+/**
+ * xe_guc_log_snapshot_capture - create a new snapshot copy the GuC log for later dumping
* @log: GuC log structure
- * @p: the printer object to output to
+ * @atomic: is the call inside an atomic section of some kind?
+ *
+ * Return: pointer to a newly allocated snapshot object or null if out of memory. Caller is
+ * responsible for calling xe_guc_log_snapshot_free when done with the snapshot.
*/
-void xe_guc_log_print(struct xe_guc_log *log, struct drm_printer *p)
+struct xe_guc_log_snapshot *xe_guc_log_snapshot_capture(struct xe_guc_log *log, bool atomic)
{
+ struct xe_guc_log_snapshot *snapshot;
struct xe_device *xe = log_to_xe(log);
- size_t size;
- void *copy;
+ struct xe_guc *guc = log_to_guc(log);
+ struct xe_gt *gt = log_to_gt(log);
+ size_t remain;
+ int i, err;
if (!log->bo) {
- drm_puts(p, "GuC log buffer not allocated");
- return;
+ xe_gt_err(gt, "GuC log buffer not allocated\n");
+ return NULL;
+ }
+
+ snapshot = xe_guc_log_snapshot_alloc(log, atomic);
+ if (!snapshot) {
+ xe_gt_err(gt, "GuC log snapshot not allocated\n");
+ return NULL;
}
- size = log->bo->size;
+ remain = snapshot->size;
+ for (i = 0; i < snapshot->num_chunks; i++) {
+ size_t size = min(GUC_LOG_CHUNK_SIZE, remain);
+
+ xe_map_memcpy_from(xe, snapshot->copy[i], &log->bo->vmap,
+ i * GUC_LOG_CHUNK_SIZE, size);
+ remain -= size;
+ }
+
+ err = xe_force_wake_get(gt_to_fw(gt), XE_FW_GT);
+ if (err) {
+ snapshot->stamp = ~0;
+ } else {
+ snapshot->stamp = xe_mmio_read32(gt, GUC_PMTIMESTAMP);
+ xe_force_wake_put(gt_to_fw(gt), XE_FW_GT);
+ }
+ snapshot->ktime = ktime_get_boottime_ns();
+ snapshot->level = log->level;
+ snapshot->ver_found = guc->fw.versions.found[XE_UC_FW_VER_RELEASE];
+ snapshot->ver_want = guc->fw.versions.wanted;
+ snapshot->path = guc->fw.path;
+
+ return snapshot;
+}
+
+/**
+ * xe_guc_log_snapshot_print - dump a previously saved copy of the GuC log to some useful location
+ * @snapshot: a snapshot of the GuC log
+ * @p: the printer object to output to
+ */
+void xe_guc_log_snapshot_print(struct xe_guc_log_snapshot *snapshot, struct drm_printer *p)
+{
+ size_t remain;
+ int i;
- copy = vmalloc(size);
- if (!copy) {
- drm_printf(p, "Failed to allocate %zu", size);
+ if (!snapshot) {
+ drm_printf(p, "GuC log snapshot not allocated!\n");
return;
}
- xe_map_memcpy_from(xe, copy, &log->bo->vmap, 0, size);
+ drm_printf(p, "GuC firmware: %s\n", snapshot->path);
+ drm_printf(p, "GuC version %u.%u.%u (wanted %u.%u.%u)\n",
+ snapshot->ver_found.major, snapshot->ver_found.minor, snapshot->ver_found.patch,
+ snapshot->ver_want.major, snapshot->ver_want.minor, snapshot->ver_want.patch);
+ drm_printf(p, "Kernel timestamp: 0x%08llX [%llu]\n", snapshot->ktime, snapshot->ktime);
+ drm_printf(p, "GuC timestamp: 0x%08X [%u]\n", snapshot->stamp, snapshot->stamp);
+ drm_printf(p, "Log level: %u\n", snapshot->level);
+
+ remain = snapshot->size;
+ for (i = 0; i < snapshot->num_chunks; i++) {
+ size_t size = min(GUC_LOG_CHUNK_SIZE, remain);
+
+ xe_print_blob_ascii85(p, i ? NULL : "Log data", snapshot->copy[i], 0, size);
+ remain -= size;
+ }
+}
+
+/**
+ * xe_guc_log_print - dump a copy of the GuC log to some useful location
+ * @log: GuC log structure
+ * @p: the printer object to output to
+ */
+void xe_guc_log_print(struct xe_guc_log *log, struct drm_printer *p)
+{
+ struct xe_guc_log_snapshot *snapshot;
- xe_print_blob_ascii85(p, "Log data", copy, 0, size);
+ drm_printf(p, "**** GuC Log ****\n");
- vfree(copy);
+ snapshot = xe_guc_log_snapshot_capture(log, false);
+ drm_printf(p, "CS reference clock: %u\n", log_to_gt(log)->info.reference_clock);
+ xe_guc_log_snapshot_print(snapshot, p);
+ xe_guc_log_snapshot_free(snapshot);
}
int xe_guc_log_init(struct xe_guc_log *log)
diff --git a/drivers/gpu/drm/xe/xe_guc_log.h b/drivers/gpu/drm/xe/xe_guc_log.h
index 2d25ab28b4b3..949d2c98343d 100644
--- a/drivers/gpu/drm/xe/xe_guc_log.h
+++ b/drivers/gpu/drm/xe/xe_guc_log.h
@@ -9,6 +9,7 @@
#include "xe_guc_log_types.h"
struct drm_printer;
+struct xe_device;
#if IS_ENABLED(CONFIG_DRM_XE_LARGE_GUC_BUFFER)
#define CRASH_BUFFER_SIZE SZ_1M
@@ -38,6 +39,9 @@ struct drm_printer;
int xe_guc_log_init(struct xe_guc_log *log);
void xe_guc_log_print(struct xe_guc_log *log, struct drm_printer *p);
+struct xe_guc_log_snapshot *xe_guc_log_snapshot_capture(struct xe_guc_log *log, bool atomic);
+void xe_guc_log_snapshot_print(struct xe_guc_log_snapshot *snapshot, struct drm_printer *p);
+void xe_guc_log_snapshot_free(struct xe_guc_log_snapshot *snapshot);
static inline u32
xe_guc_log_get_level(struct xe_guc_log *log)
diff --git a/drivers/gpu/drm/xe/xe_guc_log_types.h b/drivers/gpu/drm/xe/xe_guc_log_types.h
index 125080d138a7..962b9edbd9eb 100644
--- a/drivers/gpu/drm/xe/xe_guc_log_types.h
+++ b/drivers/gpu/drm/xe/xe_guc_log_types.h
@@ -8,8 +8,35 @@
#include <linux/types.h>
+#include "xe_uc_fw_types.h"
+
struct xe_bo;
+/**
+ * struct xe_guc_log_snapshot:
+ * Capture of the GuC log plus various state useful for decoding the log
+ */
+struct xe_guc_log_snapshot {
+ /** @size: Size in bytes of the @copy allocation */
+ size_t size;
+ /** @copy: Host memory copy of the log buffer for later dumping, split into chunks */
+ void **copy;
+ /** @num_chunks: Number of chunks within @copy */
+ int num_chunks;
+ /** @ktime: Kernel time the snapshot was taken */
+ u64 ktime;
+ /** @stamp: GuC timestamp at which the snapshot was taken */
+ u32 stamp;
+ /** @level: GuC log verbosity level */
+ u32 level;
+ /** @ver_found: GuC firmware version */
+ struct xe_uc_fw_version ver_found;
+ /** @ver_want: GuC firmware version that driver expected */
+ struct xe_uc_fw_version ver_want;
+ /** @path: Path of GuC firmware blob */
+ const char *path;
+};
+
/**
* struct xe_guc_log - GuC log
*/
--
2.46.0
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v7 06/10] drm/print: Introduce drm_line_printer
2024-09-05 20:50 [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump John.C.Harrison
` (4 preceding siblings ...)
2024-09-05 20:51 ` [PATCH v7 05/10] drm/xe/guc: Use a two stage dump for GuC logs and add more info John.C.Harrison
@ 2024-09-05 20:51 ` John.C.Harrison
2024-09-05 20:51 ` [PATCH v7 07/10] drm/xe/guc: Dead CT helper John.C.Harrison
` (12 subsequent siblings)
18 siblings, 0 replies; 54+ messages in thread
From: John.C.Harrison @ 2024-09-05 20:51 UTC (permalink / raw)
To: Intel-Xe; +Cc: Michal Wajdeczko, Jani Nikula, John Harrison
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
This drm printer wrapper can be used to increase the robustness of
the captured output generated by any other drm_printer to make sure
we didn't lost any intermediate lines of the output by adding line
numbers to each output line. Helpful for capturing some crash data.
v2: Extended short int counters to full int (JohnH)
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
---
drivers/gpu/drm/drm_print.c | 14 ++++++++
include/drm/drm_print.h | 64 +++++++++++++++++++++++++++++++++++++
2 files changed, 78 insertions(+)
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 0081190201a7..08cfea04e22b 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -235,6 +235,20 @@ void __drm_printfn_err(struct drm_printer *p, struct va_format *vaf)
}
EXPORT_SYMBOL(__drm_printfn_err);
+void __drm_printfn_line(struct drm_printer *p, struct va_format *vaf)
+{
+ unsigned int counter = ++p->line.counter;
+ const char *prefix = p->prefix ?: "";
+ const char *pad = p->prefix ? " " : "";
+
+ if (p->line.series)
+ drm_printf(p->arg, "%s%s%u.%u: %pV",
+ prefix, pad, p->line.series, counter, vaf);
+ else
+ drm_printf(p->arg, "%s%s%u: %pV", prefix, pad, counter, vaf);
+}
+EXPORT_SYMBOL(__drm_printfn_line);
+
/**
* drm_puts - print a const string to a &drm_printer stream
* @p: the &drm printer
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index d2676831d765..b3906dc04388 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -177,6 +177,10 @@ struct drm_printer {
void *arg;
const void *origin;
const char *prefix;
+ struct {
+ unsigned int series;
+ unsigned int counter;
+ } line;
enum drm_debug_category category;
};
@@ -187,6 +191,7 @@ void __drm_puts_seq_file(struct drm_printer *p, const char *str);
void __drm_printfn_info(struct drm_printer *p, struct va_format *vaf);
void __drm_printfn_dbg(struct drm_printer *p, struct va_format *vaf);
void __drm_printfn_err(struct drm_printer *p, struct va_format *vaf);
+void __drm_printfn_line(struct drm_printer *p, struct va_format *vaf);
__printf(2, 3)
void drm_printf(struct drm_printer *p, const char *f, ...);
@@ -411,6 +416,65 @@ static inline struct drm_printer drm_err_printer(struct drm_device *drm,
return p;
}
+/**
+ * drm_line_printer - construct a &drm_printer that prefixes outputs with line numbers
+ * @p: the &struct drm_printer which actually generates the output
+ * @prefix: optional output prefix, or NULL for no prefix
+ * @series: optional unique series identifier, or 0 to omit identifier in the output
+ *
+ * This printer can be used to increase the robustness of the captured output
+ * to make sure we didn't lost any intermediate lines of the output. Helpful
+ * while capturing some crash data.
+ *
+ * Example 1::
+ *
+ * void crash_dump(struct drm_device *drm)
+ * {
+ * static unsigned int id;
+ * struct drm_printer p = drm_err_printer(drm, "crash");
+ * struct drm_printer lp = drm_line_printer(&p, "dump", ++id);
+ *
+ * drm_printf(&lp, "foo");
+ * drm_printf(&lp, "bar");
+ * }
+ *
+ * Above code will print into the dmesg something like::
+ *
+ * [ ] 0000:00:00.0: [drm] *ERROR* crash dump 1.1: foo
+ * [ ] 0000:00:00.0: [drm] *ERROR* crash dump 1.2: bar
+ *
+ * Example 2::
+ *
+ * void line_dump(struct device *dev)
+ * {
+ * struct drm_printer p = drm_info_printer(dev);
+ * struct drm_printer lp = drm_line_printer(&p, NULL, 0);
+ *
+ * drm_printf(&lp, "foo");
+ * drm_printf(&lp, "bar");
+ * }
+ *
+ * Above code will print::
+ *
+ * [ ] 0000:00:00.0: [drm] 1: foo
+ * [ ] 0000:00:00.0: [drm] 2: bar
+ *
+ * RETURNS:
+ * The &drm_printer object
+ */
+static inline struct drm_printer drm_line_printer(struct drm_printer *p,
+ const char *prefix,
+ unsigned int series)
+{
+ struct drm_printer lp = {
+ .printfn = __drm_printfn_line,
+ .arg = p,
+ .prefix = prefix,
+ .line = { .series = series, },
+ };
+ return lp;
+}
+
/*
* struct device based logging
*
--
2.46.0
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v7 07/10] drm/xe/guc: Dead CT helper
2024-09-05 20:50 [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump John.C.Harrison
` (5 preceding siblings ...)
2024-09-05 20:51 ` [PATCH v7 06/10] drm/print: Introduce drm_line_printer John.C.Harrison
@ 2024-09-05 20:51 ` John.C.Harrison
2024-09-11 0:09 ` John Harrison
2024-09-11 19:55 ` Julia Filipchuk
2024-09-05 20:51 ` [PATCH v7 08/10] drm/xe/guc: Dump entire CTB on errors John.C.Harrison
` (11 subsequent siblings)
18 siblings, 2 replies; 54+ messages in thread
From: John.C.Harrison @ 2024-09-05 20:51 UTC (permalink / raw)
To: Intel-Xe; +Cc: John Harrison
From: John Harrison <John.C.Harrison@Intel.com>
Add a worker function helper for asynchronously dumping state when an
internal/fatal error is detected in CT processing. Being asynchronous
is required to avoid deadlocks and scheduling-while-atomic or
process-stalled-for-too-long issues. Also check for a bunch more error
conditions and improve the handling of some existing checks.
v2: Use compile time CONFIG check for new (but not directly CT_DEAD
related) checks and use unsigned int for a bitmask, rename
CT_DEAD_RESET to CT_DEAD_REARM and add some explaining comments,
rename 'hxg' macro parameter to 'ctb' - review feedback from Michal W.
Drop CT_DEAD_ALIVE as no need for a bitfield define to just set the
entire mask to zero.
v3: Fix kerneldoc
v4: Nullify some floating pointers after free.
v5: Add section headings and device info to make the state dump look
more like a devcoredump to allow parsing by the same tools (eventual
aim is to just call the devcoredump code itself, but that currently
requires an xe_sched_job, which is not available in the CT code).
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
---
.../drm/xe/abi/guc_communication_ctb_abi.h | 1 +
drivers/gpu/drm/xe/xe_guc.c | 2 +-
drivers/gpu/drm/xe/xe_guc_ct.c | 280 ++++++++++++++++--
drivers/gpu/drm/xe/xe_guc_ct.h | 2 +-
drivers/gpu/drm/xe/xe_guc_ct_types.h | 23 ++
5 files changed, 280 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/xe/abi/guc_communication_ctb_abi.h b/drivers/gpu/drm/xe/abi/guc_communication_ctb_abi.h
index 8f86a16dc577..f58198cf2cf6 100644
--- a/drivers/gpu/drm/xe/abi/guc_communication_ctb_abi.h
+++ b/drivers/gpu/drm/xe/abi/guc_communication_ctb_abi.h
@@ -52,6 +52,7 @@ struct guc_ct_buffer_desc {
#define GUC_CTB_STATUS_OVERFLOW (1 << 0)
#define GUC_CTB_STATUS_UNDERFLOW (1 << 1)
#define GUC_CTB_STATUS_MISMATCH (1 << 2)
+#define GUC_CTB_STATUS_DISABLED (1 << 3)
u32 reserved[13];
} __packed;
static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
diff --git a/drivers/gpu/drm/xe/xe_guc.c b/drivers/gpu/drm/xe/xe_guc.c
index 34cdb08b6e27..3fef24c965c4 100644
--- a/drivers/gpu/drm/xe/xe_guc.c
+++ b/drivers/gpu/drm/xe/xe_guc.c
@@ -1176,7 +1176,7 @@ void xe_guc_print_info(struct xe_guc *guc, struct drm_printer *p)
xe_force_wake_put(gt_to_fw(gt), XE_FW_GT);
- xe_guc_ct_print(&guc->ct, p, false);
+ xe_guc_ct_print(&guc->ct, p);
xe_guc_submit_print(guc, p);
}
diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c
index a63fe0a9077a..e31b1f0b855f 100644
--- a/drivers/gpu/drm/xe/xe_guc_ct.c
+++ b/drivers/gpu/drm/xe/xe_guc_ct.c
@@ -25,12 +25,57 @@
#include "xe_gt_sriov_pf_monitor.h"
#include "xe_gt_tlb_invalidation.h"
#include "xe_guc.h"
+#include "xe_guc_log.h"
#include "xe_guc_relay.h"
#include "xe_guc_submit.h"
#include "xe_map.h"
#include "xe_pm.h"
#include "xe_trace_guc.h"
+#if IS_ENABLED(CONFIG_DRM_XE_DEBUG)
+enum {
+ CT_DEAD_REARM, /* 0x0001 - not an error condition */
+ CT_DEAD_SETUP, /* 0x0002 */
+ CT_DEAD_H2G_WRITE, /* 0x0004 */
+ CT_DEAD_H2G_HAS_ROOM, /* 0x0008 */
+ CT_DEAD_G2H_READ, /* 0x0010 */
+ CT_DEAD_G2H_RECV, /* 0x0020 */
+ CT_DEAD_G2H_RELEASE, /* 0x0040 */
+ CT_DEAD_DEADLOCK, /* 0x0080 */
+ CT_DEAD_PROCESS_FAILED, /* 0x0100 */
+ CT_DEAD_FAST_G2H, /* 0x0200 */
+ CT_DEAD_PARSE_G2H_RESPONSE, /* 0x0400 */
+ CT_DEAD_PARSE_G2H_UNKNOWN, /* 0x0800 */
+ CT_DEAD_PARSE_G2H_ORIGIN, /* 0x1000 */
+ CT_DEAD_PARSE_G2H_TYPE, /* 0x2000 */
+};
+
+static void ct_dead_worker_func(struct work_struct *w);
+
+#define CT_DEAD(ct, ctb, reason_code) \
+ do { \
+ struct guc_ctb *_ctb = (ctb); \
+ if (_ctb) \
+ _ctb->info.broken = true; \
+ if (!(ct)->dead.reported) { \
+ struct xe_guc *guc = ct_to_guc(ct); \
+ spin_lock_irq(&ct->dead.lock); \
+ (ct)->dead.reason |= 1 << CT_DEAD_##reason_code; \
+ (ct)->dead.snapshot_log = xe_guc_log_snapshot_capture(&guc->log, true); \
+ (ct)->dead.snapshot_ct = xe_guc_ct_snapshot_capture((ct), true); \
+ spin_unlock_irq(&ct->dead.lock); \
+ queue_work(system_unbound_wq, &(ct)->dead.worker); \
+ } \
+ } while (0)
+#else
+#define CT_DEAD(ct, ctb, reason) \
+ do { \
+ struct guc_ctb *_ctb = (ctb); \
+ if (_ctb) \
+ _ctb->info.broken = true; \
+ } while (0)
+#endif
+
/* Used when a CT send wants to block and / or receive data */
struct g2h_fence {
u32 *response_buffer;
@@ -183,6 +228,10 @@ int xe_guc_ct_init(struct xe_guc_ct *ct)
xa_init(&ct->fence_lookup);
INIT_WORK(&ct->g2h_worker, g2h_worker_func);
INIT_DELAYED_WORK(&ct->safe_mode_worker, safe_mode_worker_func);
+#if IS_ENABLED(CONFIG_DRM_XE_DEBUG)
+ spin_lock_init(&ct->dead.lock);
+ INIT_WORK(&ct->dead.worker, ct_dead_worker_func);
+#endif
init_waitqueue_head(&ct->wq);
init_waitqueue_head(&ct->g2h_fence_wq);
@@ -419,10 +468,22 @@ int xe_guc_ct_enable(struct xe_guc_ct *ct)
if (ct_needs_safe_mode(ct))
ct_enter_safe_mode(ct);
+#if IS_ENABLED(CONFIG_DRM_XE_DEBUG)
+ /*
+ * The CT has now been reset so the dumper can be re-armed
+ * after any existing dead state has been dumped.
+ */
+ spin_lock_irq(&ct->dead.lock);
+ if (ct->dead.reason)
+ ct->dead.reason |= CT_DEAD_REARM;
+ spin_unlock_irq(&ct->dead.lock);
+#endif
+
return 0;
err_out:
xe_gt_err(gt, "Failed to enable GuC CT (%pe)\n", ERR_PTR(err));
+ CT_DEAD(ct, NULL, SETUP);
return err;
}
@@ -466,6 +527,19 @@ static bool h2g_has_room(struct xe_guc_ct *ct, u32 cmd_len)
if (cmd_len > h2g->info.space) {
h2g->info.head = desc_read(ct_to_xe(ct), h2g, head);
+
+ if (h2g->info.head > h2g->info.size) {
+ struct xe_device *xe = ct_to_xe(ct);
+ u32 desc_status = desc_read(xe, h2g, status);
+
+ desc_write(xe, h2g, status, desc_status | GUC_CTB_STATUS_OVERFLOW);
+
+ xe_gt_err(ct_to_gt(ct), "CT: invalid head offset %u >= %u)\n",
+ h2g->info.head, h2g->info.size);
+ CT_DEAD(ct, h2g, H2G_HAS_ROOM);
+ return false;
+ }
+
h2g->info.space = CIRC_SPACE(h2g->info.tail, h2g->info.head,
h2g->info.size) -
h2g->info.resv_space;
@@ -521,10 +595,24 @@ static void __g2h_reserve_space(struct xe_guc_ct *ct, u32 g2h_len, u32 num_g2h)
static void __g2h_release_space(struct xe_guc_ct *ct, u32 g2h_len)
{
+ bool bad = false;
+
lockdep_assert_held(&ct->fast_lock);
- xe_gt_assert(ct_to_gt(ct), ct->ctbs.g2h.info.space + g2h_len <=
- ct->ctbs.g2h.info.size - ct->ctbs.g2h.info.resv_space);
- xe_gt_assert(ct_to_gt(ct), ct->g2h_outstanding);
+
+ bad = ct->ctbs.g2h.info.space + g2h_len >
+ ct->ctbs.g2h.info.size - ct->ctbs.g2h.info.resv_space;
+ bad |= !ct->g2h_outstanding;
+
+ if (bad) {
+ xe_gt_err(ct_to_gt(ct), "Invalid G2H release: %d + %d vs %d - %d -> %d vs %d, outstanding = %d!\n",
+ ct->ctbs.g2h.info.space, g2h_len,
+ ct->ctbs.g2h.info.size, ct->ctbs.g2h.info.resv_space,
+ ct->ctbs.g2h.info.space + g2h_len,
+ ct->ctbs.g2h.info.size - ct->ctbs.g2h.info.resv_space,
+ ct->g2h_outstanding);
+ CT_DEAD(ct, &ct->ctbs.g2h, G2H_RELEASE);
+ return;
+ }
ct->ctbs.g2h.info.space += g2h_len;
if (!--ct->g2h_outstanding)
@@ -551,12 +639,43 @@ static int h2g_write(struct xe_guc_ct *ct, const u32 *action, u32 len,
u32 full_len;
struct iosys_map map = IOSYS_MAP_INIT_OFFSET(&h2g->cmds,
tail * sizeof(u32));
+ u32 desc_status;
full_len = len + GUC_CTB_HDR_LEN;
lockdep_assert_held(&ct->lock);
xe_gt_assert(gt, full_len <= GUC_CTB_MSG_MAX_LEN);
- xe_gt_assert(gt, tail <= h2g->info.size);
+
+ desc_status = desc_read(xe, h2g, status);
+ if (desc_status) {
+ xe_gt_err(gt, "CT write: non-zero status: %u\n", desc_status);
+ goto corrupted;
+ }
+
+ if (IS_ENABLED(CONFIG_DRM_XE_DEBUG)) {
+ u32 desc_tail = desc_read(xe, h2g, tail);
+ u32 desc_head = desc_read(xe, h2g, head);
+
+ if (tail != desc_tail) {
+ desc_write(xe, h2g, status, desc_status | GUC_CTB_STATUS_MISMATCH);
+ xe_gt_err(gt, "CT write: tail was modified %u != %u\n", desc_tail, tail);
+ goto corrupted;
+ }
+
+ if (tail > h2g->info.size) {
+ desc_write(xe, h2g, status, desc_status | GUC_CTB_STATUS_OVERFLOW);
+ xe_gt_err(gt, "CT write: tail out of range: %u vs %u\n",
+ tail, h2g->info.size);
+ goto corrupted;
+ }
+
+ if (desc_head >= h2g->info.size) {
+ desc_write(xe, h2g, status, desc_status | GUC_CTB_STATUS_OVERFLOW);
+ xe_gt_err(gt, "CT write: invalid head offset %u >= %u)\n",
+ desc_head, h2g->info.size);
+ goto corrupted;
+ }
+ }
/* Command will wrap, zero fill (NOPs), return and check credits again */
if (tail + full_len > h2g->info.size) {
@@ -609,6 +728,10 @@ static int h2g_write(struct xe_guc_ct *ct, const u32 *action, u32 len,
desc_read(xe, h2g, head), h2g->info.tail);
return 0;
+
+corrupted:
+ CT_DEAD(ct, &ct->ctbs.h2g, H2G_WRITE);
+ return -EPIPE;
}
/*
@@ -720,7 +843,6 @@ static int guc_ct_send_locked(struct xe_guc_ct *ct, const u32 *action, u32 len,
{
struct xe_device *xe = ct_to_xe(ct);
struct xe_gt *gt = ct_to_gt(ct);
- struct drm_printer p = xe_gt_info_printer(gt);
unsigned int sleep_period_ms = 1;
int ret;
@@ -773,8 +895,13 @@ static int guc_ct_send_locked(struct xe_guc_ct *ct, const u32 *action, u32 len,
goto broken;
#undef g2h_avail
- if (dequeue_one_g2h(ct) < 0)
+ ret = dequeue_one_g2h(ct);
+ if (ret < 0) {
+ if (ret != -ECANCELED)
+ xe_gt_err(ct_to_gt(ct), "CTB receive failed (%pe)",
+ ERR_PTR(ret));
goto broken;
+ }
goto try_again;
}
@@ -783,8 +910,7 @@ static int guc_ct_send_locked(struct xe_guc_ct *ct, const u32 *action, u32 len,
broken:
xe_gt_err(gt, "No forward process on H2G, reset required\n");
- xe_guc_ct_print(ct, &p, true);
- ct->ctbs.h2g.info.broken = true;
+ CT_DEAD(ct, &ct->ctbs.h2g, DEADLOCK);
return -EDEADLK;
}
@@ -1011,6 +1137,7 @@ static int parse_g2h_response(struct xe_guc_ct *ct, u32 *msg, u32 len)
else
xe_gt_err(gt, "unexpected response %u for FAST_REQ H2G fence 0x%x!\n",
type, fence);
+ CT_DEAD(ct, NULL, PARSE_G2H_RESPONSE);
return -EPROTO;
}
@@ -1019,8 +1146,9 @@ static int parse_g2h_response(struct xe_guc_ct *ct, u32 *msg, u32 len)
if (unlikely(!g2h_fence)) {
/* Don't tear down channel, as send could've timed out */
xe_gt_warn(gt, "G2H fence (%u) not found!\n", fence);
+ CT_DEAD(ct, NULL, PARSE_G2H_UNKNOWN);
g2h_release_space(ct, GUC_CTB_HXG_MSG_MAX_LEN);
- return 0;
+ return -EPROTO;
}
xe_gt_assert(gt, fence == g2h_fence->seqno);
@@ -1062,7 +1190,7 @@ static int parse_g2h_msg(struct xe_guc_ct *ct, u32 *msg, u32 len)
if (unlikely(origin != GUC_HXG_ORIGIN_GUC)) {
xe_gt_err(gt, "G2H channel broken on read, origin=%u, reset required\n",
origin);
- ct->ctbs.g2h.info.broken = true;
+ CT_DEAD(ct, &ct->ctbs.g2h, PARSE_G2H_ORIGIN);
return -EPROTO;
}
@@ -1080,7 +1208,7 @@ static int parse_g2h_msg(struct xe_guc_ct *ct, u32 *msg, u32 len)
default:
xe_gt_err(gt, "G2H channel broken on read, type=%u, reset required\n",
type);
- ct->ctbs.g2h.info.broken = true;
+ CT_DEAD(ct, &ct->ctbs.g2h, PARSE_G2H_TYPE);
ret = -EOPNOTSUPP;
}
@@ -1157,9 +1285,11 @@ static int process_g2h_msg(struct xe_guc_ct *ct, u32 *msg, u32 len)
xe_gt_err(gt, "unexpected G2H action 0x%04x\n", action);
}
- if (ret)
+ if (ret) {
xe_gt_err(gt, "G2H action 0x%04x failed (%pe)\n",
action, ERR_PTR(ret));
+ CT_DEAD(ct, NULL, PROCESS_FAILED);
+ }
return 0;
}
@@ -1169,7 +1299,7 @@ static int g2h_read(struct xe_guc_ct *ct, u32 *msg, bool fast_path)
struct xe_device *xe = ct_to_xe(ct);
struct xe_gt *gt = ct_to_gt(ct);
struct guc_ctb *g2h = &ct->ctbs.g2h;
- u32 tail, head, len;
+ u32 tail, head, len, desc_status;
s32 avail;
u32 action;
u32 *hxg;
@@ -1188,6 +1318,50 @@ static int g2h_read(struct xe_guc_ct *ct, u32 *msg, bool fast_path)
xe_gt_assert(gt, xe_guc_ct_enabled(ct));
+ desc_status = desc_read(xe, g2h, status);
+ if (desc_status) {
+ if (desc_status & GUC_CTB_STATUS_DISABLED) {
+ /*
+ * Potentially valid if a CLIENT_RESET request resulted in
+ * contexts/engines being reset. But should never happen as
+ * no contexts should be active when CLIENT_RESET is sent.
+ */
+ xe_gt_err(gt, "CT read: unexpected G2H after GuC has stopped!\n");
+ desc_status &= ~GUC_CTB_STATUS_DISABLED;
+ }
+
+ if (desc_status) {
+ xe_gt_err(gt, "CT read: non-zero status: %u\n", desc_status);
+ goto corrupted;
+ }
+ }
+
+ if (IS_ENABLED(CONFIG_DRM_XE_DEBUG)) {
+ u32 desc_tail = desc_read(xe, g2h, tail);
+ u32 desc_head = desc_read(xe, g2h, head);
+
+ if (g2h->info.head != desc_head) {
+ desc_write(xe, g2h, status, desc_status | GUC_CTB_STATUS_MISMATCH);
+ xe_gt_err(gt, "CT read: head was modified %u != %u\n",
+ desc_head, g2h->info.head);
+ goto corrupted;
+ }
+
+ if (g2h->info.head > g2h->info.size) {
+ desc_write(xe, g2h, status, desc_status | GUC_CTB_STATUS_OVERFLOW);
+ xe_gt_err(gt, "CT read: head out of range: %u vs %u\n",
+ g2h->info.head, g2h->info.size);
+ goto corrupted;
+ }
+
+ if (desc_tail >= g2h->info.size) {
+ desc_write(xe, g2h, status, desc_status | GUC_CTB_STATUS_OVERFLOW);
+ xe_gt_err(gt, "CT read: invalid tail offset %u >= %u)\n",
+ desc_tail, g2h->info.size);
+ goto corrupted;
+ }
+ }
+
/* Calculate DW available to read */
tail = desc_read(xe, g2h, tail);
avail = tail - g2h->info.head;
@@ -1204,9 +1378,7 @@ static int g2h_read(struct xe_guc_ct *ct, u32 *msg, bool fast_path)
if (len > avail) {
xe_gt_err(gt, "G2H channel broken on read, avail=%d, len=%d, reset required\n",
avail, len);
- g2h->info.broken = true;
-
- return -EPROTO;
+ goto corrupted;
}
head = (g2h->info.head + 1) % g2h->info.size;
@@ -1252,6 +1424,10 @@ static int g2h_read(struct xe_guc_ct *ct, u32 *msg, bool fast_path)
action, len, g2h->info.head, tail);
return len;
+
+corrupted:
+ CT_DEAD(ct, &ct->ctbs.g2h, G2H_READ);
+ return -EPROTO;
}
static void g2h_fast_path(struct xe_guc_ct *ct, u32 *msg, u32 len)
@@ -1278,9 +1454,11 @@ static void g2h_fast_path(struct xe_guc_ct *ct, u32 *msg, u32 len)
xe_gt_warn(gt, "NOT_POSSIBLE");
}
- if (ret)
+ if (ret) {
xe_gt_err(gt, "G2H action 0x%04x failed (%pe)\n",
action, ERR_PTR(ret));
+ CT_DEAD(ct, NULL, FAST_G2H);
+ }
}
/**
@@ -1340,7 +1518,6 @@ static int dequeue_one_g2h(struct xe_guc_ct *ct)
static void receive_g2h(struct xe_guc_ct *ct)
{
- struct xe_gt *gt = ct_to_gt(ct);
bool ongoing;
int ret;
@@ -1377,9 +1554,8 @@ static void receive_g2h(struct xe_guc_ct *ct)
mutex_unlock(&ct->lock);
if (unlikely(ret == -EPROTO || ret == -EOPNOTSUPP)) {
- struct drm_printer p = xe_gt_info_printer(gt);
-
- xe_guc_ct_print(ct, &p, false);
+ xe_gt_err(ct_to_gt(ct), "CT dequeue failed: %d", ret);
+ CT_DEAD(ct, NULL, G2H_RECV);
kick_reset(ct);
}
} while (ret == 1);
@@ -1409,7 +1585,7 @@ static void guc_ctb_snapshot_capture(struct xe_device *xe, struct guc_ctb *ctb,
atomic ? GFP_ATOMIC : GFP_KERNEL);
if (!snapshot->cmds) {
- drm_err(&xe->drm, "Skipping CTB commands snapshot. Only CTB info will be available.\n");
+ drm_err(&xe->drm, "Skipping CTB commands snapshot. Only CT info will be available.\n");
return;
}
@@ -1554,16 +1730,68 @@ void xe_guc_ct_snapshot_free(struct xe_guc_ct_snapshot *snapshot)
* xe_guc_ct_print - GuC CT Print.
* @ct: GuC CT.
* @p: drm_printer where it will be printed out.
- * @atomic: Boolean to indicate if this is called from atomic context like
- * reset or CTB handler or from some regular path like debugfs.
*
* This function quickly capture a snapshot and immediately print it out.
*/
-void xe_guc_ct_print(struct xe_guc_ct *ct, struct drm_printer *p, bool atomic)
+void xe_guc_ct_print(struct xe_guc_ct *ct, struct drm_printer *p)
{
struct xe_guc_ct_snapshot *snapshot;
- snapshot = xe_guc_ct_snapshot_capture(ct, atomic);
+ snapshot = xe_guc_ct_snapshot_capture(ct, false);
xe_guc_ct_snapshot_print(snapshot, p);
xe_guc_ct_snapshot_free(snapshot);
}
+
+#if IS_ENABLED(CONFIG_DRM_XE_DEBUG)
+static void ct_dead_print(struct xe_dead_ct *dead)
+{
+ struct xe_guc_ct *ct = container_of(dead, struct xe_guc_ct, dead);
+ struct xe_device *xe = ct_to_xe(ct);
+ struct xe_gt *gt = ct_to_gt(ct);
+ static int g_count;
+ struct drm_printer ip = xe_gt_info_printer(gt);
+ struct drm_printer lp = drm_line_printer(&ip, "Capture", ++g_count);
+
+ if (!dead->reason) {
+ xe_gt_err(gt, "CTB is dead for no reason!?\n");
+ return;
+ }
+
+ drm_printf(&lp, "CTB is dead - reason=0x%X\n", dead->reason);
+
+ /* Can't generate a genuine core dump at this point, so just do the good bits */
+ drm_printf(&lp, "**** Xe Device Coredump ****\n");
+ xe_device_snapshot_print(xe, &lp);
+ drm_printf(&lp, "**** GuC Log ****\n");
+ xe_guc_log_snapshot_print(dead->snapshot_log, &lp);
+ drm_printf(&lp, "**** GuC CT ****\n");
+ xe_guc_ct_snapshot_print(dead->snapshot_ct, &lp);
+
+ drm_printf(&lp, "Done.\n");
+}
+
+static void ct_dead_worker_func(struct work_struct *w)
+{
+ struct xe_guc_ct *ct = container_of(w, struct xe_guc_ct, dead.worker);
+
+ if (!ct->dead.reported) {
+ ct->dead.reported = true;
+ ct_dead_print(&ct->dead);
+ }
+
+ spin_lock_irq(&ct->dead.lock);
+
+ xe_guc_log_snapshot_free(ct->dead.snapshot_log);
+ ct->dead.snapshot_log = NULL;
+ xe_guc_ct_snapshot_free(ct->dead.snapshot_ct);
+ ct->dead.snapshot_ct = NULL;
+
+ if (ct->dead.reason & CT_DEAD_REARM) {
+ /* A reset has occurred so re-arm the error reporting */
+ ct->dead.reason = 0;
+ ct->dead.reported = false;
+ }
+
+ spin_unlock_irq(&ct->dead.lock);
+}
+#endif
diff --git a/drivers/gpu/drm/xe/xe_guc_ct.h b/drivers/gpu/drm/xe/xe_guc_ct.h
index 190202fce2d0..293041bed7ed 100644
--- a/drivers/gpu/drm/xe/xe_guc_ct.h
+++ b/drivers/gpu/drm/xe/xe_guc_ct.h
@@ -21,7 +21,7 @@ xe_guc_ct_snapshot_capture(struct xe_guc_ct *ct, bool atomic);
void xe_guc_ct_snapshot_print(struct xe_guc_ct_snapshot *snapshot,
struct drm_printer *p);
void xe_guc_ct_snapshot_free(struct xe_guc_ct_snapshot *snapshot);
-void xe_guc_ct_print(struct xe_guc_ct *ct, struct drm_printer *p, bool atomic);
+void xe_guc_ct_print(struct xe_guc_ct *ct, struct drm_printer *p);
static inline bool xe_guc_ct_enabled(struct xe_guc_ct *ct)
{
diff --git a/drivers/gpu/drm/xe/xe_guc_ct_types.h b/drivers/gpu/drm/xe/xe_guc_ct_types.h
index 761cb9031298..85e127ec91d7 100644
--- a/drivers/gpu/drm/xe/xe_guc_ct_types.h
+++ b/drivers/gpu/drm/xe/xe_guc_ct_types.h
@@ -86,6 +86,24 @@ enum xe_guc_ct_state {
XE_GUC_CT_STATE_ENABLED,
};
+#if IS_ENABLED(CONFIG_DRM_XE_DEBUG)
+/** struct xe_dead_ct - Information for debugging a dead CT */
+struct xe_dead_ct {
+ /** @lock: protects memory allocation/free operations, and @reason updates */
+ spinlock_t lock;
+ /** @reason: bit mask of CT_DEAD_* reason codes */
+ unsigned int reason;
+ /** @reported: for preventing multiple dumps per error sequence */
+ bool reported;
+ /** @worker: worker thread to get out of interrupt context before dumping */
+ struct work_struct worker;
+ /** snapshot_ct: copy of CT state and CTB content at point of error */
+ struct xe_guc_ct_snapshot *snapshot_ct;
+ /** snapshot_log: copy of GuC log at point of error */
+ struct xe_guc_log_snapshot *snapshot_log;
+};
+#endif
+
/**
* struct xe_guc_ct - GuC command transport (CT) layer
*
@@ -128,6 +146,11 @@ struct xe_guc_ct {
u32 msg[GUC_CTB_MSG_MAX_LEN];
/** @fast_msg: Message buffer */
u32 fast_msg[GUC_CTB_MSG_MAX_LEN];
+
+#if IS_ENABLED(CONFIG_DRM_XE_DEBUG)
+ /** @dead: information for debugging dead CTs */
+ struct xe_dead_ct dead;
+#endif
};
#endif
--
2.46.0
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v7 08/10] drm/xe/guc: Dump entire CTB on errors
2024-09-05 20:50 [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump John.C.Harrison
` (6 preceding siblings ...)
2024-09-05 20:51 ` [PATCH v7 07/10] drm/xe/guc: Dead CT helper John.C.Harrison
@ 2024-09-05 20:51 ` John.C.Harrison
2024-09-11 20:12 ` Julia Filipchuk
2024-09-05 20:51 ` [PATCH v7 09/10] drm/xe/guc: Add GuC log to devcoredump captures John.C.Harrison
` (10 subsequent siblings)
18 siblings, 1 reply; 54+ messages in thread
From: John.C.Harrison @ 2024-09-05 20:51 UTC (permalink / raw)
To: Intel-Xe; +Cc: John Harrison
From: John Harrison <John.C.Harrison@Intel.com>
The dump of the CT buffers was only showing the unprocessed data which
is not generally useful for saying why a hang occurred - because it
was probably caused by the commands that were just processed. So save
and dump the entire buffer but in a more compact dump format. Also
zero fill it on allocation to avoid confusion over uninitialised data
in the dump.
v2: Add kerneldoc - review feedback from Michal W.
v3: Fix kerneldoc.
v4: Use ascii85 instead of hexdump (review feedback from Matthew B).
v5: Dump the entire CTB object rather than seperately dumping just the
H2G and G2H sections. That way it includes the full header info.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
---
drivers/gpu/drm/xe/xe_guc_ct.c | 95 ++++++++++------------------
drivers/gpu/drm/xe/xe_guc_ct.h | 8 +--
drivers/gpu/drm/xe/xe_guc_ct_types.h | 6 +-
3 files changed, 41 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c
index e31b1f0b855f..6dd93dcbf1fc 100644
--- a/drivers/gpu/drm/xe/xe_guc_ct.c
+++ b/drivers/gpu/drm/xe/xe_guc_ct.c
@@ -17,6 +17,7 @@
#include "abi/guc_actions_sriov_abi.h"
#include "abi/guc_klvs_abi.h"
#include "xe_bo.h"
+#include "xe_devcoredump.h"
#include "xe_device.h"
#include "xe_gt.h"
#include "xe_gt_pagefault.h"
@@ -444,6 +445,7 @@ int xe_guc_ct_enable(struct xe_guc_ct *ct)
xe_gt_assert(gt, !xe_guc_ct_enabled(ct));
+ xe_map_memset(xe, &ct->bo->vmap, 0, 0, ct->bo->size);
guc_ct_ctb_h2g_init(xe, &ct->ctbs.h2g, &ct->bo->vmap);
guc_ct_ctb_g2h_init(xe, &ct->ctbs.g2h, &ct->bo->vmap);
@@ -1571,49 +1573,33 @@ static void g2h_worker_func(struct work_struct *w)
receive_g2h(ct);
}
-static void guc_ctb_snapshot_capture(struct xe_device *xe, struct guc_ctb *ctb,
- struct guc_ctb_snapshot *snapshot,
- bool atomic)
+struct xe_guc_ct_snapshot *xe_guc_ct_snapshot_alloc(struct xe_guc_ct *ct, bool atomic)
{
- u32 head, tail;
-
- xe_map_memcpy_from(xe, &snapshot->desc, &ctb->desc, 0,
- sizeof(struct guc_ct_buffer_desc));
- memcpy(&snapshot->info, &ctb->info, sizeof(struct guc_ctb_info));
+ struct xe_guc_ct_snapshot *snapshot;
- snapshot->cmds = kmalloc_array(ctb->info.size, sizeof(u32),
- atomic ? GFP_ATOMIC : GFP_KERNEL);
+ snapshot = kzalloc(sizeof(*snapshot), atomic ? GFP_ATOMIC : GFP_KERNEL);
+ if (!snapshot)
+ return NULL;
- if (!snapshot->cmds) {
- drm_err(&xe->drm, "Skipping CTB commands snapshot. Only CT info will be available.\n");
- return;
+ if (ct->bo) {
+ snapshot->ctb_size = ct->bo->size;
+ snapshot->ctb = kmalloc(snapshot->ctb_size, atomic ? GFP_ATOMIC : GFP_KERNEL);
}
- head = snapshot->desc.head;
- tail = snapshot->desc.tail;
-
- if (head != tail) {
- struct iosys_map map =
- IOSYS_MAP_INIT_OFFSET(&ctb->cmds, head * sizeof(u32));
-
- while (head != tail) {
- snapshot->cmds[head] = xe_map_rd(xe, &map, 0, u32);
- ++head;
- if (head == ctb->info.size) {
- head = 0;
- map = ctb->cmds;
- } else {
- iosys_map_incr(&map, sizeof(u32));
- }
- }
- }
+ return snapshot;
+}
+
+static void guc_ctb_snapshot_capture(struct xe_device *xe, struct guc_ctb *ctb,
+ struct guc_ctb_snapshot *snapshot)
+{
+ xe_map_memcpy_from(xe, &snapshot->desc, &ctb->desc, 0,
+ sizeof(struct guc_ct_buffer_desc));
+ memcpy(&snapshot->info, &ctb->info, sizeof(struct guc_ctb_info));
}
static void guc_ctb_snapshot_print(struct guc_ctb_snapshot *snapshot,
struct drm_printer *p)
{
- u32 head, tail;
-
drm_printf(p, "\tsize: %d\n", snapshot->info.size);
drm_printf(p, "\tresv_space: %d\n", snapshot->info.resv_space);
drm_printf(p, "\thead: %d\n", snapshot->info.head);
@@ -1623,25 +1609,6 @@ static void guc_ctb_snapshot_print(struct guc_ctb_snapshot *snapshot,
drm_printf(p, "\thead (memory): %d\n", snapshot->desc.head);
drm_printf(p, "\ttail (memory): %d\n", snapshot->desc.tail);
drm_printf(p, "\tstatus (memory): 0x%x\n", snapshot->desc.status);
-
- if (!snapshot->cmds)
- return;
-
- head = snapshot->desc.head;
- tail = snapshot->desc.tail;
-
- while (head != tail) {
- drm_printf(p, "\tcmd[%d]: 0x%08x\n", head,
- snapshot->cmds[head]);
- ++head;
- if (head == snapshot->info.size)
- head = 0;
- }
-}
-
-static void guc_ctb_snapshot_free(struct guc_ctb_snapshot *snapshot)
-{
- kfree(snapshot->cmds);
}
/**
@@ -1662,9 +1629,7 @@ struct xe_guc_ct_snapshot *xe_guc_ct_snapshot_capture(struct xe_guc_ct *ct,
struct xe_device *xe = ct_to_xe(ct);
struct xe_guc_ct_snapshot *snapshot;
- snapshot = kzalloc(sizeof(*snapshot),
- atomic ? GFP_ATOMIC : GFP_KERNEL);
-
+ snapshot = xe_guc_ct_snapshot_alloc(ct, atomic);
if (!snapshot) {
drm_err(&xe->drm, "Skipping CTB snapshot entirely.\n");
return NULL;
@@ -1673,12 +1638,13 @@ struct xe_guc_ct_snapshot *xe_guc_ct_snapshot_capture(struct xe_guc_ct *ct,
if (xe_guc_ct_enabled(ct) || ct->state == XE_GUC_CT_STATE_STOPPED) {
snapshot->ct_enabled = true;
snapshot->g2h_outstanding = READ_ONCE(ct->g2h_outstanding);
- guc_ctb_snapshot_capture(xe, &ct->ctbs.h2g,
- &snapshot->h2g, atomic);
- guc_ctb_snapshot_capture(xe, &ct->ctbs.g2h,
- &snapshot->g2h, atomic);
+ guc_ctb_snapshot_capture(xe, &ct->ctbs.h2g, &snapshot->h2g);
+ guc_ctb_snapshot_capture(xe, &ct->ctbs.g2h, &snapshot->g2h);
}
+ if (ct->bo && snapshot->ctb)
+ xe_map_memcpy_from(xe, snapshot->ctb, &ct->bo->vmap, 0, snapshot->ctb_size);
+
return snapshot;
}
@@ -1701,9 +1667,15 @@ void xe_guc_ct_snapshot_print(struct xe_guc_ct_snapshot *snapshot,
drm_puts(p, "G2H CTB (all sizes in DW):\n");
guc_ctb_snapshot_print(&snapshot->g2h, p);
-
drm_printf(p, "\tg2h outstanding: %d\n",
snapshot->g2h_outstanding);
+
+ if (snapshot->ctb) {
+ xe_print_blob_ascii85(p, "CTB data", snapshot->ctb, 0, snapshot->ctb_size);
+ } else {
+ drm_printf(p, "CTB snapshot missing!\n");
+ return;
+ }
} else {
drm_puts(p, "CT disabled\n");
}
@@ -1721,8 +1693,7 @@ void xe_guc_ct_snapshot_free(struct xe_guc_ct_snapshot *snapshot)
if (!snapshot)
return;
- guc_ctb_snapshot_free(&snapshot->h2g);
- guc_ctb_snapshot_free(&snapshot->g2h);
+ kfree(snapshot->ctb);
kfree(snapshot);
}
diff --git a/drivers/gpu/drm/xe/xe_guc_ct.h b/drivers/gpu/drm/xe/xe_guc_ct.h
index 293041bed7ed..338f0b75d29f 100644
--- a/drivers/gpu/drm/xe/xe_guc_ct.h
+++ b/drivers/gpu/drm/xe/xe_guc_ct.h
@@ -9,6 +9,7 @@
#include "xe_guc_ct_types.h"
struct drm_printer;
+struct xe_device;
int xe_guc_ct_init(struct xe_guc_ct *ct);
int xe_guc_ct_enable(struct xe_guc_ct *ct);
@@ -16,10 +17,9 @@ void xe_guc_ct_disable(struct xe_guc_ct *ct);
void xe_guc_ct_stop(struct xe_guc_ct *ct);
void xe_guc_ct_fast_path(struct xe_guc_ct *ct);
-struct xe_guc_ct_snapshot *
-xe_guc_ct_snapshot_capture(struct xe_guc_ct *ct, bool atomic);
-void xe_guc_ct_snapshot_print(struct xe_guc_ct_snapshot *snapshot,
- struct drm_printer *p);
+struct xe_guc_ct_snapshot *xe_guc_ct_snapshot_alloc(struct xe_guc_ct *ct, bool atomic);
+struct xe_guc_ct_snapshot *xe_guc_ct_snapshot_capture(struct xe_guc_ct *ct, bool atomic);
+void xe_guc_ct_snapshot_print(struct xe_guc_ct_snapshot *snapshot, struct drm_printer *p);
void xe_guc_ct_snapshot_free(struct xe_guc_ct_snapshot *snapshot);
void xe_guc_ct_print(struct xe_guc_ct *ct, struct drm_printer *p);
diff --git a/drivers/gpu/drm/xe/xe_guc_ct_types.h b/drivers/gpu/drm/xe/xe_guc_ct_types.h
index 85e127ec91d7..8e1b9d981d61 100644
--- a/drivers/gpu/drm/xe/xe_guc_ct_types.h
+++ b/drivers/gpu/drm/xe/xe_guc_ct_types.h
@@ -52,8 +52,6 @@ struct guc_ctb {
struct guc_ctb_snapshot {
/** @desc: snapshot of the CTB descriptor */
struct guc_ct_buffer_desc desc;
- /** @cmds: snapshot of the CTB commands */
- u32 *cmds;
/** @info: snapshot of the CTB info */
struct guc_ctb_info info;
};
@@ -70,6 +68,10 @@ struct xe_guc_ct_snapshot {
struct guc_ctb_snapshot g2h;
/** @h2g: H2G CTB snapshot */
struct guc_ctb_snapshot h2g;
+ /** @ctb_size: size of the snapshot of the CTB */
+ size_t ctb_size;
+ /** @ctb: snapshot of the entire CTB */
+ u32 *ctb;
};
/**
--
2.46.0
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v7 09/10] drm/xe/guc: Add GuC log to devcoredump captures
2024-09-05 20:50 [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump John.C.Harrison
` (7 preceding siblings ...)
2024-09-05 20:51 ` [PATCH v7 08/10] drm/xe/guc: Dump entire CTB on errors John.C.Harrison
@ 2024-09-05 20:51 ` John.C.Harrison
2024-09-11 20:25 ` Julia Filipchuk
2024-09-05 20:51 ` [PATCH v7 10/10] drm/xe/guc: Add a helper function for dumping GuC log to dmesg John.C.Harrison
` (9 subsequent siblings)
18 siblings, 1 reply; 54+ messages in thread
From: John.C.Harrison @ 2024-09-05 20:51 UTC (permalink / raw)
To: Intel-Xe; +Cc: John Harrison
From: John Harrison <John.C.Harrison@Intel.com>
Include the GuC log in devcoredump captures because they can be useful
with debugging certain types of bug.
v2: Fix kerneldoc
v3: Drop module parameter as now using more compact ascii85 encoding
rather than hexdump (although still not compressed) (review feedback
from Matthew B). Rebase onto recent refactoring of devcoredump code.
v4: Don't move the submission snapshot inside the GuC internals
structure 'cos it really doesn't belong there.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
---
drivers/gpu/drm/xe/xe_devcoredump.c | 16 ++++++++++++----
drivers/gpu/drm/xe/xe_devcoredump_types.h | 10 +++++++---
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_devcoredump.c b/drivers/gpu/drm/xe/xe_devcoredump.c
index 5e2e93ad773c..36663ef76752 100644
--- a/drivers/gpu/drm/xe/xe_devcoredump.c
+++ b/drivers/gpu/drm/xe/xe_devcoredump.c
@@ -18,8 +18,10 @@
#include "xe_gt.h"
#include "xe_gt_printk.h"
#include "xe_guc_ct.h"
+#include "xe_guc_log.h"
#include "xe_guc_submit.h"
#include "xe_hw_engine.h"
+#include "xe_module.h"
#include "xe_sched_job.h"
#include "xe_vm.h"
@@ -97,8 +99,10 @@ static ssize_t __xe_devcoredump_read(char *buffer, size_t count,
drm_printf(&p, "Process: %s\n", ss->process_name);
xe_device_snapshot_print(xe, &p);
+ drm_printf(&p, "\n**** GuC Log ****\n");
+ xe_guc_log_snapshot_print(coredump->snapshot.guc.log, &p);
drm_printf(&p, "\n**** GuC CT ****\n");
- xe_guc_ct_snapshot_print(coredump->snapshot.ct, &p);
+ xe_guc_ct_snapshot_print(coredump->snapshot.guc.ct, &p);
drm_printf(&p, "\n**** Contexts ****\n");
xe_guc_exec_queue_snapshot_print(coredump->snapshot.ge, &p);
@@ -121,8 +125,11 @@ static void xe_devcoredump_snapshot_free(struct xe_devcoredump_snapshot *ss)
{
int i;
- xe_guc_ct_snapshot_free(ss->ct);
- ss->ct = NULL;
+ xe_guc_log_snapshot_free(ss->guc.log);
+ ss->guc.log = NULL;
+
+ xe_guc_ct_snapshot_free(ss->guc.ct);
+ ss->guc.ct = NULL;
xe_guc_exec_queue_snapshot_free(ss->ge);
ss->ge = NULL;
@@ -250,7 +257,8 @@ static void devcoredump_snapshot(struct xe_devcoredump *coredump,
if (xe_force_wake_get(gt_to_fw(q->gt), XE_FORCEWAKE_ALL))
xe_gt_info(ss->gt, "failed to get forcewake for coredump capture\n");
- coredump->snapshot.ct = xe_guc_ct_snapshot_capture(&guc->ct, true);
+ coredump->snapshot.guc.log = xe_guc_log_snapshot_capture(&guc->log, true);
+ coredump->snapshot.guc.ct = xe_guc_ct_snapshot_capture(&guc->ct, true);
coredump->snapshot.ge = xe_guc_exec_queue_snapshot_capture(q);
coredump->snapshot.job = xe_sched_job_snapshot_capture(job);
coredump->snapshot.vm = xe_vm_snapshot_capture(q->vm);
diff --git a/drivers/gpu/drm/xe/xe_devcoredump_types.h b/drivers/gpu/drm/xe/xe_devcoredump_types.h
index 3cc2f095fdfb..06ac75ce63dd 100644
--- a/drivers/gpu/drm/xe/xe_devcoredump_types.h
+++ b/drivers/gpu/drm/xe/xe_devcoredump_types.h
@@ -34,9 +34,13 @@ struct xe_devcoredump_snapshot {
/** @work: Workqueue for deferred capture outside of signaling context */
struct work_struct work;
- /* GuC snapshots */
- /** @ct: GuC CT snapshot */
- struct xe_guc_ct_snapshot *ct;
+ /** @guc: GuC snapshots */
+ struct {
+ /** @guc.ct: GuC CT snapshot */
+ struct xe_guc_ct_snapshot *ct;
+ /** @guc.log: GuC log snapshot */
+ struct xe_guc_log_snapshot *log;
+ } guc;
/** @ge: GuC Submission Engine snapshot */
struct xe_guc_submit_exec_queue_snapshot *ge;
--
2.46.0
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v7 10/10] drm/xe/guc: Add a helper function for dumping GuC log to dmesg
2024-09-05 20:50 [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump John.C.Harrison
` (8 preceding siblings ...)
2024-09-05 20:51 ` [PATCH v7 09/10] drm/xe/guc: Add GuC log to devcoredump captures John.C.Harrison
@ 2024-09-05 20:51 ` John.C.Harrison
2024-09-11 20:36 ` Julia Filipchuk
2024-09-05 20:57 ` ✓ CI.Patch_applied: success for drm/xe/guc: Improve GuC log dumping and add to devcoredump (rev2) Patchwork
` (8 subsequent siblings)
18 siblings, 1 reply; 54+ messages in thread
From: John.C.Harrison @ 2024-09-05 20:51 UTC (permalink / raw)
To: Intel-Xe; +Cc: John Harrison
From: John Harrison <John.C.Harrison@Intel.com>
Create a helper function that can be used to dump the GuC log to dmesg
in a manner that is reliable for extraction and decode. The intention
is that calls to this can be added by developers when debugging
specific issues that require a GuC log but do not allow easy capture
of the log - e.g. failures in selftests and failues that lead to
kernel hangs.
Also note that this is really a temporary stop-gap. The aim is to
allow on demand creation and dumping of devcoredump captures (which
includes the GuC log and much more). Currently this is not possible as
much of the devcoredump code requires a 'struct xe_sched_job' and
those are not available at many places that might want to do the dump.
v2: Add kerneldoc - review feedback from Michal W.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
---
drivers/gpu/drm/xe/xe_guc_log.c | 18 ++++++++++++++++++
drivers/gpu/drm/xe/xe_guc_log.h | 1 +
2 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/xe/xe_guc_log.c b/drivers/gpu/drm/xe/xe_guc_log.c
index 0777ffbd14d5..84b8b258c7eb 100644
--- a/drivers/gpu/drm/xe/xe_guc_log.c
+++ b/drivers/gpu/drm/xe/xe_guc_log.c
@@ -214,6 +214,24 @@ void xe_guc_log_snapshot_print(struct xe_guc_log_snapshot *snapshot, struct drm_
}
}
+/**
+ * xe_guc_log_print_dmesg - dump a copy of the GuC log to dmesg
+ * @log: GuC log structure
+ */
+void xe_guc_log_print_dmesg(struct xe_guc_log *log)
+{
+ struct xe_gt *gt = log_to_gt(log);
+ static int g_count;
+ struct drm_printer ip = xe_gt_info_printer(gt);
+ struct drm_printer lp = drm_line_printer(&ip, "Capture", ++g_count);
+
+ drm_printf(&lp, "Dumping GuC log for %ps...\n", __builtin_return_address(0));
+
+ xe_guc_log_print(log, &lp);
+
+ drm_printf(&lp, "Done.\n");
+}
+
/**
* xe_guc_log_print - dump a copy of the GuC log to some useful location
* @log: GuC log structure
diff --git a/drivers/gpu/drm/xe/xe_guc_log.h b/drivers/gpu/drm/xe/xe_guc_log.h
index 949d2c98343d..1fb2fae1f4e1 100644
--- a/drivers/gpu/drm/xe/xe_guc_log.h
+++ b/drivers/gpu/drm/xe/xe_guc_log.h
@@ -39,6 +39,7 @@ struct xe_device;
int xe_guc_log_init(struct xe_guc_log *log);
void xe_guc_log_print(struct xe_guc_log *log, struct drm_printer *p);
+void xe_guc_log_print_dmesg(struct xe_guc_log *log);
struct xe_guc_log_snapshot *xe_guc_log_snapshot_capture(struct xe_guc_log *log, bool atomic);
void xe_guc_log_snapshot_print(struct xe_guc_log_snapshot *snapshot, struct drm_printer *p);
void xe_guc_log_snapshot_free(struct xe_guc_log_snapshot *snapshot);
--
2.46.0
^ permalink raw reply related [flat|nested] 54+ messages in thread
* ✓ CI.Patch_applied: success for drm/xe/guc: Improve GuC log dumping and add to devcoredump (rev2)
2024-09-05 20:50 [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump John.C.Harrison
` (9 preceding siblings ...)
2024-09-05 20:51 ` [PATCH v7 10/10] drm/xe/guc: Add a helper function for dumping GuC log to dmesg John.C.Harrison
@ 2024-09-05 20:57 ` Patchwork
2024-09-05 20:57 ` ✗ CI.checkpatch: warning " Patchwork
` (7 subsequent siblings)
18 siblings, 0 replies; 54+ messages in thread
From: Patchwork @ 2024-09-05 20:57 UTC (permalink / raw)
To: john.c.harrison; +Cc: intel-xe
== Series Details ==
Series: drm/xe/guc: Improve GuC log dumping and add to devcoredump (rev2)
URL : https://patchwork.freedesktop.org/series/137985/
State : success
== Summary ==
=== Applying kernel patches on branch 'drm-tip' with base: ===
Base commit: 7f3ffaf88a3a drm-tip: 2024y-09m-05d-19h-44m-52s UTC integration manifest
=== git am output follows ===
Applying: drm/xe/guc: Remove spurious line feed in debug print
Applying: drm/xe/devcoredump: Add a section heading for the submission backend
Applying: drm/xe/devcoredump: Add ASCII85 dump helper function
Applying: drm/xe/guc: Copy GuC log prior to dumping
Applying: drm/xe/guc: Use a two stage dump for GuC logs and add more info
Applying: drm/print: Introduce drm_line_printer
Applying: drm/xe/guc: Dead CT helper
Applying: drm/xe/guc: Dump entire CTB on errors
Applying: drm/xe/guc: Add GuC log to devcoredump captures
Applying: drm/xe/guc: Add a helper function for dumping GuC log to dmesg
^ permalink raw reply [flat|nested] 54+ messages in thread
* ✗ CI.checkpatch: warning for drm/xe/guc: Improve GuC log dumping and add to devcoredump (rev2)
2024-09-05 20:50 [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump John.C.Harrison
` (10 preceding siblings ...)
2024-09-05 20:57 ` ✓ CI.Patch_applied: success for drm/xe/guc: Improve GuC log dumping and add to devcoredump (rev2) Patchwork
@ 2024-09-05 20:57 ` Patchwork
2024-09-05 20:58 ` ✓ CI.KUnit: success " Patchwork
` (6 subsequent siblings)
18 siblings, 0 replies; 54+ messages in thread
From: Patchwork @ 2024-09-05 20:57 UTC (permalink / raw)
To: john.c.harrison; +Cc: intel-xe
== Series Details ==
Series: drm/xe/guc: Improve GuC log dumping and add to devcoredump (rev2)
URL : https://patchwork.freedesktop.org/series/137985/
State : warning
== Summary ==
+ KERNEL=/kernel
+ git clone https://gitlab.freedesktop.org/drm/maintainer-tools mt
Cloning into 'mt'...
warning: redirecting to https://gitlab.freedesktop.org/drm/maintainer-tools.git/
+ git -C mt rev-list -n1 origin/master
c62d7e164862503a3662a095da1c6c9014248cb2
+ cd /kernel
+ git config --global --add safe.directory /kernel
+ git log -n1
commit 394a22c1f649be5bf07d58b630aa3e36c084f3c8
Author: John Harrison <John.C.Harrison@Intel.com>
Date: Thu Sep 5 13:51:05 2024 -0700
drm/xe/guc: Add a helper function for dumping GuC log to dmesg
Create a helper function that can be used to dump the GuC log to dmesg
in a manner that is reliable for extraction and decode. The intention
is that calls to this can be added by developers when debugging
specific issues that require a GuC log but do not allow easy capture
of the log - e.g. failures in selftests and failues that lead to
kernel hangs.
Also note that this is really a temporary stop-gap. The aim is to
allow on demand creation and dumping of devcoredump captures (which
includes the GuC log and much more). Currently this is not possible as
much of the devcoredump code requires a 'struct xe_sched_job' and
those are not available at many places that might want to do the dump.
v2: Add kerneldoc - review feedback from Michal W.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
+ /mt/dim checkpatch 7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d drm-intel
c1b6085dae2e drm/xe/guc: Remove spurious line feed in debug print
93c2469fde94 drm/xe/devcoredump: Add a section heading for the submission backend
41e9a65650a5 drm/xe/devcoredump: Add ASCII85 dump helper function
0319f8f8d6b9 drm/xe/guc: Copy GuC log prior to dumping
9923ff30ac15 drm/xe/guc: Use a two stage dump for GuC logs and add more info
8cdf5b5e9e12 drm/print: Introduce drm_line_printer
7332d3d58548 drm/xe/guc: Dead CT helper
-:87: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'ct' - possible side-effects?
#87: FILE: drivers/gpu/drm/xe/xe_guc_ct.c:55:
+#define CT_DEAD(ct, ctb, reason_code) \
+ do { \
+ struct guc_ctb *_ctb = (ctb); \
+ if (_ctb) \
+ _ctb->info.broken = true; \
+ if (!(ct)->dead.reported) { \
+ struct xe_guc *guc = ct_to_guc(ct); \
+ spin_lock_irq(&ct->dead.lock); \
+ (ct)->dead.reason |= 1 << CT_DEAD_##reason_code; \
+ (ct)->dead.snapshot_log = xe_guc_log_snapshot_capture(&guc->log, true); \
+ (ct)->dead.snapshot_ct = xe_guc_ct_snapshot_capture((ct), true); \
+ spin_unlock_irq(&ct->dead.lock); \
+ queue_work(system_unbound_wq, &(ct)->dead.worker); \
+ } \
+ } while (0)
-:103: WARNING:MACRO_ARG_UNUSED: Argument 'ct' is not used in function-like macro
#103: FILE: drivers/gpu/drm/xe/xe_guc_ct.c:71:
+#define CT_DEAD(ct, ctb, reason) \
+ do { \
+ struct guc_ctb *_ctb = (ctb); \
+ if (_ctb) \
+ _ctb->info.broken = true; \
+ } while (0)
-:103: WARNING:MACRO_ARG_UNUSED: Argument 'reason' is not used in function-like macro
#103: FILE: drivers/gpu/drm/xe/xe_guc_ct.c:71:
+#define CT_DEAD(ct, ctb, reason) \
+ do { \
+ struct guc_ctb *_ctb = (ctb); \
+ if (_ctb) \
+ _ctb->info.broken = true; \
+ } while (0)
total: 0 errors, 2 warnings, 1 checks, 510 lines checked
7358f7258afc drm/xe/guc: Dump entire CTB on errors
-:16: WARNING:TYPO_SPELLING: 'seperately' may be misspelled - perhaps 'separately'?
#16:
v5: Dump the entire CTB object rather than seperately dumping just the
^^^^^^^^^^
total: 0 errors, 1 warnings, 0 checks, 195 lines checked
f67041bdc3d0 drm/xe/guc: Add GuC log to devcoredump captures
394a22c1f649 drm/xe/guc: Add a helper function for dumping GuC log to dmesg
^ permalink raw reply [flat|nested] 54+ messages in thread
* ✓ CI.KUnit: success for drm/xe/guc: Improve GuC log dumping and add to devcoredump (rev2)
2024-09-05 20:50 [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump John.C.Harrison
` (11 preceding siblings ...)
2024-09-05 20:57 ` ✗ CI.checkpatch: warning " Patchwork
@ 2024-09-05 20:58 ` Patchwork
2024-09-05 21:10 ` ✓ CI.Build: " Patchwork
` (5 subsequent siblings)
18 siblings, 0 replies; 54+ messages in thread
From: Patchwork @ 2024-09-05 20:58 UTC (permalink / raw)
To: john.c.harrison; +Cc: intel-xe
== Series Details ==
Series: drm/xe/guc: Improve GuC log dumping and add to devcoredump (rev2)
URL : https://patchwork.freedesktop.org/series/137985/
State : success
== Summary ==
+ trap cleanup EXIT
+ /kernel/tools/testing/kunit/kunit.py run --kunitconfig /kernel/drivers/gpu/drm/xe/.kunitconfig
[20:57:34] Configuring KUnit Kernel ...
Generating .config ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
[20:57:38] Building KUnit Kernel ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
Building with:
$ make ARCH=um O=.kunit --jobs=48
../lib/iomap.c:156:5: warning: no previous prototype for ‘ioread64_lo_hi’ [-Wmissing-prototypes]
156 | u64 ioread64_lo_hi(const void __iomem *addr)
| ^~~~~~~~~~~~~~
../lib/iomap.c:163:5: warning: no previous prototype for ‘ioread64_hi_lo’ [-Wmissing-prototypes]
163 | u64 ioread64_hi_lo(const void __iomem *addr)
| ^~~~~~~~~~~~~~
../lib/iomap.c:170:5: warning: no previous prototype for ‘ioread64be_lo_hi’ [-Wmissing-prototypes]
170 | u64 ioread64be_lo_hi(const void __iomem *addr)
| ^~~~~~~~~~~~~~~~
../lib/iomap.c:178:5: warning: no previous prototype for ‘ioread64be_hi_lo’ [-Wmissing-prototypes]
178 | u64 ioread64be_hi_lo(const void __iomem *addr)
| ^~~~~~~~~~~~~~~~
../lib/iomap.c:264:6: warning: no previous prototype for ‘iowrite64_lo_hi’ [-Wmissing-prototypes]
264 | void iowrite64_lo_hi(u64 val, void __iomem *addr)
| ^~~~~~~~~~~~~~~
../lib/iomap.c:272:6: warning: no previous prototype for ‘iowrite64_hi_lo’ [-Wmissing-prototypes]
272 | void iowrite64_hi_lo(u64 val, void __iomem *addr)
| ^~~~~~~~~~~~~~~
../lib/iomap.c:280:6: warning: no previous prototype for ‘iowrite64be_lo_hi’ [-Wmissing-prototypes]
280 | void iowrite64be_lo_hi(u64 val, void __iomem *addr)
| ^~~~~~~~~~~~~~~~~
../lib/iomap.c:288:6: warning: no previous prototype for ‘iowrite64be_hi_lo’ [-Wmissing-prototypes]
288 | void iowrite64be_hi_lo(u64 val, void __iomem *addr)
| ^~~~~~~~~~~~~~~~~
[20:58:05] Starting KUnit Kernel (1/1)...
[20:58:05] ============================================================
Running tests with:
$ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt
[20:58:05] =================== guc_dbm (7 subtests) ===================
[20:58:05] [PASSED] test_empty
[20:58:05] [PASSED] test_default
[20:58:05] ======================== test_size ========================
[20:58:05] [PASSED] 4
[20:58:05] [PASSED] 8
[20:58:05] [PASSED] 32
[20:58:05] [PASSED] 256
[20:58:05] ==================== [PASSED] test_size ====================
[20:58:05] ======================= test_reuse ========================
[20:58:05] [PASSED] 4
[20:58:05] [PASSED] 8
[20:58:05] [PASSED] 32
[20:58:05] [PASSED] 256
[20:58:05] =================== [PASSED] test_reuse ====================
[20:58:05] =================== test_range_overlap ====================
[20:58:05] [PASSED] 4
[20:58:05] [PASSED] 8
[20:58:05] [PASSED] 32
[20:58:05] [PASSED] 256
[20:58:05] =============== [PASSED] test_range_overlap ================
[20:58:05] =================== test_range_compact ====================
[20:58:05] [PASSED] 4
[20:58:05] [PASSED] 8
[20:58:05] [PASSED] 32
[20:58:05] [PASSED] 256
[20:58:05] =============== [PASSED] test_range_compact ================
[20:58:05] ==================== test_range_spare =====================
[20:58:05] [PASSED] 4
[20:58:05] [PASSED] 8
[20:58:05] [PASSED] 32
[20:58:05] [PASSED] 256
[20:58:05] ================ [PASSED] test_range_spare =================
[20:58:05] ===================== [PASSED] guc_dbm =====================
[20:58:05] =================== guc_idm (6 subtests) ===================
[20:58:05] [PASSED] bad_init
[20:58:05] [PASSED] no_init
[20:58:05] [PASSED] init_fini
[20:58:05] [PASSED] check_used
[20:58:05] [PASSED] check_quota
[20:58:05] [PASSED] check_all
[20:58:05] ===================== [PASSED] guc_idm =====================
[20:58:05] ================== no_relay (3 subtests) ===================
[20:58:05] [PASSED] xe_drops_guc2pf_if_not_ready
[20:58:05] [PASSED] xe_drops_guc2vf_if_not_ready
[20:58:05] [PASSED] xe_rejects_send_if_not_ready
[20:58:05] ==================== [PASSED] no_relay =====================
[20:58:05] ================== pf_relay (14 subtests) ==================
[20:58:05] [PASSED] pf_rejects_guc2pf_too_short
[20:58:05] [PASSED] pf_rejects_guc2pf_too_long
[20:58:05] [PASSED] pf_rejects_guc2pf_no_payload
[20:58:05] [PASSED] pf_fails_no_payload
[20:58:05] [PASSED] pf_fails_bad_origin
[20:58:05] [PASSED] pf_fails_bad_type
[20:58:05] [PASSED] pf_txn_reports_error
[20:58:05] [PASSED] pf_txn_sends_pf2guc
[20:58:05] [PASSED] pf_sends_pf2guc
[20:58:05] [SKIPPED] pf_loopback_nop
[20:58:05] [SKIPPED] pf_loopback_echo
[20:58:05] [SKIPPED] pf_loopback_fail
[20:58:05] [SKIPPED] pf_loopback_busy
[20:58:05] [SKIPPED] pf_loopback_retry
[20:58:05] ==================== [PASSED] pf_relay =====================
[20:58:05] ================== vf_relay (3 subtests) ===================
[20:58:05] [PASSED] vf_rejects_guc2vf_too_short
[20:58:05] [PASSED] vf_rejects_guc2vf_too_long
[20:58:05] [PASSED] vf_rejects_guc2vf_no_payload
[20:58:05] ==================== [PASSED] vf_relay =====================
[20:58:05] ================= pf_service (11 subtests) =================
[20:58:05] [PASSED] pf_negotiate_any
[20:58:05] [PASSED] pf_negotiate_base_match
[20:58:05] [PASSED] pf_negotiate_base_newer
[20:58:05] [PASSED] pf_negotiate_base_next
[20:58:05] [SKIPPED] pf_negotiate_base_older
[20:58:05] [PASSED] pf_negotiate_base_prev
[20:58:05] [PASSED] pf_negotiate_latest_match
[20:58:05] [PASSED] pf_negotiate_latest_newer
[20:58:05] [PASSED] pf_negotiate_latest_next
[20:58:05] [SKIPPED] pf_negotiate_latest_older
[20:58:05] [SKIPPED] pf_negotiate_latest_prev
[20:58:05] =================== [PASSED] pf_service ====================
[20:58:05] ===================== lmtt (1 subtest) =====================
[20:58:05] ======================== test_ops =========================
[20:58:05] [PASSED] 2-level
[20:58:05] [PASSED] multi-level
[20:58:05] ==================== [PASSED] test_ops =====================
[20:58:05] ====================== [PASSED] lmtt =======================
[20:58:05] =================== xe_mocs (2 subtests) ===================
[20:58:05] ================ xe_live_mocs_kernel_kunit ================
[20:58:05] =========== [SKIPPED] xe_live_mocs_kernel_kunit ============
[20:58:05] ================ xe_live_mocs_reset_kunit =================
[20:58:05] ============ [SKIPPED] xe_live_mocs_reset_kunit ============
[20:58:05] ==================== [SKIPPED] xe_mocs =====================
[20:58:05] ================= xe_migrate (2 subtests) ==================
[20:58:05] ================= xe_migrate_sanity_kunit =================
[20:58:05] ============ [SKIPPED] xe_migrate_sanity_kunit =============
[20:58:05] ================== xe_validate_ccs_kunit ==================
[20:58:05] ============= [SKIPPED] xe_validate_ccs_kunit ==============
[20:58:05] =================== [SKIPPED] xe_migrate ===================
[20:58:05] ================== xe_dma_buf (1 subtest) ==================
[20:58:05] ==================== xe_dma_buf_kunit =====================
[20:58:05] ================ [SKIPPED] xe_dma_buf_kunit ================
[20:58:05] =================== [SKIPPED] xe_dma_buf ===================
[20:58:05] ==================== xe_bo (2 subtests) ====================
[20:58:05] ================== xe_ccs_migrate_kunit ===================
[20:58:05] ============== [SKIPPED] xe_ccs_migrate_kunit ==============
[20:58:05] ==================== xe_bo_evict_kunit ====================
[20:58:05] =============== [SKIPPED] xe_bo_evict_kunit ================
[20:58:05] ===================== [SKIPPED] xe_bo ======================
[20:58:05] ==================== args (11 subtests) ====================
[20:58:05] [PASSED] count_args_test
[20:58:05] [PASSED] call_args_example
[20:58:05] [PASSED] call_args_test
[20:58:05] [PASSED] drop_first_arg_example
[20:58:05] [PASSED] drop_first_arg_test
[20:58:05] [PASSED] first_arg_example
[20:58:05] [PASSED] first_arg_test
[20:58:05] [PASSED] last_arg_example
[20:58:05] [PASSED] last_arg_test
[20:58:05] [PASSED] pick_arg_example
[20:58:05] [PASSED] sep_comma_example
[20:58:05] ====================== [PASSED] args =======================
[20:58:05] =================== xe_pci (2 subtests) ====================
stty: 'standard input': Inappropriate ioctl for device
[20:58:05] [PASSED] xe_gmdid_graphics_ip
[20:58:05] [PASSED] xe_gmdid_media_ip
[20:58:05] ===================== [PASSED] xe_pci ======================
[20:58:05] =================== xe_rtp (2 subtests) ====================
[20:58:05] =============== xe_rtp_process_to_sr_tests ================
[20:58:05] [PASSED] coalesce-same-reg
[20:58:05] [PASSED] no-match-no-add
[20:58:05] [PASSED] match-or
[20:58:05] [PASSED] match-or-xfail
[20:58:05] [PASSED] no-match-no-add-multiple-rules
[20:58:05] [PASSED] two-regs-two-entries
[20:58:05] [PASSED] clr-one-set-other
[20:58:05] [PASSED] set-field
[20:58:05] [PASSED] conflict-duplicate
[20:58:05] [PASSED] conflict-not-disjoint
[20:58:05] [PASSED] conflict-reg-type
[20:58:05] =========== [PASSED] xe_rtp_process_to_sr_tests ============
[20:58:05] ================== xe_rtp_process_tests ===================
[20:58:05] [PASSED] active1
[20:58:05] [PASSED] active2
[20:58:05] [PASSED] active-inactive
[20:58:05] [PASSED] inactive-active
[20:58:05] [PASSED] inactive-1st_or_active-inactive
[20:58:05] [PASSED] inactive-2nd_or_active-inactive
[20:58:05] [PASSED] inactive-last_or_active-inactive
[20:58:05] [PASSED] inactive-no_or_active-inactive
[20:58:05] ============== [PASSED] xe_rtp_process_tests ===============
[20:58:05] ===================== [PASSED] xe_rtp ======================
[20:58:05] ==================== xe_wa (1 subtest) =====================
[20:58:05] ======================== xe_wa_gt =========================
[20:58:05] [PASSED] TIGERLAKE (B0)
[20:58:05] [PASSED] DG1 (A0)
[20:58:05] [PASSED] DG1 (B0)
[20:58:05] [PASSED] ALDERLAKE_S (A0)
[20:58:05] [PASSED] ALDERLAKE_S (B0)
[20:58:05] [PASSED] ALDERLAKE_S (C0)
[20:58:05] [PASSED] ALDERLAKE_S (D0)
[20:58:05] [PASSED] ALDERLAKE_P (A0)
[20:58:05] [PASSED] ALDERLAKE_P (B0)
[20:58:05] [PASSED] ALDERLAKE_P (C0)
[20:58:05] [PASSED] ALDERLAKE_S_RPLS (D0)
[20:58:05] [PASSED] ALDERLAKE_P_RPLU (E0)
[20:58:05] [PASSED] DG2_G10 (C0)
[20:58:05] [PASSED] DG2_G11 (B1)
[20:58:05] [PASSED] DG2_G12 (A1)
[20:58:05] [PASSED] METEORLAKE (g:A0, m:A0)
[20:58:05] [PASSED] METEORLAKE (g:A0, m:A0)
[20:58:05] [PASSED] METEORLAKE (g:A0, m:A0)
[20:58:05] [PASSED] LUNARLAKE (g:A0, m:A0)
[20:58:05] [PASSED] LUNARLAKE (g:B0, m:A0)
[20:58:05] [PASSED] BATTLEMAGE (g:A0, m:A1)
[20:58:05] ==================== [PASSED] xe_wa_gt =====================
[20:58:05] ====================== [PASSED] xe_wa ======================
[20:58:05] ============================================================
[20:58:05] Testing complete. Ran 121 tests: passed: 106, skipped: 15
[20:58:05] Elapsed time: 30.670s total, 4.172s configuring, 26.227s building, 0.225s running
+ /kernel/tools/testing/kunit/kunit.py run --kunitconfig /kernel/drivers/gpu/drm/tests/.kunitconfig
[20:58:05] Configuring KUnit Kernel ...
Regenerating .config ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
[20:58:07] Building KUnit Kernel ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
Building with:
$ make ARCH=um O=.kunit --jobs=48
../lib/iomap.c:156:5: warning: no previous prototype for ‘ioread64_lo_hi’ [-Wmissing-prototypes]
156 | u64 ioread64_lo_hi(const void __iomem *addr)
| ^~~~~~~~~~~~~~
../lib/iomap.c:163:5: warning: no previous prototype for ‘ioread64_hi_lo’ [-Wmissing-prototypes]
163 | u64 ioread64_hi_lo(const void __iomem *addr)
| ^~~~~~~~~~~~~~
../lib/iomap.c:170:5: warning: no previous prototype for ‘ioread64be_lo_hi’ [-Wmissing-prototypes]
170 | u64 ioread64be_lo_hi(const void __iomem *addr)
| ^~~~~~~~~~~~~~~~
../lib/iomap.c:178:5: warning: no previous prototype for ‘ioread64be_hi_lo’ [-Wmissing-prototypes]
178 | u64 ioread64be_hi_lo(const void __iomem *addr)
| ^~~~~~~~~~~~~~~~
../lib/iomap.c:264:6: warning: no previous prototype for ‘iowrite64_lo_hi’ [-Wmissing-prototypes]
264 | void iowrite64_lo_hi(u64 val, void __iomem *addr)
| ^~~~~~~~~~~~~~~
../lib/iomap.c:272:6: warning: no previous prototype for ‘iowrite64_hi_lo’ [-Wmissing-prototypes]
272 | void iowrite64_hi_lo(u64 val, void __iomem *addr)
| ^~~~~~~~~~~~~~~
../lib/iomap.c:280:6: warning: no previous prototype for ‘iowrite64be_lo_hi’ [-Wmissing-prototypes]
280 | void iowrite64be_lo_hi(u64 val, void __iomem *addr)
| ^~~~~~~~~~~~~~~~~
../lib/iomap.c:288:6: warning: no previous prototype for ‘iowrite64be_hi_lo’ [-Wmissing-prototypes]
288 | void iowrite64be_hi_lo(u64 val, void __iomem *addr)
| ^~~~~~~~~~~~~~~~~
[20:58:29] Starting KUnit Kernel (1/1)...
[20:58:29] ============================================================
Running tests with:
$ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt
[20:58:29] ============ drm_test_pick_cmdline (2 subtests) ============
[20:58:29] [PASSED] drm_test_pick_cmdline_res_1920_1080_60
[20:58:29] =============== drm_test_pick_cmdline_named ===============
[20:58:29] [PASSED] NTSC
[20:58:29] [PASSED] NTSC-J
[20:58:29] [PASSED] PAL
[20:58:29] [PASSED] PAL-M
[20:58:29] =========== [PASSED] drm_test_pick_cmdline_named ===========
[20:58:29] ============== [PASSED] drm_test_pick_cmdline ==============
[20:58:29] ================== drm_buddy (7 subtests) ==================
[20:58:29] [PASSED] drm_test_buddy_alloc_limit
[20:58:29] [PASSED] drm_test_buddy_alloc_optimistic
[20:58:29] [PASSED] drm_test_buddy_alloc_pessimistic
[20:58:29] [PASSED] drm_test_buddy_alloc_pathological
[20:58:29] [PASSED] drm_test_buddy_alloc_contiguous
[20:58:29] [PASSED] drm_test_buddy_alloc_clear
[20:58:29] [PASSED] drm_test_buddy_alloc_range_bias
[20:58:29] ==================== [PASSED] drm_buddy ====================
[20:58:29] ============= drm_cmdline_parser (40 subtests) =============
[20:58:29] [PASSED] drm_test_cmdline_force_d_only
[20:58:29] [PASSED] drm_test_cmdline_force_D_only_dvi
[20:58:29] [PASSED] drm_test_cmdline_force_D_only_hdmi
[20:58:29] [PASSED] drm_test_cmdline_force_D_only_not_digital
[20:58:29] [PASSED] drm_test_cmdline_force_e_only
[20:58:29] [PASSED] drm_test_cmdline_res
[20:58:29] [PASSED] drm_test_cmdline_res_vesa
[20:58:29] [PASSED] drm_test_cmdline_res_vesa_rblank
[20:58:29] [PASSED] drm_test_cmdline_res_rblank
[20:58:29] [PASSED] drm_test_cmdline_res_bpp
[20:58:29] [PASSED] drm_test_cmdline_res_refresh
[20:58:29] [PASSED] drm_test_cmdline_res_bpp_refresh
[20:58:29] [PASSED] drm_test_cmdline_res_bpp_refresh_interlaced
[20:58:29] [PASSED] drm_test_cmdline_res_bpp_refresh_margins
[20:58:29] [PASSED] drm_test_cmdline_res_bpp_refresh_force_off
[20:58:29] [PASSED] drm_test_cmdline_res_bpp_refresh_force_on
[20:58:29] [PASSED] drm_test_cmdline_res_bpp_refresh_force_on_analog
[20:58:29] [PASSED] drm_test_cmdline_res_bpp_refresh_force_on_digital
[20:58:29] [PASSED] drm_test_cmdline_res_bpp_refresh_interlaced_margins_force_on
[20:58:29] [PASSED] drm_test_cmdline_res_margins_force_on
[20:58:29] [PASSED] drm_test_cmdline_res_vesa_margins
[20:58:29] [PASSED] drm_test_cmdline_name
[20:58:29] [PASSED] drm_test_cmdline_name_bpp
[20:58:29] [PASSED] drm_test_cmdline_name_option
[20:58:29] [PASSED] drm_test_cmdline_name_bpp_option
[20:58:29] [PASSED] drm_test_cmdline_rotate_0
[20:58:29] [PASSED] drm_test_cmdline_rotate_90
[20:58:29] [PASSED] drm_test_cmdline_rotate_180
[20:58:29] [PASSED] drm_test_cmdline_rotate_270
[20:58:29] [PASSED] drm_test_cmdline_hmirror
[20:58:29] [PASSED] drm_test_cmdline_vmirror
[20:58:29] [PASSED] drm_test_cmdline_margin_options
[20:58:29] [PASSED] drm_test_cmdline_multiple_options
[20:58:29] [PASSED] drm_test_cmdline_bpp_extra_and_option
[20:58:29] [PASSED] drm_test_cmdline_extra_and_option
[20:58:29] [PASSED] drm_test_cmdline_freestanding_options
[20:58:29] [PASSED] drm_test_cmdline_freestanding_force_e_and_options
[20:58:29] [PASSED] drm_test_cmdline_panel_orientation
[20:58:29] ================ drm_test_cmdline_invalid =================
[20:58:29] [PASSED] margin_only
[20:58:29] [PASSED] interlace_only
[20:58:29] [PASSED] res_missing_x
[20:58:29] [PASSED] res_missing_y
[20:58:29] [PASSED] res_bad_y
[20:58:29] [PASSED] res_missing_y_bpp
[20:58:29] [PASSED] res_bad_bpp
[20:58:29] [PASSED] res_bad_refresh
[20:58:29] [PASSED] res_bpp_refresh_force_on_off
[20:58:29] [PASSED] res_invalid_mode
[20:58:29] [PASSED] res_bpp_wrong_place_mode
[20:58:29] [PASSED] name_bpp_refresh
[20:58:29] [PASSED] name_refresh
[20:58:29] [PASSED] name_refresh_wrong_mode
[20:58:29] [PASSED] name_refresh_invalid_mode
[20:58:29] [PASSED] rotate_multiple
[20:58:29] [PASSED] rotate_invalid_val
[20:58:29] [PASSED] rotate_truncated
[20:58:29] [PASSED] invalid_option
[20:58:29] [PASSED] invalid_tv_option
[20:58:29] [PASSED] truncated_tv_option
[20:58:29] ============ [PASSED] drm_test_cmdline_invalid =============
[20:58:29] =============== drm_test_cmdline_tv_options ===============
[20:58:29] [PASSED] NTSC
[20:58:29] [PASSED] NTSC_443
[20:58:29] [PASSED] NTSC_J
[20:58:29] [PASSED] PAL
[20:58:29] [PASSED] PAL_M
[20:58:29] [PASSED] PAL_N
[20:58:29] [PASSED] SECAM
[20:58:29] [PASSED] MONO_525
[20:58:29] [PASSED] MONO_625
[20:58:29] =========== [PASSED] drm_test_cmdline_tv_options ===========
[20:58:29] =============== [PASSED] drm_cmdline_parser ================
[20:58:29] ========== drmm_connector_hdmi_init (19 subtests) ==========
[20:58:29] [PASSED] drm_test_connector_hdmi_init_valid
[20:58:29] [PASSED] drm_test_connector_hdmi_init_bpc_8
[20:58:29] [PASSED] drm_test_connector_hdmi_init_bpc_10
[20:58:29] [PASSED] drm_test_connector_hdmi_init_bpc_12
[20:58:29] [PASSED] drm_test_connector_hdmi_init_bpc_invalid
[20:58:29] [PASSED] drm_test_connector_hdmi_init_bpc_null
[20:58:29] [PASSED] drm_test_connector_hdmi_init_formats_empty
[20:58:29] [PASSED] drm_test_connector_hdmi_init_formats_no_rgb
[20:58:29] [PASSED] drm_test_connector_hdmi_init_null_ddc
[20:58:29] [PASSED] drm_test_connector_hdmi_init_null_product
[20:58:29] [PASSED] drm_test_connector_hdmi_init_null_vendor
[20:58:29] [PASSED] drm_test_connector_hdmi_init_product_length_exact
[20:58:29] [PASSED] drm_test_connector_hdmi_init_product_length_too_long
[20:58:29] [PASSED] drm_test_connector_hdmi_init_product_valid
[20:58:29] [PASSED] drm_test_connector_hdmi_init_vendor_length_exact
[20:58:29] [PASSED] drm_test_connector_hdmi_init_vendor_length_too_long
[20:58:29] [PASSED] drm_test_connector_hdmi_init_vendor_valid
[20:58:29] ========= drm_test_connector_hdmi_init_type_valid =========
[20:58:29] [PASSED] HDMI-A
[20:58:29] [PASSED] HDMI-B
[20:58:29] ===== [PASSED] drm_test_connector_hdmi_init_type_valid =====
[20:58:29] ======== drm_test_connector_hdmi_init_type_invalid ========
[20:58:29] [PASSED] Unknown
[20:58:29] [PASSED] VGA
[20:58:29] [PASSED] DVI-I
[20:58:29] [PASSED] DVI-D
[20:58:29] [PASSED] DVI-A
[20:58:29] [PASSED] Composite
[20:58:29] [PASSED] SVIDEO
[20:58:29] [PASSED] LVDS
[20:58:29] [PASSED] Component
[20:58:29] [PASSED] DIN
[20:58:29] [PASSED] DP
[20:58:29] [PASSED] TV
[20:58:29] [PASSED] eDP
[20:58:29] [PASSED] Virtual
[20:58:29] [PASSED] DSI
[20:58:29] [PASSED] DPI
[20:58:29] [PASSED] Writeback
[20:58:29] [PASSED] SPI
[20:58:29] [PASSED] USB
[20:58:29] ==== [PASSED] drm_test_connector_hdmi_init_type_invalid ====
[20:58:29] ============ [PASSED] drmm_connector_hdmi_init =============
[20:58:29] ============= drmm_connector_init (3 subtests) =============
[20:58:29] [PASSED] drm_test_drmm_connector_init
[20:58:29] [PASSED] drm_test_drmm_connector_init_null_ddc
[20:58:29] ========= drm_test_drmm_connector_init_type_valid =========
[20:58:29] [PASSED] Unknown
[20:58:29] [PASSED] VGA
[20:58:29] [PASSED] DVI-I
[20:58:29] [PASSED] DVI-D
[20:58:29] [PASSED] DVI-A
[20:58:29] [PASSED] Composite
[20:58:29] [PASSED] SVIDEO
[20:58:29] [PASSED] LVDS
[20:58:29] [PASSED] Component
[20:58:29] [PASSED] DIN
[20:58:29] [PASSED] DP
[20:58:29] [PASSED] HDMI-A
[20:58:29] [PASSED] HDMI-B
[20:58:29] [PASSED] TV
[20:58:29] [PASSED] eDP
[20:58:29] [PASSED] Virtual
[20:58:29] [PASSED] DSI
[20:58:29] [PASSED] DPI
[20:58:29] [PASSED] Writeback
[20:58:29] [PASSED] SPI
[20:58:29] [PASSED] USB
[20:58:29] ===== [PASSED] drm_test_drmm_connector_init_type_valid =====
[20:58:29] =============== [PASSED] drmm_connector_init ===============
[20:58:29] = drm_connector_attach_broadcast_rgb_property (2 subtests) =
[20:58:29] [PASSED] drm_test_drm_connector_attach_broadcast_rgb_property
[20:58:29] [PASSED] drm_test_drm_connector_attach_broadcast_rgb_property_hdmi_connector
[20:58:29] === [PASSED] drm_connector_attach_broadcast_rgb_property ===
[20:58:29] ========== drm_get_tv_mode_from_name (2 subtests) ==========
[20:58:29] ========== drm_test_get_tv_mode_from_name_valid ===========
[20:58:29] [PASSED] NTSC
[20:58:29] [PASSED] NTSC-443
[20:58:29] [PASSED] NTSC-J
[20:58:29] [PASSED] PAL
[20:58:29] [PASSED] PAL-M
[20:58:29] [PASSED] PAL-N
[20:58:29] [PASSED] SECAM
[20:58:29] [PASSED] Mono
[20:58:29] ====== [PASSED] drm_test_get_tv_mode_from_name_valid =======
[20:58:29] [PASSED] drm_test_get_tv_mode_from_name_truncated
[20:58:29] ============ [PASSED] drm_get_tv_mode_from_name ============
[20:58:29] = drm_test_connector_hdmi_compute_mode_clock (12 subtests) =
[20:58:29] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb
[20:58:29] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb_10bpc
[20:58:29] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb_10bpc_vic_1
[20:58:29] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb_12bpc
[20:58:29] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb_12bpc_vic_1
[20:58:29] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb_double
[20:58:29] = drm_test_connector_hdmi_compute_mode_clock_yuv420_valid =
[20:58:29] [PASSED] VIC 96
[20:58:29] [PASSED] VIC 97
[20:58:29] [PASSED] VIC 101
[20:58:29] [PASSED] VIC 102
[20:58:29] [PASSED] VIC 106
[20:58:29] [PASSED] VIC 107
[20:58:29] === [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv420_valid ===
[20:58:29] [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv420_10_bpc
[20:58:29] [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv420_12_bpc
[20:58:29] [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv422_8_bpc
[20:58:29] [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv422_10_bpc
[20:58:29] [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv422_12_bpc
[20:58:29] === [PASSED] drm_test_connector_hdmi_compute_mode_clock ====
[20:58:29] == drm_hdmi_connector_get_broadcast_rgb_name (2 subtests) ==
[20:58:29] === drm_test_drm_hdmi_connector_get_broadcast_rgb_name ====
[20:58:29] [PASSED] Automatic
[20:58:29] [PASSED] Full
[20:58:29] [PASSED] Limited 16:235
[20:58:29] === [PASSED] drm_test_drm_hdmi_connector_get_broadcast_rgb_name ===
[20:58:29] [PASSED] drm_test_drm_hdmi_connector_get_broadcast_rgb_name_invalid
[20:58:29] ==== [PASSED] drm_hdmi_connector_get_broadcast_rgb_name ====
[20:58:29] == drm_hdmi_connector_get_output_format_name (2 subtests) ==
[20:58:29] === drm_test_drm_hdmi_connector_get_output_format_name ====
[20:58:29] [PASSED] RGB
[20:58:29] [PASSED] YUV 4:2:0
[20:58:29] [PASSED] YUV 4:2:2
[20:58:29] [PASSED] YUV 4:4:4
[20:58:29] === [PASSED] drm_test_drm_hdmi_connector_get_output_format_name ===
[20:58:29] [PASSED] drm_test_drm_hdmi_connector_get_output_format_name_invalid
[20:58:29] ==== [PASSED] drm_hdmi_connector_get_output_format_name ====
[20:58:29] ============= drm_damage_helper (21 subtests) ==============
[20:58:29] [PASSED] drm_test_damage_iter_no_damage
[20:58:29] [PASSED] drm_test_damage_iter_no_damage_fractional_src
[20:58:29] [PASSED] drm_test_damage_iter_no_damage_src_moved
[20:58:29] [PASSED] drm_test_damage_iter_no_damage_fractional_src_moved
[20:58:29] [PASSED] drm_test_damage_iter_no_damage_not_visible
[20:58:29] [PASSED] drm_test_damage_iter_no_damage_no_crtc
[20:58:29] [PASSED] drm_test_damage_iter_no_damage_no_fb
[20:58:29] [PASSED] drm_test_damage_iter_simple_damage
[20:58:29] [PASSED] drm_test_damage_iter_single_damage
[20:58:29] [PASSED] drm_test_damage_iter_single_damage_intersect_src
[20:58:29] [PASSED] drm_test_damage_iter_single_damage_outside_src
[20:58:29] [PASSED] drm_test_damage_iter_single_damage_fractional_src
[20:58:29] [PASSED] drm_test_damage_iter_single_damage_intersect_fractional_src
[20:58:29] [PASSED] drm_test_damage_iter_single_damage_outside_fractional_src
[20:58:29] [PASSED] drm_test_damage_iter_single_damage_src_moved
[20:58:29] [PASSED] drm_test_damage_iter_single_damage_fractional_src_moved
[20:58:29] [PASSED] drm_test_damage_iter_damage
[20:58:29] [PASSED] drm_test_damage_iter_damage_one_intersect
[20:58:29] [PASSED] drm_test_damage_iter_damage_one_outside
[20:58:29] [PASSED] drm_test_damage_iter_damage_src_moved
[20:58:29] [PASSED] drm_test_damage_iter_damage_not_visible
[20:58:29] ================ [PASSED] drm_damage_helper ================
[20:58:29] ============== drm_dp_mst_helper (3 subtests) ==============
[20:58:29] ============== drm_test_dp_mst_calc_pbn_mode ==============
[20:58:29] [PASSED] Clock 154000 BPP 30 DSC disabled
[20:58:29] [PASSED] Clock 234000 BPP 30 DSC disabled
[20:58:29] [PASSED] Clock 297000 BPP 24 DSC disabled
[20:58:29] [PASSED] Clock 332880 BPP 24 DSC enabled
[20:58:29] [PASSED] Clock 324540 BPP 24 DSC enabled
[20:58:29] ========== [PASSED] drm_test_dp_mst_calc_pbn_mode ==========
[20:58:29] ============== drm_test_dp_mst_calc_pbn_div ===============
[20:58:29] [PASSED] Link rate 2000000 lane count 4
[20:58:29] [PASSED] Link rate 2000000 lane count 2
[20:58:29] [PASSED] Link rate 2000000 lane count 1
[20:58:29] [PASSED] Link rate 1350000 lane count 4
[20:58:29] [PASSED] Link rate 1350000 lane count 2
[20:58:29] [PASSED] Link rate 1350000 lane count 1
[20:58:29] [PASSED] Link rate 1000000 lane count 4
[20:58:29] [PASSED] Link rate 1000000 lane count 2
[20:58:29] [PASSED] Link rate 1000000 lane count 1
[20:58:29] [PASSED] Link rate 810000 lane count 4
[20:58:29] [PASSED] Link rate 810000 lane count 2
[20:58:29] [PASSED] Link rate 810000 lane count 1
[20:58:29] [PASSED] Link rate 540000 lane count 4
[20:58:29] [PASSED] Link rate 540000 lane count 2
[20:58:29] [PASSED] Link rate 540000 lane count 1
[20:58:29] [PASSED] Link rate 270000 lane count 4
[20:58:29] [PASSED] Link rate 270000 lane count 2
[20:58:29] [PASSED] Link rate 270000 lane count 1
[20:58:29] [PASSED] Link rate 162000 lane count 4
[20:58:29] [PASSED] Link rate 162000 lane count 2
[20:58:29] [PASSED] Link rate 162000 lane count 1
[20:58:29] ========== [PASSED] drm_test_dp_mst_calc_pbn_div ===========
[20:58:29] ========= drm_test_dp_mst_sideband_msg_req_decode =========
[20:58:29] [PASSED] DP_ENUM_PATH_RESOURCES with port number
[20:58:29] [PASSED] DP_POWER_UP_PHY with port number
[20:58:29] [PASSED] DP_POWER_DOWN_PHY with port number
[20:58:29] [PASSED] DP_ALLOCATE_PAYLOAD with SDP stream sinks
[20:58:29] [PASSED] DP_ALLOCATE_PAYLOAD with port number
[20:58:29] [PASSED] DP_ALLOCATE_PAYLOAD with VCPI
[20:58:29] [PASSED] DP_ALLOCATE_PAYLOAD with PBN
[20:58:29] [PASSED] DP_QUERY_PAYLOAD with port number
[20:58:29] [PASSED] DP_QUERY_PAYLOAD with VCPI
[20:58:29] [PASSED] DP_REMOTE_DPCD_READ with port number
[20:58:29] [PASSED] DP_REMOTE_DPCD_READ with DPCD address
[20:58:29] [PASSED] DP_REMOTE_DPCD_READ with max number of bytes
[20:58:29] [PASSED] DP_REMOTE_DPCD_WRITE with port number
[20:58:29] [PASSED] DP_REMOTE_DPCD_WRITE with DPCD address
[20:58:29] [PASSED] DP_REMOTE_DPCD_WRITE with data array
[20:58:29] [PASSED] DP_REMOTE_I2C_READ with port number
[20:58:29] [PASSED] DP_REMOTE_I2C_READ with I2C device ID
[20:58:29] [PASSED] DP_REMOTE_I2C_READ with transactions array
[20:58:29] [PASSED] DP_REMOTE_I2C_WRITE with port number
[20:58:29] [PASSED] DP_REMOTE_I2C_WRITE with I2C device ID
[20:58:29] [PASSED] DP_REMOTE_I2C_WRITE with data array
[20:58:29] [PASSED] DP_QUERY_STREAM_ENC_STATUS with stream ID
[20:58:29] [PASSED] DP_QUERY_STREAM_ENC_STATUS with client ID
[20:58:29] [PASSED] DP_QUERY_STREAM_ENC_STATUS with stream event
[20:58:29] [PASSED] DP_QUERY_STREAM_ENC_STATUS with valid stream event
[20:58:29] [PASSED] DP_QUERY_STREAM_ENC_STATUS with stream behavior
[20:58:29] [PASSED] DP_QUERY_STREAM_ENC_STATUS with a valid stream behavior
[20:58:29] ===== [PASSED] drm_test_dp_mst_sideband_msg_req_decode =====
[20:58:29] ================ [PASSED] drm_dp_mst_helper ================
[20:58:29] ================== drm_exec (7 subtests) ===================
[20:58:29] [PASSED] sanitycheck
[20:58:29] [PASSED] test_lock
[20:58:29] [PASSED] test_lock_unlock
[20:58:29] [PASSED] test_duplicates
[20:58:29] [PASSED] test_prepare
[20:58:29] [PASSED] test_prepare_array
[20:58:29] [PASSED] test_multiple_loops
[20:58:29] ==================== [PASSED] drm_exec =====================
[20:58:29] =========== drm_format_helper_test (17 subtests) ===========
[20:58:29] ============== drm_test_fb_xrgb8888_to_gray8 ==============
[20:58:29] [PASSED] single_pixel_source_buffer
[20:58:29] [PASSED] single_pixel_clip_rectangle
[20:58:29] [PASSED] well_known_colors
[20:58:29] [PASSED] destination_pitch
[20:58:29] ========== [PASSED] drm_test_fb_xrgb8888_to_gray8 ==========
[20:58:29] ============= drm_test_fb_xrgb8888_to_rgb332 ==============
[20:58:29] [PASSED] single_pixel_source_buffer
[20:58:29] [PASSED] single_pixel_clip_rectangle
[20:58:29] [PASSED] well_known_colors
[20:58:29] [PASSED] destination_pitch
[20:58:29] ========= [PASSED] drm_test_fb_xrgb8888_to_rgb332 ==========
[20:58:29] ============= drm_test_fb_xrgb8888_to_rgb565 ==============
[20:58:29] [PASSED] single_pixel_source_buffer
[20:58:29] [PASSED] single_pixel_clip_rectangle
[20:58:29] [PASSED] well_known_colors
[20:58:29] [PASSED] destination_pitch
[20:58:29] ========= [PASSED] drm_test_fb_xrgb8888_to_rgb565 ==========
[20:58:29] ============ drm_test_fb_xrgb8888_to_xrgb1555 =============
[20:58:29] [PASSED] single_pixel_source_buffer
[20:58:29] [PASSED] single_pixel_clip_rectangle
[20:58:29] [PASSED] well_known_colors
[20:58:29] [PASSED] destination_pitch
[20:58:29] ======== [PASSED] drm_test_fb_xrgb8888_to_xrgb1555 =========
[20:58:29] ============ drm_test_fb_xrgb8888_to_argb1555 =============
[20:58:29] [PASSED] single_pixel_source_buffer
[20:58:29] [PASSED] single_pixel_clip_rectangle
[20:58:29] [PASSED] well_known_colors
[20:58:29] [PASSED] destination_pitch
[20:58:29] ======== [PASSED] drm_test_fb_xrgb8888_to_argb1555 =========
[20:58:29] ============ drm_test_fb_xrgb8888_to_rgba5551 =============
[20:58:29] [PASSED] single_pixel_source_buffer
[20:58:29] [PASSED] single_pixel_clip_rectangle
[20:58:29] [PASSED] well_known_colors
[20:58:29] [PASSED] destination_pitch
[20:58:29] ======== [PASSED] drm_test_fb_xrgb8888_to_rgba5551 =========
[20:58:29] ============= drm_test_fb_xrgb8888_to_rgb888 ==============
[20:58:29] [PASSED] single_pixel_source_buffer
[20:58:29] [PASSED] single_pixel_clip_rectangle
[20:58:29] [PASSED] well_known_colors
[20:58:29] [PASSED] destination_pitch
[20:58:29] ========= [PASSED] drm_test_fb_xrgb8888_to_rgb888 ==========
[20:58:29] ============ drm_test_fb_xrgb8888_to_argb8888 =============
[20:58:29] [PASSED] single_pixel_source_buffer
[20:58:29] [PASSED] single_pixel_clip_rectangle
[20:58:29] [PASSED] well_known_colors
[20:58:29] [PASSED] destination_pitch
[20:58:29] ======== [PASSED] drm_test_fb_xrgb8888_to_argb8888 =========
[20:58:29] =========== drm_test_fb_xrgb8888_to_xrgb2101010 ===========
[20:58:29] [PASSED] single_pixel_source_buffer
[20:58:29] [PASSED] single_pixel_clip_rectangle
[20:58:29] [PASSED] well_known_colors
[20:58:29] [PASSED] destination_pitch
[20:58:29] ======= [PASSED] drm_test_fb_xrgb8888_to_xrgb2101010 =======
[20:58:29] =========== drm_test_fb_xrgb8888_to_argb2101010 ===========
[20:58:29] [PASSED] single_pixel_source_buffer
[20:58:29] [PASSED] single_pixel_clip_rectangle
[20:58:29] [PASSED] well_known_colors
[20:58:29] [PASSED] destination_pitch
[20:58:29] ======= [PASSED] drm_test_fb_xrgb8888_to_argb2101010 =======
[20:58:29] ============== drm_test_fb_xrgb8888_to_mono ===============
[20:58:29] [PASSED] single_pixel_source_buffer
[20:58:29] [PASSED] single_pixel_clip_rectangle
[20:58:29] [PASSED] well_known_colors
[20:58:29] [PASSED] destination_pitch
[20:58:29] ========== [PASSED] drm_test_fb_xrgb8888_to_mono ===========
[20:58:29] ==================== drm_test_fb_swab =====================
[20:58:29] [PASSED] single_pixel_source_buffer
[20:58:29] [PASSED] single_pixel_clip_rectangle
[20:58:29] [PASSED] well_known_colors
[20:58:29] [PASSED] destination_pitch
[20:58:29] ================ [PASSED] drm_test_fb_swab =================
[20:58:29] ============ drm_test_fb_xrgb8888_to_xbgr8888 =============
[20:58:29] [PASSED] single_pixel_source_buffer
[20:58:29] [PASSED] single_pixel_clip_rectangle
[20:58:29] [PASSED] well_known_colors
[20:58:29] [PASSED] destination_pitch
[20:58:29] ======== [PASSED] drm_test_fb_xrgb8888_to_xbgr8888 =========
[20:58:29] ============ drm_test_fb_xrgb8888_to_abgr8888 =============
[20:58:29] [PASSED] single_pixel_source_buffer
[20:58:29] [PASSED] single_pixel_clip_rectangle
[20:58:29] [PASSED] well_known_colors
[20:58:29] [PASSED] destination_pitch
[20:58:29] ======== [PASSED] drm_test_fb_xrgb8888_to_abgr8888 =========
[20:58:29] ================= drm_test_fb_clip_offset =================
[20:58:29] [PASSED] pass through
[20:58:29] [PASSED] horizontal offset
[20:58:29] [PASSED] vertical offset
[20:58:29] [PASSED] horizontal and vertical offset
[20:58:29] [PASSED] horizontal offset (custom pitch)
[20:58:29] [PASSED] vertical offset (custom pitch)
[20:58:29] [PASSED] horizontal and vertical offset (custom pitch)
[20:58:29] ============= [PASSED] drm_test_fb_clip_offset =============
[20:58:29] ============== drm_test_fb_build_fourcc_list ==============
[20:58:29] [PASSED] no native formats
[20:58:29] [PASSED] XRGB8888 as native format
[20:58:29] [PASSED] remove duplicates
[20:58:29] [PASSED] convert alpha formats
[20:58:29] [PASSED] random formats
[20:58:29] ========== [PASSED] drm_test_fb_build_fourcc_list ==========
[20:58:29] =================== drm_test_fb_memcpy ====================
[20:58:29] [PASSED] single_pixel_source_buffer: XR24 little-endian (0x34325258)
[20:58:29] [PASSED] single_pixel_source_buffer: XRA8 little-endian (0x38415258)
[20:58:29] [PASSED] single_pixel_source_buffer: YU24 little-endian (0x34325559)
[20:58:29] [PASSED] single_pixel_clip_rectangle: XB24 little-endian (0x34324258)
[20:58:29] [PASSED] single_pixel_clip_rectangle: XRA8 little-endian (0x38415258)
[20:58:29] [PASSED] single_pixel_clip_rectangle: YU24 little-endian (0x34325559)
[20:58:29] [PASSED] well_known_colors: XB24 little-endian (0x34324258)
[20:58:29] [PASSED] well_known_colors: XRA8 little-endian (0x38415258)
[20:58:29] [PASSED] well_known_colors: YU24 little-endian (0x34325559)
[20:58:29] [PASSED] destination_pitch: XB24 little-endian (0x34324258)
[20:58:29] [PASSED] destination_pitch: XRA8 little-endian (0x38415258)
[20:58:29] [PASSED] destination_pitch: YU24 little-endian (0x34325559)
[20:58:29] =============== [PASSED] drm_test_fb_memcpy ================
[20:58:29] ============= [PASSED] drm_format_helper_test ==============
[20:58:29] ================= drm_format (18 subtests) =================
[20:58:29] [PASSED] drm_test_format_block_width_invalid
[20:58:29] [PASSED] drm_test_format_block_width_one_plane
[20:58:29] [PASSED] drm_test_format_block_width_two_plane
[20:58:29] [PASSED] drm_test_format_block_width_three_plane
[20:58:29] [PASSED] drm_test_format_block_width_tiled
[20:58:29] [PASSED] drm_test_format_block_height_invalid
[20:58:29] [PASSED] drm_test_format_block_height_one_plane
[20:58:29] [PASSED] drm_test_format_block_height_two_plane
[20:58:29] [PASSED] drm_test_format_block_height_three_plane
[20:58:29] [PASSED] drm_test_format_block_height_tiled
[20:58:29] [PASSED] drm_test_format_min_pitch_invalid
[20:58:29] [PASSED] drm_test_format_min_pitch_one_plane_8bpp
[20:58:29] [PASSED] drm_test_format_min_pitch_one_plane_16bpp
[20:58:29] [PASSED] drm_test_format_min_pitch_one_plane_24bpp
[20:58:29] [PASSED] drm_test_format_min_pitch_one_plane_32bpp
[20:58:29] [PASSED] drm_test_format_min_pitch_two_plane
[20:58:29] [PASSED] drm_test_format_min_pitch_three_plane_8bpp
[20:58:29] [PASSED] drm_test_format_min_pitch_tiled
[20:58:29] =================== [PASSED] drm_format ====================
[20:58:29] =============== drm_framebuffer (1 subtest) ================
[20:58:29] =============== drm_test_framebuffer_create ===============
[20:58:29] [PASSED] ABGR8888 normal sizes
[20:58:29] [PASSED] ABGR8888 max sizes
[20:58:29] [PASSED] ABGR8888 pitch greater than min required
[20:58:29] [PASSED] ABGR8888 pitch less than min required
[20:58:29] [PASSED] ABGR8888 Invalid width
[20:58:29] [PASSED] ABGR8888 Invalid buffer handle
[20:58:29] [PASSED] No pixel format
[20:58:29] [PASSED] ABGR8888 Width 0
[20:58:29] [PASSED] ABGR8888 Height 0
[20:58:29] [PASSED] ABGR8888 Out of bound height * pitch combination
[20:58:29] [PASSED] ABGR8888 Large buffer offset
[20:58:29] [PASSED] ABGR8888 Set DRM_MODE_FB_MODIFIERS without modifiers
[20:58:29] [PASSED] ABGR8888 Valid buffer modifier
[20:58:29] [PASSED] ABGR8888 Invalid buffer modifier(DRM_FORMAT_MOD_SAMSUNG_64_32_TILE)
[20:58:29] [PASSED] ABGR8888 Extra pitches without DRM_MODE_FB_MODIFIERS
[20:58:29] [PASSED] ABGR8888 Extra pitches with DRM_MODE_FB_MODIFIERS
[20:58:29] [PASSED] NV12 Normal sizes
[20:58:29] [PASSED] NV12 Max sizes
[20:58:29] [PASSED] NV12 Invalid pitch
[20:58:29] [PASSED] NV12 Invalid modifier/missing DRM_MODE_FB_MODIFIERS flag
[20:58:29] [PASSED] NV12 different modifier per-plane
[20:58:29] [PASSED] NV12 with DRM_FORMAT_MOD_SAMSUNG_64_32_TILE
[20:58:29] [PASSED] NV12 Valid modifiers without DRM_MODE_FB_MODIFIERS
[20:58:29] [PASSED] NV12 Modifier for inexistent plane
[20:58:29] [PASSED] NV12 Handle for inexistent plane
[20:58:29] [PASSED] NV12 Handle for inexistent plane without DRM_MODE_FB_MODIFIERS
[20:58:29] [PASSED] YVU420 DRM_MODE_FB_MODIFIERS set without modifier
[20:58:29] [PASSED] YVU420 Normal sizes
[20:58:29] [PASSED] YVU420 Max sizes
[20:58:29] [PASSED] YVU420 Invalid pitch
[20:58:29] [PASSED] YVU420 Different pitches
[20:58:29] [PASSED] YVU420 Different buffer offsets/pitches
[20:58:29] [PASSED] YVU420 Modifier set just for plane 0, without DRM_MODE_FB_MODIFIERS
[20:58:29] [PASSED] YVU420 Modifier set just for planes 0, 1, without DRM_MODE_FB_MODIFIERS
[20:58:29] [PASSED] YVU420 Modifier set just for plane 0, 1, with DRM_MODE_FB_MODIFIERS
[20:58:29] [PASSED] YVU420 Valid modifier
[20:58:29] [PASSED] YVU420 Different modifiers per plane
[20:58:29] [PASSED] YVU420 Modifier for inexistent plane
[20:58:29] [PASSED] X0L2 Normal sizes
[20:58:29] [PASSED] X0L2 Max sizes
[20:58:29] [PASSED] X0L2 Invalid pitch
[20:58:29] [PASSED] X0L2 Pitch greater than minimum required
[20:58:29] [PASSED] X0L2 Handle for inexistent plane
[20:58:29] [PASSED] X0L2 Offset for inexistent plane, without DRM_MODE_FB_MODIFIERS set
[20:58:29] [PASSED] X0L2 Modifier without DRM_MODE_FB_MODIFIERS set
[20:58:29] [PASSED] X0L2 Valid modifier
[20:58:29] [PASSED] X0L2 Modifier for inexistent plane
[20:58:29] =========== [PASSED] drm_test_framebuffer_create ===========
[20:58:29] ================= [PASSED] drm_framebuffer =================
[20:58:29] ================ drm_gem_shmem (8 subtests) ================
[20:58:29] [PASSED] drm_gem_shmem_test_obj_create
[20:58:29] [PASSED] drm_gem_shmem_test_obj_create_private
[20:58:29] [PASSED] drm_gem_shmem_test_pin_pages
[20:58:29] [PASSED] drm_gem_shmem_test_vmap
[20:58:29] [PASSED] drm_gem_shmem_test_get_pages_sgt
[20:58:29] [PASSED] drm_gem_shmem_test_get_sg_table
[20:58:29] [PASSED] drm_gem_shmem_test_madvise
[20:58:29] [PASSED] drm_gem_shmem_test_purge
[20:58:29] ================== [PASSED] drm_gem_shmem ==================
[20:58:29] === drm_atomic_helper_connector_hdmi_check (22 subtests) ===
[20:58:29] [PASSED] drm_test_check_broadcast_rgb_auto_cea_mode
[20:58:29] [PASSED] drm_test_check_broadcast_rgb_auto_cea_mode_vic_1
[20:58:29] [PASSED] drm_test_check_broadcast_rgb_full_cea_mode
[20:58:29] [PASSED] drm_test_check_broadcast_rgb_full_cea_mode_vic_1
[20:58:29] [PASSED] drm_test_check_broadcast_rgb_limited_cea_mode
[20:58:29] [PASSED] drm_test_check_broadcast_rgb_limited_cea_mode_vic_1
[20:58:29] [PASSED] drm_test_check_broadcast_rgb_crtc_mode_changed
[20:58:29] [PASSED] drm_test_check_broadcast_rgb_crtc_mode_not_changed
[20:58:29] [PASSED] drm_test_check_hdmi_funcs_reject_rate
[20:58:29] [PASSED] drm_test_check_max_tmds_rate_bpc_fallback
[20:58:29] [PASSED] drm_test_check_max_tmds_rate_format_fallback
[20:58:29] [PASSED] drm_test_check_output_bpc_crtc_mode_changed
[20:58:29] [PASSED] drm_test_check_output_bpc_crtc_mode_not_changed
[20:58:29] [PASSED] drm_test_check_output_bpc_dvi
[20:58:29] [PASSED] drm_test_check_output_bpc_format_vic_1
[20:58:29] [PASSED] drm_test_check_output_bpc_format_display_8bpc_only
[20:58:29] [PASSED] drm_test_check_output_bpc_format_display_rgb_only
[20:58:29] [PASSED] drm_test_check_output_bpc_format_driver_8bpc_only
[20:58:29] [PASSED] drm_test_check_output_bpc_format_driver_rgb_only
[20:58:29] [PASSED] drm_test_check_tmds_char_rate_rgb_8bpc
[20:58:29] [PASSED] drm_test_check_tmds_char_rate_rgb_10bpc
[20:58:29] [PASSED] drm_test_check_tmds_char_rate_rgb_12bpc
[20:58:29] ===== [PASSED] drm_atomic_helper_connector_hdmi_check ======
[20:58:29] === drm_atomic_helper_connector_hdmi_reset (6 subtests) ====
[20:58:29] [PASSED] drm_test_check_broadcast_rgb_value
[20:58:29] [PASSED] drm_test_check_bpc_8_value
[20:58:29] [PASSED] drm_test_check_bpc_10_value
[20:58:29] [PASSED] drm_test_check_bpc_12_value
[20:58:29] [PASSED] drm_test_check_format_value
[20:58:29] [PASSED] drm_test_check_tmds_char_value
[20:58:29] ===== [PASSED] drm_atomic_helper_connector_hdmi_reset ======
[20:58:29] ================= drm_managed (2 subtests) =================
[20:58:29] [PASSED] drm_test_managed_release_action
[20:58:29] [PASSED] drm_test_managed_run_action
[20:58:29] =================== [PASSED] drm_managed ===================
[20:58:29] =================== drm_mm (6 subtests) ====================
[20:58:29] [PASSED] drm_test_mm_init
[20:58:29] [PASSED] drm_test_mm_debug
[20:58:29] [PASSED] drm_test_mm_align32
[20:58:29] [PASSED] drm_test_mm_align64
[20:58:29] [PASSED] drm_test_mm_lowest
[20:58:29] [PASSED] drm_test_mm_highest
[20:58:29] ===================== [PASSED] drm_mm ======================
[20:58:29] ============= drm_modes_analog_tv (5 subtests) =============
[20:58:29] [PASSED] drm_test_modes_analog_tv_mono_576i
[20:58:29] [PASSED] drm_test_modes_analog_tv_ntsc_480i
[20:58:29] [PASSED] drm_test_modes_analog_tv_ntsc_480i_inlined
[20:58:29] [PASSED] drm_test_modes_analog_tv_pal_576i
[20:58:29] [PASSED] drm_test_modes_analog_tv_pal_576i_inlined
[20:58:29] =============== [PASSED] drm_modes_analog_tv ===============
[20:58:29] ============== drm_plane_helper (2 subtests) ===============
[20:58:29] =============== drm_test_check_plane_state ================
[20:58:29] [PASSED] clipping_simple
[20:58:29] [PASSED] clipping_rotate_reflect
[20:58:29] [PASSED] positioning_simple
[20:58:29] [PASSED] upscaling
[20:58:29] [PASSED] downscaling
[20:58:29] [PASSED] rounding1
[20:58:29] [PASSED] rounding2
[20:58:29] [PASSED] rounding3
[20:58:29] [PASSED] rounding4
[20:58:29] =========== [PASSED] drm_test_check_plane_state ============
[20:58:29] =========== drm_test_check_invalid_plane_state ============
[20:58:29] [PASSED] positioning_invalid
[20:58:29] [PASSED] upscaling_invalid
stty: 'standard input': Inappropriate ioctl for device
[20:58:29] [PASSED] downscaling_invalid
[20:58:29] ======= [PASSED] drm_test_check_invalid_plane_state ========
[20:58:29] ================ [PASSED] drm_plane_helper =================
[20:58:29] ====== drm_connector_helper_tv_get_modes (1 subtest) =======
[20:58:29] ====== drm_test_connector_helper_tv_get_modes_check =======
[20:58:29] [PASSED] None
[20:58:29] [PASSED] PAL
[20:58:29] [PASSED] NTSC
[20:58:29] [PASSED] Both, NTSC Default
[20:58:29] [PASSED] Both, PAL Default
[20:58:29] [PASSED] Both, NTSC Default, with PAL on command-line
[20:58:29] [PASSED] Both, PAL Default, with NTSC on command-line
[20:58:29] == [PASSED] drm_test_connector_helper_tv_get_modes_check ===
[20:58:29] ======== [PASSED] drm_connector_helper_tv_get_modes ========
[20:58:29] ================== drm_rect (9 subtests) ===================
[20:58:29] [PASSED] drm_test_rect_clip_scaled_div_by_zero
[20:58:29] [PASSED] drm_test_rect_clip_scaled_not_clipped
[20:58:29] [PASSED] drm_test_rect_clip_scaled_clipped
[20:58:29] [PASSED] drm_test_rect_clip_scaled_signed_vs_unsigned
[20:58:29] ================= drm_test_rect_intersect =================
[20:58:29] [PASSED] top-left x bottom-right: 2x2+1+1 x 2x2+0+0
[20:58:29] [PASSED] top-right x bottom-left: 2x2+0+0 x 2x2+1-1
[20:58:29] [PASSED] bottom-left x top-right: 2x2+1-1 x 2x2+0+0
[20:58:29] [PASSED] bottom-right x top-left: 2x2+0+0 x 2x2+1+1
[20:58:29] [PASSED] right x left: 2x1+0+0 x 3x1+1+0
[20:58:29] [PASSED] left x right: 3x1+1+0 x 2x1+0+0
[20:58:29] [PASSED] up x bottom: 1x2+0+0 x 1x3+0-1
[20:58:29] [PASSED] bottom x up: 1x3+0-1 x 1x2+0+0
[20:58:29] [PASSED] touching corner: 1x1+0+0 x 2x2+1+1
[20:58:29] [PASSED] touching side: 1x1+0+0 x 1x1+1+0
[20:58:29] [PASSED] equal rects: 2x2+0+0 x 2x2+0+0
[20:58:29] [PASSED] inside another: 2x2+0+0 x 1x1+1+1
[20:58:29] [PASSED] far away: 1x1+0+0 x 1x1+3+6
[20:58:29] [PASSED] points intersecting: 0x0+5+10 x 0x0+5+10
[20:58:29] [PASSED] points not intersecting: 0x0+0+0 x 0x0+5+10
[20:58:29] ============= [PASSED] drm_test_rect_intersect =============
[20:58:29] ================ drm_test_rect_calc_hscale ================
[20:58:29] [PASSED] normal use
[20:58:29] [PASSED] out of max range
[20:58:29] [PASSED] out of min range
[20:58:29] [PASSED] zero dst
[20:58:29] [PASSED] negative src
[20:58:29] [PASSED] negative dst
[20:58:29] ============ [PASSED] drm_test_rect_calc_hscale ============
[20:58:29] ================ drm_test_rect_calc_vscale ================
[20:58:29] [PASSED] normal use
[20:58:29] [PASSED] out of max range
[20:58:29] [PASSED] out of min range
[20:58:29] [PASSED] zero dst
[20:58:29] [PASSED] negative src
[20:58:29] [PASSED] negative dst
[20:58:29] ============ [PASSED] drm_test_rect_calc_vscale ============
[20:58:29] ================== drm_test_rect_rotate ===================
[20:58:29] [PASSED] reflect-x
[20:58:29] [PASSED] reflect-y
[20:58:29] [PASSED] rotate-0
[20:58:29] [PASSED] rotate-90
[20:58:29] [PASSED] rotate-180
[20:58:29] [PASSED] rotate-270
[20:58:29] ============== [PASSED] drm_test_rect_rotate ===============
[20:58:29] ================ drm_test_rect_rotate_inv =================
[20:58:29] [PASSED] reflect-x
[20:58:29] [PASSED] reflect-y
[20:58:29] [PASSED] rotate-0
[20:58:29] [PASSED] rotate-90
[20:58:29] [PASSED] rotate-180
[20:58:29] [PASSED] rotate-270
[20:58:29] ============ [PASSED] drm_test_rect_rotate_inv =============
[20:58:29] ==================== [PASSED] drm_rect =====================
[20:58:29] ============================================================
[20:58:29] Testing complete. Ran 515 tests: passed: 515
[20:58:29] Elapsed time: 24.167s total, 1.751s configuring, 22.196s building, 0.204s running
+ /kernel/tools/testing/kunit/kunit.py run --kunitconfig /kernel/drivers/gpu/drm/ttm/tests/.kunitconfig
[20:58:29] Configuring KUnit Kernel ...
Regenerating .config ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
[20:58:31] Building KUnit Kernel ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
Building with:
$ make ARCH=um O=.kunit --jobs=48
[20:58:40] Starting KUnit Kernel (1/1)...
[20:58:40] ============================================================
Running tests with:
$ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt
[20:58:40] ================= ttm_device (5 subtests) ==================
[20:58:40] [PASSED] ttm_device_init_basic
[20:58:40] [PASSED] ttm_device_init_multiple
[20:58:40] [PASSED] ttm_device_fini_basic
[20:58:40] [PASSED] ttm_device_init_no_vma_man
[20:58:40] ================== ttm_device_init_pools ==================
[20:58:40] [PASSED] No DMA allocations, no DMA32 required
[20:58:40] [PASSED] DMA allocations, DMA32 required
[20:58:40] [PASSED] No DMA allocations, DMA32 required
[20:58:40] [PASSED] DMA allocations, no DMA32 required
[20:58:40] ============== [PASSED] ttm_device_init_pools ==============
[20:58:40] =================== [PASSED] ttm_device ====================
[20:58:40] ================== ttm_pool (8 subtests) ===================
[20:58:40] ================== ttm_pool_alloc_basic ===================
[20:58:40] [PASSED] One page
[20:58:40] [PASSED] More than one page
[20:58:40] [PASSED] Above the allocation limit
[20:58:40] [PASSED] One page, with coherent DMA mappings enabled
[20:58:40] [PASSED] Above the allocation limit, with coherent DMA mappings enabled
[20:58:40] ============== [PASSED] ttm_pool_alloc_basic ===============
[20:58:40] ============== ttm_pool_alloc_basic_dma_addr ==============
[20:58:40] [PASSED] One page
[20:58:40] [PASSED] More than one page
[20:58:40] [PASSED] Above the allocation limit
[20:58:40] [PASSED] One page, with coherent DMA mappings enabled
[20:58:40] [PASSED] Above the allocation limit, with coherent DMA mappings enabled
[20:58:40] ========== [PASSED] ttm_pool_alloc_basic_dma_addr ==========
[20:58:40] [PASSED] ttm_pool_alloc_order_caching_match
[20:58:40] [PASSED] ttm_pool_alloc_caching_mismatch
[20:58:40] [PASSED] ttm_pool_alloc_order_mismatch
[20:58:40] [PASSED] ttm_pool_free_dma_alloc
[20:58:40] [PASSED] ttm_pool_free_no_dma_alloc
[20:58:40] [PASSED] ttm_pool_fini_basic
[20:58:40] ==================== [PASSED] ttm_pool =====================
[20:58:40] ================ ttm_resource (8 subtests) =================
[20:58:40] ================= ttm_resource_init_basic =================
[20:58:40] [PASSED] Init resource in TTM_PL_SYSTEM
[20:58:40] [PASSED] Init resource in TTM_PL_VRAM
[20:58:40] [PASSED] Init resource in a private placement
[20:58:40] [PASSED] Init resource in TTM_PL_SYSTEM, set placement flags
[20:58:40] ============= [PASSED] ttm_resource_init_basic =============
[20:58:40] [PASSED] ttm_resource_init_pinned
[20:58:40] [PASSED] ttm_resource_fini_basic
[20:58:40] [PASSED] ttm_resource_manager_init_basic
[20:58:40] [PASSED] ttm_resource_manager_usage_basic
[20:58:40] [PASSED] ttm_resource_manager_set_used_basic
[20:58:40] [PASSED] ttm_sys_man_alloc_basic
[20:58:40] [PASSED] ttm_sys_man_free_basic
[20:58:40] ================== [PASSED] ttm_resource ===================
[20:58:40] =================== ttm_tt (15 subtests) ===================
[20:58:40] ==================== ttm_tt_init_basic ====================
[20:58:40] [PASSED] Page-aligned size
[20:58:40] [PASSED] Extra pages requested
[20:58:40] ================ [PASSED] ttm_tt_init_basic ================
[20:58:40] [PASSED] ttm_tt_init_misaligned
[20:58:40] [PASSED] ttm_tt_fini_basic
[20:58:40] [PASSED] ttm_tt_fini_sg
[20:58:40] [PASSED] ttm_tt_fini_shmem
[20:58:40] [PASSED] ttm_tt_create_basic
[20:58:40] [PASSED] ttm_tt_create_invalid_bo_type
[20:58:40] [PASSED] ttm_tt_create_ttm_exists
[20:58:40] [PASSED] ttm_tt_create_failed
[20:58:40] [PASSED] ttm_tt_destroy_basic
[20:58:40] [PASSED] ttm_tt_populate_null_ttm
[20:58:40] [PASSED] ttm_tt_populate_populated_ttm
[20:58:40] [PASSED] ttm_tt_unpopulate_basic
[20:58:40] [PASSED] ttm_tt_unpopulate_empty_ttm
[20:58:40] [PASSED] ttm_tt_swapin_basic
[20:58:40] ===================== [PASSED] ttm_tt ======================
[20:58:40] =================== ttm_bo (14 subtests) ===================
[20:58:40] =========== ttm_bo_reserve_optimistic_no_ticket ===========
[20:58:40] [PASSED] Cannot be interrupted and sleeps
[20:58:40] [PASSED] Cannot be interrupted, locks straight away
[20:58:40] [PASSED] Can be interrupted, sleeps
[20:58:40] ======= [PASSED] ttm_bo_reserve_optimistic_no_ticket =======
[20:58:40] [PASSED] ttm_bo_reserve_locked_no_sleep
[20:58:40] [PASSED] ttm_bo_reserve_no_wait_ticket
[20:58:40] [PASSED] ttm_bo_reserve_double_resv
[20:58:40] [PASSED] ttm_bo_reserve_interrupted
[20:58:40] [PASSED] ttm_bo_reserve_deadlock
[20:58:40] [PASSED] ttm_bo_unreserve_basic
[20:58:40] [PASSED] ttm_bo_unreserve_pinned
[20:58:40] [PASSED] ttm_bo_unreserve_bulk
[20:58:40] [PASSED] ttm_bo_put_basic
[20:58:40] [PASSED] ttm_bo_put_shared_resv
[20:58:40] [PASSED] ttm_bo_pin_basic
[20:58:40] [PASSED] ttm_bo_pin_unpin_resource
[20:58:40] [PASSED] ttm_bo_multiple_pin_one_unpin
[20:58:40] ===================== [PASSED] ttm_bo ======================
[20:58:40] ============== ttm_bo_validate (22 subtests) ===============
[20:58:40] ============== ttm_bo_init_reserved_sys_man ===============
[20:58:40] [PASSED] Buffer object for userspace
[20:58:40] [PASSED] Kernel buffer object
[20:58:40] [PASSED] Shared buffer object
[20:58:40] ========== [PASSED] ttm_bo_init_reserved_sys_man ===========
[20:58:40] ============== ttm_bo_init_reserved_mock_man ==============
[20:58:40] [PASSED] Buffer object for userspace
[20:58:40] [PASSED] Kernel buffer object
[20:58:40] [PASSED] Shared buffer object
[20:58:40] ========== [PASSED] ttm_bo_init_reserved_mock_man ==========
[20:58:40] [PASSED] ttm_bo_init_reserved_resv
[20:58:40] ================== ttm_bo_validate_basic ==================
[20:58:40] [PASSED] Buffer object for userspace
[20:58:40] [PASSED] Kernel buffer object
[20:58:40] [PASSED] Shared buffer object
[20:58:40] ============== [PASSED] ttm_bo_validate_basic ==============
[20:58:40] [PASSED] ttm_bo_validate_invalid_placement
[20:58:40] ============= ttm_bo_validate_same_placement ==============
[20:58:40] [PASSED] System manager
[20:58:40] [PASSED] VRAM manager
[20:58:40] ========= [PASSED] ttm_bo_validate_same_placement ==========
[20:58:40] [PASSED] ttm_bo_validate_failed_alloc
[20:58:40] [PASSED] ttm_bo_validate_pinned
[20:58:40] [PASSED] ttm_bo_validate_busy_placement
[20:58:40] ================ ttm_bo_validate_multihop =================
[20:58:40] [PASSED] Buffer object for userspace
[20:58:40] [PASSED] Kernel buffer object
[20:58:40] [PASSED] Shared buffer object
[20:58:40] ============ [PASSED] ttm_bo_validate_multihop =============
[20:58:40] ========== ttm_bo_validate_no_placement_signaled ==========
[20:58:40] [PASSED] Buffer object in system domain, no page vector
[20:58:40] [PASSED] Buffer object in system domain with an existing page vector
[20:58:40] ====== [PASSED] ttm_bo_validate_no_placement_signaled ======
[20:58:40] ======== ttm_bo_validate_no_placement_not_signaled ========
[20:58:40] [PASSED] Buffer object for userspace
[20:58:40] [PASSED] Kernel buffer object
[20:58:40] [PASSED] Shared buffer object
[20:58:40] ==== [PASSED] ttm_bo_validate_no_placement_not_signaled ====
[20:58:40] [PASSED] ttm_bo_validate_move_fence_signaled
[20:58:40] ========= ttm_bo_validate_move_fence_not_signaled =========
[20:58:40] [PASSED] Waits for GPU
[20:58:40] [PASSED] Tries to lock straight away
[20:58:40] ===== [PASSED] ttm_bo_validate_move_fence_not_signaled =====
[20:58:40] [PASSED] ttm_bo_validate_swapout
[20:58:40] [PASSED] ttm_bo_validate_happy_evict
[20:58:40] [PASSED] ttm_bo_validate_all_pinned_evict
[20:58:40] [PASSED] ttm_bo_validate_allowed_only_evict
[20:58:40] [PASSED] ttm_bo_validate_deleted_evict
[20:58:40] [PASSED] ttm_bo_validate_busy_domain_evict
[20:58:40] [PASSED] ttm_bo_validate_evict_gutting
[20:58:40] [PASSED] ttm_bo_validate_recrusive_evict
stty: 'standard input': Inappropriate ioctl for device
[20:58:40] ================= [PASSED] ttm_bo_validate =================
[20:58:40] ============================================================
[20:58:40] Testing complete. Ran 102 tests: passed: 102
[20:58:41] Elapsed time: 11.383s total, 1.754s configuring, 8.957s building, 0.562s running
+ cleanup
++ stat -c %u:%g /kernel
+ chown -R 1003:1003 /kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* ✓ CI.Build: success for drm/xe/guc: Improve GuC log dumping and add to devcoredump (rev2)
2024-09-05 20:50 [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump John.C.Harrison
` (12 preceding siblings ...)
2024-09-05 20:58 ` ✓ CI.KUnit: success " Patchwork
@ 2024-09-05 21:10 ` Patchwork
2024-09-05 21:13 ` ✓ CI.Hooks: " Patchwork
` (4 subsequent siblings)
18 siblings, 0 replies; 54+ messages in thread
From: Patchwork @ 2024-09-05 21:10 UTC (permalink / raw)
To: john.c.harrison; +Cc: intel-xe
== Series Details ==
Series: drm/xe/guc: Improve GuC log dumping and add to devcoredump (rev2)
URL : https://patchwork.freedesktop.org/series/137985/
State : success
== Summary ==
lib/modules/6.11.0-rc6-xe/kernel/sound/core/seq/
lib/modules/6.11.0-rc6-xe/kernel/sound/core/seq/snd-seq.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/core/snd-seq-device.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/core/snd-hwdep.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/core/snd.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/core/snd-pcm.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/core/snd-compress.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/core/snd-timer.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/soundcore.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/intel/
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/intel/atom/
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/intel/atom/snd-soc-sst-atom-hifi2-platform.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/intel/atom/sst/
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/intel/atom/sst/snd-intel-sst-acpi.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/intel/atom/sst/snd-intel-sst-core.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/intel/common/
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/intel/common/snd-soc-acpi-intel-match.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/amd/
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/amd/snd-acp-config.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/sof/
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/sof/intel/
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/sof/intel/snd-sof-pci-intel-tgl.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/sof/intel/snd-sof-intel-hda-mlink.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/sof/intel/snd-sof-pci-intel-cnl.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/sof/intel/snd-sof-pci-intel-lnl.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/sof/intel/snd-sof-intel-hda-common.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/sof/intel/snd-sof-intel-hda-generic.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/sof/intel/snd-sof-intel-hda.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/sof/intel/snd-sof-pci-intel-mtl.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/sof/amd/
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/sof/amd/snd-sof-amd-renoir.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/sof/amd/snd-sof-amd-acp.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/sof/snd-sof-utils.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/sof/snd-sof-pci.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/sof/snd-sof.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/sof/snd-sof-probes.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/sof/xtensa/
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/sof/xtensa/snd-sof-xtensa-dsp.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/snd-soc-core.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/snd-soc-acpi.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/codecs/
lib/modules/6.11.0-rc6-xe/kernel/sound/soc/codecs/snd-soc-hdac-hda.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/hda/
lib/modules/6.11.0-rc6-xe/kernel/sound/hda/snd-intel-sdw-acpi.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/hda/ext/
lib/modules/6.11.0-rc6-xe/kernel/sound/hda/ext/snd-hda-ext-core.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/hda/snd-intel-dspcfg.ko
lib/modules/6.11.0-rc6-xe/kernel/sound/hda/snd-hda-core.ko
lib/modules/6.11.0-rc6-xe/kernel/arch/
lib/modules/6.11.0-rc6-xe/kernel/arch/x86/
lib/modules/6.11.0-rc6-xe/kernel/arch/x86/kernel/
lib/modules/6.11.0-rc6-xe/kernel/arch/x86/kernel/msr.ko
lib/modules/6.11.0-rc6-xe/kernel/arch/x86/kernel/cpuid.ko
lib/modules/6.11.0-rc6-xe/kernel/arch/x86/crypto/
lib/modules/6.11.0-rc6-xe/kernel/arch/x86/crypto/sha512-ssse3.ko
lib/modules/6.11.0-rc6-xe/kernel/arch/x86/crypto/crct10dif-pclmul.ko
lib/modules/6.11.0-rc6-xe/kernel/arch/x86/crypto/ghash-clmulni-intel.ko
lib/modules/6.11.0-rc6-xe/kernel/arch/x86/crypto/sha1-ssse3.ko
lib/modules/6.11.0-rc6-xe/kernel/arch/x86/crypto/crc32-pclmul.ko
lib/modules/6.11.0-rc6-xe/kernel/arch/x86/crypto/sha256-ssse3.ko
lib/modules/6.11.0-rc6-xe/kernel/arch/x86/crypto/aesni-intel.ko
lib/modules/6.11.0-rc6-xe/kernel/arch/x86/crypto/polyval-clmulni.ko
lib/modules/6.11.0-rc6-xe/kernel/arch/x86/events/
lib/modules/6.11.0-rc6-xe/kernel/arch/x86/events/intel/
lib/modules/6.11.0-rc6-xe/kernel/arch/x86/events/intel/intel-cstate.ko
lib/modules/6.11.0-rc6-xe/kernel/arch/x86/events/rapl.ko
lib/modules/6.11.0-rc6-xe/kernel/arch/x86/kvm/
lib/modules/6.11.0-rc6-xe/kernel/arch/x86/kvm/kvm.ko
lib/modules/6.11.0-rc6-xe/kernel/arch/x86/kvm/kvm-intel.ko
lib/modules/6.11.0-rc6-xe/kernel/crypto/
lib/modules/6.11.0-rc6-xe/kernel/crypto/crypto_simd.ko
lib/modules/6.11.0-rc6-xe/kernel/crypto/cmac.ko
lib/modules/6.11.0-rc6-xe/kernel/crypto/ccm.ko
lib/modules/6.11.0-rc6-xe/kernel/crypto/cryptd.ko
lib/modules/6.11.0-rc6-xe/kernel/crypto/polyval-generic.ko
lib/modules/6.11.0-rc6-xe/kernel/crypto/async_tx/
lib/modules/6.11.0-rc6-xe/kernel/crypto/async_tx/async_xor.ko
lib/modules/6.11.0-rc6-xe/kernel/crypto/async_tx/async_tx.ko
lib/modules/6.11.0-rc6-xe/kernel/crypto/async_tx/async_memcpy.ko
lib/modules/6.11.0-rc6-xe/kernel/crypto/async_tx/async_pq.ko
lib/modules/6.11.0-rc6-xe/kernel/crypto/async_tx/async_raid6_recov.ko
lib/modules/6.11.0-rc6-xe/build
lib/modules/6.11.0-rc6-xe/modules.alias.bin
lib/modules/6.11.0-rc6-xe/modules.builtin
lib/modules/6.11.0-rc6-xe/modules.softdep
lib/modules/6.11.0-rc6-xe/modules.alias
lib/modules/6.11.0-rc6-xe/modules.order
lib/modules/6.11.0-rc6-xe/modules.symbols
lib/modules/6.11.0-rc6-xe/modules.dep.bin
+ mv kernel-nodebug.tar.gz ..
+ cd ..
+ rm -rf archive
++ date +%s
^[[0Ksection_end:1725570631:package_x86_64_nodebug
^[[0K
+ echo -e '\e[0Ksection_end:1725570631:package_x86_64_nodebug\r\e[0K'
+ sync
+ cleanup
++ stat -c %u:%g /kernel
+ chown -R 1003:1003 /kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* ✓ CI.Hooks: success for drm/xe/guc: Improve GuC log dumping and add to devcoredump (rev2)
2024-09-05 20:50 [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump John.C.Harrison
` (13 preceding siblings ...)
2024-09-05 21:10 ` ✓ CI.Build: " Patchwork
@ 2024-09-05 21:13 ` Patchwork
2024-09-05 21:14 ` ✗ CI.checksparse: warning " Patchwork
` (3 subsequent siblings)
18 siblings, 0 replies; 54+ messages in thread
From: Patchwork @ 2024-09-05 21:13 UTC (permalink / raw)
To: john.c.harrison; +Cc: intel-xe
== Series Details ==
Series: drm/xe/guc: Improve GuC log dumping and add to devcoredump (rev2)
URL : https://patchwork.freedesktop.org/series/137985/
State : success
== Summary ==
run-parts: executing /workspace/ci/hooks/00-showenv
+ export
+ grep -Ei '(^|\W)CI_'
declare -x CI_KERNEL_BUILD_DIR="/workspace/kernel/build64-default"
declare -x CI_KERNEL_SRC_DIR="/workspace/kernel"
declare -x CI_TOOLS_SRC_DIR="/workspace/ci"
declare -x CI_WORKSPACE_DIR="/workspace"
run-parts: executing /workspace/ci/hooks/10-build-W1
+ SRC_DIR=/workspace/kernel
+ RESTORE_DISPLAY_CONFIG=0
+ '[' -n /workspace/kernel/build64-default ']'
+ BUILD_DIR=/workspace/kernel/build64-default
+ cd /workspace/kernel
++ nproc
+ make -j48 O=/workspace/kernel/build64-default modules_prepare
make[1]: Entering directory '/workspace/kernel/build64-default'
GEN Makefile
UPD include/generated/compile.h
mkdir -p /workspace/kernel/build64-default/tools/objtool && make O=/workspace/kernel/build64-default subdir=tools/objtool --no-print-directory -C objtool
UPD include/config/kernel.release
UPD include/generated/utsrelease.h
CALL ../scripts/checksyscalls.sh
HOSTCC /workspace/kernel/build64-default/tools/objtool/fixdep.o
HOSTLD /workspace/kernel/build64-default/tools/objtool/fixdep-in.o
LINK /workspace/kernel/build64-default/tools/objtool/fixdep
INSTALL libsubcmd_headers
CC /workspace/kernel/build64-default/tools/objtool/libsubcmd/exec-cmd.o
CC /workspace/kernel/build64-default/tools/objtool/libsubcmd/help.o
CC /workspace/kernel/build64-default/tools/objtool/libsubcmd/pager.o
CC /workspace/kernel/build64-default/tools/objtool/libsubcmd/parse-options.o
CC /workspace/kernel/build64-default/tools/objtool/libsubcmd/run-command.o
CC /workspace/kernel/build64-default/tools/objtool/libsubcmd/subcmd-config.o
CC /workspace/kernel/build64-default/tools/objtool/libsubcmd/sigchain.o
LD /workspace/kernel/build64-default/tools/objtool/libsubcmd/libsubcmd-in.o
AR /workspace/kernel/build64-default/tools/objtool/libsubcmd/libsubcmd.a
CC /workspace/kernel/build64-default/tools/objtool/weak.o
CC /workspace/kernel/build64-default/tools/objtool/check.o
CC /workspace/kernel/build64-default/tools/objtool/special.o
CC /workspace/kernel/build64-default/tools/objtool/builtin-check.o
CC /workspace/kernel/build64-default/tools/objtool/elf.o
CC /workspace/kernel/build64-default/tools/objtool/objtool.o
CC /workspace/kernel/build64-default/tools/objtool/orc_gen.o
CC /workspace/kernel/build64-default/tools/objtool/orc_dump.o
CC /workspace/kernel/build64-default/tools/objtool/libstring.o
CC /workspace/kernel/build64-default/tools/objtool/libctype.o
CC /workspace/kernel/build64-default/tools/objtool/str_error_r.o
CC /workspace/kernel/build64-default/tools/objtool/librbtree.o
CC /workspace/kernel/build64-default/tools/objtool/arch/x86/special.o
CC /workspace/kernel/build64-default/tools/objtool/arch/x86/decode.o
CC /workspace/kernel/build64-default/tools/objtool/arch/x86/orc.o
LD /workspace/kernel/build64-default/tools/objtool/arch/x86/objtool-in.o
LD /workspace/kernel/build64-default/tools/objtool/objtool-in.o
LINK /workspace/kernel/build64-default/tools/objtool/objtool
make[1]: Leaving directory '/workspace/kernel/build64-default'
++ nproc
+ make -j48 O=/workspace/kernel/build64-default W=1 drivers/gpu/drm/xe
make[1]: Entering directory '/workspace/kernel/build64-default'
make[2]: Nothing to be done for 'drivers/gpu/drm/xe'.
make[1]: Leaving directory '/workspace/kernel/build64-default'
run-parts: executing /workspace/ci/hooks/11-build-32b
+++ realpath /workspace/ci/hooks/11-build-32b
++ dirname /workspace/ci/hooks/11-build-32b
+ THIS_SCRIPT_DIR=/workspace/ci/hooks
+ SRC_DIR=/workspace/kernel
+ TOOLS_SRC_DIR=/workspace/ci
+ '[' -n /workspace/kernel/build64-default ']'
+ BUILD_DIR=/workspace/kernel/build64-default
+ BUILD_DIR=/workspace/kernel/build64-default/build32
+ cd /workspace/kernel
+ mkdir -p /workspace/kernel/build64-default/build32
++ nproc
+ make -j48 ARCH=i386 O=/workspace/kernel/build64-default/build32 defconfig
make[1]: Entering directory '/workspace/kernel/build64-default/build32'
GEN Makefile
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/confdata.o
HOSTCC scripts/kconfig/expr.o
LEX scripts/kconfig/lexer.lex.c
YACC scripts/kconfig/parser.tab.[ch]
HOSTCC scripts/kconfig/menu.o
HOSTCC scripts/kconfig/preprocess.o
HOSTCC scripts/kconfig/symbol.o
HOSTCC scripts/kconfig/util.o
HOSTCC scripts/kconfig/lexer.lex.o
HOSTCC scripts/kconfig/parser.tab.o
HOSTLD scripts/kconfig/conf
*** Default configuration is based on 'i386_defconfig'
#
# configuration written to .config
#
make[1]: Leaving directory '/workspace/kernel/build64-default/build32'
+ cd /workspace/kernel/build64-default/build32
+ /workspace/kernel/scripts/kconfig/merge_config.sh .config /workspace/ci/kernel/10-xe.fragment
Using .config as base
Merging /workspace/ci/kernel/10-xe.fragment
Value of CONFIG_DRM_XE is redefined by fragment /workspace/ci/kernel/10-xe.fragment:
Previous value: # CONFIG_DRM_XE is not set
New value: CONFIG_DRM_XE=m
Value of CONFIG_SND_DEBUG is redefined by fragment /workspace/ci/kernel/10-xe.fragment:
Previous value: # CONFIG_SND_DEBUG is not set
New value: CONFIG_SND_DEBUG=y
Value of CONFIG_SND_HDA_INTEL is redefined by fragment /workspace/ci/kernel/10-xe.fragment:
Previous value: CONFIG_SND_HDA_INTEL=y
New value: CONFIG_SND_HDA_INTEL=m
Value of CONFIG_SND_HDA_CODEC_HDMI is redefined by fragment /workspace/ci/kernel/10-xe.fragment:
Previous value: # CONFIG_SND_HDA_CODEC_HDMI is not set
New value: CONFIG_SND_HDA_CODEC_HDMI=m
GEN Makefile
WARNING: unmet direct dependencies detected for FB_IOMEM_HELPERS
Depends on [n]: HAS_IOMEM [=y] && FB_CORE [=n]
Selected by [m]:
- DRM_XE_DISPLAY [=y] && HAS_IOMEM [=y] && DRM [=y] && DRM_XE [=m] && DRM_XE [=m]=m [=m]
#
# configuration written to .config
#
Value requested for CONFIG_HAVE_UID16 not in final .config
Requested value: CONFIG_HAVE_UID16=y
Actual value:
Value requested for CONFIG_UID16 not in final .config
Requested value: CONFIG_UID16=y
Actual value:
Value requested for CONFIG_X86_32 not in final .config
Requested value: CONFIG_X86_32=y
Actual value:
Value requested for CONFIG_OUTPUT_FORMAT not in final .config
Requested value: CONFIG_OUTPUT_FORMAT="elf32-i386"
Actual value: CONFIG_OUTPUT_FORMAT="elf64-x86-64"
Value requested for CONFIG_ARCH_MMAP_RND_BITS_MIN not in final .config
Requested value: CONFIG_ARCH_MMAP_RND_BITS_MIN=8
Actual value: CONFIG_ARCH_MMAP_RND_BITS_MIN=28
Value requested for CONFIG_ARCH_MMAP_RND_BITS_MAX not in final .config
Requested value: CONFIG_ARCH_MMAP_RND_BITS_MAX=16
Actual value: CONFIG_ARCH_MMAP_RND_BITS_MAX=32
Value requested for CONFIG_PGTABLE_LEVELS not in final .config
Requested value: CONFIG_PGTABLE_LEVELS=2
Actual value: CONFIG_PGTABLE_LEVELS=5
Value requested for CONFIG_X86_BIGSMP not in final .config
Requested value: # CONFIG_X86_BIGSMP is not set
Actual value:
Value requested for CONFIG_X86_INTEL_QUARK not in final .config
Requested value: # CONFIG_X86_INTEL_QUARK is not set
Actual value:
Value requested for CONFIG_X86_RDC321X not in final .config
Requested value: # CONFIG_X86_RDC321X is not set
Actual value:
Value requested for CONFIG_X86_32_NON_STANDARD not in final .config
Requested value: # CONFIG_X86_32_NON_STANDARD is not set
Actual value:
Value requested for CONFIG_X86_32_IRIS not in final .config
Requested value: # CONFIG_X86_32_IRIS is not set
Actual value:
Value requested for CONFIG_M486SX not in final .config
Requested value: # CONFIG_M486SX is not set
Actual value:
Value requested for CONFIG_M486 not in final .config
Requested value: # CONFIG_M486 is not set
Actual value:
Value requested for CONFIG_M586 not in final .config
Requested value: # CONFIG_M586 is not set
Actual value:
Value requested for CONFIG_M586TSC not in final .config
Requested value: # CONFIG_M586TSC is not set
Actual value:
Value requested for CONFIG_M586MMX not in final .config
Requested value: # CONFIG_M586MMX is not set
Actual value:
Value requested for CONFIG_M686 not in final .config
Requested value: CONFIG_M686=y
Actual value:
Value requested for CONFIG_MPENTIUMII not in final .config
Requested value: # CONFIG_MPENTIUMII is not set
Actual value:
Value requested for CONFIG_MPENTIUMIII not in final .config
Requested value: # CONFIG_MPENTIUMIII is not set
Actual value:
Value requested for CONFIG_MPENTIUMM not in final .config
Requested value: # CONFIG_MPENTIUMM is not set
Actual value:
Value requested for CONFIG_MPENTIUM4 not in final .config
Requested value: # CONFIG_MPENTIUM4 is not set
Actual value:
Value requested for CONFIG_MK6 not in final .config
Requested value: # CONFIG_MK6 is not set
Actual value:
Value requested for CONFIG_MK7 not in final .config
Requested value: # CONFIG_MK7 is not set
Actual value:
Value requested for CONFIG_MCRUSOE not in final .config
Requested value: # CONFIG_MCRUSOE is not set
Actual value:
Value requested for CONFIG_MEFFICEON not in final .config
Requested value: # CONFIG_MEFFICEON is not set
Actual value:
Value requested for CONFIG_MWINCHIPC6 not in final .config
Requested value: # CONFIG_MWINCHIPC6 is not set
Actual value:
Value requested for CONFIG_MWINCHIP3D not in final .config
Requested value: # CONFIG_MWINCHIP3D is not set
Actual value:
Value requested for CONFIG_MELAN not in final .config
Requested value: # CONFIG_MELAN is not set
Actual value:
Value requested for CONFIG_MGEODEGX1 not in final .config
Requested value: # CONFIG_MGEODEGX1 is not set
Actual value:
Value requested for CONFIG_MGEODE_LX not in final .config
Requested value: # CONFIG_MGEODE_LX is not set
Actual value:
Value requested for CONFIG_MCYRIXIII not in final .config
Requested value: # CONFIG_MCYRIXIII is not set
Actual value:
Value requested for CONFIG_MVIAC3_2 not in final .config
Requested value: # CONFIG_MVIAC3_2 is not set
Actual value:
Value requested for CONFIG_MVIAC7 not in final .config
Requested value: # CONFIG_MVIAC7 is not set
Actual value:
Value requested for CONFIG_X86_GENERIC not in final .config
Requested value: # CONFIG_X86_GENERIC is not set
Actual value:
Value requested for CONFIG_X86_INTERNODE_CACHE_SHIFT not in final .config
Requested value: CONFIG_X86_INTERNODE_CACHE_SHIFT=5
Actual value: CONFIG_X86_INTERNODE_CACHE_SHIFT=6
Value requested for CONFIG_X86_L1_CACHE_SHIFT not in final .config
Requested value: CONFIG_X86_L1_CACHE_SHIFT=5
Actual value: CONFIG_X86_L1_CACHE_SHIFT=6
Value requested for CONFIG_X86_USE_PPRO_CHECKSUM not in final .config
Requested value: CONFIG_X86_USE_PPRO_CHECKSUM=y
Actual value:
Value requested for CONFIG_X86_MINIMUM_CPU_FAMILY not in final .config
Requested value: CONFIG_X86_MINIMUM_CPU_FAMILY=6
Actual value: CONFIG_X86_MINIMUM_CPU_FAMILY=64
Value requested for CONFIG_CPU_SUP_TRANSMETA_32 not in final .config
Requested value: CONFIG_CPU_SUP_TRANSMETA_32=y
Actual value:
Value requested for CONFIG_CPU_SUP_VORTEX_32 not in final .config
Requested value: CONFIG_CPU_SUP_VORTEX_32=y
Actual value:
Value requested for CONFIG_HPET_TIMER not in final .config
Requested value: # CONFIG_HPET_TIMER is not set
Actual value: CONFIG_HPET_TIMER=y
Value requested for CONFIG_NR_CPUS_RANGE_END not in final .config
Requested value: CONFIG_NR_CPUS_RANGE_END=8
Actual value: CONFIG_NR_CPUS_RANGE_END=512
Value requested for CONFIG_NR_CPUS_DEFAULT not in final .config
Requested value: CONFIG_NR_CPUS_DEFAULT=8
Actual value: CONFIG_NR_CPUS_DEFAULT=64
Value requested for CONFIG_X86_ANCIENT_MCE not in final .config
Requested value: # CONFIG_X86_ANCIENT_MCE is not set
Actual value:
Value requested for CONFIG_X86_LEGACY_VM86 not in final .config
Requested value: # CONFIG_X86_LEGACY_VM86 is not set
Actual value:
Value requested for CONFIG_X86_ESPFIX32 not in final .config
Requested value: CONFIG_X86_ESPFIX32=y
Actual value:
Value requested for CONFIG_TOSHIBA not in final .config
Requested value: # CONFIG_TOSHIBA is not set
Actual value:
Value requested for CONFIG_X86_REBOOTFIXUPS not in final .config
Requested value: # CONFIG_X86_REBOOTFIXUPS is not set
Actual value:
Value requested for CONFIG_MICROCODE_INITRD32 not in final .config
Requested value: CONFIG_MICROCODE_INITRD32=y
Actual value:
Value requested for CONFIG_NOHIGHMEM not in final .config
Requested value: # CONFIG_NOHIGHMEM is not set
Actual value:
Value requested for CONFIG_HIGHMEM4G not in final .config
Requested value: CONFIG_HIGHMEM4G=y
Actual value:
Value requested for CONFIG_HIGHMEM64G not in final .config
Requested value: # CONFIG_HIGHMEM64G is not set
Actual value:
Value requested for CONFIG_VMSPLIT_3G not in final .config
Requested value: CONFIG_VMSPLIT_3G=y
Actual value:
Value requested for CONFIG_VMSPLIT_3G_OPT not in final .config
Requested value: # CONFIG_VMSPLIT_3G_OPT is not set
Actual value:
Value requested for CONFIG_VMSPLIT_2G not in final .config
Requested value: # CONFIG_VMSPLIT_2G is not set
Actual value:
Value requested for CONFIG_VMSPLIT_2G_OPT not in final .config
Requested value: # CONFIG_VMSPLIT_2G_OPT is not set
Actual value:
Value requested for CONFIG_VMSPLIT_1G not in final .config
Requested value: # CONFIG_VMSPLIT_1G is not set
Actual value:
Value requested for CONFIG_PAGE_OFFSET not in final .config
Requested value: CONFIG_PAGE_OFFSET=0xC0000000
Actual value:
Value requested for CONFIG_HIGHMEM not in final .config
Requested value: CONFIG_HIGHMEM=y
Actual value:
Value requested for CONFIG_X86_PAE not in final .config
Requested value: # CONFIG_X86_PAE is not set
Actual value:
Value requested for CONFIG_ARCH_FLATMEM_ENABLE not in final .config
Requested value: CONFIG_ARCH_FLATMEM_ENABLE=y
Actual value:
Value requested for CONFIG_ARCH_SELECT_MEMORY_MODEL not in final .config
Requested value: CONFIG_ARCH_SELECT_MEMORY_MODEL=y
Actual value:
Value requested for CONFIG_ILLEGAL_POINTER_VALUE not in final .config
Requested value: CONFIG_ILLEGAL_POINTER_VALUE=0
Actual value: CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
Value requested for CONFIG_HIGHPTE not in final .config
Requested value: # CONFIG_HIGHPTE is not set
Actual value:
Value requested for CONFIG_COMPAT_VDSO not in final .config
Requested value: # CONFIG_COMPAT_VDSO is not set
Actual value:
Value requested for CONFIG_FUNCTION_PADDING_CFI not in final .config
Requested value: CONFIG_FUNCTION_PADDING_CFI=0
Actual value: CONFIG_FUNCTION_PADDING_CFI=11
Value requested for CONFIG_FUNCTION_PADDING_BYTES not in final .config
Requested value: CONFIG_FUNCTION_PADDING_BYTES=4
Actual value: CONFIG_FUNCTION_PADDING_BYTES=16
Value requested for CONFIG_APM not in final .config
Requested value: # CONFIG_APM is not set
Actual value:
Value requested for CONFIG_X86_POWERNOW_K6 not in final .config
Requested value: # CONFIG_X86_POWERNOW_K6 is not set
Actual value:
Value requested for CONFIG_X86_POWERNOW_K7 not in final .config
Requested value: # CONFIG_X86_POWERNOW_K7 is not set
Actual value:
Value requested for CONFIG_X86_GX_SUSPMOD not in final .config
Requested value: # CONFIG_X86_GX_SUSPMOD is not set
Actual value:
Value requested for CONFIG_X86_SPEEDSTEP_ICH not in final .config
Requested value: # CONFIG_X86_SPEEDSTEP_ICH is not set
Actual value:
Value requested for CONFIG_X86_SPEEDSTEP_SMI not in final .config
Requested value: # CONFIG_X86_SPEEDSTEP_SMI is not set
Actual value:
Value requested for CONFIG_X86_CPUFREQ_NFORCE2 not in final .config
Requested value: # CONFIG_X86_CPUFREQ_NFORCE2 is not set
Actual value:
Value requested for CONFIG_X86_LONGRUN not in final .config
Requested value: # CONFIG_X86_LONGRUN is not set
Actual value:
Value requested for CONFIG_X86_LONGHAUL not in final .config
Requested value: # CONFIG_X86_LONGHAUL is not set
Actual value:
Value requested for CONFIG_X86_E_POWERSAVER not in final .config
Requested value: # CONFIG_X86_E_POWERSAVER is not set
Actual value:
Value requested for CONFIG_PCI_GOBIOS not in final .config
Requested value: # CONFIG_PCI_GOBIOS is not set
Actual value:
Value requested for CONFIG_PCI_GOMMCONFIG not in final .config
Requested value: # CONFIG_PCI_GOMMCONFIG is not set
Actual value:
Value requested for CONFIG_PCI_GODIRECT not in final .config
Requested value: # CONFIG_PCI_GODIRECT is not set
Actual value:
Value requested for CONFIG_PCI_GOANY not in final .config
Requested value: CONFIG_PCI_GOANY=y
Actual value:
Value requested for CONFIG_PCI_BIOS not in final .config
Requested value: CONFIG_PCI_BIOS=y
Actual value:
Value requested for CONFIG_ISA not in final .config
Requested value: # CONFIG_ISA is not set
Actual value:
Value requested for CONFIG_SCx200 not in final .config
Requested value: # CONFIG_SCx200 is not set
Actual value:
Value requested for CONFIG_OLPC not in final .config
Requested value: # CONFIG_OLPC is not set
Actual value:
Value requested for CONFIG_ALIX not in final .config
Requested value: # CONFIG_ALIX is not set
Actual value:
Value requested for CONFIG_NET5501 not in final .config
Requested value: # CONFIG_NET5501 is not set
Actual value:
Value requested for CONFIG_GEOS not in final .config
Requested value: # CONFIG_GEOS is not set
Actual value:
Value requested for CONFIG_COMPAT_32 not in final .config
Requested value: CONFIG_COMPAT_32=y
Actual value:
Value requested for CONFIG_HAVE_ATOMIC_IOMAP not in final .config
Requested value: CONFIG_HAVE_ATOMIC_IOMAP=y
Actual value:
Value requested for CONFIG_ARCH_32BIT_OFF_T not in final .config
Requested value: CONFIG_ARCH_32BIT_OFF_T=y
Actual value:
Value requested for CONFIG_ARCH_WANT_IPC_PARSE_VERSION not in final .config
Requested value: CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
Actual value:
Value requested for CONFIG_MODULES_USE_ELF_REL not in final .config
Requested value: CONFIG_MODULES_USE_ELF_REL=y
Actual value:
Value requested for CONFIG_ARCH_MMAP_RND_BITS not in final .config
Requested value: CONFIG_ARCH_MMAP_RND_BITS=8
Actual value: CONFIG_ARCH_MMAP_RND_BITS=28
Value requested for CONFIG_CLONE_BACKWARDS not in final .config
Requested value: CONFIG_CLONE_BACKWARDS=y
Actual value:
Value requested for CONFIG_OLD_SIGSUSPEND3 not in final .config
Requested value: CONFIG_OLD_SIGSUSPEND3=y
Actual value:
Value requested for CONFIG_OLD_SIGACTION not in final .config
Requested value: CONFIG_OLD_SIGACTION=y
Actual value:
Value requested for CONFIG_ARCH_SPLIT_ARG64 not in final .config
Requested value: CONFIG_ARCH_SPLIT_ARG64=y
Actual value:
Value requested for CONFIG_FUNCTION_ALIGNMENT not in final .config
Requested value: CONFIG_FUNCTION_ALIGNMENT=4
Actual value: CONFIG_FUNCTION_ALIGNMENT=16
Value requested for CONFIG_SELECT_MEMORY_MODEL not in final .config
Requested value: CONFIG_SELECT_MEMORY_MODEL=y
Actual value:
Value requested for CONFIG_FLATMEM_MANUAL not in final .config
Requested value: CONFIG_FLATMEM_MANUAL=y
Actual value:
Value requested for CONFIG_SPARSEMEM_MANUAL not in final .config
Requested value: # CONFIG_SPARSEMEM_MANUAL is not set
Actual value:
Value requested for CONFIG_FLATMEM not in final .config
Requested value: CONFIG_FLATMEM=y
Actual value:
Value requested for CONFIG_SPARSEMEM_STATIC not in final .config
Requested value: CONFIG_SPARSEMEM_STATIC=y
Actual value:
Value requested for CONFIG_BOUNCE not in final .config
Requested value: CONFIG_BOUNCE=y
Actual value:
Value requested for CONFIG_KMAP_LOCAL not in final .config
Requested value: CONFIG_KMAP_LOCAL=y
Actual value:
Value requested for CONFIG_HOTPLUG_PCI_COMPAQ not in final .config
Requested value: # CONFIG_HOTPLUG_PCI_COMPAQ is not set
Actual value:
Value requested for CONFIG_HOTPLUG_PCI_IBM not in final .config
Requested value: # CONFIG_HOTPLUG_PCI_IBM is not set
Actual value:
Value requested for CONFIG_EFI_CAPSULE_QUIRK_QUARK_CSH not in final .config
Requested value: CONFIG_EFI_CAPSULE_QUIRK_QUARK_CSH=y
Actual value:
Value requested for CONFIG_PCH_PHUB not in final .config
Requested value: # CONFIG_PCH_PHUB is not set
Actual value:
Value requested for CONFIG_SCSI_NSP32 not in final .config
Requested value: # CONFIG_SCSI_NSP32 is not set
Actual value:
Value requested for CONFIG_PATA_CS5520 not in final .config
Requested value: # CONFIG_PATA_CS5520 is not set
Actual value:
Value requested for CONFIG_PATA_CS5530 not in final .config
Requested value: # CONFIG_PATA_CS5530 is not set
Actual value:
Value requested for CONFIG_PATA_CS5535 not in final .config
Requested value: # CONFIG_PATA_CS5535 is not set
Actual value:
Value requested for CONFIG_PATA_CS5536 not in final .config
Requested value: # CONFIG_PATA_CS5536 is not set
Actual value:
Value requested for CONFIG_PATA_SC1200 not in final .config
Requested value: # CONFIG_PATA_SC1200 is not set
Actual value:
Value requested for CONFIG_PCH_GBE not in final .config
Requested value: # CONFIG_PCH_GBE is not set
Actual value:
Value requested for CONFIG_INPUT_WISTRON_BTNS not in final .config
Requested value: # CONFIG_INPUT_WISTRON_BTNS is not set
Actual value:
Value requested for CONFIG_SERIAL_TIMBERDALE not in final .config
Requested value: # CONFIG_SERIAL_TIMBERDALE is not set
Actual value:
Value requested for CONFIG_SERIAL_PCH_UART not in final .config
Requested value: # CONFIG_SERIAL_PCH_UART is not set
Actual value:
Value requested for CONFIG_HW_RANDOM_GEODE not in final .config
Requested value: CONFIG_HW_RANDOM_GEODE=y
Actual value:
Value requested for CONFIG_SONYPI not in final .config
Requested value: # CONFIG_SONYPI is not set
Actual value:
Value requested for CONFIG_PC8736x_GPIO not in final .config
Requested value: # CONFIG_PC8736x_GPIO is not set
Actual value:
Value requested for CONFIG_NSC_GPIO not in final .config
Requested value: # CONFIG_NSC_GPIO is not set
Actual value:
Value requested for CONFIG_I2C_EG20T not in final .config
Requested value: # CONFIG_I2C_EG20T is not set
Actual value:
Value requested for CONFIG_SCx200_ACB not in final .config
Requested value: # CONFIG_SCx200_ACB is not set
Actual value:
Value requested for CONFIG_PTP_1588_CLOCK_PCH not in final .config
Requested value: # CONFIG_PTP_1588_CLOCK_PCH is not set
Actual value:
Value requested for CONFIG_SBC8360_WDT not in final .config
Requested value: # CONFIG_SBC8360_WDT is not set
Actual value:
Value requested for CONFIG_SBC7240_WDT not in final .config
Requested value: # CONFIG_SBC7240_WDT is not set
Actual value:
Value requested for CONFIG_MFD_CS5535 not in final .config
Requested value: # CONFIG_MFD_CS5535 is not set
Actual value:
Value requested for CONFIG_AGP_ALI not in final .config
Requested value: # CONFIG_AGP_ALI is not set
Actual value:
Value requested for CONFIG_AGP_ATI not in final .config
Requested value: # CONFIG_AGP_ATI is not set
Actual value:
Value requested for CONFIG_AGP_AMD not in final .config
Requested value: # CONFIG_AGP_AMD is not set
Actual value:
Value requested for CONFIG_AGP_NVIDIA not in final .config
Requested value: # CONFIG_AGP_NVIDIA is not set
Actual value:
Value requested for CONFIG_AGP_SWORKS not in final .config
Requested value: # CONFIG_AGP_SWORKS is not set
Actual value:
Value requested for CONFIG_AGP_EFFICEON not in final .config
Requested value: # CONFIG_AGP_EFFICEON is not set
Actual value:
Value requested for CONFIG_SND_PCM not in final .config
Requested value: CONFIG_SND_PCM=y
Actual value: CONFIG_SND_PCM=m
Value requested for CONFIG_SND_HWDEP not in final .config
Requested value: CONFIG_SND_HWDEP=y
Actual value: CONFIG_SND_HWDEP=m
Value requested for CONFIG_SND_DYNAMIC_MINORS not in final .config
Requested value: # CONFIG_SND_DYNAMIC_MINORS is not set
Actual value: CONFIG_SND_DYNAMIC_MINORS=y
Value requested for CONFIG_SND_CS5530 not in final .config
Requested value: # CONFIG_SND_CS5530 is not set
Actual value:
Value requested for CONFIG_SND_CS5535AUDIO not in final .config
Requested value: # CONFIG_SND_CS5535AUDIO is not set
Actual value:
Value requested for CONFIG_SND_SIS7019 not in final .config
Requested value: # CONFIG_SND_SIS7019 is not set
Actual value:
Value requested for CONFIG_SND_HDA not in final .config
Requested value: CONFIG_SND_HDA=y
Actual value: CONFIG_SND_HDA=m
Value requested for CONFIG_SND_HDA_CORE not in final .config
Requested value: CONFIG_SND_HDA_CORE=y
Actual value: CONFIG_SND_HDA_CORE=m
Value requested for CONFIG_SND_INTEL_DSP_CONFIG not in final .config
Requested value: CONFIG_SND_INTEL_DSP_CONFIG=y
Actual value: CONFIG_SND_INTEL_DSP_CONFIG=m
Value requested for CONFIG_SND_INTEL_SOUNDWIRE_ACPI not in final .config
Requested value: CONFIG_SND_INTEL_SOUNDWIRE_ACPI=y
Actual value: CONFIG_SND_INTEL_SOUNDWIRE_ACPI=m
Value requested for CONFIG_LEDS_OT200 not in final .config
Requested value: # CONFIG_LEDS_OT200 is not set
Actual value:
Value requested for CONFIG_PCH_DMA not in final .config
Requested value: # CONFIG_PCH_DMA is not set
Actual value:
Value requested for CONFIG_CLKSRC_I8253 not in final .config
Requested value: CONFIG_CLKSRC_I8253=y
Actual value:
Value requested for CONFIG_MAILBOX not in final .config
Requested value: # CONFIG_MAILBOX is not set
Actual value: CONFIG_MAILBOX=y
Value requested for CONFIG_CRYPTO_SERPENT_SSE2_586 not in final .config
Requested value: # CONFIG_CRYPTO_SERPENT_SSE2_586 is not set
Actual value:
Value requested for CONFIG_CRYPTO_TWOFISH_586 not in final .config
Requested value: # CONFIG_CRYPTO_TWOFISH_586 is not set
Actual value:
Value requested for CONFIG_CRYPTO_DEV_GEODE not in final .config
Requested value: # CONFIG_CRYPTO_DEV_GEODE is not set
Actual value:
Value requested for CONFIG_CRYPTO_DEV_HIFN_795X not in final .config
Requested value: # CONFIG_CRYPTO_DEV_HIFN_795X is not set
Actual value:
Value requested for CONFIG_CRYPTO_LIB_POLY1305_RSIZE not in final .config
Requested value: CONFIG_CRYPTO_LIB_POLY1305_RSIZE=1
Actual value: CONFIG_CRYPTO_LIB_POLY1305_RSIZE=11
Value requested for CONFIG_AUDIT_GENERIC not in final .config
Requested value: CONFIG_AUDIT_GENERIC=y
Actual value:
Value requested for CONFIG_GENERIC_VDSO_32 not in final .config
Requested value: CONFIG_GENERIC_VDSO_32=y
Actual value:
Value requested for CONFIG_DEBUG_KMAP_LOCAL not in final .config
Requested value: # CONFIG_DEBUG_KMAP_LOCAL is not set
Actual value:
Value requested for CONFIG_DEBUG_HIGHMEM not in final .config
Requested value: # CONFIG_DEBUG_HIGHMEM is not set
Actual value:
Value requested for CONFIG_HAVE_DEBUG_STACKOVERFLOW not in final .config
Requested value: CONFIG_HAVE_DEBUG_STACKOVERFLOW=y
Actual value:
Value requested for CONFIG_DEBUG_STACKOVERFLOW not in final .config
Requested value: # CONFIG_DEBUG_STACKOVERFLOW is not set
Actual value:
Value requested for CONFIG_HAVE_FUNCTION_GRAPH_TRACER not in final .config
Requested value: CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
Actual value:
Value requested for CONFIG_HAVE_FUNCTION_GRAPH_RETVAL not in final .config
Requested value: CONFIG_HAVE_FUNCTION_GRAPH_RETVAL=y
Actual value:
Value requested for CONFIG_DRM_KUNIT_TEST not in final .config
Requested value: CONFIG_DRM_KUNIT_TEST=m
Actual value:
Value requested for CONFIG_DRM_XE_WERROR not in final .config
Requested value: CONFIG_DRM_XE_WERROR=y
Actual value:
Value requested for CONFIG_DRM_XE_DEBUG not in final .config
Requested value: CONFIG_DRM_XE_DEBUG=y
Actual value:
Value requested for CONFIG_DRM_XE_DEBUG_MEM not in final .config
Requested value: CONFIG_DRM_XE_DEBUG_MEM=y
Actual value:
Value requested for CONFIG_DRM_XE_KUNIT_TEST not in final .config
Requested value: CONFIG_DRM_XE_KUNIT_TEST=m
Actual value:
++ nproc
+ make -j48 ARCH=i386 olddefconfig
GEN Makefile
WARNING: unmet direct dependencies detected for FB_IOMEM_HELPERS
Depends on [n]: HAS_IOMEM [=y] && FB_CORE [=n]
Selected by [m]:
- DRM_XE_DISPLAY [=y] && HAS_IOMEM [=y] && DRM [=y] && DRM_XE [=m] && DRM_XE [=m]=m [=m]
#
# configuration written to .config
#
++ nproc
+ make -j48 ARCH=i386
SYNC include/config/auto.conf.cmd
GEN Makefile
WARNING: unmet direct dependencies detected for FB_IOMEM_HELPERS
Depends on [n]: HAS_IOMEM [=y] && FB_CORE [=n]
Selected by [m]:
- DRM_XE_DISPLAY [=y] && HAS_IOMEM [=y] && DRM [=y] && DRM_XE [=m] && DRM_XE [=m]=m [=m]
WARNING: unmet direct dependencies detected for FB_IOMEM_HELPERS
Depends on [n]: HAS_IOMEM [=y] && FB_CORE [=n]
Selected by [m]:
- DRM_XE_DISPLAY [=y] && HAS_IOMEM [=y] && DRM [=y] && DRM_XE [=m] && DRM_XE [=m]=m [=m]
WARNING: unmet direct dependencies detected for FB_IOMEM_HELPERS
Depends on [n]: HAS_IOMEM [=y] && FB_CORE [=n]
Selected by [m]:
- DRM_XE_DISPLAY [=y] && HAS_IOMEM [=y] && DRM [=y] && DRM_XE [=m] && DRM_XE [=m]=m [=m]
GEN Makefile
UPD include/generated/uapi/linux/version.h
WRAP arch/x86/include/generated/uapi/asm/bpf_perf_event.h
WRAP arch/x86/include/generated/uapi/asm/errno.h
WRAP arch/x86/include/generated/uapi/asm/fcntl.h
WRAP arch/x86/include/generated/uapi/asm/ioctl.h
WRAP arch/x86/include/generated/uapi/asm/ioctls.h
WRAP arch/x86/include/generated/uapi/asm/ipcbuf.h
WRAP arch/x86/include/generated/uapi/asm/param.h
WRAP arch/x86/include/generated/uapi/asm/poll.h
WRAP arch/x86/include/generated/uapi/asm/resource.h
WRAP arch/x86/include/generated/uapi/asm/socket.h
WRAP arch/x86/include/generated/uapi/asm/sockios.h
WRAP arch/x86/include/generated/uapi/asm/termbits.h
WRAP arch/x86/include/generated/uapi/asm/termios.h
WRAP arch/x86/include/generated/uapi/asm/types.h
SYSHDR arch/x86/include/generated/uapi/asm/unistd_32.h
SYSHDR arch/x86/include/generated/uapi/asm/unistd_x32.h
SYSHDR arch/x86/include/generated/uapi/asm/unistd_64.h
SYSTBL arch/x86/include/generated/asm/syscalls_32.h
UPD include/generated/compile.h
WRAP arch/x86/include/generated/asm/early_ioremap.h
WRAP arch/x86/include/generated/asm/mcs_spinlock.h
WRAP arch/x86/include/generated/asm/irq_regs.h
HOSTCC arch/x86/tools/relocs_32.o
WRAP arch/x86/include/generated/asm/kmap_size.h
WRAP arch/x86/include/generated/asm/local64.h
HOSTCC arch/x86/tools/relocs_64.o
WRAP arch/x86/include/generated/asm/mmiowb.h
WRAP arch/x86/include/generated/asm/module.lds.h
HOSTCC arch/x86/tools/relocs_common.o
WRAP arch/x86/include/generated/asm/rwonce.h
WRAP arch/x86/include/generated/asm/unaligned.h
HOSTCC scripts/kallsyms
HOSTCC scripts/sorttable
HOSTCC scripts/asn1_compiler
HOSTCC scripts/selinux/genheaders/genheaders
HOSTCC scripts/selinux/mdp/mdp
HOSTLD arch/x86/tools/relocs
UPD include/config/kernel.release
UPD include/generated/utsrelease.h
CC scripts/mod/empty.o
HOSTCC scripts/mod/mk_elfconfig
CC scripts/mod/devicetable-offsets.s
UPD scripts/mod/devicetable-offsets.h
MKELF scripts/mod/elfconfig.h
HOSTCC scripts/mod/modpost.o
HOSTCC scripts/mod/file2alias.o
HOSTCC scripts/mod/sumversion.o
HOSTCC scripts/mod/symsearch.o
HOSTLD scripts/mod/modpost
CC kernel/bounds.s
CHKSHA1 /workspace/kernel/include/linux/atomic/atomic-arch-fallback.h
CHKSHA1 /workspace/kernel/include/linux/atomic/atomic-instrumented.h
CHKSHA1 /workspace/kernel/include/linux/atomic/atomic-long.h
UPD include/generated/timeconst.h
UPD include/generated/bounds.h
CC arch/x86/kernel/asm-offsets.s
UPD include/generated/asm-offsets.h
CALL /workspace/kernel/scripts/checksyscalls.sh
LDS scripts/module.lds
CC ipc/util.o
CC ipc/msgutil.o
CC ipc/msg.o
HOSTCC usr/gen_init_cpio
CC ipc/sem.o
CC init/main.o
CC ipc/shm.o
CC ipc/syscall.o
CC certs/system_keyring.o
UPD init/utsversion-tmp.h
CC arch/x86/power/cpu.o
CC ipc/ipc_sysctl.o
AS arch/x86/lib/atomic64_cx8_32.o
CC security/commoncap.o
CC init/do_mounts.o
CC arch/x86/pci/i386.o
CC ipc/mqueue.o
CC arch/x86/video/video-common.o
AS arch/x86/lib/checksum_32.o
CC arch/x86/power/hibernate_32.o
CC security/lsm_syscalls.o
CC arch/x86/pci/init.o
CC mm/filemap.o
CC init/do_mounts_initrd.o
CC io_uring/io_uring.o
CC block/bdev.o
AS arch/x86/power/hibernate_asm_32.o
CC block/partitions/core.o
GEN security/selinux/flask.h security/selinux/av_permissions.h
AR drivers/cache/built-in.a
AR arch/x86/net/built-in.a
CC arch/x86/realmode/init.o
CC security/keys/gc.o
AR arch/x86/crypto/built-in.a
CC security/integrity/iint.o
AR virt/lib/built-in.a
CC arch/x86/events/amd/core.o
CC net/core/sock.o
CC fs/notify/dnotify/dnotify.o
CC lib/math/div64.o
CC security/selinux/avc.o
CC arch/x86/mm/pat/set_memory.o
CC net/core/request_sock.o
CC arch/x86/kernel/fpu/init.o
CC io_uring/opdef.o
CC sound/core/seq/seq.o
AR arch/x86/platform/atom/built-in.a
AR sound/i2c/other/built-in.a
AR virt/built-in.a
CC arch/x86/kernel/fpu/bugs.o
AR drivers/irqchip/built-in.a
AR sound/drivers/opl3/built-in.a
CC arch/x86/lib/cmdline.o
CC arch/x86/entry/vdso/vma.o
AS arch/x86/realmode/rm/header.o
CC arch/x86/platform/efi/memmap.o
AR sound/i2c/built-in.a
AR arch/x86/platform/ce4100/built-in.a
AR sound/drivers/opl4/built-in.a
AR drivers/bus/mhi/built-in.a
AR sound/drivers/mpu401/built-in.a
CC kernel/sched/core.o
CC lib/math/gcd.o
HOSTCC certs/extract-cert
AR drivers/bus/built-in.a
AS arch/x86/realmode/rm/trampoline_32.o
AR sound/drivers/vx/built-in.a
AR sound/drivers/pcsp/built-in.a
AS arch/x86/realmode/rm/stack.o
AR drivers/pwm/built-in.a
AR sound/drivers/built-in.a
CC crypto/asymmetric_keys/asymmetric_type.o
CC drivers/pci/msi/pcidev_msi.o
CC security/selinux/hooks.o
AS arch/x86/realmode/rm/reboot.o
CC security/selinux/selinuxfs.o
CC security/keys/key.o
AS arch/x86/lib/cmpxchg8b_emu.o
AS arch/x86/realmode/rm/wakeup_asm.o
CC lib/math/lcm.o
CC arch/x86/lib/cpu.o
CC arch/x86/realmode/rm/wakemain.o
CC lib/math/int_log.o
CC arch/x86/realmode/rm/video-mode.o
GEN usr/initramfs_data.cpio
CC lib/math/int_pow.o
CC arch/x86/kernel/fpu/core.o
COPY usr/initramfs_inc_data
AS usr/initramfs_data.o
CC crypto/asymmetric_keys/restrict.o
AR usr/built-in.a
CC arch/x86/pci/pcbios.o
CERT certs/x509_certificate_list
CC lib/math/int_sqrt.o
CERT certs/signing_key.x509
AS certs/system_certificates.o
AS arch/x86/realmode/rm/copy.o
AR certs/built-in.a
AS arch/x86/realmode/rm/bioscall.o
CC arch/x86/lib/delay.o
CC lib/math/reciprocal_div.o
CC arch/x86/realmode/rm/regs.o
CC ipc/namespace.o
CC arch/x86/realmode/rm/video-vga.o
CC lib/math/rational.o
CC arch/x86/realmode/rm/video-vesa.o
CC sound/core/seq/seq_lock.o
AR arch/x86/video/built-in.a
CC arch/x86/realmode/rm/video-bios.o
CC drivers/pci/msi/api.o
AS arch/x86/lib/getuser.o
CC net/ethernet/eth.o
CC drivers/pci/msi/msi.o
CC security/integrity/integrity_audit.o
CC security/keys/keyring.o
CC crypto/asymmetric_keys/signature.o
PASYMS arch/x86/realmode/rm/pasyms.h
LDS arch/x86/realmode/rm/realmode.lds
CC kernel/locking/mutex.o
CC arch/x86/power/hibernate.o
CC arch/x86/platform/efi/quirks.o
CC kernel/power/qos.o
LD arch/x86/realmode/rm/realmode.elf
CC crypto/asymmetric_keys/public_key.o
RELOCS arch/x86/realmode/rm/realmode.relocs
OBJCOPY arch/x86/realmode/rm/realmode.bin
GEN arch/x86/lib/inat-tables.c
AS arch/x86/realmode/rmpiggy.o
ASN.1 crypto/asymmetric_keys/x509.asn1.[ch]
CC arch/x86/entry/vdso/extable.o
CC kernel/locking/semaphore.o
AR arch/x86/realmode/built-in.a
CC arch/x86/kernel/fpu/regset.o
LDS arch/x86/entry/vdso/vdso32/vdso32.lds
AR net/802/built-in.a
ASN.1 crypto/asymmetric_keys/x509_akid.asn1.[ch]
CC block/fops.o
CC block/bio.o
CC arch/x86/lib/insn-eval.o
CC net/sched/sch_generic.o
AR fs/notify/dnotify/built-in.a
CC block/partitions/msdos.o
CC fs/notify/inotify/inotify_fsnotify.o
CC net/netlink/af_netlink.o
CC block/partitions/efi.o
CC net/netlink/genetlink.o
AR lib/math/built-in.a
CC fs/notify/inotify/inotify_user.o
CC lib/crypto/mpi/generic_mpih-lshift.o
CC sound/core/seq/seq_clientmgr.o
CC lib/crypto/mpi/generic_mpih-mul1.o
CC lib/crypto/memneq.o
CC arch/x86/events/intel/core.o
CC arch/x86/pci/mmconfig_32.o
CC lib/crypto/utils.o
CC arch/x86/events/intel/bts.o
CC arch/x86/events/amd/lbr.o
CC arch/x86/mm/pat/memtype.o
CC kernel/sched/fair.o
CC net/sched/sch_mq.o
CC security/keys/keyctl.o
CC lib/zlib_inflate/inffast.o
CC crypto/asymmetric_keys/x509_loader.o
CC lib/zlib_inflate/inflate.o
AR security/integrity/built-in.a
AR arch/x86/power/built-in.a
CC security/keys/permission.o
CC security/min_addr.o
CC init/initramfs.o
CC mm/mempool.o
CC mm/oom_kill.o
CC drivers/pci/msi/irqdomain.o
CC arch/x86/kernel/fpu/signal.o
CC mm/fadvise.o
CC kernel/sched/build_policy.o
CC lib/zlib_deflate/deflate.o
AS arch/x86/entry/vdso/vdso32/note.o
CC crypto/asymmetric_keys/x509_public_key.o
CC lib/zlib_deflate/deftree.o
AS arch/x86/entry/vdso/vdso32/system_call.o
CC lib/zlib_deflate/deflate_syms.o
CC lib/crypto/mpi/generic_mpih-mul2.o
AS arch/x86/entry/vdso/vdso32/sigreturn.o
CC crypto/api.o
CC lib/zlib_inflate/infutil.o
CC arch/x86/entry/vdso/vdso32/vclock_gettime.o
CC ipc/mq_sysctl.o
CC arch/x86/lib/insn.o
CC arch/x86/platform/efi/efi.o
CC arch/x86/pci/direct.o
CC arch/x86/pci/mmconfig-shared.o
AR block/partitions/built-in.a
CC crypto/cipher.o
CC arch/x86/platform/efi/efi_32.o
AR fs/notify/inotify/built-in.a
AR fs/notify/fanotify/built-in.a
CC kernel/locking/rwsem.o
CC fs/notify/fsnotify.o
AR net/ethernet/built-in.a
ASN.1 crypto/asymmetric_keys/pkcs7.asn1.[ch]
AS arch/x86/platform/efi/efi_stub_32.o
CC lib/lzo/lzo1x_compress.o
AR net/bpf/built-in.a
CC kernel/power/main.o
CC kernel/power/console.o
CC crypto/asymmetric_keys/pkcs7_trust.o
CC net/ethtool/ioctl.o
CC arch/x86/events/amd/ibs.o
CC arch/x86/events/amd/uncore.o
CC arch/x86/lib/kaslr.o
CC lib/zlib_inflate/inftrees.o
CC arch/x86/platform/efi/runtime-map.o
CC arch/x86/mm/pat/memtype_interval.o
AR ipc/built-in.a
CC arch/x86/lib/memcpy_32.o
AR arch/x86/platform/geode/built-in.a
CC net/netlink/policy.o
CC kernel/power/process.o
CC lib/lzo/lzo1x_decompress_safe.o
CC mm/maccess.o
CC crypto/asymmetric_keys/pkcs7_verify.o
CC lib/zlib_inflate/inflate_syms.o
CC lib/crypto/chacha.o
CC lib/crypto/mpi/generic_mpih-mul3.o
CC sound/core/seq/seq_memory.o
AS arch/x86/lib/memmove_32.o
AR drivers/pci/msi/built-in.a
CC drivers/pci/pcie/portdrv.o
CC sound/core/seq/seq_queue.o
CC arch/x86/lib/misc.o
CC kernel/locking/percpu-rwsem.o
CC arch/x86/lib/pc-conf-reg.o
CC lib/crypto/aes.o
AS arch/x86/lib/putuser.o
CC arch/x86/entry/vdso/vdso32/vgetcpu.o
AR lib/zlib_deflate/built-in.a
CC lib/crypto/arc4.o
CC net/sched/sch_frag.o
CC kernel/locking/spinlock.o
CC arch/x86/kernel/fpu/xstate.o
HOSTCC arch/x86/entry/vdso/vdso2c
AS arch/x86/lib/retpoline.o
CC security/keys/process_keys.o
CC block/elevator.o
CC block/blk-core.o
CC security/selinux/netlink.o
CC block/blk-sysfs.o
CC init/calibrate.o
CC kernel/printk/printk.o
CC arch/x86/lib/string_32.o
AR lib/zlib_inflate/built-in.a
CC block/blk-flush.o
AR lib/lzo/built-in.a
CC security/selinux/nlmsgtab.o
CC crypto/asymmetric_keys/x509.asn1.o
CC fs/nfs_common/nfsacl.o
CC arch/x86/lib/strstr_32.o
CC net/core/skbuff.o
CC crypto/asymmetric_keys/x509_akid.asn1.o
CC arch/x86/lib/usercopy.o
CC crypto/asymmetric_keys/x509_cert_parser.o
AR arch/x86/mm/pat/built-in.a
CC crypto/asymmetric_keys/pkcs7.asn1.o
CC arch/x86/mm/init.o
CC fs/notify/notification.o
CC crypto/asymmetric_keys/pkcs7_parser.o
CC arch/x86/lib/usercopy_32.o
CC arch/x86/pci/fixup.o
AR arch/x86/platform/efi/built-in.a
CC arch/x86/pci/acpi.o
CC drivers/video/console/dummycon.o
AR arch/x86/platform/iris/built-in.a
CC init/init_task.o
CC arch/x86/entry/vdso/vdso32-setup.o
CC arch/x86/platform/intel/iosf_mbi.o
CC lib/crypto/mpi/generic_mpih-rshift.o
CC drivers/video/console/vgacon.o
CC mm/page-writeback.o
AR drivers/idle/built-in.a
CC kernel/locking/osq_lock.o
CC arch/x86/lib/msr-smp.o
CC fs/nfs_common/grace.o
CC security/keys/request_key.o
AR arch/x86/platform/intel-mid/built-in.a
AR arch/x86/virt/svm/built-in.a
AR arch/x86/virt/vmx/built-in.a
CC drivers/video/backlight/backlight.o
CC block/blk-settings.o
CC mm/folio-compat.o
AR arch/x86/virt/built-in.a
CC mm/readahead.o
CC block/blk-ioc.o
AR arch/x86/platform/intel-quark/built-in.a
AR arch/x86/platform/olpc/built-in.a
CC drivers/pci/pcie/rcec.o
CC sound/core/seq/seq_fifo.o
AR arch/x86/platform/scx200/built-in.a
AR arch/x86/platform/ts5500/built-in.a
CC arch/x86/kernel/cpu/mce/core.o
VDSO arch/x86/entry/vdso/vdso32.so.dbg
CC arch/x86/kernel/acpi/boot.o
OBJCOPY arch/x86/entry/vdso/vdso32.so
VDSO2C arch/x86/entry/vdso/vdso-image-32.c
CC arch/x86/entry/vdso/vdso-image-32.o
AR net/netlink/built-in.a
AR arch/x86/events/amd/built-in.a
CC mm/swap.o
AR arch/x86/platform/uv/built-in.a
CC kernel/locking/qspinlock.o
CC mm/truncate.o
CC kernel/power/suspend.o
CC arch/x86/kernel/apic/apic.o
CC arch/x86/lib/cache-smp.o
AR crypto/asymmetric_keys/built-in.a
CC crypto/compress.o
CC sound/core/seq/seq_prioq.o
CC arch/x86/kernel/apic/apic_common.o
CC fs/notify/group.o
CC lib/crypto/mpi/generic_mpih-sub1.o
CC net/netfilter/core.o
CC net/netfilter/nf_log.o
AR arch/x86/entry/vdso/built-in.a
AR arch/x86/entry/vsyscall/built-in.a
CC arch/x86/lib/msr.o
AS arch/x86/entry/entry.o
CC net/netfilter/nf_queue.o
AS arch/x86/entry/entry_32.o
CC security/keys/request_key_auth.o
CC net/core/datagram.o
CC net/sched/sch_api.o
AR arch/x86/platform/intel/built-in.a
CC security/selinux/netif.o
AR arch/x86/platform/built-in.a
CC arch/x86/entry/syscall_32.o
CC arch/x86/entry/common.o
CC init/version.o
CC net/sched/sch_blackhole.o
CC fs/iomap/trace.o
AR arch/x86/kernel/fpu/built-in.a
CC arch/x86/pci/legacy.o
CC arch/x86/events/zhaoxin/core.o
AR fs/nfs_common/built-in.a
CC net/sched/cls_api.o
CC kernel/locking/rtmutex_api.o
CC arch/x86/events/core.o
CC arch/x86/mm/init_32.o
CC io_uring/kbuf.o
CC drivers/pci/pcie/aspm.o
CC net/core/stream.o
CC kernel/irq/irqdesc.o
AR init/built-in.a
CC arch/x86/kernel/apic/apic_noop.o
CC lib/crypto/gf128mul.o
CC kernel/irq/handle.o
AR drivers/video/console/built-in.a
CC drivers/pci/pcie/pme.o
AS arch/x86/lib/msr-reg.o
CC crypto/algapi.o
AR drivers/video/backlight/built-in.a
CC net/core/scm.o
CC sound/core/seq/seq_timer.o
AR drivers/video/fbdev/core/built-in.a
CC lib/crypto/mpi/generic_mpih-add1.o
AR drivers/video/fbdev/omap/built-in.a
CC fs/notify/mark.o
CC arch/x86/events/intel/ds.o
AR drivers/video/fbdev/omap2/omapfb/dss/built-in.a
CC sound/core/seq/seq_system.o
AR drivers/video/fbdev/omap2/omapfb/displays/built-in.a
AR drivers/video/fbdev/omap2/omapfb/built-in.a
AR drivers/video/fbdev/omap2/built-in.a
AR drivers/video/fbdev/built-in.a
CC security/keys/user_defined.o
CC drivers/video/aperture.o
CC arch/x86/kernel/acpi/sleep.o
CC mm/vmscan.o
CC arch/x86/pci/irq.o
CC arch/x86/kernel/apic/ipi.o
CC arch/x86/lib/msr-reg-export.o
CC net/ethtool/common.o
CC kernel/power/hibernate.o
AS arch/x86/entry/thunk.o
CC sound/core/seq/seq_ports.o
CC kernel/power/snapshot.o
CC net/sched/act_api.o
CC lib/crypto/blake2s.o
AS arch/x86/lib/hweight.o
CC arch/x86/lib/iomem.o
CC kernel/irq/manage.o
CC lib/crypto/mpi/ec.o
CC kernel/printk/printk_safe.o
CC block/blk-map.o
CC lib/crypto/mpi/mpicoder.o
AR arch/x86/events/zhaoxin/built-in.a
CC sound/core/seq/seq_info.o
CC arch/x86/mm/fault.o
CC arch/x86/mm/ioremap.o
CC lib/crypto/mpi/mpi-add.o
CC kernel/power/swap.o
CC kernel/locking/qrwlock.o
CC security/selinux/netnode.o
CC security/selinux/netport.o
CC arch/x86/mm/extable.o
CC security/keys/proc.o
AR arch/x86/entry/built-in.a
CC fs/iomap/iter.o
CC kernel/printk/nbcon.o
CC lib/crypto/mpi/mpi-bit.o
AS arch/x86/kernel/acpi/wakeup_32.o
CC kernel/power/user.o
CC kernel/power/poweroff.o
CC net/netfilter/nf_sockopt.o
CC arch/x86/kernel/acpi/cstate.o
CC arch/x86/kernel/cpu/mce/severity.o
CC net/netfilter/utils.o
CC arch/x86/lib/atomic64_32.o
CC lib/crypto/mpi/mpi-cmp.o
CC io_uring/rsrc.o
CC fs/notify/fdinfo.o
CC drivers/video/cmdline.o
CC arch/x86/lib/inat.o
CC block/blk-merge.o
AR drivers/pci/pcie/built-in.a
AR drivers/pci/pwrctl/built-in.a
CC arch/x86/kernel/apic/vector.o
CC drivers/pci/hotplug/pci_hotplug_core.o
CC drivers/video/nomodeset.o
AR arch/x86/lib/built-in.a
CC sound/core/sound.o
CC crypto/scatterwalk.o
AR arch/x86/lib/lib.a
CC sound/core/seq/seq_dummy.o
CC sound/core/init.o
AR kernel/locking/built-in.a
CC block/blk-timeout.o
CC security/keys/sysctl.o
CC net/ipv4/netfilter/nf_defrag_ipv4.o
CC kernel/printk/printk_ringbuffer.o
CC arch/x86/pci/common.o
CC net/ethtool/netlink.o
CC arch/x86/pci/early.o
CC arch/x86/mm/mmap.o
CC sound/core/memory.o
AR arch/x86/kernel/acpi/built-in.a
CC arch/x86/kernel/kprobes/core.o
CC net/ipv4/route.o
CC arch/x86/pci/bus_numa.o
CC lib/crypto/mpi/mpi-sub-ui.o
CC arch/x86/pci/amd_bus.o
CC kernel/sched/build_utility.o
LDS arch/x86/kernel/vmlinux.lds
AR fs/notify/built-in.a
CC arch/x86/kernel/kprobes/opt.o
AS arch/x86/kernel/head_32.o
CC drivers/video/hdmi.o
CC lib/crypto/mpi/mpi-div.o
CC fs/iomap/buffered-io.o
CC fs/iomap/direct-io.o
CC net/sched/sch_fifo.o
CC net/sched/cls_cgroup.o
CC fs/iomap/fiemap.o
CC arch/x86/kernel/cpu/mce/genpool.o
CC crypto/proc.o
CC crypto/aead.o
CC security/keys/keyctl_pkey.o
CC crypto/geniv.o
AR sound/core/seq/built-in.a
CC arch/x86/mm/pgtable.o
CC kernel/printk/sysctl.o
CC fs/iomap/seek.o
CC security/selinux/status.o
CC net/sched/ematch.o
CC arch/x86/mm/physaddr.o
CC arch/x86/events/intel/knc.o
CC sound/core/control.o
CC io_uring/notif.o
CC io_uring/tctx.o
CC arch/x86/kernel/cpu/mtrr/mtrr.o
CC drivers/pci/hotplug/acpi_pcihp.o
CC kernel/irq/spurious.o
CC arch/x86/kernel/cpu/mtrr/if.o
AR kernel/power/built-in.a
CC kernel/rcu/update.o
AR kernel/printk/built-in.a
CC arch/x86/kernel/apic/init.o
CC arch/x86/kernel/cpu/microcode/core.o
CC kernel/rcu/sync.o
CC net/netfilter/nfnetlink.o
CC net/ipv4/inetpeer.o
CC lib/crypto/mpi/mpi-inv.o
CC arch/x86/kernel/cpu/cacheinfo.o
CC arch/x86/kernel/apic/hw_nmi.o
CC kernel/irq/resend.o
CC security/selinux/ss/ebitmap.o
CC crypto/lskcipher.o
CC kernel/rcu/srcutree.o
CC lib/crypto/mpi/mpi-mod.o
AR arch/x86/pci/built-in.a
CC lib/crypto/mpi/mpi-mul.o
CC arch/x86/kernel/cpu/mce/intel.o
CC crypto/skcipher.o
CC net/ipv4/netfilter/nf_reject_ipv4.o
CC net/ipv4/protocol.o
AR security/keys/built-in.a
AR drivers/video/built-in.a
CC net/ipv4/ip_input.o
CC arch/x86/kernel/cpu/scattered.o
CC arch/x86/kernel/cpu/mce/amd.o
CC arch/x86/mm/tlb.o
AR arch/x86/kernel/kprobes/built-in.a
CC sound/core/misc.o
CC sound/core/device.o
CC kernel/irq/chip.o
CC crypto/seqiv.o
CC kernel/rcu/tree.o
CC security/selinux/ss/hashtab.o
CC crypto/echainiv.o
CC fs/iomap/swapfile.o
CC block/blk-lib.o
CC net/ethtool/bitset.o
AR drivers/pci/hotplug/built-in.a
AR drivers/pci/controller/dwc/built-in.a
AR drivers/pci/controller/mobiveil/built-in.a
CC drivers/pci/access.o
AR drivers/pci/switch/built-in.a
CC net/ipv4/netfilter/ip_tables.o
AR drivers/pci/controller/plda/built-in.a
AR drivers/pci/controller/built-in.a
CC net/ipv4/netfilter/iptable_filter.o
CC arch/x86/events/intel/lbr.o
CC arch/x86/kernel/cpu/mtrr/generic.o
AR sound/isa/ad1816a/built-in.a
CC arch/x86/kernel/cpu/microcode/intel.o
AR sound/isa/ad1848/built-in.a
AR sound/isa/cs423x/built-in.a
CC drivers/pci/bus.o
AR sound/isa/es1688/built-in.a
AR sound/isa/galaxy/built-in.a
CC crypto/ahash.o
AR sound/isa/gus/built-in.a
AR sound/isa/msnd/built-in.a
CC arch/x86/kernel/apic/io_apic.o
AR sound/isa/opti9xx/built-in.a
AR sound/isa/sb/built-in.a
AR sound/isa/wavefront/built-in.a
CC fs/quota/dquot.o
CC net/ipv4/ip_fragment.o
AR drivers/char/ipmi/built-in.a
AR sound/isa/wss/built-in.a
AR sound/isa/built-in.a
CC drivers/acpi/acpica/dsargs.o
CC drivers/pnp/pnpacpi/core.o
AR drivers/acpi/pmic/built-in.a
CC drivers/acpi/dptf/int340x_thermal.o
CC fs/proc/task_mmu.o
AR net/sched/built-in.a
CC lib/crypto/mpi/mpih-cmp.o
CC drivers/pnp/core.o
CC mm/shrinker.o
CC net/xfrm/xfrm_policy.o
CC drivers/pnp/card.o
CC net/core/gen_stats.o
CC fs/proc/inode.o
CC io_uring/filetable.o
CC arch/x86/kernel/apic/msi.o
AR drivers/amba/built-in.a
CC arch/x86/kernel/cpu/mtrr/cleanup.o
CC security/selinux/ss/symtab.o
CC security/selinux/ss/sidtab.o
AR drivers/clk/actions/built-in.a
CC net/netfilter/nfnetlink_log.o
CC security/selinux/ss/avtab.o
AR drivers/clk/analogbits/built-in.a
AR drivers/clk/bcm/built-in.a
AR drivers/clk/imgtec/built-in.a
AR drivers/clk/imx/built-in.a
CC sound/core/info.o
AR drivers/clk/ingenic/built-in.a
CC drivers/acpi/acpica/dscontrol.o
AR drivers/clk/mediatek/built-in.a
CC sound/core/isadma.o
AR drivers/clk/microchip/built-in.a
CC arch/x86/kernel/head32.o
AR drivers/clk/mstar/built-in.a
CC arch/x86/kernel/ebda.o
AR drivers/clk/mvebu/built-in.a
AR drivers/acpi/dptf/built-in.a
AR drivers/clk/ralink/built-in.a
CC security/selinux/ss/policydb.o
CC block/blk-mq.o
AR drivers/clk/renesas/built-in.a
CC io_uring/rw.o
CC arch/x86/mm/cpu_entry_area.o
AR drivers/clk/socfpga/built-in.a
AR drivers/clk/sophgo/built-in.a
CC kernel/irq/dummychip.o
AR drivers/clk/sprd/built-in.a
CC kernel/rcu/rcu_segcblist.o
CC drivers/pnp/pnpacpi/rsparser.o
AR drivers/clk/starfive/built-in.a
CC fs/proc/root.o
CC drivers/pci/probe.o
CC arch/x86/kernel/apic/probe_32.o
AR drivers/clk/sunxi-ng/built-in.a
CC lib/crypto/mpi/mpih-div.o
AR drivers/clk/ti/built-in.a
CC arch/x86/kernel/cpu/microcode/amd.o
AR drivers/clk/versatile/built-in.a
AR drivers/clk/xilinx/built-in.a
AR drivers/clk/built-in.a
CC lib/crypto/mpi/mpih-mul.o
AR fs/iomap/built-in.a
AR kernel/livepatch/built-in.a
CC kernel/dma/mapping.o
CC security/security.o
CC arch/x86/kernel/cpu/mtrr/amd.o
CC kernel/entry/common.o
CC drivers/acpi/acpica/dsdebug.o
CC kernel/module/main.o
CC net/ethtool/strset.o
CC net/ethtool/linkinfo.o
CC crypto/shash.o
CC sound/core/vmaster.o
CC kernel/time/time.o
CC drivers/pnp/driver.o
CC mm/shmem.o
CC security/lsm_audit.o
CC kernel/irq/devres.o
CC kernel/futex/core.o
CC kernel/irq/autoprobe.o
CC fs/proc/base.o
CC arch/x86/mm/maccess.o
CC kernel/module/strict_rwx.o
CC arch/x86/kernel/platform-quirks.o
CC arch/x86/events/intel/p4.o
CC io_uring/net.o
CC net/core/gen_estimator.o
CC drivers/acpi/acpica/dsfield.o
CC arch/x86/kernel/cpu/mce/threshold.o
CC net/ipv4/netfilter/iptable_mangle.o
CC kernel/cgroup/cgroup.o
CC kernel/cgroup/rstat.o
CC arch/x86/kernel/cpu/mtrr/cyrix.o
CC kernel/irq/irqdomain.o
CC security/device_cgroup.o
CC arch/x86/events/intel/p6.o
CC fs/proc/generic.o
CC arch/x86/mm/pgprot.o
CC kernel/futex/syscalls.o
CC lib/crypto/mpi/mpi-pow.o
CC sound/core/ctljack.o
CC kernel/futex/pi.o
CC arch/x86/events/intel/pt.o
AR arch/x86/kernel/cpu/microcode/built-in.a
CC kernel/dma/direct.o
CC io_uring/poll.o
AR drivers/pnp/pnpacpi/built-in.a
CC crypto/akcipher.o
CC arch/x86/kernel/process_32.o
CC drivers/pnp/resource.o
AR arch/x86/kernel/apic/built-in.a
CC sound/core/jack.o
CC net/netfilter/nf_conntrack_core.o
CC drivers/acpi/acpica/dsinit.o
CC arch/x86/mm/pgtable_32.o
CC arch/x86/events/probe.o
CC fs/proc/array.o
CC fs/proc/fd.o
CC net/ethtool/linkmodes.o
CC kernel/time/timer.o
CC net/ethtool/rss.o
CC kernel/entry/syscall_user_dispatch.o
CC net/netfilter/nf_conntrack_standalone.o
CC drivers/pnp/manager.o
CC fs/quota/quota_v2.o
CC arch/x86/kernel/cpu/mtrr/centaur.o
CC crypto/sig.o
CC fs/proc/proc_tty.o
CC drivers/acpi/acpica/dsmethod.o
CC arch/x86/events/utils.o
CC net/core/net_namespace.o
CC kernel/module/kmod.o
CC drivers/pci/host-bridge.o
CC arch/x86/events/intel/uncore.o
CC net/ipv4/netfilter/ipt_REJECT.o
CC fs/kernfs/mount.o
CC lib/crypto/mpi/mpiutil.o
CC fs/sysfs/file.o
CC [M] net/ipv4/netfilter/iptable_nat.o
AR arch/x86/kernel/cpu/mce/built-in.a
CC arch/x86/mm/iomap_32.o
CC sound/core/timer.o
CC fs/devpts/inode.o
CC kernel/futex/requeue.o
CC kernel/futex/waitwake.o
CC kernel/dma/ops_helpers.o
AR kernel/entry/built-in.a
CC kernel/cgroup/namespace.o
CC arch/x86/mm/hugetlbpage.o
CC kernel/trace/trace_clock.o
CC drivers/acpi/acpica/dsmthdat.o
CC arch/x86/kernel/cpu/mtrr/legacy.o
CC fs/netfs/buffered_read.o
CC kernel/irq/proc.o
CC fs/netfs/buffered_write.o
CC fs/quota/quota_tree.o
AR kernel/sched/built-in.a
CC drivers/pnp/support.o
CC block/blk-mq-tag.o
CC fs/netfs/direct_read.o
CC drivers/pnp/interface.o
CC crypto/kpp.o
AR sound/pci/ac97/built-in.a
AR sound/ppc/built-in.a
CC net/ethtool/linkstate.o
AR sound/pci/ali5451/built-in.a
AR sound/pci/asihpi/built-in.a
AR sound/pci/au88x0/built-in.a
CC fs/kernfs/inode.o
AR arch/x86/kernel/cpu/mtrr/built-in.a
CC arch/x86/kernel/cpu/topology_common.o
AR sound/pci/aw2/built-in.a
AR sound/pci/ctxfi/built-in.a
CC kernel/trace/ring_buffer.o
ASN.1 crypto/rsapubkey.asn1.[ch]
AR sound/pci/ca0106/built-in.a
CC fs/proc/cmdline.o
CC drivers/pci/remove.o
CC security/selinux/ss/services.o
CC fs/proc/consoles.o
CC drivers/acpi/acpica/dsobject.o
AR sound/pci/cs46xx/built-in.a
CC drivers/acpi/acpica/dsopcode.o
CC kernel/module/tree_lookup.o
CC kernel/module/kallsyms.o
AR sound/pci/cs5535audio/built-in.a
CC net/netfilter/nf_conntrack_expect.o
AR sound/pci/lola/built-in.a
AR lib/crypto/mpi/built-in.a
AR sound/pci/lx6464es/built-in.a
CC lib/crypto/blake2s-generic.o
AR sound/pci/echoaudio/built-in.a
CC drivers/acpi/acpica/dspkginit.o
AR sound/pci/emu10k1/built-in.a
CC fs/sysfs/dir.o
AR sound/pci/hda/built-in.a
AR sound/pci/ice1712/built-in.a
CC [M] sound/pci/hda/hda_bind.o
CC [M] sound/pci/hda/hda_codec.o
AR sound/pci/korg1212/built-in.a
CC fs/sysfs/symlink.o
CC kernel/dma/dummy.o
CC fs/sysfs/mount.o
CC fs/netfs/direct_write.o
AR fs/devpts/built-in.a
CC arch/x86/events/intel/uncore_nhmex.o
AR kernel/futex/built-in.a
CC arch/x86/mm/dump_pagetables.o
CC io_uring/eventfd.o
CC kernel/bpf/core.o
CC arch/x86/mm/highmem_32.o
CC mm/util.o
AR net/ipv4/netfilter/built-in.a
CC mm/mmzone.o
CC drivers/acpi/acpica/dsutils.o
CC net/xfrm/xfrm_state.o
CC arch/x86/kernel/cpu/topology_ext.o
CC kernel/irq/migration.o
CC drivers/pnp/quirks.o
CC drivers/acpi/acpica/dswexec.o
CC net/ipv4/ip_forward.o
CC io_uring/uring_cmd.o
CC fs/proc/cpuinfo.o
CC fs/quota/quota.o
AR kernel/rcu/built-in.a
CC arch/x86/events/rapl.o
CC drivers/acpi/acpica/dswload.o
CC lib/crypto/sha1.o
CC arch/x86/kernel/cpu/topology_amd.o
CC drivers/pnp/system.o
ASN.1 crypto/rsaprivkey.asn1.[ch]
CC drivers/pci/pci.o
CC crypto/rsa.o
CC crypto/rsa_helper.o
CC net/core/secure_seq.o
AR sound/arm/built-in.a
AR sound/sh/built-in.a
CC fs/sysfs/group.o
CC fs/kernfs/dir.o
CC block/blk-stat.o
CC kernel/module/procfs.o
CC kernel/dma/remap.o
CC block/blk-mq-sysfs.o
CC crypto/rsa-pkcs1pad.o
CC arch/x86/kernel/cpu/common.o
CC kernel/time/hrtimer.o
CC kernel/time/timekeeping.o
CC arch/x86/kernel/cpu/rdrand.o
CC drivers/acpi/acpica/dswload2.o
CC arch/x86/kernel/cpu/match.o
CC fs/proc/devices.o
CC arch/x86/kernel/cpu/bugs.o
CC net/ethtool/debug.o
CC [M] sound/pci/hda/hda_jack.o
CC sound/core/hrtimer.o
CC net/netfilter/nf_conntrack_helper.o
CC [M] sound/pci/hda/hda_auto_parser.o
CC kernel/irq/cpuhotplug.o
CC mm/vmstat.o
CC [M] sound/pci/hda/hda_sysfs.o
CC mm/backing-dev.o
CC lib/crypto/sha256.o
AR sound/synth/emux/built-in.a
AR sound/synth/built-in.a
AR arch/x86/mm/built-in.a
CC kernel/irq/pm.o
CC sound/core/seq_device.o
CC kernel/irq/msi.o
CC [M] sound/core/hwdep.o
CC kernel/events/core.o
CC net/unix/af_unix.o
CC fs/netfs/io.o
AR drivers/pnp/built-in.a
CC net/unix/garbage.o
CC net/netfilter/nf_conntrack_proto.o
CC drivers/acpi/acpica/dswscope.o
CC block/blk-mq-cpumap.o
CC kernel/module/sysfs.o
AR kernel/dma/built-in.a
CC arch/x86/kernel/cpu/aperfmperf.o
CC net/netfilter/nf_conntrack_proto_generic.o
CC mm/mm_init.o
AR fs/sysfs/built-in.a
CC arch/x86/kernel/cpu/cpuid-deps.o
CC fs/ext4/balloc.o
CC arch/x86/events/intel/uncore_snb.o
CC fs/proc/interrupts.o
CC net/core/flow_dissector.o
CC mm/percpu.o
CC net/netfilter/nf_conntrack_proto_tcp.o
CC crypto/acompress.o
CC fs/quota/kqid.o
AR lib/crypto/built-in.a
CC drivers/acpi/acpica/dswstate.o
CC arch/x86/events/intel/uncore_snbep.o
CC lib/lz4/lz4_decompress.o
CC fs/ext4/bitmap.o
CC net/ipv4/ip_options.o
CC [M] sound/core/pcm.o
CC kernel/events/ring_buffer.o
CC [M] sound/core/pcm_native.o
CC io_uring/openclose.o
CC [M] sound/pci/hda/hda_controller.o
CC arch/x86/kernel/cpu/umwait.o
CC net/ethtool/wol.o
CC net/core/sysctl_net_core.o
CC fs/kernfs/file.o
CC fs/jbd2/transaction.o
CC block/blk-mq-sched.o
CC fs/proc/loadavg.o
AR kernel/module/built-in.a
CC fs/jbd2/commit.o
CC lib/zstd/zstd_decompress_module.o
CC fs/quota/netlink.o
CC kernel/irq/affinity.o
CC drivers/acpi/acpica/evevent.o
CC lib/zstd/decompress/huf_decompress.o
CC kernel/cgroup/cgroup-v1.o
CC fs/jbd2/recovery.o
CC kernel/time/ntp.o
CC kernel/trace/trace.o
CC fs/netfs/iterator.o
CC drivers/dma/dw/core.o
CC net/netfilter/nf_conntrack_proto_udp.o
AR drivers/soc/apple/built-in.a
CC net/unix/sysctl_net_unix.o
AR drivers/soc/aspeed/built-in.a
CC crypto/scompress.o
AR drivers/soc/bcm/built-in.a
AR drivers/soc/fsl/built-in.a
CC drivers/dma/dw/dw.o
CC drivers/acpi/acpica/evgpe.o
AR drivers/soc/fujitsu/built-in.a
CC drivers/acpi/acpica/evgpeblk.o
CC kernel/time/clocksource.o
MKCAP arch/x86/kernel/cpu/capflags.c
AR drivers/soc/hisilicon/built-in.a
AR drivers/soc/imx/built-in.a
AR drivers/soc/ixp4xx/built-in.a
CC kernel/fork.o
AR drivers/soc/loongson/built-in.a
CC drivers/acpi/acpica/evgpeinit.o
AR drivers/soc/mediatek/built-in.a
CC security/selinux/ss/conditional.o
AR drivers/soc/microchip/built-in.a
CC kernel/irq/matrix.o
AR drivers/soc/nuvoton/built-in.a
CC fs/netfs/locking.o
AR drivers/soc/pxa/built-in.a
CC fs/netfs/main.o
AR drivers/soc/amlogic/built-in.a
AR drivers/soc/qcom/built-in.a
CC fs/netfs/misc.o
CC fs/proc/meminfo.o
AR drivers/soc/renesas/built-in.a
AR drivers/soc/sunxi/built-in.a
AR drivers/soc/rockchip/built-in.a
CC [M] sound/core/pcm_lib.o
AR drivers/soc/ti/built-in.a
AR drivers/soc/xilinx/built-in.a
AR drivers/soc/built-in.a
CC [M] sound/core/pcm_misc.o
CC io_uring/sqpoll.o
CC net/ethtool/features.o
AR fs/quota/built-in.a
AR lib/lz4/built-in.a
CC net/ethtool/privflags.o
CC net/ethtool/rings.o
CC kernel/exec_domain.o
CC net/netfilter/nf_conntrack_proto_icmp.o
CC net/core/dev.o
CC drivers/acpi/acpica/evgpeutil.o
CC fs/kernfs/symlink.o
CC block/ioctl.o
CC net/ipv4/ip_output.o
CC kernel/panic.o
AR kernel/bpf/built-in.a
CC net/ethtool/channels.o
CC drivers/acpi/acpica/evglock.o
CC net/ethtool/coalesce.o
CC io_uring/xattr.o
CC [M] sound/pci/hda/hda_proc.o
CC fs/jbd2/checkpoint.o
CC drivers/pci/pci-driver.o
CC fs/jbd2/revoke.o
CC net/core/dev_addr_lists.o
CC crypto/algboss.o
CC fs/proc/stat.o
CC fs/netfs/objects.o
AR net/unix/built-in.a
CC io_uring/nop.o
CC net/xfrm/xfrm_hash.o
CC drivers/dma/dw/idma32.o
CC drivers/dma/dw/acpi.o
CC kernel/time/jiffies.o
CC [M] sound/core/pcm_memory.o
CC fs/netfs/write_collect.o
CC net/core/dst.o
CC drivers/acpi/acpica/evhandler.o
CC lib/zstd/decompress/zstd_ddict.o
CC kernel/cgroup/freezer.o
CC drivers/acpi/acpica/evmisc.o
CC mm/slab_common.o
CC fs/netfs/write_issue.o
CC net/ipv4/ip_sockglue.o
AR fs/kernfs/built-in.a
CC lib/zstd/decompress/zstd_decompress.o
CC block/genhd.o
CC fs/ext4/block_validity.o
CC block/ioprio.o
AR kernel/irq/built-in.a
CC security/selinux/ss/mls.o
CC kernel/cpu.o
CC drivers/dma/hsu/hsu.o
CC kernel/time/timer_list.o
CC net/ethtool/pause.o
CC security/selinux/ss/context.o
CC arch/x86/events/intel/uncore_discovery.o
CC arch/x86/events/intel/cstate.o
CC net/xfrm/xfrm_input.o
CC fs/proc/uptime.o
CC drivers/acpi/acpica/evregion.o
CC net/netfilter/nf_conntrack_extend.o
CC fs/ext4/dir.o
CC io_uring/fs.o
CC fs/jbd2/journal.o
CC lib/xz/xz_dec_syms.o
CC arch/x86/kernel/cpu/powerflags.o
AR drivers/dma/dw/built-in.a
CC kernel/trace/trace_output.o
CC fs/ramfs/inode.o
CC crypto/testmgr.o
CC [M] sound/pci/hda/hda_hwdep.o
CC net/xfrm/xfrm_output.o
CC net/netfilter/nf_conntrack_acct.o
CC net/netfilter/nf_conntrack_seqadj.o
CC io_uring/splice.o
CC crypto/cmac.o
CC fs/fat/cache.o
CC fs/hugetlbfs/inode.o
CC net/ethtool/eee.o
CC net/ethtool/tsinfo.o
CC [M] sound/core/memalloc.o
CC net/core/netevent.o
CC lib/zstd/decompress/zstd_decompress_block.o
CC lib/xz/xz_dec_stream.o
CC drivers/acpi/acpica/evrgnini.o
CC drivers/pci/search.o
CC fs/proc/util.o
CC kernel/cgroup/legacy_freezer.o
CC kernel/time/timeconv.o
CC net/ipv6/netfilter/ip6_tables.o
CC net/ipv6/af_inet6.o
AR drivers/dma/hsu/built-in.a
CC net/ipv6/anycast.o
AR drivers/dma/idxd/built-in.a
AR drivers/dma/mediatek/built-in.a
AR drivers/dma/qcom/built-in.a
AR drivers/dma/stm32/built-in.a
AR drivers/dma/ti/built-in.a
AR drivers/dma/xilinx/built-in.a
CC drivers/dma/dmaengine.o
CC drivers/dma/virt-dma.o
CC fs/ramfs/file-mmu.o
CC net/ethtool/cabletest.o
CC net/packet/af_packet.o
CC crypto/hmac.o
AR arch/x86/events/intel/built-in.a
CC net/ipv6/netfilter/ip6table_filter.o
CC arch/x86/events/msr.o
CC block/badblocks.o
AR fs/netfs/built-in.a
CC [M] sound/pci/hda/patch_hdmi.o
CC drivers/acpi/acpica/evsci.o
CC drivers/acpi/acpica/evxface.o
CC kernel/time/timecounter.o
CC lib/xz/xz_dec_lzma2.o
CC drivers/acpi/acpica/evxfevnt.o
CC net/ipv6/netfilter/ip6table_mangle.o
CC kernel/time/alarmtimer.o
CC security/selinux/netlabel.o
CC fs/proc/version.o
CC drivers/acpi/acpica/evxfgpe.o
CC fs/ext4/ext4_jbd2.o
CC fs/ext4/extents.o
CC io_uring/sync.o
CC fs/fat/dir.o
CC [M] sound/pci/hda/hda_eld.o
CC kernel/cgroup/pids.o
CC [M] sound/core/pcm_timer.o
CC drivers/pci/rom.o
CC drivers/pci/setup-res.o
CC drivers/acpi/acpica/evxfregn.o
CC lib/dim/dim.o
CC mm/compaction.o
CC mm/show_mem.o
CC lib/dim/net_dim.o
CC drivers/acpi/acpica/exconcat.o
CC kernel/cgroup/rdma.o
CC net/ipv4/inet_hashtables.o
CC lib/fonts/fonts.o
AR fs/ramfs/built-in.a
CC crypto/crypto_null.o
CC fs/isofs/namei.o
CC crypto/md5.o
CC lib/argv_split.o
CC fs/isofs/inode.o
CC kernel/trace/trace_seq.o
CC net/netfilter/nf_conntrack_proto_icmpv6.o
AR arch/x86/events/built-in.a
CC fs/proc/softirqs.o
CC kernel/trace/trace_stat.o
AR fs/hugetlbfs/built-in.a
CC drivers/acpi/acpica/exconfig.o
CC lib/xz/xz_dec_bcj.o
CC arch/x86/kernel/cpu/topology.o
CC drivers/acpi/acpica/exconvrt.o
CC lib/dim/rdma_dim.o
CC net/xfrm/xfrm_sysctl.o
CC fs/nfs/client.o
CC fs/isofs/dir.o
CC lib/fonts/font_8x16.o
CC block/blk-rq-qos.o
CC net/ethtool/tunnels.o
LD [M] sound/core/snd-hwdep.o
LD [M] sound/core/snd-pcm.o
AR sound/core/built-in.a
CC fs/nfs/dir.o
CC drivers/dma/acpi-dma.o
CC lib/bug.o
CC net/ethtool/fec.o
CC net/ipv6/ip6_output.o
CC drivers/pci/irq.o
CC lib/buildid.o
CC io_uring/msg_ring.o
CC net/ipv6/netfilter/nf_defrag_ipv6_hooks.o
CC io_uring/advise.o
CC crypto/sha256_generic.o
CC lib/clz_tab.o
CC kernel/cgroup/cpuset.o
AR lib/xz/built-in.a
CC lib/cmdline.o
CC drivers/acpi/acpica/excreate.o
CC drivers/acpi/acpica/exdebug.o
CC fs/nfs/file.o
CC kernel/trace/trace_printk.o
CC drivers/acpi/acpica/exdump.o
CC mm/shmem_quota.o
CC block/disk-events.o
CC kernel/time/posix-timers.o
AR lib/fonts/built-in.a
CC block/blk-ia-ranges.o
CC net/core/neighbour.o
CC lib/zstd/zstd_common_module.o
CC fs/proc/namespaces.o
CC fs/proc/self.o
AR lib/dim/built-in.a
CC drivers/acpi/acpica/exfield.o
CC mm/interval_tree.o
AR security/selinux/built-in.a
AR security/built-in.a
CC net/ipv4/inet_timewait_sock.o
CC fs/ext4/extents_status.o
CC drivers/acpi/acpica/exfldio.o
CC block/early-lookup.o
CC lib/zstd/common/debug.o
AR sound/usb/misc/built-in.a
CC lib/zstd/common/entropy_common.o
AR sound/usb/usx2y/built-in.a
AR sound/usb/caiaq/built-in.a
AR sound/usb/6fire/built-in.a
CC lib/zstd/common/error_private.o
CC lib/zstd/common/fse_decompress.o
CC fs/fat/fatent.o
AR sound/usb/hiface/built-in.a
CC lib/cpumask.o
AR sound/usb/bcd2000/built-in.a
CC fs/isofs/util.o
AR sound/usb/built-in.a
AR drivers/dma/built-in.a
CC crypto/sha512_generic.o
CC net/netfilter/nf_conntrack_netlink.o
CC net/xfrm/xfrm_replay.o
CC drivers/pci/vpd.o
AR fs/jbd2/built-in.a
CC arch/x86/kernel/cpu/proc.o
CC kernel/events/callchain.o
CC drivers/pci/setup-bus.o
CC net/xfrm/xfrm_device.o
CC net/xfrm/xfrm_nat_keepalive.o
CC drivers/virtio/virtio.o
CC kernel/trace/pid_list.o
CC [M] sound/pci/hda/hda_intel.o
CC fs/proc/thread_self.o
CC kernel/exit.o
CC drivers/tty/vt/vt_ioctl.o
CC drivers/acpi/acpica/exmisc.o
CC drivers/acpi/acpica/exmutex.o
CC net/netfilter/nf_conntrack_ftp.o
CC fs/isofs/rock.o
CC drivers/tty/hvc/hvc_console.o
CC drivers/acpi/acpica/exnames.o
CC drivers/acpi/acpica/exoparg1.o
CC io_uring/epoll.o
CC net/ethtool/eeprom.o
CC drivers/acpi/acpica/exoparg2.o
CC drivers/char/hw_random/core.o
CC lib/zstd/common/zstd_common.o
CC net/ipv6/netfilter/nf_conntrack_reasm.o
CC fs/nfs/getroot.o
CC block/bounce.o
AR lib/zstd/built-in.a
CC lib/ctype.o
CC drivers/pci/vc.o
CC net/core/rtnetlink.o
CC lib/dec_and_lock.o
CC drivers/virtio/virtio_ring.o
CC block/bsg.o
CC net/ipv6/netfilter/nf_reject_ipv6.o
AR drivers/iommu/amd/built-in.a
CC fs/proc/proc_sysctl.o
AR drivers/iommu/intel/built-in.a
AR drivers/iommu/arm/arm-smmu/built-in.a
AR drivers/gpu/host1x/built-in.a
AR drivers/iommu/arm/arm-smmu-v3/built-in.a
AR drivers/iommu/arm/built-in.a
CC arch/x86/kernel/signal.o
CC net/core/utils.o
AR drivers/iommu/iommufd/built-in.a
CC drivers/iommu/iommu.o
CC kernel/events/hw_breakpoint.o
CC kernel/time/posix-cpu-timers.o
CC drivers/acpi/acpica/exoparg3.o
CC crypto/sha3_generic.o
CC lib/decompress.o
CC arch/x86/kernel/signal_32.o
CC net/ipv4/inet_connection_sock.o
CC io_uring/statx.o
CC lib/decompress_bunzip2.o
CC kernel/trace/trace_sched_switch.o
AR drivers/gpu/drm/tests/built-in.a
AR drivers/gpu/drm/arm/built-in.a
CC drivers/gpu/drm/display/drm_display_helper_mod.o
AR net/packet/built-in.a
CC drivers/gpu/drm/display/drm_dp_dual_mode_helper.o
CC fs/fat/file.o
CC fs/isofs/export.o
CC drivers/virtio/virtio_anchor.o
AR drivers/tty/hvc/built-in.a
CC fs/isofs/joliet.o
CC crypto/ecb.o
CC mm/list_lru.o
CC arch/x86/kernel/traps.o
CC drivers/char/hw_random/intel-rng.o
CC drivers/acpi/acpica/exoparg6.o
CC net/xfrm/xfrm_algo.o
CC drivers/tty/vt/vc_screen.o
CC drivers/iommu/iommu-traces.o
CC net/core/link_watch.o
CC net/ethtool/stats.o
AR net/dsa/built-in.a
CC net/ipv4/tcp.o
CC net/sunrpc/auth_gss/auth_gss.o
LD [M] sound/pci/hda/snd-hda-codec.o
CC net/sunrpc/clnt.o
LD [M] sound/pci/hda/snd-hda-codec-hdmi.o
LD [M] sound/pci/hda/snd-hda-intel.o
CC drivers/pci/mmap.o
AR sound/pci/mixart/built-in.a
CC net/ipv6/netfilter/ip6t_ipv6header.o
CC net/ipv6/netfilter/ip6t_REJECT.o
AR sound/pci/nm256/built-in.a
CC block/blk-cgroup.o
CC arch/x86/kernel/idt.o
CC drivers/acpi/acpica/exprep.o
CC lib/decompress_inflate.o
AR sound/pci/oxygen/built-in.a
AR sound/pci/pcxhr/built-in.a
CC crypto/cbc.o
AR sound/pci/riptide/built-in.a
CC arch/x86/kernel/cpu/feat_ctl.o
AR sound/pci/rme9652/built-in.a
CC io_uring/timeout.o
AR sound/pci/trident/built-in.a
CC drivers/virtio/virtio_pci_modern_dev.o
AR sound/pci/ymfpci/built-in.a
AR sound/pci/vx222/built-in.a
CC drivers/char/agp/backend.o
AR sound/pci/built-in.a
CC lib/decompress_unlz4.o
CC fs/isofs/compress.o
CC kernel/cgroup/misc.o
CC drivers/char/hw_random/amd-rng.o
CC mm/workingset.o
AR sound/firewire/built-in.a
AR sound/sparc/built-in.a
CC kernel/time/posix-clock.o
AR sound/spi/built-in.a
CC kernel/time/itimer.o
CC kernel/events/uprobes.o
AR sound/parisc/built-in.a
CC mm/debug.o
AR sound/pcmcia/vx/built-in.a
CC drivers/gpu/drm/display/drm_dp_helper.o
AR sound/pcmcia/pdaudiocf/built-in.a
CC drivers/gpu/drm/display/drm_dp_mst_topology.o
AR sound/pcmcia/built-in.a
CC drivers/acpi/acpica/exregion.o
AR sound/mips/built-in.a
CC net/netfilter/nf_conntrack_irc.o
AR sound/soc/built-in.a
CC fs/fat/inode.o
CC net/netfilter/nf_conntrack_sip.o
CC mm/gup.o
AR sound/atmel/built-in.a
AR sound/hda/built-in.a
CC [M] sound/hda/hda_bus_type.o
CC crypto/ctr.o
CC arch/x86/kernel/cpu/intel.o
CC fs/proc/proc_net.o
CC drivers/tty/vt/selection.o
CC arch/x86/kernel/cpu/tsx.o
CC lib/decompress_unlzma.o
CC drivers/gpu/drm/ttm/ttm_tt.o
CC kernel/trace/trace_nop.o
CC drivers/pci/devres.o
CC drivers/gpu/drm/ttm/ttm_bo.o
CC lib/decompress_unlzo.o
CC fs/proc/kcore.o
CC net/xfrm/xfrm_user.o
CC kernel/cgroup/debug.o
CC drivers/char/agp/generic.o
CC drivers/gpu/drm/i915/i915_config.o
CC drivers/acpi/acpica/exresnte.o
CC fs/nfs/inode.o
CC fs/nfs/super.o
CC drivers/gpu/drm/i915/i915_driver.o
CC drivers/iommu/iommu-sysfs.o
CC drivers/virtio/virtio_pci_legacy_dev.o
CC drivers/char/hw_random/geode-rng.o
CC net/ethtool/phc_vclocks.o
CC crypto/gcm.o
CC net/ethtool/mm.o
CC fs/ext4/file.o
CC drivers/char/hw_random/via-rng.o
CC drivers/gpu/drm/display/drm_dsc_helper.o
AR sound/x86/built-in.a
CC drivers/acpi/acpica/exresolv.o
CC drivers/acpi/acpica/exresop.o
CC drivers/acpi/acpica/exserial.o
AR fs/isofs/built-in.a
CC [M] sound/hda/hdac_bus.o
CC fs/ext4/fsmap.o
CC io_uring/fdinfo.o
CC io_uring/cancel.o
CC drivers/char/agp/isoch.o
AR net/ipv6/netfilter/built-in.a
CC net/ipv6/ip6_input.o
CC kernel/time/clockevents.o
CC net/ipv6/addrconf.o
CC kernel/time/tick-common.o
CC drivers/tty/vt/keyboard.o
CC lib/decompress_unxz.o
CC drivers/gpu/drm/ttm/ttm_bo_util.o
CC kernel/trace/blktrace.o
CC block/blk-ioprio.o
CC drivers/iommu/dma-iommu.o
CC drivers/pci/proc.o
CC net/netfilter/nf_nat_core.o
CC drivers/gpu/drm/display/drm_hdcp_helper.o
CC drivers/acpi/acpica/exstore.o
CC block/blk-iolatency.o
CC drivers/iommu/iova.o
CC drivers/gpu/drm/ttm/ttm_bo_vm.o
CC drivers/tty/vt/vt.o
AR drivers/char/hw_random/built-in.a
CC fs/proc/vmcore.o
AR kernel/cgroup/built-in.a
CC drivers/char/mem.o
CC drivers/virtio/virtio_pci_modern.o
CC drivers/char/random.o
CC arch/x86/kernel/cpu/intel_epb.o
CC fs/fat/misc.o
CC drivers/char/agp/amd64-agp.o
CC lib/decompress_unzstd.o
AR kernel/events/built-in.a
CC net/sunrpc/auth_gss/gss_generic_token.o
CC kernel/time/tick-broadcast.o
AR drivers/gpu/vga/built-in.a
CC net/sunrpc/auth_gss/gss_mech_switch.o
CC net/ethtool/module.o
CC [M] sound/hda/hdac_device.o
CC drivers/char/agp/intel-agp.o
CC drivers/acpi/acpica/exstoren.o
CC drivers/virtio/virtio_pci_common.o
CC drivers/acpi/acpica/exstorob.o
CC crypto/ccm.o
CC drivers/tty/serial/8250/8250_core.o
CC net/core/filter.o
CC block/blk-iocost.o
CC arch/x86/kernel/cpu/amd.o
CC drivers/tty/serial/8250/8250_platform.o
CC net/ethtool/cmis_fw_update.o
CC io_uring/waitid.o
CC crypto/aes_generic.o
CC drivers/gpu/drm/display/drm_hdmi_helper.o
CC mm/mmap_lock.o
CC drivers/pci/pci-sysfs.o
CC fs/proc/kmsg.o
CC drivers/tty/serial/serial_core.o
CC drivers/gpu/drm/ttm/ttm_module.o
CC lib/dump_stack.o
CC drivers/acpi/acpica/exsystem.o
CC block/mq-deadline.o
CC net/sunrpc/auth_gss/svcauth_gss.o
CC drivers/virtio/virtio_pci_legacy.o
CC drivers/tty/serial/serial_base_bus.o
CC fs/ext4/fsync.o
CC lib/earlycpio.o
CC kernel/time/tick-broadcast-hrtimer.o
CC fs/fat/nfs.o
CC drivers/gpu/drm/i915/i915_drm_client.o
CC kernel/time/tick-oneshot.o
CC net/core/sock_diag.o
CC drivers/acpi/acpica/extrace.o
CC drivers/char/agp/intel-gtt.o
CC net/netfilter/nf_nat_proto.o
CC net/ethtool/cmis_cdb.o
AR drivers/iommu/built-in.a
CC drivers/acpi/acpica/exutils.o
CC drivers/acpi/acpica/hwacpi.o
CC drivers/connector/cn_queue.o
CC fs/proc/page.o
CC kernel/trace/trace_events.o
CC net/ipv6/addrlabel.o
CC net/netfilter/nf_nat_helper.o
AR drivers/tty/ipwireless/built-in.a
CC drivers/gpu/drm/ttm/ttm_execbuf_util.o
CC crypto/crc32c_generic.o
CC [M] sound/hda/hdac_sysfs.o
CC drivers/tty/tty_io.o
CC crypto/authenc.o
COPY drivers/tty/vt/defkeymap.c
CC drivers/tty/n_tty.o
CC net/ethtool/pse-pd.o
CC drivers/tty/vt/consolemap.o
CC lib/extable.o
CC kernel/time/tick-sched.o
CC io_uring/register.o
CC lib/flex_proportions.o
CC drivers/tty/serial/8250/8250_pnp.o
CC lib/idr.o
CC net/sunrpc/xprt.o
CC net/ipv4/tcp_input.o
CC mm/highmem.o
CC drivers/pci/slot.o
CC drivers/virtio/virtio_pci_admin_legacy_io.o
CC drivers/acpi/acpica/hwesleep.o
CC arch/x86/kernel/cpu/hygon.o
CC fs/fat/namei_vfat.o
CC drivers/gpu/drm/display/drm_scdc_helper.o
CC [M] sound/hda/hdac_regmap.o
AR net/xfrm/built-in.a
CC drivers/char/misc.o
CC net/sunrpc/auth_gss/gss_rpc_upcall.o
CC arch/x86/kernel/cpu/centaur.o
CC lib/irq_regs.o
CC fs/fat/namei_msdos.o
CC net/sunrpc/socklib.o
CC drivers/pci/pci-acpi.o
CC drivers/tty/serial/8250/8250_rsa.o
AR fs/proc/built-in.a
CC lib/is_single_threaded.o
CC drivers/acpi/acpica/hwgpe.o
CC fs/exportfs/expfs.o
CC drivers/gpu/drm/ttm/ttm_range_manager.o
CC fs/nfs/io.o
CC lib/klist.o
CC fs/ext4/hash.o
AR net/wireless/tests/built-in.a
CC arch/x86/kernel/cpu/transmeta.o
CC net/wireless/core.o
AR drivers/char/agp/built-in.a
CC drivers/gpu/drm/i915/i915_getparam.o
CC net/wireless/sysfs.o
CC drivers/connector/connector.o
CC block/kyber-iosched.o
CC net/wireless/radiotap.o
CC kernel/softirq.o
CC drivers/virtio/virtio_input.o
CC drivers/gpu/drm/i915/i915_ioctl.o
CC drivers/pci/iomap.o
CC net/core/dev_ioctl.o
CC drivers/char/virtio_console.o
HOSTCC drivers/tty/vt/conmakehash
CC crypto/authencesn.o
CC net/core/tso.o
CC lib/kobject.o
CC [M] sound/hda/hdac_controller.o
AR drivers/gpu/drm/display/built-in.a
CC block/blk-mq-pci.o
CC net/ethtool/plca.o
CC mm/memory.o
CC drivers/acpi/acpica/hwregs.o
CC kernel/time/timer_migration.o
CC net/core/sock_reuseport.o
CC drivers/tty/vt/defkeymap.o
CC io_uring/truncate.o
CC net/netfilter/nf_nat_masquerade.o
CC drivers/tty/serial/8250/8250_port.o
CC drivers/gpu/drm/i915/i915_irq.o
CC drivers/tty/serial/serial_ctrl.o
AR fs/exportfs/built-in.a
CONMK drivers/tty/vt/consolemap_deftbl.c
CC drivers/gpu/drm/i915/i915_mitigations.o
CC fs/lockd/clntlock.o
CC drivers/gpu/drm/ttm/ttm_resource.o
CC drivers/tty/vt/consolemap_deftbl.o
CC arch/x86/kernel/cpu/zhaoxin.o
CC fs/lockd/clntproc.o
AR drivers/tty/vt/built-in.a
CC net/sunrpc/auth_gss/gss_rpc_xdr.o
CC crypto/lzo.o
AR fs/fat/built-in.a
CC block/blk-mq-virtio.o
CC fs/ext4/ialloc.o
CC fs/ext4/indirect.o
CC drivers/acpi/acpica/hwsleep.o
CC io_uring/memmap.o
CC net/sunrpc/xprtsock.o
CC mm/mincore.o
CC fs/nls/nls_base.o
CC drivers/pci/quirks.o
CC lib/kobject_uevent.o
CC fs/nls/nls_cp437.o
CC fs/nfs/direct.o
CC drivers/virtio/virtio_dma_buf.o
CC drivers/connector/cn_proc.o
CC drivers/gpu/drm/i915/i915_module.o
CC net/wireless/util.o
CC drivers/gpu/drm/i915/i915_params.o
CC arch/x86/kernel/cpu/vortex.o
CC fs/ext4/inline.o
CC [M] sound/hda/hdac_stream.o
CC drivers/acpi/acpica/hwvalid.o
AR drivers/gpu/drm/renesas/rcar-du/built-in.a
AR drivers/gpu/drm/renesas/rz-du/built-in.a
AR drivers/gpu/drm/renesas/built-in.a
AR drivers/gpu/drm/omapdrm/built-in.a
CC crypto/lzo-rle.o
CC drivers/acpi/acpica/hwxface.o
CC drivers/acpi/acpica/hwxfsleep.o
AR net/ethtool/built-in.a
CC drivers/tty/serial/serial_port.o
CC arch/x86/kernel/cpu/perfctr-watchdog.o
CC fs/nls/nls_ascii.o
CC drivers/tty/serial/8250/8250_dma.o
CC net/ipv6/route.o
CC drivers/tty/tty_ioctl.o
CC block/blk-mq-debugfs.o
CC drivers/tty/serial/8250/8250_dwlib.o
CC kernel/trace/trace_export.o
CC drivers/tty/serial/8250/8250_pcilib.o
CC io_uring/io-wq.o
CC drivers/gpu/drm/ttm/ttm_pool.o
CC drivers/tty/serial/earlycon.o
CC fs/ext4/inode.o
CC drivers/tty/tty_ldisc.o
CC drivers/char/hpet.o
AR drivers/virtio/built-in.a
CC drivers/base/power/sysfs.o
CC block/blk-pm.o
CC drivers/tty/tty_buffer.o
CC drivers/acpi/acpica/hwpci.o
CC drivers/base/power/generic_ops.o
CC block/holder.o
CC fs/nls/nls_iso8859-1.o
CC net/netfilter/nf_nat_ftp.o
CC net/ipv4/tcp_output.o
CC net/sunrpc/auth_gss/trace.o
CC drivers/gpu/drm/i915/i915_pci.o
CC crypto/rng.o
CC drivers/char/nvram.o
CC fs/lockd/clntxdr.o
CC fs/lockd/host.o
CC arch/x86/kernel/cpu/vmware.o
CC [M] sound/hda/array.o
CC drivers/gpu/drm/i915/i915_scatterlist.o
AR drivers/connector/built-in.a
CC drivers/acpi/acpica/nsaccess.o
CC lib/logic_pio.o
CC kernel/time/vsyscall.o
CC kernel/time/timekeeping_debug.o
CC net/ipv6/ip6_fib.o
CC fs/nls/nls_utf8.o
CC net/ipv6/ipv6_sockglue.o
CC drivers/tty/serial/8250/8250_early.o
AR net/mac80211/tests/built-in.a
CC net/netlabel/netlabel_user.o
CC net/mac80211/main.o
CC kernel/trace/trace_event_perf.o
CC drivers/base/power/common.o
CC net/netlabel/netlabel_kapi.o
CC drivers/gpu/drm/i915/i915_suspend.o
CC kernel/trace/trace_events_filter.o
CC fs/lockd/svc.o
CC net/sunrpc/sched.o
AR block/built-in.a
CC drivers/gpu/drm/ttm/ttm_device.o
CC net/ipv6/ndisc.o
CC drivers/tty/tty_port.o
AR fs/nls/built-in.a
CC crypto/drbg.o
CC drivers/base/power/qos.o
CC drivers/gpu/drm/i915/i915_switcheroo.o
CC io_uring/futex.o
CC drivers/acpi/acpica/nsalloc.o
CC net/sunrpc/auth.o
CC arch/x86/kernel/cpu/hypervisor.o
CC net/wireless/reg.o
CC [M] sound/hda/hdmi_chmap.o
CC drivers/base/power/runtime.o
CC lib/maple_tree.o
AR drivers/char/built-in.a
CC kernel/time/namespace.o
CC drivers/base/regmap/regmap.o
CC drivers/base/firmware_loader/builtin/main.o
CC drivers/base/power/wakeirq.o
CC drivers/pci/pci-label.o
CC drivers/tty/serial/8250/8250_exar.o
CC fs/ext4/ioctl.o
CC net/netfilter/nf_nat_irc.o
CC arch/x86/kernel/cpu/mshyperv.o
CC drivers/acpi/acpica/nsarguments.o
CC drivers/acpi/acpica/nsconvert.o
CC net/wireless/scan.o
AR drivers/base/firmware_loader/builtin/built-in.a
CC drivers/base/firmware_loader/main.o
CC lib/memcat_p.o
CC fs/nfs/pagelist.o
CC net/ipv4/tcp_timer.o
CC drivers/gpu/drm/ttm/ttm_sys_manager.o
CC fs/nfs/read.o
CC net/netlabel/netlabel_domainhash.o
CC fs/ext4/mballoc.o
CC drivers/base/power/main.o
CC crypto/jitterentropy.o
CC drivers/tty/tty_mutex.o
CC drivers/acpi/acpica/nsdump.o
CC crypto/jitterentropy-kcapi.o
CC net/wireless/nl80211.o
AR kernel/time/built-in.a
CC drivers/acpi/acpica/nseval.o
CC drivers/base/power/wakeup.o
CC fs/nfs/symlink.o
CC mm/mlock.o
CC fs/lockd/svclock.o
CC drivers/pci/vgaarb.o
CC drivers/gpu/drm/i915/i915_sysfs.o
CC io_uring/napi.o
CC fs/lockd/svcshare.o
CC net/netlabel/netlabel_addrlist.o
CC [M] sound/hda/trace.o
CC drivers/gpu/drm/ttm/ttm_agp_backend.o
CC drivers/acpi/acpica/nsinit.o
CC drivers/base/power/wakeup_stats.o
CC drivers/base/power/trace.o
CC drivers/tty/serial/8250/8250_lpss.o
CC kernel/trace/trace_events_trigger.o
CC net/netfilter/nf_nat_sip.o
CC arch/x86/kernel/cpu/debugfs.o
CC [M] sound/hda/hdac_component.o
CC drivers/base/regmap/regcache.o
CC crypto/ghash-generic.o
CC drivers/acpi/acpica/nsload.o
CC drivers/acpi/acpica/nsnames.o
CC kernel/trace/trace_eprobe.o
CC net/netfilter/x_tables.o
CC net/sunrpc/auth_gss/gss_krb5_mech.o
AR drivers/base/firmware_loader/built-in.a
CC net/sunrpc/auth_gss/gss_krb5_seal.o
CC drivers/acpi/acpica/nsobject.o
AR drivers/gpu/drm/ttm/built-in.a
CC net/rfkill/core.o
AR drivers/gpu/drm/tilcdc/built-in.a
CC drivers/acpi/acpica/nsparse.o
CC net/netfilter/xt_tcpudp.o
CC crypto/hash_info.o
CC drivers/tty/serial/8250/8250_mid.o
CC crypto/rsapubkey.asn1.o
CC net/netlabel/netlabel_mgmt.o
CC net/netlabel/netlabel_unlabeled.o
CC crypto/rsaprivkey.asn1.o
CC fs/nfs/unlink.o
CC drivers/gpu/drm/i915/i915_utils.o
AR crypto/built-in.a
CC arch/x86/kernel/cpu/capflags.o
CC net/netlabel/netlabel_cipso_v4.o
AR drivers/pci/built-in.a
CC drivers/base/regmap/regcache-rbtree.o
AR arch/x86/kernel/cpu/built-in.a
CC lib/nmi_backtrace.o
CC [M] sound/hda/hdac_i915.o
CC arch/x86/kernel/irq.o
CC net/netlabel/netlabel_calipso.o
CC drivers/tty/serial/8250/8250_pci.o
CC drivers/acpi/acpica/nspredef.o
CC drivers/block/loop.o
CC [M] sound/hda/intel-dsp-config.o
CC drivers/block/virtio_blk.o
CC fs/lockd/svcproc.o
CC mm/mmap.o
AR drivers/misc/eeprom/built-in.a
AR drivers/misc/cb710/built-in.a
AR drivers/misc/ti-st/built-in.a
AR drivers/misc/lis3lv02d/built-in.a
AR drivers/misc/cardreader/built-in.a
AR drivers/misc/keba/built-in.a
AR drivers/misc/built-in.a
CC drivers/gpu/drm/i915/intel_clock_gating.o
AR drivers/mfd/built-in.a
CC fs/lockd/svcsubs.o
CC drivers/base/regmap/regcache-flat.o
CC net/ipv4/tcp_ipv4.o
AR drivers/base/power/built-in.a
CC net/sunrpc/auth_gss/gss_krb5_unseal.o
CC net/sunrpc/auth_gss/gss_krb5_wrap.o
CC fs/lockd/mon.o
CC net/sunrpc/auth_gss/gss_krb5_crypto.o
AR io_uring/built-in.a
CC drivers/base/regmap/regcache-maple.o
CC drivers/acpi/acpica/nsprepkg.o
CC fs/nfs/write.o
AR drivers/base/test/built-in.a
CC net/netfilter/xt_CONNSECMARK.o
CC drivers/base/regmap/regmap-debugfs.o
CC net/mac80211/status.o
CC net/sunrpc/auth_null.o
CC drivers/tty/serial/8250/8250_pericom.o
CC net/core/fib_notifier.o
CC net/rfkill/input.o
CC net/netfilter/xt_NFLOG.o
CC kernel/trace/trace_kprobe.o
CC net/core/xdp.o
CC net/ipv4/tcp_minisocks.o
CC net/ipv6/udp.o
CC net/ipv6/udplite.o
CC [M] sound/hda/intel-nhlt.o
CC net/sunrpc/auth_tls.o
CC drivers/acpi/acpica/nsrepair.o
CC net/ipv4/tcp_cong.o
CC mm/mmu_gather.o
CC net/core/flow_offload.o
CC net/netfilter/xt_SECMARK.o
CC drivers/acpi/x86/apple.o
CC net/sunrpc/auth_gss/gss_krb5_keys.o
CC drivers/acpi/acpica/nsrepair2.o
CC drivers/gpu/drm/i915/intel_device_info.o
CC drivers/acpi/acpica/nssearch.o
CC net/ipv4/tcp_metrics.o
CC net/mac80211/driver-ops.o
AR net/netlabel/built-in.a
CC mm/mprotect.o
AR net/rfkill/built-in.a
CC mm/mremap.o
CC lib/objpool.o
CC net/core/gro.o
CC kernel/resource.o
CC drivers/acpi/acpica/nsutils.o
CC drivers/gpu/drm/i915/intel_memory_region.o
AR drivers/tty/serial/8250/built-in.a
AR drivers/base/regmap/built-in.a
AR drivers/tty/serial/built-in.a
CC drivers/base/component.o
CC drivers/tty/tty_ldsem.o
CC [M] sound/hda/intel-sdw-acpi.o
CC fs/lockd/trace.o
CC fs/lockd/xdr.o
AR drivers/block/built-in.a
CC drivers/acpi/x86/cmos_rtc.o
CC fs/nfs/namespace.o
CC net/mac80211/sta_info.o
CC lib/plist.o
CC fs/lockd/clnt4xdr.o
CC mm/msync.o
CC fs/nfs/mount_clnt.o
CC net/wireless/mlme.o
CC fs/lockd/xdr4.o
CC lib/radix-tree.o
CC net/9p/mod.o
CC net/dns_resolver/dns_key.o
CC lib/ratelimit.o
CC drivers/acpi/acpica/nswalk.o
CC net/ipv6/raw.o
CC arch/x86/kernel/irq_32.o
CC net/sunrpc/auth_unix.o
CC net/netfilter/xt_TCPMSS.o
CC fs/nfs/nfstrace.o
CC lib/rbtree.o
LD [M] sound/hda/snd-hda-core.o
AR net/sunrpc/auth_gss/built-in.a
LD [M] sound/hda/snd-intel-dspcfg.o
LD [M] sound/hda/snd-intel-sdw-acpi.o
CC fs/ext4/migrate.o
CC net/mac80211/wep.o
AR sound/xen/built-in.a
CC drivers/base/core.o
AR sound/virtio/built-in.a
CC drivers/tty/tty_baudrate.o
CC drivers/base/bus.o
CC sound/sound_core.o
CC drivers/acpi/x86/lpss.o
CC net/ipv4/tcp_fastopen.o
CC net/core/netdev-genl.o
CC drivers/acpi/acpica/nsxfeval.o
CC net/9p/client.o
CC lib/seq_buf.o
CC drivers/gpu/drm/i915/intel_pcode.o
CC net/dns_resolver/dns_query.o
CC net/wireless/ibss.o
CC mm/page_vma_mapped.o
CC drivers/base/dd.o
CC net/9p/error.o
CC drivers/acpi/tables.o
CC kernel/sysctl.o
CC net/ipv6/icmp.o
CC mm/pagewalk.o
CC sound/last.o
CC net/ipv4/tcp_rate.o
CC kernel/trace/error_report-traces.o
CC arch/x86/kernel/dumpstack_32.o
CC drivers/base/syscore.o
CC net/core/netdev-genl-gen.o
CC fs/ext4/mmp.o
CC drivers/acpi/acpica/nsxfname.o
CC net/core/gso.o
CC net/ipv4/tcp_recovery.o
CC fs/nfs/export.o
CC drivers/tty/tty_jobctrl.o
CC arch/x86/kernel/time.o
CC drivers/acpi/osi.o
CC drivers/base/driver.o
CC drivers/acpi/x86/s2idle.o
CC fs/lockd/svc4proc.o
CC fs/ext4/move_extent.o
AR sound/built-in.a
CC drivers/tty/n_null.o
CC drivers/acpi/x86/utils.o
CC net/ipv6/mcast.o
AR net/dns_resolver/built-in.a
CC drivers/acpi/acpica/nsxfobj.o
CC net/core/net-sysfs.o
CC fs/lockd/procfs.o
CC net/ipv6/reassembly.o
CC lib/siphash.o
CC drivers/acpi/acpica/psargs.o
CC net/ipv6/tcp_ipv6.o
CC kernel/capability.o
CC fs/ext4/namei.o
CC arch/x86/kernel/ioport.o
CC net/netfilter/xt_conntrack.o
CC drivers/gpu/drm/i915/intel_region_ttm.o
CC net/core/hotdata.o
CC arch/x86/kernel/dumpstack.o
CC kernel/trace/power-traces.o
CC kernel/ptrace.o
CC drivers/base/class.o
CC net/mac80211/aead_api.o
CC net/ipv4/tcp_ulp.o
CC mm/pgtable-generic.o
CC kernel/user.o
CC arch/x86/kernel/nmi.o
CC drivers/tty/pty.o
CC drivers/gpu/drm/virtio/virtgpu_drv.o
CC net/ipv4/tcp_offload.o
CC net/core/net-procfs.o
CC mm/rmap.o
CC lib/string.o
CC drivers/acpi/osl.o
CC net/core/netpoll.o
CC drivers/acpi/acpica/psloop.o
AR drivers/gpu/drm/imx/built-in.a
CC net/ipv4/tcp_plb.o
CC fs/ext4/page-io.o
CC drivers/acpi/x86/blacklist.o
CC kernel/signal.o
CC kernel/sys.o
AR fs/unicode/built-in.a
CC fs/autofs/init.o
CC net/ipv6/ping.o
CC lib/timerqueue.o
CC net/9p/protocol.o
CC fs/autofs/inode.o
CC kernel/umh.o
CC net/ipv6/exthdrs.o
CC net/mac80211/wpa.o
CC fs/autofs/root.o
CC lib/vsprintf.o
CC arch/x86/kernel/ldt.o
CC lib/win_minmax.o
CC net/ipv4/datagram.o
CC net/ipv6/datagram.o
CC drivers/acpi/acpica/psobject.o
AR fs/lockd/built-in.a
CC net/handshake/alert.o
CC drivers/gpu/drm/i915/intel_runtime_pm.o
AR drivers/acpi/x86/built-in.a
CC drivers/acpi/utils.o
CC net/ipv6/ip6_flowlabel.o
CC net/mac80211/scan.o
CC drivers/gpu/drm/virtio/virtgpu_kms.o
CC drivers/tty/tty_audit.o
CC mm/vmalloc.o
CC net/netfilter/xt_policy.o
CC net/sunrpc/svc.o
CC drivers/base/platform.o
CC net/netfilter/xt_state.o
CC lib/xarray.o
CC [M] net/netfilter/nf_log_syslog.o
CC net/9p/trans_common.o
CC fs/autofs/symlink.o
CC drivers/acpi/acpica/psopcode.o
CC fs/ext4/readpage.o
CC mm/process_vm_access.o
CC drivers/base/cpu.o
CC net/9p/trans_fd.o
CC net/core/fib_rules.o
CC drivers/acpi/acpica/psopinfo.o
CC drivers/tty/sysrq.o
CC kernel/workqueue.o
CC drivers/gpu/drm/virtio/virtgpu_gem.o
CC drivers/gpu/drm/i915/intel_sbi.o
CC net/wireless/sme.o
CC arch/x86/kernel/setup.o
CC kernel/trace/rpm-traces.o
CC net/ipv4/raw.o
CC arch/x86/kernel/x86_init.o
CC drivers/acpi/acpica/psparse.o
AR drivers/nfc/built-in.a
CC drivers/gpu/drm/i915/intel_step.o
CC drivers/acpi/reboot.o
CC kernel/pid.o
AR drivers/gpu/drm/i2c/built-in.a
CC fs/autofs/waitq.o
CC net/sunrpc/svcsock.o
CC drivers/acpi/acpica/psscope.o
CC net/ipv4/udp.o
CC net/wireless/chan.o
CC fs/autofs/expire.o
CC drivers/acpi/acpica/pstree.o
CC drivers/gpu/drm/i915/intel_uncore.o
CC net/9p/trans_virtio.o
CC drivers/gpu/drm/virtio/virtgpu_vram.o
CC drivers/gpu/drm/virtio/virtgpu_display.o
CC net/handshake/genl.o
CC net/mac80211/offchannel.o
CC [M] net/netfilter/xt_mark.o
CC net/mac80211/ht.o
CC drivers/gpu/drm/i915/intel_wakeref.o
CC mm/page_alloc.o
CC fs/ext4/resize.o
CC net/ipv4/udplite.o
CC drivers/base/firmware.o
CC kernel/task_work.o
CC mm/init-mm.o
CC drivers/gpu/drm/virtio/virtgpu_vq.o
CC mm/memblock.o
CC net/handshake/netlink.o
CC net/ipv4/udp_offload.o
CC drivers/acpi/nvs.o
CC arch/x86/kernel/i8259.o
AR drivers/tty/built-in.a
CC drivers/acpi/acpica/psutils.o
CC kernel/extable.o
CC net/ipv6/inet6_connection_sock.o
CC net/handshake/request.o
CC kernel/trace/trace_dynevent.o
CC drivers/gpu/drm/i915/vlv_sideband.o
CC net/handshake/tlshd.o
CC mm/slub.o
CC drivers/base/init.o
CC drivers/gpu/drm/i915/vlv_suspend.o
AR drivers/dax/hmem/built-in.a
AR drivers/dax/built-in.a
CC arch/x86/kernel/irqinit.o
CC drivers/dma-buf/dma-buf.o
CC drivers/acpi/acpica/pswalk.o
CC fs/autofs/dev-ioctl.o
CC drivers/dma-buf/dma-fence.o
CC kernel/trace/trace_probe.o
CC net/core/net-traces.o
CC drivers/acpi/acpica/psxface.o
CC drivers/dma-buf/dma-fence-array.o
CC fs/nfs/sysfs.o
CC drivers/dma-buf/dma-fence-chain.o
CC [M] net/netfilter/xt_nat.o
CC drivers/dma-buf/dma-fence-unwrap.o
CC lib/lockref.o
CC fs/ext4/super.o
CC net/sunrpc/svcauth.o
CC fs/ext4/symlink.o
CC drivers/base/map.o
CC net/mac80211/agg-tx.o
AR drivers/cxl/core/built-in.a
AR drivers/cxl/built-in.a
CC drivers/gpu/drm/i915/soc/intel_dram.o
CC net/ipv4/arp.o
AR net/9p/built-in.a
CC net/devres.o
CC lib/bcd.o
CC drivers/acpi/acpica/rsaddr.o
CC lib/sort.o
CC fs/ext4/sysfs.o
CC net/socket.o
CC kernel/trace/trace_uprobe.o
CC lib/parser.o
CC drivers/gpu/drm/i915/soc/intel_gmch.o
CC arch/x86/kernel/jump_label.o
CC mm/madvise.o
CC drivers/gpu/drm/virtio/virtgpu_fence.o
CC net/ipv4/icmp.o
CC drivers/dma-buf/dma-resv.o
CC net/ipv6/udp_offload.o
AR fs/autofs/built-in.a
CC arch/x86/kernel/irq_work.o
CC fs/9p/vfs_super.o
CC drivers/gpu/drm/i915/soc/intel_pch.o
CC drivers/base/devres.o
CC fs/9p/vfs_inode.o
CC drivers/dma-buf/sync_file.o
CC drivers/acpi/acpica/rscalc.o
AR fs/hostfs/built-in.a
CC fs/debugfs/inode.o
CC drivers/acpi/acpica/rscreate.o
CC fs/tracefs/inode.o
CC lib/debug_locks.o
CC fs/tracefs/event_inode.o
CC net/handshake/trace.o
CC kernel/trace/rethook.o
CC net/wireless/ethtool.o
CC fs/nfs/fs_context.o
CC net/wireless/mesh.o
CC lib/random32.o
CC fs/ext4/xattr.o
CC arch/x86/kernel/probe_roms.o
CC [M] net/netfilter/xt_LOG.o
CC drivers/acpi/acpica/rsdumpinfo.o
CC fs/9p/vfs_inode_dotl.o
CC fs/ext4/xattr_hurd.o
CC kernel/params.o
CC drivers/gpu/drm/i915/i915_memcpy.o
CC net/mac80211/agg-rx.o
CC drivers/gpu/drm/virtio/virtgpu_object.o
CC fs/nfs/nfsroot.o
CC drivers/base/attribute_container.o
CC fs/debugfs/file.o
AR drivers/dma-buf/built-in.a
CC drivers/gpu/drm/virtio/virtgpu_debugfs.o
CC net/wireless/ap.o
CC kernel/kthread.o
CC lib/bust_spinlocks.o
CC fs/nfs/sysctl.o
CC drivers/acpi/acpica/rsinfo.o
CC net/mac80211/vht.o
CC net/sunrpc/svcauth_unix.o
CC net/ipv6/seg6.o
CC net/mac80211/he.o
CC net/mac80211/s1g.o
CC net/mac80211/ibss.o
CC drivers/gpu/drm/i915/i915_mm.o
CC net/ipv4/devinet.o
CC net/ipv4/af_inet.o
CC arch/x86/kernel/sys_ia32.o
CC drivers/acpi/acpica/rsio.o
CC fs/9p/vfs_addr.o
CC net/wireless/trace.o
AR fs/tracefs/built-in.a
CC [M] fs/efivarfs/inode.o
CC drivers/gpu/drm/i915/i915_sw_fence.o
CC net/wireless/ocb.o
CC drivers/base/transport_class.o
CC fs/ext4/xattr_trusted.o
CC drivers/gpu/drm/i915/i915_sw_fence_work.o
CC mm/page_io.o
CC mm/swap_state.o
CC lib/kasprintf.o
CC fs/nfs/nfs3super.o
CC fs/9p/vfs_file.o
CC drivers/gpu/drm/virtio/virtgpu_plane.o
AR kernel/trace/built-in.a
CC drivers/acpi/acpica/rsirq.o
CC [M] net/netfilter/xt_MASQUERADE.o
CC drivers/macintosh/mac_hid.o
CC [M] net/netfilter/xt_addrtype.o
CC lib/bitmap.o
CC drivers/base/topology.o
CC drivers/gpu/drm/i915/i915_syncmap.o
CC kernel/sys_ni.o
CC net/wireless/pmsr.o
CC lib/scatterlist.o
AR drivers/scsi/pcmcia/built-in.a
CC drivers/scsi/scsi.o
CC drivers/gpu/drm/i915/i915_user_extensions.o
AR net/handshake/built-in.a
AR fs/debugfs/built-in.a
CC drivers/scsi/hosts.o
CC drivers/scsi/scsi_ioctl.o
CC drivers/acpi/acpica/rslist.o
CC [M] fs/efivarfs/file.o
CC fs/nfs/nfs3client.o
CC arch/x86/kernel/ksysfs.o
CC fs/9p/vfs_dir.o
CC net/core/selftests.o
CC [M] fs/efivarfs/super.o
CC lib/list_sort.o
CC kernel/nsproxy.o
CC net/ipv6/fib6_notifier.o
AR drivers/macintosh/built-in.a
CC fs/nfs/nfs3proc.o
CC drivers/acpi/wakeup.o
CC mm/swapfile.o
CC [M] fs/efivarfs/vars.o
GEN net/wireless/shipped-certs.c
CC drivers/acpi/acpica/rsmemory.o
CC drivers/gpu/drm/i915/i915_debugfs.o
CC drivers/gpu/drm/virtio/virtgpu_ioctl.o
CC fs/nfs/nfs3xdr.o
CC kernel/notifier.o
CC fs/9p/vfs_dentry.o
CC net/mac80211/iface.o
CC drivers/base/container.o
CC net/ipv6/rpl.o
CC fs/9p/v9fs.o
CC fs/9p/fid.o
CC lib/uuid.o
CC kernel/ksysfs.o
CC arch/x86/kernel/bootflag.o
CC fs/ext4/xattr_user.o
CC fs/ext4/fast_commit.o
CC drivers/acpi/acpica/rsmisc.o
CC drivers/gpu/drm/virtio/virtgpu_prime.o
CC drivers/gpu/drm/virtio/virtgpu_trace_points.o
CC drivers/scsi/scsicam.o
CC drivers/acpi/sleep.o
CC kernel/cred.o
CC drivers/scsi/scsi_error.o
CC drivers/base/property.o
CC lib/iov_iter.o
CC net/ipv6/ioam6.o
AR net/netfilter/built-in.a
CC net/sysctl_net.o
CC fs/ext4/orphan.o
CC net/ipv4/igmp.o
LD [M] fs/efivarfs/efivarfs.o
CC fs/ext4/acl.o
CC fs/open.o
CC net/wireless/shipped-certs.o
CC net/ipv4/fib_frontend.o
CC arch/x86/kernel/e820.o
CC drivers/gpu/drm/i915/i915_debugfs_params.o
CC drivers/gpu/drm/virtio/virtgpu_submit.o
CC net/ipv6/sysctl_net_ipv6.o
CC fs/read_write.o
CC drivers/acpi/acpica/rsserial.o
CC fs/file_table.o
CC kernel/reboot.o
CC arch/x86/kernel/pci-dma.o
CC net/ipv6/xfrm6_policy.o
CC fs/9p/xattr.o
CC lib/clz_ctz.o
CC drivers/scsi/scsi_lib.o
CC lib/bsearch.o
CC drivers/scsi/constants.o
CC net/mac80211/link.o
CC fs/super.o
CC net/sunrpc/addr.o
CC fs/ext4/xattr_security.o
CC drivers/acpi/device_sysfs.o
CC kernel/async.o
CC net/core/ptp_classifier.o
CC drivers/acpi/acpica/rsutils.o
CC drivers/acpi/acpica/rsxface.o
CC drivers/scsi/scsi_lib_dma.o
CC drivers/scsi/scsi_scan.o
CC kernel/range.o
CC fs/nfs/nfs3acl.o
CC drivers/gpu/drm/i915/i915_pmu.o
CC drivers/acpi/device_pm.o
CC kernel/smpboot.o
CC net/mac80211/rate.o
CC net/core/netprio_cgroup.o
CC lib/find_bit.o
CC lib/llist.o
AR fs/9p/built-in.a
CC kernel/ucount.o
CC fs/nfs/nfs4proc.o
CC drivers/base/cacheinfo.o
CC kernel/regset.o
AR drivers/gpu/drm/virtio/built-in.a
CC kernel/ksyms_common.o
CC arch/x86/kernel/quirks.o
CC net/mac80211/michael.o
CC kernel/groups.o
AR drivers/gpu/drm/panel/built-in.a
CC lib/lwq.o
CC drivers/acpi/acpica/tbdata.o
CC net/mac80211/tkip.o
CC lib/memweight.o
CC mm/swap_slots.o
AR drivers/gpu/drm/bridge/analogix/built-in.a
AR drivers/gpu/drm/bridge/cadence/built-in.a
AR drivers/gpu/drm/bridge/imx/built-in.a
AR drivers/gpu/drm/bridge/synopsys/built-in.a
CC mm/dmapool.o
AR drivers/gpu/drm/bridge/built-in.a
CC net/ipv6/xfrm6_state.o
CC mm/hugetlb.o
CC lib/kfifo.o
CC arch/x86/kernel/kdebugfs.o
CC arch/x86/kernel/alternative.o
CC arch/x86/kernel/i8253.o
CC lib/percpu-refcount.o
GEN drivers/scsi/scsi_devinfo_tbl.c
CC drivers/scsi/scsi_devinfo.o
CC net/ipv6/xfrm6_input.o
CC kernel/kcmp.o
CC fs/char_dev.o
AR drivers/gpu/drm/hisilicon/built-in.a
CC net/ipv6/xfrm6_output.o
CC fs/stat.o
CC net/sunrpc/rpcb_clnt.o
CC drivers/acpi/acpica/tbfadt.o
CC kernel/freezer.o
CC net/ipv6/xfrm6_protocol.o
CC net/sunrpc/timer.o
CC lib/rhashtable.o
CC lib/base64.o
CC drivers/acpi/acpica/tbfind.o
CC fs/nfs/nfs4xdr.o
CC net/sunrpc/xdr.o
CC drivers/base/swnode.o
CC arch/x86/kernel/hw_breakpoint.o
CC fs/exec.o
CC drivers/base/auxiliary.o
AR drivers/nvme/common/built-in.a
AR drivers/nvme/host/built-in.a
CC kernel/profile.o
CC drivers/scsi/scsi_sysctl.o
AR drivers/nvme/target/built-in.a
AR drivers/nvme/built-in.a
CC drivers/gpu/drm/i915/gt/gen2_engine_cs.o
CC arch/x86/kernel/tsc.o
CC mm/mmu_notifier.o
AR drivers/gpu/drm/mxsfb/built-in.a
CC fs/nfs/nfs4state.o
CC net/core/netclassid_cgroup.o
CC kernel/stacktrace.o
CC lib/once.o
CC fs/nfs/nfs4renewd.o
CC lib/refcount.o
CC arch/x86/kernel/tsc_msr.o
CC drivers/acpi/proc.o
CC drivers/scsi/scsi_proc.o
CC drivers/scsi/scsi_debugfs.o
CC drivers/acpi/acpica/tbinstal.o
CC drivers/acpi/acpica/tbprint.o
CC drivers/scsi/scsi_trace.o
CC drivers/ata/libata-core.o
CC lib/rcuref.o
AR drivers/net/phy/qcom/built-in.a
CC drivers/net/phy/mdio-boardinfo.o
AR drivers/net/pse-pd/built-in.a
CC lib/usercopy.o
CC drivers/base/devtmpfs.o
CC drivers/acpi/acpica/tbutils.o
CC lib/errseq.o
CC drivers/base/module.o
CC net/ipv4/fib_semantics.o
CC lib/bucket_locks.o
CC lib/generic-radix-tree.o
CC arch/x86/kernel/io_delay.o
CC net/ipv4/fib_trie.o
CC drivers/acpi/bus.o
CC drivers/scsi/scsi_logging.o
CC drivers/scsi/scsi_pm.o
CC net/ipv6/netfilter.o
CC fs/pipe.o
CC net/ipv6/proc.o
CC drivers/gpu/drm/i915/gt/gen6_engine_cs.o
CC arch/x86/kernel/rtc.o
CC drivers/acpi/acpica/tbxface.o
CC fs/nfs/nfs4super.o
CC net/ipv4/fib_notifier.o
CC kernel/dma.o
CC drivers/net/mdio/acpi_mdio.o
CC arch/x86/kernel/resource.o
CC net/ipv4/inet_fragment.o
CC kernel/smp.o
AR drivers/net/pcs/built-in.a
CC mm/migrate.o
CC net/ipv6/syncookies.o
AS arch/x86/kernel/irqflags.o
CC net/ipv6/calipso.o
CC drivers/acpi/glue.o
CC drivers/acpi/scan.o
AR drivers/net/ethernet/3com/built-in.a
CC drivers/net/ethernet/8390/ne2k-pci.o
CC drivers/net/ethernet/8390/8390.o
CC drivers/scsi/scsi_bsg.o
CC net/core/dst_cache.o
CC lib/bitmap-str.o
CC net/mac80211/aes_cmac.o
CC net/core/gro_cells.o
CC drivers/scsi/scsi_common.o
CC drivers/gpu/drm/i915/gt/gen6_ppgtt.o
CC net/ipv6/ah6.o
CC drivers/acpi/acpica/tbxfload.o
CC drivers/net/mdio/fwnode_mdio.o
CC lib/string_helpers.o
CC drivers/net/phy/stubs.o
CC kernel/uid16.o
CC drivers/base/auxiliary_sysfs.o
CC arch/x86/kernel/static_call.o
CC drivers/scsi/scsi_transport_spi.o
CC drivers/scsi/virtio_scsi.o
CC drivers/acpi/mipi-disco-img.o
CC drivers/acpi/acpica/tbxfroot.o
CC drivers/acpi/acpica/utaddress.o
CC drivers/ata/libata-scsi.o
CC net/core/failover.o
CC net/ipv6/esp6.o
CC fs/nfs/nfs4file.o
CC lib/hexdump.o
CC fs/namei.o
CC kernel/kallsyms.o
CC drivers/acpi/resource.o
CC arch/x86/kernel/process.o
CC drivers/base/devcoredump.o
CC drivers/acpi/acpica/utalloc.o
CC drivers/net/phy/mdio_devres.o
CC fs/fcntl.o
CC lib/kstrtox.o
CC kernel/acct.o
CC drivers/ata/libata-eh.o
CC net/mac80211/aes_gmac.o
CC drivers/scsi/sd.o
CC drivers/net/phy/phy.o
CC drivers/acpi/acpica/utascii.o
CC drivers/scsi/sr.o
CC net/sunrpc/sunrpc_syms.o
AR drivers/net/ethernet/8390/built-in.a
CC net/sunrpc/cache.o
AR drivers/net/mdio/built-in.a
CC net/ipv6/sit.o
AR drivers/net/ethernet/adaptec/built-in.a
CC drivers/ata/libata-transport.o
CC drivers/ata/libata-trace.o
AR drivers/net/wireless/admtek/built-in.a
AR drivers/net/ethernet/agere/built-in.a
CC net/ipv6/addrconf_core.o
AR drivers/net/ethernet/alacritech/built-in.a
AR drivers/net/wireless/ath/built-in.a
AR drivers/net/wireless/atmel/built-in.a
AR drivers/net/ethernet/alteon/built-in.a
AR drivers/net/wireless/broadcom/built-in.a
AR drivers/net/ethernet/amazon/built-in.a
AR drivers/net/ethernet/amd/built-in.a
AR drivers/net/wireless/intel/built-in.a
AR drivers/net/usb/built-in.a
AR drivers/net/wireless/intersil/built-in.a
AR drivers/net/ethernet/aquantia/built-in.a
AR drivers/net/ethernet/arc/built-in.a
CC fs/nfs/delegation.o
AR drivers/net/ethernet/asix/built-in.a
AR drivers/net/wireless/marvell/built-in.a
AR drivers/net/wireless/mediatek/built-in.a
AR drivers/net/ethernet/atheros/built-in.a
CC fs/nfs/nfs4idmap.o
AR drivers/net/ethernet/cadence/built-in.a
AR drivers/net/wireless/microchip/built-in.a
CC net/sunrpc/rpc_pipe.o
CC drivers/net/ethernet/broadcom/bnx2.o
AR drivers/net/wireless/purelifi/built-in.a
AR drivers/net/wireless/quantenna/built-in.a
AR drivers/net/wireless/ralink/built-in.a
AR drivers/net/wireless/realtek/built-in.a
AR drivers/net/wireless/rsi/built-in.a
AR drivers/net/wireless/silabs/built-in.a
AR drivers/net/wireless/st/built-in.a
CC net/sunrpc/sysfs.o
AR drivers/net/wireless/ti/built-in.a
AR drivers/net/wireless/zydas/built-in.a
CC lib/iomap.o
CC mm/page_counter.o
AR drivers/net/wireless/virtual/built-in.a
CC drivers/acpi/acpica/utbuffer.o
CC lib/iomap_copy.o
AR drivers/net/wireless/built-in.a
CC drivers/net/phy/phy-c45.o
CC drivers/gpu/drm/i915/gt/gen7_renderclear.o
CC lib/devres.o
CC drivers/base/platform-msi.o
CC kernel/vmcore_info.o
CC net/ipv4/ping.o
CC net/ipv6/exthdrs_core.o
CC kernel/elfcorehdr.o
CC net/ipv6/ip6_checksum.o
CC lib/check_signature.o
AR net/core/built-in.a
CC net/ipv4/ip_tunnel_core.o
CC drivers/gpu/drm/i915/gt/gen8_engine_cs.o
CC mm/hugetlb_cgroup.o
CC net/sunrpc/svc_xprt.o
AR drivers/net/ethernet/brocade/built-in.a
CC net/mac80211/fils_aead.o
AR drivers/net/ethernet/cavium/common/built-in.a
CC lib/interval_tree.o
AR drivers/net/ethernet/cavium/thunder/built-in.a
CC net/mac80211/cfg.o
AR drivers/net/ethernet/cavium/liquidio/built-in.a
CC drivers/acpi/acpica/utcksum.o
AR drivers/net/ethernet/cavium/octeon/built-in.a
AR drivers/net/ethernet/cavium/built-in.a
CC fs/nfs/callback.o
AR drivers/net/ethernet/chelsio/built-in.a
CC drivers/acpi/acpica/utcopy.o
AR fs/ext4/built-in.a
CC drivers/ata/libata-sata.o
CC drivers/base/physical_location.o
AR drivers/gpu/drm/tiny/built-in.a
CC fs/nfs/callback_xdr.o
CC drivers/ata/libata-sff.o
AR drivers/gpu/drm/xlnx/built-in.a
CC drivers/base/trace.o
CC drivers/net/phy/phy-core.o
CC lib/assoc_array.o
CC drivers/net/phy/phy_device.o
CC net/ipv6/ip6_icmp.o
AR drivers/net/ethernet/cisco/built-in.a
CC net/sunrpc/xprtmultipath.o
CC drivers/net/mii.o
CC fs/nfs/callback_proc.o
CC kernel/crash_reserve.o
CC net/mac80211/ethtool.o
CC drivers/acpi/acpi_processor.o
CC drivers/ata/libata-pmp.o
CC drivers/net/phy/linkmode.o
CC net/ipv6/output_core.o
CC drivers/net/phy/mdio_bus.o
CC drivers/acpi/acpica/utexcep.o
CC drivers/net/phy/mdio_device.o
CC arch/x86/kernel/ptrace.o
CC drivers/net/phy/swphy.o
CC drivers/ata/libata-acpi.o
CC drivers/gpu/drm/i915/gt/gen8_ppgtt.o
CC fs/nfs/nfs4namespace.o
CC net/mac80211/rx.o
CC net/ipv6/protocol.o
CC drivers/net/phy/fixed_phy.o
CC mm/early_ioremap.o
CC drivers/acpi/acpica/utdebug.o
AR drivers/base/built-in.a
CC lib/bitrev.o
CC net/sunrpc/stats.o
CC drivers/firewire/init_ohci1394_dma.o
CC drivers/cdrom/cdrom.o
CC drivers/ata/libata-pata-timings.o
CC net/sunrpc/sysctl.o
AR drivers/net/ethernet/cortina/built-in.a
CC kernel/kexec_core.o
CC net/ipv6/ip6_offload.o
AR drivers/net/ethernet/dec/tulip/built-in.a
AR drivers/net/ethernet/dec/built-in.a
CC lib/crc-ccitt.o
CC drivers/gpu/drm/i915/gt/intel_breadcrumbs.o
CC net/mac80211/spectmgmt.o
AR drivers/auxdisplay/built-in.a
CC net/mac80211/tx.o
CC net/ipv4/gre_offload.o
CC drivers/acpi/acpica/utdecode.o
CC drivers/ata/ahci.o
CC drivers/net/phy/realtek.o
CC lib/crc16.o
CC drivers/net/loopback.o
CC net/ipv6/tcpv6_offload.o
CC drivers/acpi/processor_core.o
CC drivers/scsi/sr_ioctl.o
CC drivers/ata/libahci.o
CC drivers/gpu/drm/i915/gt/intel_context.o
CC drivers/scsi/sr_vendor.o
CC drivers/ata/ata_piix.o
CC kernel/crash_core.o
CC mm/secretmem.o
CC arch/x86/kernel/tls.o
CC mm/hmm.o
AR drivers/firewire/built-in.a
CC drivers/acpi/acpica/utdelete.o
CC drivers/acpi/processor_pdc.o
CC net/ipv6/exthdrs_offload.o
CC drivers/acpi/ec.o
CC drivers/pcmcia/cs.o
CC drivers/pcmcia/socket_sysfs.o
HOSTCC lib/gen_crc32table
CC net/ipv4/metrics.o
CC drivers/net/netconsole.o
CC drivers/acpi/dock.o
CC fs/ioctl.o
CC drivers/acpi/pci_root.o
CC fs/readdir.o
CC lib/xxhash.o
CC fs/nfs/nfs4getroot.o
CC fs/select.o
CC net/ipv6/inet6_hashtables.o
CC drivers/pcmcia/cardbus.o
CC drivers/acpi/acpica/uterror.o
CC net/ipv6/mcast_snoop.o
CC drivers/net/ethernet/broadcom/tg3.o
CC drivers/acpi/pci_link.o
CC kernel/kexec.o
CC drivers/gpu/drm/i915/gt/intel_context_sseu.o
CC drivers/acpi/acpica/uteval.o
CC drivers/scsi/sg.o
CC drivers/acpi/acpica/utglobal.o
CC drivers/pcmcia/ds.o
CC net/mac80211/key.o
CC net/mac80211/util.o
AR drivers/net/phy/built-in.a
CC drivers/net/virtio_net.o
CC net/mac80211/parse.o
CC drivers/acpi/acpica/uthex.o
CC mm/memfd.o
CC drivers/ata/pata_amd.o
CC arch/x86/kernel/step.o
CC fs/nfs/nfs4client.o
CC net/ipv4/netlink.o
CC net/ipv4/nexthop.o
CC kernel/utsname.o
CC mm/ptdump.o
CC kernel/pid_namespace.o
CC arch/x86/kernel/i8237.o
CC drivers/ata/pata_oldpiix.o
CC lib/genalloc.o
CC drivers/gpu/drm/i915/gt/intel_engine_cs.o
AR drivers/cdrom/built-in.a
CC drivers/usb/common/common.o
CC drivers/usb/core/usb.o
CC drivers/pcmcia/pcmcia_resource.o
CC arch/x86/kernel/stacktrace.o
CC drivers/acpi/acpica/utids.o
CC drivers/gpu/drm/i915/gt/intel_engine_heartbeat.o
CC lib/percpu_counter.o
CC drivers/gpu/drm/i915/gt/intel_engine_pm.o
CC drivers/usb/core/hub.o
CC drivers/gpu/drm/i915/gt/intel_engine_user.o
CC drivers/gpu/drm/i915/gt/intel_execlists_submission.o
CC drivers/usb/core/hcd.o
CC drivers/usb/core/urb.o
CC net/mac80211/wme.o
CC drivers/acpi/acpica/utinit.o
CC drivers/acpi/pci_irq.o
AR drivers/usb/phy/built-in.a
CC fs/nfs/nfs4session.o
CC fs/dcache.o
AR drivers/gpu/drm/gud/built-in.a
CC net/ipv4/udp_tunnel_stub.o
CC net/ipv4/ip_tunnel.o
CC mm/execmem.o
CC arch/x86/kernel/reboot.o
CC net/mac80211/chan.o
AR net/sunrpc/built-in.a
CC net/mac80211/trace.o
CC drivers/acpi/acpica/utlock.o
CC lib/audit.o
CC drivers/usb/mon/mon_main.o
CC drivers/usb/host/pci-quirks.o
AR drivers/gpu/drm/solomon/built-in.a
CC drivers/usb/host/ehci-hcd.o
CC drivers/usb/common/debug.o
CC drivers/acpi/acpica/utmath.o
CC kernel/stop_machine.o
AR net/ipv6/built-in.a
CC drivers/acpi/acpica/utmisc.o
AR net/wireless/built-in.a
CC drivers/ata/pata_sch.o
CC drivers/acpi/acpica/utmutex.o
CC fs/nfs/dns_resolve.o
CC [M] drivers/gpu/drm/scheduler/sched_main.o
CC drivers/usb/mon/mon_stat.o
CC fs/nfs/nfs4trace.o
AR drivers/usb/common/built-in.a
CC net/ipv4/sysctl_net_ipv4.o
CC drivers/usb/class/usblp.o
CC drivers/acpi/acpica/utnonansi.o
CC fs/inode.o
CC drivers/usb/host/ehci-pci.o
AR mm/built-in.a
CC drivers/ata/pata_mpiix.o
CC kernel/audit.o
CC drivers/ata/ata_generic.o
CC drivers/pcmcia/cistpl.o
CC lib/syscall.o
CC drivers/scsi/scsi_sysfs.o
CC [M] drivers/gpu/drm/scheduler/sched_fence.o
CC arch/x86/kernel/msr.o
CC net/ipv4/proc.o
CC drivers/usb/host/ohci-hcd.o
CC drivers/gpu/drm/i915/gt/intel_ggtt.o
CC drivers/usb/mon/mon_text.o
CC drivers/acpi/acpica/utobject.o
CC drivers/pcmcia/pcmcia_cis.o
AR drivers/net/ethernet/dlink/built-in.a
CC drivers/pcmcia/rsrc_mgr.o
CC drivers/gpu/drm/i915/gt/intel_ggtt_fencing.o
AR drivers/net/ethernet/emulex/built-in.a
HOSTCC drivers/gpu/drm/xe/xe_gen_wa_oob
CC kernel/auditfilter.o
CC drivers/usb/host/ohci-pci.o
CC arch/x86/kernel/cpuid.o
CC drivers/input/serio/serio.o
GEN xe_wa_oob.c xe_wa_oob.h
CC [M] drivers/gpu/drm/xe/xe_bb.o
CC drivers/input/serio/i8042.o
CC drivers/net/net_failover.o
CC arch/x86/kernel/early-quirks.o
CC arch/x86/kernel/smp.o
CC net/ipv4/fib_rules.o
CC drivers/usb/host/uhci-hcd.o
AR drivers/usb/class/built-in.a
CC lib/errname.o
CC drivers/input/serio/serport.o
CC lib/nlattr.o
CC lib/cpu_rmap.o
CC drivers/usb/host/xhci.o
CC drivers/acpi/acpica/utosi.o
AR drivers/ata/built-in.a
CC drivers/gpu/drm/i915/gt/intel_gt.o
CC lib/dynamic_queue_limits.o
CC [M] drivers/gpu/drm/scheduler/sched_entity.o
CC drivers/pcmcia/rsrc_nonstatic.o
CC arch/x86/kernel/smpboot.o
CC fs/attr.o
CC drivers/usb/host/xhci-mem.o
CC drivers/usb/mon/mon_bin.o
CC net/ipv4/ipmr.o
CC drivers/input/serio/libps2.o
CC drivers/gpu/drm/drm_aperture.o
CC [M] drivers/gpu/drm/xe/xe_bo.o
CC net/ipv4/ipmr_base.o
CC drivers/acpi/acpica/utownerid.o
CC drivers/gpu/drm/drm_atomic.o
AR drivers/scsi/built-in.a
CC drivers/input/keyboard/atkbd.o
CC drivers/usb/core/message.o
CC drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.o
CC drivers/pcmcia/yenta_socket.o
CC net/ipv4/syncookies.o
CC lib/glob.o
CC drivers/rtc/lib.o
CC arch/x86/kernel/tsc_sync.o
CC drivers/rtc/class.o
CC net/mac80211/mlme.o
CC drivers/acpi/acpica/utpredef.o
CC drivers/gpu/drm/drm_atomic_uapi.o
CC drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.o
CC kernel/auditsc.o
LD [M] drivers/gpu/drm/scheduler/gpu-sched.o
CC drivers/rtc/interface.o
CC net/mac80211/tdls.o
CC drivers/gpu/drm/drm_auth.o
CC net/ipv4/tunnel4.o
CC drivers/gpu/drm/i915/gt/intel_gt_clock_utils.o
CC kernel/audit_watch.o
CC drivers/acpi/acpica/utresdecode.o
CC arch/x86/kernel/setup_percpu.o
CC net/mac80211/ocb.o
CC drivers/rtc/nvmem.o
AR drivers/input/serio/built-in.a
AR drivers/i3c/built-in.a
CC drivers/i2c/algos/i2c-algo-bit.o
AR drivers/media/i2c/built-in.a
AR drivers/media/tuners/built-in.a
AR drivers/media/rc/keymaps/built-in.a
AR drivers/media/common/b2c2/built-in.a
AR drivers/media/rc/built-in.a
AR drivers/media/common/saa7146/built-in.a
CC drivers/rtc/dev.o
AR drivers/media/platform/allegro-dvt/built-in.a
CC lib/strncpy_from_user.o
AR drivers/media/common/siano/built-in.a
CC drivers/gpu/drm/drm_blend.o
AR drivers/media/common/v4l2-tpg/built-in.a
AR drivers/media/platform/amlogic/meson-ge2d/built-in.a
CC lib/strnlen_user.o
AR drivers/media/platform/amlogic/built-in.a
AR drivers/media/common/videobuf2/built-in.a
AR drivers/media/common/built-in.a
AR drivers/media/platform/amphion/built-in.a
CC net/ipv4/ipconfig.o
CC kernel/audit_fsnotify.o
AR drivers/media/platform/aspeed/built-in.a
AR drivers/media/platform/atmel/built-in.a
CC drivers/acpi/acpica/utresrc.o
AR drivers/media/platform/broadcom/built-in.a
CC drivers/rtc/proc.o
AR drivers/media/platform/cadence/built-in.a
AR drivers/media/platform/imagination/built-in.a
AR drivers/media/platform/chips-media/coda/built-in.a
CC drivers/acpi/acpi_apd.o
AR drivers/media/platform/chips-media/wave5/built-in.a
AR drivers/usb/mon/built-in.a
CC drivers/acpi/acpica/utstate.o
AR drivers/media/platform/chips-media/built-in.a
CC drivers/acpi/acpi_platform.o
CC drivers/rtc/sysfs.o
AR drivers/media/platform/intel/built-in.a
CC drivers/usb/host/xhci-ext-caps.o
AR drivers/media/platform/marvell/built-in.a
AR drivers/media/platform/mediatek/jpeg/built-in.a
CC drivers/usb/host/xhci-ring.o
AR drivers/media/platform/mediatek/mdp/built-in.a
AR drivers/media/platform/mediatek/vcodec/common/built-in.a
AR drivers/media/platform/mediatek/vcodec/encoder/built-in.a
AR drivers/media/platform/mediatek/vcodec/decoder/built-in.a
AR drivers/media/platform/mediatek/vcodec/built-in.a
AR drivers/media/platform/mediatek/vpu/built-in.a
AR drivers/media/platform/mediatek/mdp3/built-in.a
AR drivers/media/platform/mediatek/built-in.a
CC drivers/gpu/drm/i915/gt/intel_gt_debugfs.o
AR drivers/input/keyboard/built-in.a
AR drivers/media/platform/microchip/built-in.a
CC drivers/usb/host/xhci-hub.o
AR drivers/media/platform/nuvoton/built-in.a
CC drivers/input/mouse/psmouse-base.o
AR drivers/media/platform/nvidia/tegra-vde/built-in.a
AR drivers/media/platform/nxp/dw100/built-in.a
CC drivers/gpu/drm/drm_bridge.o
AR drivers/media/platform/nvidia/built-in.a
AR drivers/media/platform/nxp/imx-jpeg/built-in.a
CC drivers/i2c/busses/i2c-i801.o
AR drivers/media/platform/nxp/imx8-isi/built-in.a
AR drivers/media/platform/nxp/built-in.a
AR drivers/i2c/muxes/built-in.a
CC drivers/gpu/drm/i915/gt/intel_gt_engines_debugfs.o
CC drivers/input/mouse/synaptics.o
CC drivers/usb/host/xhci-dbg.o
AR drivers/media/platform/qcom/camss/built-in.a
AR drivers/media/platform/qcom/venus/built-in.a
CC drivers/acpi/acpica/utstring.o
AR drivers/media/platform/qcom/built-in.a
CC arch/x86/kernel/mpparse.o
CC fs/bad_inode.o
CC drivers/i2c/i2c-boardinfo.o
AR drivers/media/platform/raspberrypi/pisp_be/built-in.a
CC [M] drivers/gpu/drm/xe/xe_bo_evict.o
CC lib/net_utils.o
AR drivers/media/platform/raspberrypi/built-in.a
CC drivers/acpi/acpi_pnp.o
CC drivers/gpu/drm/drm_cache.o
AR drivers/media/platform/renesas/rcar-vin/built-in.a
AR drivers/pcmcia/built-in.a
CC drivers/acpi/acpica/utstrsuppt.o
AR drivers/media/platform/renesas/rzg2l-cru/built-in.a
CC drivers/acpi/acpica/utstrtoul64.o
AR drivers/media/platform/renesas/vsp1/built-in.a
CC drivers/usb/core/driver.o
AR drivers/media/platform/renesas/built-in.a
CC net/ipv4/netfilter.o
CC drivers/rtc/rtc-mc146818-lib.o
CC drivers/rtc/rtc-cmos.o
AR drivers/media/platform/rockchip/rga/built-in.a
CC lib/sg_pool.o
AR drivers/media/platform/rockchip/rkisp1/built-in.a
CC lib/stackdepot.o
AR drivers/media/platform/rockchip/built-in.a
AR drivers/media/platform/samsung/exynos-gsc/built-in.a
AR drivers/media/platform/samsung/exynos4-is/built-in.a
AR drivers/media/pci/ttpci/built-in.a
AR drivers/i2c/algos/built-in.a
AR drivers/media/platform/samsung/s3c-camif/built-in.a
AR drivers/media/pci/b2c2/built-in.a
AR drivers/media/platform/samsung/s5p-g2d/built-in.a
AR drivers/media/platform/samsung/s5p-jpeg/built-in.a
AR drivers/media/platform/samsung/s5p-mfc/built-in.a
AR drivers/media/usb/b2c2/built-in.a
AR drivers/media/usb/dvb-usb/built-in.a
AR drivers/media/pci/pluto2/built-in.a
CC net/mac80211/airtime.o
AR drivers/media/platform/samsung/built-in.a
AR drivers/media/pci/dm1105/built-in.a
AR drivers/input/joystick/built-in.a
CC drivers/usb/storage/scsiglue.o
AR drivers/media/usb/dvb-usb-v2/built-in.a
AR drivers/media/usb/s2255/built-in.a
AR drivers/media/platform/st/sti/bdisp/built-in.a
CC drivers/usb/storage/protocol.o
CC drivers/usb/storage/transport.o
AR drivers/media/pci/pt1/built-in.a
AR drivers/media/usb/siano/built-in.a
AR drivers/media/usb/ttusb-budget/built-in.a
CC net/mac80211/eht.o
AR drivers/media/platform/st/sti/c8sectpfe/built-in.a
AR drivers/media/platform/st/sti/delta/built-in.a
AR drivers/media/pci/pt3/built-in.a
AR drivers/media/pci/mantis/built-in.a
AR drivers/media/usb/ttusb-dec/built-in.a
CC drivers/i2c/i2c-core-base.o
AR drivers/media/usb/built-in.a
AR drivers/media/platform/st/sti/hva/built-in.a
AR drivers/media/pci/ngene/built-in.a
CC drivers/acpi/acpica/utxface.o
AR drivers/media/platform/st/stm32/built-in.a
AR drivers/media/pci/ddbridge/built-in.a
AR drivers/media/platform/st/built-in.a
CC drivers/usb/storage/usb.o
AR drivers/usb/misc/built-in.a
AR drivers/media/pci/saa7146/built-in.a
AR drivers/media/pci/smipcie/built-in.a
AR drivers/media/pci/netup_unidvb/built-in.a
AR drivers/media/mmc/siano/built-in.a
AR drivers/media/platform/sunxi/sun4i-csi/built-in.a
AR drivers/media/mmc/built-in.a
AR drivers/media/platform/sunxi/sun6i-csi/built-in.a
AR drivers/media/pci/intel/ipu3/built-in.a
AR drivers/media/platform/ti/am437x/built-in.a
AR drivers/media/firewire/built-in.a
AR drivers/media/platform/sunxi/sun6i-mipi-csi2/built-in.a
AR drivers/media/pci/intel/ivsc/built-in.a
AR drivers/media/platform/ti/cal/built-in.a
AR drivers/media/pci/intel/built-in.a
AR drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/built-in.a
CC drivers/usb/early/ehci-dbgp.o
AR drivers/media/pci/built-in.a
AR drivers/media/platform/ti/vpe/built-in.a
AR drivers/media/platform/sunxi/sun8i-di/built-in.a
AR drivers/media/platform/ti/davinci/built-in.a
AR drivers/media/platform/sunxi/sun8i-rotate/built-in.a
AR drivers/media/platform/ti/j721e-csi2rx/built-in.a
CC drivers/usb/storage/initializers.o
AR drivers/media/platform/sunxi/built-in.a
CC drivers/input/mouse/focaltech.o
CC kernel/audit_tree.o
CC drivers/acpi/power.o
CC net/mac80211/led.o
CC fs/nfs/nfs4sysctl.o
AR drivers/media/platform/ti/omap/built-in.a
CC drivers/acpi/event.o
AR drivers/media/platform/ti/omap3isp/built-in.a
AR drivers/media/platform/ti/built-in.a
CC kernel/kprobes.o
AR drivers/media/platform/verisilicon/built-in.a
AR drivers/media/platform/via/built-in.a
AR drivers/media/platform/xilinx/built-in.a
AR drivers/media/platform/built-in.a
CC drivers/acpi/evged.o
CC kernel/seccomp.o
AR drivers/media/spi/built-in.a
CC kernel/relay.o
CC lib/asn1_decoder.o
AR drivers/media/test-drivers/built-in.a
AR drivers/media/built-in.a
CC kernel/utsname_sysctl.o
CC drivers/i2c/i2c-core-smbus.o
CC drivers/gpu/drm/drm_client.o
CC drivers/acpi/acpica/utxfinit.o
CC drivers/acpi/sysfs.o
CC drivers/usb/host/xhci-trace.o
CC drivers/usb/host/xhci-debugfs.o
GEN lib/oid_registry_data.c
CC drivers/input/mouse/alps.o
CC drivers/gpu/drm/i915/gt/intel_gt_irq.o
CC drivers/usb/host/xhci-pci.o
CC arch/x86/kernel/trace_clock.o
CC arch/x86/kernel/trace.o
AR drivers/input/tablet/built-in.a
AR drivers/input/touchscreen/built-in.a
CC [M] drivers/gpu/drm/xe/xe_devcoredump.o
CC [M] drivers/gpu/drm/xe/xe_device.o
CC kernel/delayacct.o
CC net/ipv4/tcp_cubic.o
AR drivers/pps/clients/built-in.a
AR drivers/i2c/busses/built-in.a
AR drivers/pps/generators/built-in.a
CC drivers/pps/pps.o
CC drivers/usb/storage/sierra_ms.o
CC drivers/gpu/drm/drm_client_modeset.o
CC drivers/usb/storage/option_ms.o
AR drivers/rtc/built-in.a
CC drivers/acpi/acpica/utxferror.o
CC [M] drivers/gpu/drm/xe/xe_device_sysfs.o
CC drivers/acpi/acpica/utxfmutex.o
CC drivers/usb/storage/usual-tables.o
CC drivers/input/mouse/byd.o
CC drivers/usb/core/config.o
CC drivers/i2c/i2c-core-acpi.o
CC kernel/taskstats.o
CC drivers/input/mouse/logips2pp.o
CC drivers/ptp/ptp_clock.o
CC lib/ucs2_string.o
CC drivers/acpi/property.o
CC drivers/ptp/ptp_chardev.o
AR drivers/usb/early/built-in.a
CC net/mac80211/pm.o
CC drivers/ptp/ptp_sysfs.o
CC drivers/usb/core/file.o
CC drivers/acpi/debugfs.o
AR fs/nfs/built-in.a
CC fs/file.o
AR drivers/net/ethernet/engleder/built-in.a
CC net/ipv4/tcp_sigpool.o
CC kernel/tsacct.o
CC drivers/gpu/drm/drm_color_mgmt.o
AR drivers/acpi/acpica/built-in.a
CC arch/x86/kernel/rethook.o
CC net/ipv4/cipso_ipv4.o
CC drivers/acpi/acpi_lpat.o
CC lib/sbitmap.o
CC kernel/tracepoint.o
CC drivers/acpi/acpi_pcc.o
CC drivers/input/mouse/lifebook.o
CC drivers/pps/kapi.o
CC net/mac80211/rc80211_minstrel_ht.o
CC lib/group_cpus.o
CC drivers/power/supply/power_supply_core.o
CC lib/fw_table.o
CC drivers/hwmon/hwmon.o
AR drivers/usb/storage/built-in.a
CC [M] drivers/gpu/drm/xe/xe_dma_buf.o
CC [M] drivers/gpu/drm/xe/xe_drm_client.o
CC drivers/gpu/drm/drm_connector.o
CC drivers/usb/core/buffer.o
CC drivers/acpi/ac.o
CC kernel/irq_work.o
CC drivers/gpu/drm/i915/gt/intel_gt_mcr.o
CC drivers/gpu/drm/i915/gt/intel_gt_pm.o
CC [M] drivers/gpu/drm/xe/xe_exec.o
CC drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.o
CC kernel/static_call.o
CC drivers/input/mouse/trackpoint.o
CC drivers/acpi/button.o
CC drivers/usb/core/sysfs.o
CC [M] drivers/gpu/drm/xe/xe_execlist.o
CC drivers/i2c/i2c-smbus.o
CC drivers/pps/sysfs.o
CC [M] drivers/gpu/drm/xe/xe_exec_queue.o
CC arch/x86/kernel/vmcore_info_32.o
CC drivers/acpi/fan_core.o
CC [M] drivers/gpu/drm/xe/xe_force_wake.o
CC drivers/ptp/ptp_vclock.o
CC drivers/usb/core/endpoint.o
CC drivers/ptp/ptp_kvm_x86.o
CC net/ipv4/xfrm4_policy.o
AR drivers/input/misc/built-in.a
CC drivers/input/input.o
CC net/ipv4/xfrm4_state.o
AR lib/lib.a
CC drivers/input/input-compat.o
CC net/ipv4/xfrm4_input.o
CC drivers/acpi/fan_attr.o
CC drivers/gpu/drm/drm_crtc.o
CC kernel/padata.o
CC drivers/acpi/fan_hwmon.o
CC [M] drivers/gpu/drm/xe/xe_ggtt.o
CC drivers/gpu/drm/drm_displayid.o
CC drivers/power/supply/power_supply_sysfs.o
GEN lib/crc32table.h
CC lib/oid_registry.o
CC kernel/jump_label.o
CC drivers/acpi/acpi_video.o
AR drivers/pps/built-in.a
CC drivers/input/mouse/cypress_ps2.o
AR drivers/thermal/broadcom/built-in.a
AR drivers/thermal/renesas/built-in.a
CC kernel/context_tracking.o
AR drivers/thermal/samsung/built-in.a
CC drivers/thermal/intel/intel_tcc.o
CC drivers/usb/core/devio.o
CC drivers/thermal/intel/therm_throt.o
CC net/ipv4/xfrm4_output.o
CC drivers/input/input-mt.o
CC drivers/ptp/ptp_kvm_common.o
CC arch/x86/kernel/machine_kexec_32.o
CC drivers/gpu/drm/drm_drv.o
CC drivers/gpu/drm/drm_dumb_buffers.o
CC drivers/acpi/video_detect.o
CC drivers/input/input-poller.o
AS arch/x86/kernel/relocate_kernel_32.o
CC lib/crc32.o
CC fs/filesystems.o
CC fs/namespace.o
CC drivers/acpi/processor_driver.o
CC [M] drivers/thermal/intel/x86_pkg_temp_thermal.o
CC drivers/power/supply/power_supply_leds.o
AR drivers/watchdog/built-in.a
CC drivers/gpu/drm/drm_edid.o
CC drivers/md/md.o
AR drivers/i2c/built-in.a
CC drivers/gpu/drm/drm_eld.o
CC drivers/md/md-bitmap.o
CC drivers/gpu/drm/drm_encoder.o
CC net/ipv4/xfrm4_protocol.o
CC drivers/gpu/drm/drm_file.o
CC fs/seq_file.o
AR drivers/usb/host/built-in.a
CC drivers/usb/core/notify.o
CC drivers/md/md-autodetect.o
AR drivers/hwmon/built-in.a
CC drivers/usb/core/generic.o
CC drivers/cpufreq/cpufreq.o
CC drivers/cpuidle/governors/menu.o
CC drivers/cpufreq/freq_table.o
CC drivers/cpuidle/governors/haltpoll.o
CC drivers/cpufreq/cpufreq_performance.o
CC drivers/gpu/drm/drm_fourcc.o
CC drivers/input/mouse/psmouse-smbus.o
CC drivers/cpuidle/cpuidle.o
CC drivers/md/dm.o
CC drivers/gpu/drm/i915/gt/intel_gt_pm_irq.o
CC drivers/gpu/drm/i915/gt/intel_gt_requests.o
AR drivers/thermal/st/built-in.a
CC drivers/md/dm-table.o
AR lib/built-in.a
CC drivers/power/supply/power_supply_hwmon.o
CC drivers/md/dm-target.o
CC drivers/acpi/processor_thermal.o
CC drivers/md/dm-linear.o
CC kernel/iomem.o
CC drivers/input/ff-core.o
AR drivers/ptp/built-in.a
CC drivers/acpi/processor_idle.o
CC drivers/usb/core/quirks.o
CC [M] drivers/gpu/drm/xe/xe_gpu_scheduler.o
CC arch/x86/kernel/crash_dump_32.o
CC kernel/rseq.o
CC drivers/acpi/processor_throttling.o
AR drivers/mmc/built-in.a
CC [M] drivers/gpu/drm/xe/xe_gsc.o
CC [M] drivers/gpu/drm/xe/xe_gsc_debugfs.o
AR drivers/thermal/qcom/built-in.a
CC [M] drivers/gpu/drm/xe/xe_gsc_proxy.o
CC drivers/cpuidle/driver.o
CC drivers/gpu/drm/i915/gt/intel_gt_sysfs.o
CC drivers/gpu/drm/drm_framebuffer.o
CC drivers/gpu/drm/drm_gem.o
CC drivers/usb/core/devices.o
CC drivers/usb/core/phy.o
CC fs/xattr.o
CC fs/libfs.o
AR drivers/thermal/intel/built-in.a
AR drivers/thermal/tegra/built-in.a
CC drivers/acpi/processor_perflib.o
CC drivers/input/touchscreen.o
AR drivers/thermal/mediatek/built-in.a
AR drivers/ufs/built-in.a
CC drivers/thermal/thermal_core.o
AR drivers/leds/trigger/built-in.a
AR drivers/leds/blink/built-in.a
AR drivers/leds/simple/built-in.a
CC drivers/leds/led-core.o
CC drivers/gpu/drm/drm_ioctl.o
AR drivers/power/supply/built-in.a
AR drivers/power/built-in.a
CC drivers/input/ff-memless.o
AR drivers/input/mouse/built-in.a
CC drivers/input/sparse-keymap.o
CC net/mac80211/wbrf.o
CC drivers/md/dm-stripe.o
CC drivers/gpu/drm/drm_lease.o
CC fs/fs-writeback.o
AR drivers/firmware/arm_ffa/built-in.a
AR drivers/firmware/arm_scmi/built-in.a
AR drivers/cpuidle/governors/built-in.a
AR drivers/firmware/broadcom/built-in.a
CC drivers/clocksource/acpi_pm.o
AR drivers/crypto/stm32/built-in.a
CC drivers/cpuidle/governor.o
CC arch/x86/kernel/crash.o
AR drivers/crypto/xilinx/built-in.a
AR drivers/firmware/cirrus/built-in.a
AR net/ipv4/built-in.a
AR drivers/net/ethernet/broadcom/built-in.a
AR drivers/firmware/meson/built-in.a
AR drivers/crypto/hisilicon/built-in.a
CC drivers/leds/led-class.o
AR drivers/net/ethernet/fujitsu/built-in.a
AR drivers/net/ethernet/ezchip/built-in.a
AR drivers/firmware/microchip/built-in.a
AR drivers/net/ethernet/fungible/built-in.a
AR drivers/crypto/intel/keembay/built-in.a
CC drivers/thermal/thermal_sysfs.o
AR drivers/net/ethernet/google/built-in.a
AR drivers/crypto/intel/ixp4xx/built-in.a
CC drivers/usb/core/port.o
AR drivers/crypto/intel/built-in.a
AR drivers/net/ethernet/huawei/built-in.a
AR drivers/crypto/starfive/built-in.a
AR drivers/crypto/built-in.a
CC drivers/net/ethernet/intel/e1000/e1000_main.o
CC drivers/firmware/efi/efi-bgrt.o
CC drivers/firmware/efi/libstub/efi-stub-helper.o
CC drivers/cpuidle/sysfs.o
CC drivers/net/ethernet/intel/e1000/e1000_hw.o
CC drivers/gpu/drm/drm_managed.o
CC drivers/net/ethernet/intel/e1000e/82571.o
CC drivers/usb/core/hcd-pci.o
CC drivers/usb/core/usb-acpi.o
CC drivers/net/ethernet/intel/e1000e/ich8lan.o
CC drivers/net/ethernet/intel/e1000e/80003es2lan.o
CC drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.o
CC drivers/input/vivaldi-fmap.o
CC [M] drivers/gpu/drm/xe/xe_gsc_submit.o
CC drivers/net/ethernet/intel/e100.o
AR kernel/built-in.a
CC drivers/acpi/container.o
CC [M] drivers/gpu/drm/xe/xe_gt.o
CC [M] drivers/gpu/drm/xe/xe_gt_ccs_mode.o
CC drivers/hid/usbhid/hid-core.o
CC drivers/clocksource/i8253.o
CC drivers/hid/usbhid/hiddev.o
CC drivers/hid/usbhid/hid-pidff.o
AR drivers/firmware/imx/built-in.a
CC arch/x86/kernel/module.o
AR drivers/firmware/psci/built-in.a
CC drivers/leds/led-triggers.o
CC drivers/gpu/drm/i915/gt/intel_gtt.o
CC drivers/gpu/drm/i915/gt/intel_llc.o
CC drivers/md/dm-ioctl.o
CC drivers/input/input-leds.o
CC drivers/gpu/drm/drm_mm.o
CC drivers/thermal/thermal_trip.o
CC drivers/input/evdev.o
CC drivers/cpuidle/poll_state.o
CC [M] drivers/gpu/drm/xe/xe_gt_clock.o
CC drivers/cpuidle/cpuidle-haltpoll.o
CC drivers/firmware/efi/efi.o
AR drivers/net/ethernet/i825xx/built-in.a
CC drivers/firmware/efi/vars.o
CC drivers/thermal/thermal_helpers.o
CC drivers/acpi/thermal_lib.o
CC drivers/cpufreq/cpufreq_userspace.o
CC drivers/hid/hid-core.o
AR net/mac80211/built-in.a
CC drivers/net/ethernet/intel/e1000e/mac.o
CC drivers/acpi/thermal.o
AR net/built-in.a
CC drivers/firmware/efi/libstub/gop.o
AR drivers/clocksource/built-in.a
CC drivers/hid/hid-input.o
CC fs/pnode.o
CC drivers/hid/hid-quirks.o
CC fs/splice.o
CC [M] drivers/gpu/drm/xe/xe_gt_freq.o
CC drivers/firmware/efi/reboot.o
CC drivers/firmware/efi/memattr.o
AR drivers/usb/core/built-in.a
AR drivers/usb/built-in.a
AR drivers/platform/x86/amd/built-in.a
CC drivers/firmware/efi/libstub/secureboot.o
AR drivers/platform/x86/intel/built-in.a
CC drivers/platform/x86/wmi.o
CC drivers/hid/hid-debug.o
CC drivers/md/dm-io.o
CC [M] drivers/gpu/drm/xe/xe_gt_idle.o
CC drivers/firmware/efi/libstub/tpm.o
CC drivers/platform/x86/wmi-bmof.o
CC arch/x86/kernel/doublefault_32.o
AR drivers/cpuidle/built-in.a
CC drivers/mailbox/mailbox.o
AR drivers/perf/built-in.a
AR drivers/hwtracing/intel_th/built-in.a
AR drivers/android/built-in.a
AR drivers/nvmem/layouts/built-in.a
CC drivers/nvmem/core.o
CC drivers/mailbox/pcc.o
CC drivers/thermal/thermal_hwmon.o
AR drivers/leds/built-in.a
CC drivers/cpufreq/cpufreq_ondemand.o
CC drivers/thermal/gov_step_wise.o
CC drivers/platform/x86/eeepc-laptop.o
CC drivers/firmware/efi/libstub/file.o
CC drivers/net/ethernet/intel/e1000/e1000_ethtool.o
CC drivers/gpu/drm/i915/gt/intel_lrc.o
CC [M] drivers/gpu/drm/xe/xe_gt_mcr.o
CC drivers/firmware/efi/tpm.o
CC arch/x86/kernel/early_printk.o
CC drivers/firmware/efi/memmap.o
CC drivers/platform/x86/p2sb.o
CC drivers/gpu/drm/i915/gt/intel_migrate.o
CC drivers/net/ethernet/intel/e1000/e1000_param.o
CC drivers/gpu/drm/drm_mode_config.o
CC drivers/firmware/efi/capsule.o
CC fs/sync.o
CC drivers/hid/hidraw.o
CC drivers/acpi/nhlt.o
CC drivers/acpi/acpi_memhotplug.o
CC drivers/firmware/efi/libstub/mem.o
CC arch/x86/kernel/hpet.o
AR drivers/input/built-in.a
CC arch/x86/kernel/amd_nb.o
CC drivers/hid/hid-generic.o
CC [M] drivers/gpu/drm/xe/xe_gt_pagefault.o
CC fs/utimes.o
AR drivers/hid/usbhid/built-in.a
CC drivers/firmware/efi/libstub/random.o
AR drivers/platform/surface/built-in.a
CC drivers/thermal/gov_user_space.o
CC drivers/firmware/efi/esrt.o
AR drivers/net/ethernet/microsoft/built-in.a
CC drivers/firmware/efi/runtime-wrappers.o
AR drivers/net/ethernet/litex/built-in.a
CC drivers/hid/hid-a4tech.o
CC fs/d_path.o
CC [M] drivers/gpu/drm/xe/xe_gt_sysfs.o
AR drivers/mailbox/built-in.a
CC drivers/firmware/efi/libstub/randomalloc.o
CC drivers/firmware/efi/libstub/pci.o
CC arch/x86/kernel/kvm.o
AR drivers/firmware/qcom/built-in.a
AR drivers/firmware/smccc/built-in.a
CC drivers/acpi/ioapic.o
CC drivers/hid/hid-apple.o
AR drivers/firmware/tegra/built-in.a
CC arch/x86/kernel/kvmclock.o
CC [M] drivers/gpu/drm/xe/xe_gt_throttle.o
CC drivers/gpu/drm/i915/gt/intel_mocs.o
CC drivers/md/dm-kcopyd.o
CC drivers/acpi/battery.o
CC drivers/firmware/efi/libstub/skip_spaces.o
CC drivers/gpu/drm/drm_mode_object.o
CC drivers/firmware/efi/libstub/lib-cmdline.o
CC drivers/net/ethernet/intel/e1000e/manage.o
CC drivers/cpufreq/cpufreq_governor.o
CC drivers/firmware/efi/capsule-loader.o
CC drivers/firmware/efi/libstub/lib-ctype.o
CC drivers/gpu/drm/drm_modes.o
AR drivers/thermal/built-in.a
CC drivers/gpu/drm/drm_modeset_lock.o
CC drivers/gpu/drm/drm_plane.o
CC [M] drivers/gpu/drm/xe/xe_gt_tlb_invalidation.o
CC drivers/firmware/efi/libstub/alignedmem.o
CC drivers/firmware/efi/libstub/relocate.o
CC drivers/acpi/bgrt.o
AR drivers/nvmem/built-in.a
CC drivers/hid/hid-belkin.o
AR drivers/firmware/xilinx/built-in.a
CC drivers/net/ethernet/intel/e1000e/nvm.o
CC drivers/hid/hid-cherry.o
CC drivers/firmware/efi/libstub/printk.o
CC drivers/net/ethernet/intel/e1000e/phy.o
CC fs/stack.o
CC drivers/acpi/spcr.o
CC arch/x86/kernel/paravirt.o
AR drivers/platform/x86/built-in.a
CC drivers/gpu/drm/i915/gt/intel_ppgtt.o
AR drivers/platform/built-in.a
CC drivers/gpu/drm/i915/gt/intel_rc6.o
CC drivers/hid/hid-chicony.o
AR drivers/net/ethernet/marvell/octeon_ep/built-in.a
CC drivers/hid/hid-cypress.o
AR drivers/net/ethernet/marvell/octeon_ep_vf/built-in.a
AR drivers/net/ethernet/marvell/octeontx2/built-in.a
CC drivers/gpu/drm/i915/gt/intel_region_lmem.o
AR drivers/net/ethernet/marvell/prestera/built-in.a
CC drivers/net/ethernet/marvell/sky2.o
CC drivers/firmware/efi/libstub/vsprintf.o
CC drivers/gpu/drm/i915/gt/intel_renderstate.o
CC arch/x86/kernel/pvclock.o
CC drivers/gpu/drm/drm_prime.o
CC drivers/hid/hid-ezkey.o
CC drivers/md/dm-sysfs.o
CC drivers/gpu/drm/i915/gt/intel_reset.o
CC fs/fs_struct.o
CC [M] drivers/gpu/drm/xe/xe_gt_topology.o
CC drivers/firmware/dmi_scan.o
CC [M] drivers/gpu/drm/xe/xe_guc.o
AR drivers/net/ethernet/mellanox/built-in.a
CC [M] drivers/gpu/drm/xe/xe_guc_ads.o
CC [M] drivers/gpu/drm/xe/xe_guc_ct.o
CC drivers/cpufreq/cpufreq_governor_attr_set.o
CC drivers/firmware/dmi-id.o
CC [M] drivers/gpu/drm/xe/xe_guc_db_mgr.o
CC drivers/firmware/memmap.o
CC drivers/hid/hid-gyration.o
CC drivers/hid/hid-ite.o
CC arch/x86/kernel/pcspeaker.o
CC drivers/gpu/drm/i915/gt/intel_ring.o
CC drivers/firmware/efi/libstub/x86-stub.o
CC drivers/cpufreq/acpi-cpufreq.o
CC drivers/gpu/drm/i915/gt/intel_ring_submission.o
CC drivers/firmware/efi/libstub/smbios.o
AR drivers/net/ethernet/meta/built-in.a
CC drivers/md/dm-stats.o
CC drivers/md/dm-rq.o
CC drivers/hid/hid-kensington.o
CC fs/statfs.o
CC drivers/cpufreq/amd-pstate.o
CC [M] drivers/gpu/drm/xe/xe_guc_hwconfig.o
AR drivers/net/ethernet/intel/e1000/built-in.a
CC drivers/gpu/drm/i915/gt/intel_rps.o
STUBCPY drivers/firmware/efi/libstub/alignedmem.stub.o
AR drivers/acpi/built-in.a
CC arch/x86/kernel/check.o
CC drivers/md/dm-io-rewind.o
CC drivers/gpu/drm/i915/gt/intel_sa_media.o
CC drivers/cpufreq/amd-pstate-trace.o
CC drivers/firmware/efi/earlycon.o
CC fs/fs_pin.o
CC arch/x86/kernel/uprobes.o
CC drivers/net/ethernet/intel/e1000e/param.o
CC arch/x86/kernel/perf_regs.o
CC drivers/hid/hid-lg.o
CC drivers/gpu/drm/drm_print.o
CC drivers/cpufreq/intel_pstate.o
CC fs/nsfs.o
STUBCPY drivers/firmware/efi/libstub/efi-stub-helper.stub.o
CC drivers/md/dm-builtin.o
CC [M] drivers/gpu/drm/xe/xe_guc_id_mgr.o
CC drivers/net/ethernet/intel/e1000e/ethtool.o
CC drivers/gpu/drm/i915/gt/intel_sseu.o
CC drivers/gpu/drm/drm_property.o
CC drivers/hid/hid-lgff.o
AR drivers/net/ethernet/micrel/built-in.a
AR drivers/net/ethernet/microchip/built-in.a
CC fs/fs_types.o
AR drivers/net/ethernet/mscc/built-in.a
AR drivers/net/ethernet/myricom/built-in.a
CC [M] drivers/gpu/drm/xe/xe_guc_klv_helpers.o
AR drivers/net/ethernet/natsemi/built-in.a
CC fs/fs_context.o
CC [M] drivers/gpu/drm/xe/xe_guc_log.o
CC [M] drivers/gpu/drm/xe/xe_guc_pc.o
CC drivers/gpu/drm/i915/gt/intel_sseu_debugfs.o
CC drivers/net/ethernet/intel/e1000e/netdev.o
CC arch/x86/kernel/tracepoint.o
CC drivers/hid/hid-lg4ff.o
CC drivers/gpu/drm/i915/gt/intel_timeline.o
CC drivers/hid/hid-lg-g15.o
CC drivers/hid/hid-microsoft.o
CC arch/x86/kernel/itmt.o
CC drivers/md/dm-raid1.o
CC drivers/gpu/drm/i915/gt/intel_tlb.o
STUBCPY drivers/firmware/efi/libstub/file.stub.o
STUBCPY drivers/firmware/efi/libstub/gop.stub.o
STUBCPY drivers/firmware/efi/libstub/lib-cmdline.stub.o
STUBCPY drivers/firmware/efi/libstub/lib-ctype.stub.o
STUBCPY drivers/firmware/efi/libstub/mem.stub.o
CC fs/fs_parser.o
STUBCPY drivers/firmware/efi/libstub/pci.stub.o
CC drivers/md/dm-log.o
CC drivers/gpu/drm/i915/gt/intel_wopcm.o
STUBCPY drivers/firmware/efi/libstub/printk.stub.o
CC drivers/gpu/drm/i915/gt/intel_workarounds.o
STUBCPY drivers/firmware/efi/libstub/random.stub.o
STUBCPY drivers/firmware/efi/libstub/randomalloc.stub.o
CC drivers/gpu/drm/drm_syncobj.o
STUBCPY drivers/firmware/efi/libstub/relocate.stub.o
STUBCPY drivers/firmware/efi/libstub/secureboot.stub.o
CC drivers/gpu/drm/i915/gt/shmem_utils.o
CC drivers/gpu/drm/i915/gt/sysfs_engines.o
STUBCPY drivers/firmware/efi/libstub/skip_spaces.stub.o
AR drivers/net/ethernet/neterion/built-in.a
STUBCPY drivers/firmware/efi/libstub/smbios.stub.o
CC arch/x86/kernel/umip.o
CC [M] drivers/gpu/drm/xe/xe_guc_submit.o
AR drivers/net/ethernet/netronome/built-in.a
STUBCPY drivers/firmware/efi/libstub/tpm.stub.o
CC [M] drivers/gpu/drm/xe/xe_heci_gsc.o
CC drivers/gpu/drm/i915/gt/intel_ggtt_gmch.o
CC drivers/gpu/drm/drm_sysfs.o
STUBCPY drivers/firmware/efi/libstub/vsprintf.stub.o
CC drivers/gpu/drm/i915/gt/gen6_renderstate.o
STUBCPY drivers/firmware/efi/libstub/x86-stub.stub.o
AR drivers/firmware/efi/libstub/lib.a
CC drivers/net/ethernet/intel/e1000e/ptp.o
AR drivers/firmware/efi/built-in.a
CC fs/fsopen.o
AR drivers/firmware/built-in.a
CC fs/init.o
CC [M] drivers/gpu/drm/xe/xe_hw_engine.o
CC drivers/gpu/drm/i915/gt/gen7_renderstate.o
AR drivers/net/ethernet/ni/built-in.a
CC drivers/md/dm-region-hash.o
CC drivers/net/ethernet/nvidia/forcedeth.o
CC [M] drivers/gpu/drm/xe/xe_hw_engine_class_sysfs.o
CC drivers/hid/hid-monterey.o
CC fs/kernel_read_file.o
CC fs/mnt_idmapping.o
CC drivers/gpu/drm/drm_trace_points.o
CC drivers/hid/hid-ntrig.o
CC drivers/gpu/drm/i915/gt/gen8_renderstate.o
CC drivers/gpu/drm/i915/gt/gen9_renderstate.o
CC drivers/gpu/drm/i915/gem/i915_gem_busy.o
CC arch/x86/kernel/unwind_frame.o
CC [M] drivers/gpu/drm/xe/xe_hw_engine_group.o
CC drivers/gpu/drm/drm_vblank.o
CC fs/remap_range.o
CC drivers/gpu/drm/i915/gem/i915_gem_clflush.o
CC drivers/gpu/drm/i915/gem/i915_gem_context.o
CC drivers/hid/hid-pl.o
CC drivers/hid/hid-petalynx.o
CC [M] drivers/gpu/drm/xe/xe_hw_fence.o
CC fs/pidfs.o
CC drivers/gpu/drm/i915/gem/i915_gem_create.o
CC drivers/hid/hid-redragon.o
CC drivers/gpu/drm/i915/gem/i915_gem_dmabuf.o
CC drivers/hid/hid-samsung.o
CC drivers/md/dm-zero.o
CC [M] drivers/gpu/drm/xe/xe_huc.o
CC drivers/hid/hid-sony.o
CC drivers/gpu/drm/drm_vblank_work.o
CC drivers/gpu/drm/i915/gem/i915_gem_domain.o
CC drivers/hid/hid-sunplus.o
CC drivers/hid/hid-topseed.o
AR drivers/net/ethernet/oki-semi/built-in.a
CC fs/buffer.o
AR drivers/net/ethernet/packetengines/built-in.a
CC drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o
CC drivers/gpu/drm/drm_vma_manager.o
CC drivers/gpu/drm/i915/gem/i915_gem_internal.o
CC drivers/gpu/drm/i915/gem/i915_gem_lmem.o
CC fs/mpage.o
CC drivers/gpu/drm/i915/gem/i915_gem_mman.o
CC drivers/gpu/drm/i915/gem/i915_gem_object.o
CC fs/proc_namespace.o
CC [M] drivers/gpu/drm/xe/xe_irq.o
CC [M] drivers/gpu/drm/xe/xe_lrc.o
CC drivers/gpu/drm/i915/gem/i915_gem_pages.o
CC drivers/gpu/drm/i915/gem/i915_gem_phys.o
CC drivers/gpu/drm/i915/gem/i915_gem_pm.o
AR arch/x86/kernel/built-in.a
AR arch/x86/built-in.a
CC [M] drivers/gpu/drm/xe/xe_migrate.o
CC [M] drivers/gpu/drm/xe/xe_mmio.o
CC drivers/gpu/drm/drm_writeback.o
CC drivers/gpu/drm/i915/gem/i915_gem_region.o
CC drivers/gpu/drm/drm_panel.o
AR drivers/cpufreq/built-in.a
CC [M] drivers/gpu/drm/xe/xe_mocs.o
CC [M] drivers/gpu/drm/xe/xe_module.o
CC drivers/gpu/drm/drm_pci.o
CC [M] drivers/gpu/drm/xe/xe_oa.o
CC drivers/gpu/drm/i915/gem/i915_gem_shmem.o
CC drivers/gpu/drm/i915/gem/i915_gem_shrinker.o
CC [M] drivers/gpu/drm/xe/xe_observation.o
AR drivers/md/built-in.a
CC [M] drivers/gpu/drm/xe/xe_pat.o
AR drivers/net/ethernet/marvell/built-in.a
CC drivers/gpu/drm/i915/gem/i915_gem_stolen.o
AR drivers/net/ethernet/qlogic/built-in.a
CC drivers/gpu/drm/i915/gem/i915_gem_throttle.o
CC fs/direct-io.o
CC drivers/gpu/drm/drm_debugfs.o
CC fs/eventpoll.o
CC drivers/gpu/drm/drm_debugfs_crc.o
CC fs/anon_inodes.o
CC fs/signalfd.o
CC [M] drivers/gpu/drm/xe/xe_pci.o
CC [M] drivers/gpu/drm/xe/xe_pcode.o
CC [M] drivers/gpu/drm/xe/xe_pm.o
CC drivers/gpu/drm/i915/gem/i915_gem_tiling.o
CC drivers/gpu/drm/i915/gem/i915_gem_ttm.o
CC fs/timerfd.o
CC fs/eventfd.o
CC drivers/gpu/drm/i915/gem/i915_gem_ttm_move.o
CC [M] drivers/gpu/drm/xe/xe_preempt_fence.o
CC drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.o
CC drivers/gpu/drm/drm_panel_orientation_quirks.o
CC fs/aio.o
AR drivers/net/ethernet/qualcomm/emac/built-in.a
CC fs/locks.o
CC [M] drivers/gpu/drm/xe/xe_pt.o
CC drivers/gpu/drm/drm_buddy.o
AR drivers/net/ethernet/qualcomm/built-in.a
CC drivers/gpu/drm/i915/gem/i915_gem_userptr.o
CC drivers/gpu/drm/drm_gem_shmem_helper.o
CC drivers/gpu/drm/drm_atomic_helper.o
AR drivers/hid/built-in.a
CC drivers/gpu/drm/i915/gem/i915_gem_wait.o
CC drivers/gpu/drm/i915/gem/i915_gemfs.o
CC drivers/gpu/drm/i915/i915_active.o
CC drivers/gpu/drm/drm_atomic_state_helper.o
CC drivers/gpu/drm/i915/i915_cmd_parser.o
CC drivers/gpu/drm/i915/i915_deps.o
CC drivers/gpu/drm/i915/i915_gem.o
CC fs/binfmt_misc.o
CC drivers/gpu/drm/drm_crtc_helper.o
CC [M] drivers/gpu/drm/xe/xe_pt_walk.o
CC [M] drivers/gpu/drm/xe/xe_query.o
CC drivers/gpu/drm/i915/i915_gem_evict.o
CC [M] drivers/gpu/drm/xe/xe_range_fence.o
CC drivers/gpu/drm/drm_damage_helper.o
CC fs/binfmt_script.o
CC drivers/gpu/drm/drm_encoder_slave.o
CC [M] drivers/gpu/drm/xe/xe_reg_sr.o
CC drivers/gpu/drm/i915/i915_gem_gtt.o
CC drivers/gpu/drm/i915/i915_gem_ww.o
CC [M] drivers/gpu/drm/xe/xe_reg_whitelist.o
CC [M] drivers/gpu/drm/xe/xe_rtp.o
CC fs/binfmt_elf.o
CC fs/mbcache.o
CC drivers/net/ethernet/realtek/8139too.o
AR drivers/net/ethernet/renesas/built-in.a
CC fs/posix_acl.o
AR drivers/net/ethernet/rdc/built-in.a
CC [M] drivers/gpu/drm/xe/xe_ring_ops.o
AR drivers/net/ethernet/rocker/built-in.a
CC drivers/gpu/drm/i915/i915_query.o
AR drivers/net/ethernet/samsung/built-in.a
AR drivers/net/ethernet/seeq/built-in.a
AR drivers/net/ethernet/silan/built-in.a
CC drivers/gpu/drm/i915/i915_request.o
CC drivers/gpu/drm/i915/i915_scheduler.o
CC drivers/gpu/drm/i915/i915_trace_points.o
CC drivers/gpu/drm/drm_flip_work.o
CC drivers/gpu/drm/i915/i915_ttm_buddy_manager.o
CC [M] drivers/gpu/drm/xe/xe_sa.o
AR drivers/net/ethernet/sis/built-in.a
CC [M] drivers/gpu/drm/xe/xe_sched_job.o
AR drivers/net/ethernet/sfc/built-in.a
AR drivers/net/ethernet/smsc/built-in.a
AR drivers/net/ethernet/socionext/built-in.a
CC drivers/net/ethernet/realtek/r8169_main.o
AR drivers/net/ethernet/stmicro/built-in.a
AR drivers/net/ethernet/sun/built-in.a
CC drivers/gpu/drm/i915/i915_vma.o
CC drivers/gpu/drm/i915/i915_vma_resource.o
CC drivers/gpu/drm/drm_format_helper.o
AR drivers/net/ethernet/tehuti/built-in.a
CC [M] drivers/gpu/drm/xe/xe_step.o
CC [M] drivers/gpu/drm/xe/xe_sync.o
CC drivers/gpu/drm/drm_gem_atomic_helper.o
CC [M] drivers/gpu/drm/xe/xe_tile.o
CC drivers/net/ethernet/realtek/r8169_firmware.o
AR drivers/net/ethernet/ti/built-in.a
AR drivers/net/ethernet/vertexcom/built-in.a
CC fs/coredump.o
AR drivers/net/ethernet/via/built-in.a
AR drivers/net/ethernet/wangxun/built-in.a
CC drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.o
AR drivers/net/ethernet/nvidia/built-in.a
AR drivers/net/ethernet/wiznet/built-in.a
AR drivers/net/ethernet/xilinx/built-in.a
AR drivers/net/ethernet/xircom/built-in.a
CC fs/drop_caches.o
CC drivers/net/ethernet/realtek/r8169_phy_config.o
AR drivers/net/ethernet/synopsys/built-in.a
CC drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.o
CC fs/sysctls.o
CC drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.o
AR drivers/net/ethernet/intel/e1000e/built-in.a
AR drivers/net/ethernet/intel/built-in.a
CC drivers/gpu/drm/drm_gem_framebuffer_helper.o
CC drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_debugfs.o
AR drivers/net/ethernet/pensando/built-in.a
CC drivers/gpu/drm/drm_kms_helper_common.o
CC fs/fhandle.o
CC [M] drivers/gpu/drm/xe/xe_tile_sysfs.o
CC drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.o
CC [M] drivers/gpu/drm/xe/xe_trace.o
CC drivers/gpu/drm/drm_modeset_helper.o
CC drivers/gpu/drm/drm_plane_helper.o
CC [M] drivers/gpu/drm/xe/xe_trace_bo.o
CC drivers/gpu/drm/drm_probe_helper.o
CC [M] drivers/gpu/drm/xe/xe_trace_guc.o
CC [M] drivers/gpu/drm/xe/xe_ttm_sys_mgr.o
CC drivers/gpu/drm/i915/gt/uc/intel_guc.o
CC drivers/gpu/drm/i915/gt/uc/intel_guc_ads.o
CC [M] drivers/gpu/drm/xe/xe_ttm_stolen_mgr.o
CC [M] drivers/gpu/drm/xe/xe_ttm_vram_mgr.o
CC drivers/gpu/drm/i915/gt/uc/intel_guc_capture.o
CC drivers/gpu/drm/i915/gt/uc/intel_guc_ct.o
CC drivers/gpu/drm/drm_rect.o
CC [M] drivers/gpu/drm/xe/xe_tuning.o
CC drivers/gpu/drm/drm_self_refresh_helper.o
CC [M] drivers/gpu/drm/xe/xe_uc.o
CC [M] drivers/gpu/drm/xe/xe_uc_fw.o
CC [M] drivers/gpu/drm/xe/xe_vm.o
CC drivers/gpu/drm/i915/gt/uc/intel_guc_debugfs.o
CC [M] drivers/gpu/drm/xe/xe_vram.o
CC drivers/gpu/drm/drm_simple_kms_helper.o
CC drivers/gpu/drm/bridge/panel.o
CC drivers/gpu/drm/drm_mipi_dsi.o
CC drivers/gpu/drm/i915/gt/uc/intel_guc_fw.o
CC drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.o
CC drivers/gpu/drm/i915/gt/uc/intel_guc_log.o
CC drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.o
CC [M] drivers/gpu/drm/xe/xe_vram_freq.o
CC drivers/gpu/drm/i915/gt/uc/intel_guc_rc.o
CC drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.o
CC [M] drivers/gpu/drm/drm_exec.o
CC [M] drivers/gpu/drm/xe/xe_wait_user_fence.o
CC [M] drivers/gpu/drm/drm_gpuvm.o
CC [M] drivers/gpu/drm/xe/xe_wa.o
CC [M] drivers/gpu/drm/xe/xe_wopcm.o
CC drivers/gpu/drm/i915/gt/uc/intel_guc_submission.o
CC [M] drivers/gpu/drm/xe/xe_hmm.o
CC drivers/gpu/drm/i915/gt/uc/intel_huc.o
CC drivers/gpu/drm/i915/gt/uc/intel_huc_debugfs.o
CC drivers/gpu/drm/i915/gt/uc/intel_huc_fw.o
CC drivers/gpu/drm/i915/gt/uc/intel_uc.o
CC [M] drivers/gpu/drm/xe/xe_hwmon.o
CC drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.o
CC [M] drivers/gpu/drm/drm_suballoc.o
CC [M] drivers/gpu/drm/drm_gem_ttm_helper.o
CC [M] drivers/gpu/drm/xe/xe_gt_sriov_vf.o
CC [M] drivers/gpu/drm/xe/xe_guc_relay.o
CC [M] drivers/gpu/drm/xe/xe_memirq.o
CC drivers/gpu/drm/i915/gt/uc/intel_uc_fw.o
CC [M] drivers/gpu/drm/xe/xe_sriov.o
CC [M] drivers/gpu/drm/xe/display/ext/i915_irq.o
CC [M] drivers/gpu/drm/xe/display/ext/i915_utils.o
CC [M] drivers/gpu/drm/xe/display/intel_fb_bo.o
CC [M] drivers/gpu/drm/xe/display/intel_fbdev_fb.o
CC drivers/gpu/drm/i915/gt/intel_gsc.o
CC drivers/gpu/drm/i915/i915_hwmon.o
CC [M] drivers/gpu/drm/xe/display/xe_display.o
CC [M] drivers/gpu/drm/xe/display/xe_display_misc.o
CC [M] drivers/gpu/drm/xe/display/xe_display_rps.o
CC drivers/gpu/drm/i915/display/hsw_ips.o
AR fs/built-in.a
CC [M] drivers/gpu/drm/xe/display/xe_display_wa.o
CC [M] drivers/gpu/drm/xe/display/xe_dsb_buffer.o
CC drivers/gpu/drm/i915/display/i9xx_plane.o
CC [M] drivers/gpu/drm/xe/display/xe_fb_pin.o
CC [M] drivers/gpu/drm/xe/display/xe_hdcp_gsc.o
CC drivers/gpu/drm/i915/display/i9xx_wm.o
CC drivers/gpu/drm/i915/display/intel_alpm.o
CC drivers/gpu/drm/i915/display/intel_atomic.o
CC drivers/gpu/drm/i915/display/intel_atomic_plane.o
LD [M] drivers/gpu/drm/drm_suballoc_helper.o
CC drivers/gpu/drm/i915/display/intel_audio.o
CC drivers/gpu/drm/i915/display/intel_bios.o
CC [M] drivers/gpu/drm/xe/display/xe_plane_initial.o
CC drivers/gpu/drm/i915/display/intel_bw.o
CC [M] drivers/gpu/drm/xe/display/xe_tdf.o
CC [M] drivers/gpu/drm/xe/i915-soc/intel_dram.o
CC drivers/gpu/drm/i915/display/intel_cdclk.o
CC [M] drivers/gpu/drm/xe/i915-soc/intel_pch.o
CC [M] drivers/gpu/drm/xe/i915-display/icl_dsi.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_alpm.o
CC drivers/gpu/drm/i915/display/intel_color.o
CC drivers/gpu/drm/i915/display/intel_combo_phy.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_atomic.o
CC drivers/gpu/drm/i915/display/intel_connector.o
CC drivers/gpu/drm/i915/display/intel_crtc.o
CC drivers/gpu/drm/i915/display/intel_crtc_state_dump.o
CC drivers/gpu/drm/i915/display/intel_cursor.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_atomic_plane.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_audio.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_backlight.o
CC drivers/gpu/drm/i915/display/intel_display.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_bios.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_bw.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_cdclk.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_color.o
CC drivers/gpu/drm/i915/display/intel_display_driver.o
CC drivers/gpu/drm/i915/display/intel_display_irq.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_combo_phy.o
LD [M] drivers/gpu/drm/drm_ttm_helper.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_connector.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_crtc.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_crtc_state_dump.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_cursor.o
AR drivers/net/ethernet/realtek/built-in.a
AR drivers/net/ethernet/built-in.a
CC [M] drivers/gpu/drm/xe/i915-display/intel_cx0_phy.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_ddi.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_ddi_buf_trans.o
AR drivers/net/built-in.a
CC [M] drivers/gpu/drm/xe/i915-display/intel_display.o
CC drivers/gpu/drm/i915/display/intel_display_params.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_display_device.o
CC drivers/gpu/drm/i915/display/intel_display_power.o
CC drivers/gpu/drm/i915/display/intel_display_power_map.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_display_driver.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_display_irq.o
CC drivers/gpu/drm/i915/display/intel_display_power_well.o
CC drivers/gpu/drm/i915/display/intel_display_reset.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_display_params.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_display_power.o
CC drivers/gpu/drm/i915/display/intel_display_rps.o
CC drivers/gpu/drm/i915/display/intel_display_wa.o
CC drivers/gpu/drm/i915/display/intel_dmc.o
CC drivers/gpu/drm/i915/display/intel_dmc_wl.o
CC drivers/gpu/drm/i915/display/intel_dpio_phy.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_display_power_map.o
CC drivers/gpu/drm/i915/display/intel_dpll.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_display_power_well.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_display_trace.o
CC drivers/gpu/drm/i915/display/intel_dpll_mgr.o
CC drivers/gpu/drm/i915/display/intel_dpt.o
CC drivers/gpu/drm/i915/display/intel_dpt_common.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_display_wa.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_dkl_phy.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_dmc.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_dp.o
CC drivers/gpu/drm/i915/display/intel_drrs.o
CC drivers/gpu/drm/i915/display/intel_dsb.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_dp_aux.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_dp_aux_backlight.o
CC drivers/gpu/drm/i915/display/intel_dsb_buffer.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_dp_hdcp.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_dp_link_training.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_dp_mst.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_dpll.o
CC drivers/gpu/drm/i915/display/intel_fb.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_dpll_mgr.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_dpt_common.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_drrs.o
CC drivers/gpu/drm/i915/display/intel_fb_bo.o
CC drivers/gpu/drm/i915/display/intel_fb_pin.o
CC drivers/gpu/drm/i915/display/intel_fbc.o
CC drivers/gpu/drm/i915/display/intel_fdi.o
CC drivers/gpu/drm/i915/display/intel_fifo_underrun.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_dsb.o
CC drivers/gpu/drm/i915/display/intel_frontbuffer.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_dsi.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_dsi_dcs_backlight.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_dsi_vbt.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_encoder.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_fb.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_fbc.o
CC drivers/gpu/drm/i915/display/intel_global_state.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_fdi.o
CC drivers/gpu/drm/i915/display/intel_hdcp.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_fifo_underrun.o
CC drivers/gpu/drm/i915/display/intel_hdcp_gsc.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_frontbuffer.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_global_state.o
CC drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_gmbus.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_hdcp.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_hdcp_gsc_message.o
CC drivers/gpu/drm/i915/display/intel_hotplug.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_hdmi.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_hotplug.o
CC drivers/gpu/drm/i915/display/intel_hotplug_irq.o
CC drivers/gpu/drm/i915/display/intel_hti.o
CC drivers/gpu/drm/i915/display/intel_link_bw.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_hotplug_irq.o
CC drivers/gpu/drm/i915/display/intel_load_detect.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_hti.o
CC drivers/gpu/drm/i915/display/intel_lpe_audio.o
CC drivers/gpu/drm/i915/display/intel_modeset_lock.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_link_bw.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_lspcon.o
CC drivers/gpu/drm/i915/display/intel_modeset_setup.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_modeset_lock.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_modeset_setup.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_modeset_verify.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_panel.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_pmdemand.o
CC drivers/gpu/drm/i915/display/intel_modeset_verify.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_pps.o
CC drivers/gpu/drm/i915/display/intel_overlay.o
CC drivers/gpu/drm/i915/display/intel_pch_display.o
CC drivers/gpu/drm/i915/display/intel_pch_refclk.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_psr.o
CC drivers/gpu/drm/i915/display/intel_plane_initial.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_qp_tables.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_quirks.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_snps_phy.o
CC drivers/gpu/drm/i915/display/intel_pmdemand.o
CC drivers/gpu/drm/i915/display/intel_psr.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_tc.o
CC drivers/gpu/drm/i915/display/intel_quirks.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_vblank.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_vdsc.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_vga.o
CC drivers/gpu/drm/i915/display/intel_sprite.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_vrr.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_dmc_wl.o
CC drivers/gpu/drm/i915/display/intel_sprite_uapi.o
CC drivers/gpu/drm/i915/display/intel_tc.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_wm.o
CC drivers/gpu/drm/i915/display/intel_vblank.o
CC [M] drivers/gpu/drm/xe/i915-display/skl_scaler.o
CC drivers/gpu/drm/i915/display/intel_vga.o
CC [M] drivers/gpu/drm/xe/i915-display/skl_universal_plane.o
CC [M] drivers/gpu/drm/xe/i915-display/skl_watermark.o
CC drivers/gpu/drm/i915/display/intel_wm.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_acpi.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_opregion.o
CC drivers/gpu/drm/i915/display/skl_scaler.o
CC [M] drivers/gpu/drm/xe/xe_debugfs.o
CC [M] drivers/gpu/drm/xe/xe_gt_debugfs.o
CC [M] drivers/gpu/drm/xe/xe_gt_sriov_vf_debugfs.o
CC drivers/gpu/drm/i915/display/skl_universal_plane.o
CC [M] drivers/gpu/drm/xe/xe_gt_stats.o
CC drivers/gpu/drm/i915/display/skl_watermark.o
CC [M] drivers/gpu/drm/xe/xe_guc_debugfs.o
CC drivers/gpu/drm/i915/display/intel_acpi.o
CC [M] drivers/gpu/drm/xe/xe_huc_debugfs.o
CC drivers/gpu/drm/i915/display/intel_opregion.o
CC [M] drivers/gpu/drm/xe/xe_uc_debugfs.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_display_debugfs.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_display_debugfs_params.o
CC [M] drivers/gpu/drm/xe/i915-display/intel_pipe_crc.o
CC drivers/gpu/drm/i915/display/intel_display_debugfs.o
CC drivers/gpu/drm/i915/display/intel_display_debugfs_params.o
CC drivers/gpu/drm/i915/display/intel_pipe_crc.o
CC drivers/gpu/drm/i915/display/dvo_ch7017.o
CC drivers/gpu/drm/i915/display/dvo_ch7xxx.o
CC drivers/gpu/drm/i915/display/dvo_ivch.o
CC drivers/gpu/drm/i915/display/dvo_ns2501.o
CC drivers/gpu/drm/i915/display/dvo_sil164.o
CC drivers/gpu/drm/i915/display/dvo_tfp410.o
CC drivers/gpu/drm/i915/display/g4x_dp.o
CC drivers/gpu/drm/i915/display/g4x_hdmi.o
CC drivers/gpu/drm/i915/display/icl_dsi.o
CC drivers/gpu/drm/i915/display/intel_backlight.o
CC drivers/gpu/drm/i915/display/intel_crt.o
CC drivers/gpu/drm/i915/display/intel_cx0_phy.o
CC drivers/gpu/drm/i915/display/intel_ddi.o
CC drivers/gpu/drm/i915/display/intel_ddi_buf_trans.o
CC drivers/gpu/drm/i915/display/intel_display_device.o
CC drivers/gpu/drm/i915/display/intel_display_trace.o
CC drivers/gpu/drm/i915/display/intel_dkl_phy.o
CC drivers/gpu/drm/i915/display/intel_dp.o
CC drivers/gpu/drm/i915/display/intel_dp_aux.o
CC drivers/gpu/drm/i915/display/intel_dp_aux_backlight.o
CC drivers/gpu/drm/i915/display/intel_dp_hdcp.o
CC drivers/gpu/drm/i915/display/intel_dp_link_training.o
CC drivers/gpu/drm/i915/display/intel_dp_mst.o
CC drivers/gpu/drm/i915/display/intel_dsi.o
CC drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.o
CC drivers/gpu/drm/i915/display/intel_dsi_vbt.o
CC drivers/gpu/drm/i915/display/intel_dvo.o
CC drivers/gpu/drm/i915/display/intel_encoder.o
CC drivers/gpu/drm/i915/display/intel_gmbus.o
CC drivers/gpu/drm/i915/display/intel_hdmi.o
CC drivers/gpu/drm/i915/display/intel_lspcon.o
CC drivers/gpu/drm/i915/display/intel_lvds.o
CC drivers/gpu/drm/i915/display/intel_panel.o
CC drivers/gpu/drm/i915/display/intel_pps.o
CC drivers/gpu/drm/i915/display/intel_qp_tables.o
CC drivers/gpu/drm/i915/display/intel_sdvo.o
CC drivers/gpu/drm/i915/display/intel_snps_phy.o
CC drivers/gpu/drm/i915/display/intel_tv.o
CC drivers/gpu/drm/i915/display/intel_vdsc.o
CC drivers/gpu/drm/i915/display/intel_vrr.o
CC drivers/gpu/drm/i915/display/vlv_dsi.o
CC drivers/gpu/drm/i915/display/vlv_dsi_pll.o
CC drivers/gpu/drm/i915/i915_perf.o
CC drivers/gpu/drm/i915/pxp/intel_pxp.o
CC drivers/gpu/drm/i915/pxp/intel_pxp_huc.o
CC drivers/gpu/drm/i915/pxp/intel_pxp_tee.o
CC drivers/gpu/drm/i915/i915_gpu_error.o
CC drivers/gpu/drm/i915/i915_vgpu.o
LD [M] drivers/gpu/drm/xe/xe.o
AR drivers/gpu/drm/i915/built-in.a
AR drivers/gpu/drm/built-in.a
AR drivers/gpu/built-in.a
AR drivers/built-in.a
AR built-in.a
AR vmlinux.a
LD vmlinux.o
OBJCOPY modules.builtin.modinfo
GEN modules.builtin
MODPOST Module.symvers
CC .vmlinux.export.o
CC [M] fs/efivarfs/efivarfs.mod.o
CC [M] drivers/gpu/drm/drm_exec.mod.o
CC [M] drivers/gpu/drm/drm_gpuvm.mod.o
CC [M] drivers/gpu/drm/drm_suballoc_helper.mod.o
CC [M] drivers/gpu/drm/drm_ttm_helper.mod.o
CC [M] drivers/gpu/drm/scheduler/gpu-sched.mod.o
CC [M] drivers/gpu/drm/xe/xe.mod.o
CC [M] drivers/thermal/intel/x86_pkg_temp_thermal.mod.o
CC [M] sound/core/snd-hwdep.mod.o
CC [M] sound/core/snd-pcm.mod.o
CC [M] sound/pci/hda/snd-hda-codec.mod.o
CC [M] sound/pci/hda/snd-hda-codec-hdmi.mod.o
CC [M] sound/pci/hda/snd-hda-intel.mod.o
CC [M] sound/hda/snd-hda-core.mod.o
CC [M] sound/hda/snd-intel-dspcfg.mod.o
CC [M] sound/hda/snd-intel-sdw-acpi.mod.o
CC [M] net/netfilter/nf_log_syslog.mod.o
CC [M] net/netfilter/xt_mark.mod.o
CC [M] net/netfilter/xt_nat.mod.o
CC [M] net/netfilter/xt_LOG.mod.o
CC [M] net/netfilter/xt_MASQUERADE.mod.o
CC [M] net/netfilter/xt_addrtype.mod.o
CC [M] net/ipv4/netfilter/iptable_nat.mod.o
LD [M] drivers/thermal/intel/x86_pkg_temp_thermal.ko
LD [M] drivers/gpu/drm/drm_ttm_helper.ko
LD [M] sound/pci/hda/snd-hda-codec.ko
LD [M] fs/efivarfs/efivarfs.ko
LD [M] sound/pci/hda/snd-hda-intel.ko
LD [M] sound/hda/snd-intel-sdw-acpi.ko
LD [M] net/netfilter/xt_mark.ko
LD [M] net/netfilter/xt_nat.ko
LD [M] net/netfilter/xt_addrtype.ko
LD [M] net/ipv4/netfilter/iptable_nat.ko
LD [M] net/netfilter/xt_LOG.ko
LD [M] drivers/gpu/drm/scheduler/gpu-sched.ko
LD [M] sound/hda/snd-hda-core.ko
LD [M] sound/hda/snd-intel-dspcfg.ko
LD [M] sound/pci/hda/snd-hda-codec-hdmi.ko
LD [M] net/netfilter/nf_log_syslog.ko
LD [M] drivers/gpu/drm/drm_suballoc_helper.ko
LD [M] drivers/gpu/drm/drm_exec.ko
LD [M] sound/core/snd-pcm.ko
LD [M] sound/core/snd-hwdep.ko
LD [M] net/netfilter/xt_MASQUERADE.ko
LD [M] drivers/gpu/drm/drm_gpuvm.ko
LD [M] drivers/gpu/drm/xe/xe.ko
UPD include/generated/utsversion.h
CC init/version-timestamp.o
KSYMS .tmp_vmlinux0.kallsyms.S
AS .tmp_vmlinux0.kallsyms.o
LD .tmp_vmlinux1
NM .tmp_vmlinux1.syms
KSYMS .tmp_vmlinux1.kallsyms.S
AS .tmp_vmlinux1.kallsyms.o
LD .tmp_vmlinux2
NM .tmp_vmlinux2.syms
KSYMS .tmp_vmlinux2.kallsyms.S
AS .tmp_vmlinux2.kallsyms.o
LD vmlinux
NM System.map
SORTTAB vmlinux
RELOCS arch/x86/boot/compressed/vmlinux.relocs
RSTRIP vmlinux
CC arch/x86/boot/a20.o
AS arch/x86/boot/bioscall.o
CC arch/x86/boot/cmdline.o
AS arch/x86/boot/copy.o
HOSTCC arch/x86/boot/mkcpustr
CC arch/x86/boot/cpuflags.o
CC arch/x86/boot/cpucheck.o
CC arch/x86/boot/early_serial_console.o
CC arch/x86/boot/edd.o
CC arch/x86/boot/main.o
CC arch/x86/boot/memory.o
CC arch/x86/boot/pm.o
AS arch/x86/boot/pmjump.o
CC arch/x86/boot/printf.o
CC arch/x86/boot/regs.o
CC arch/x86/boot/string.o
CC arch/x86/boot/tty.o
CC arch/x86/boot/video.o
CC arch/x86/boot/video-mode.o
CC arch/x86/boot/version.o
CC arch/x86/boot/video-vga.o
CC arch/x86/boot/video-vesa.o
CC arch/x86/boot/video-bios.o
HOSTCC arch/x86/boot/tools/build
CPUSTR arch/x86/boot/cpustr.h
CC arch/x86/boot/cpu.o
LDS arch/x86/boot/compressed/vmlinux.lds
AS arch/x86/boot/compressed/kernel_info.o
AS arch/x86/boot/compressed/head_32.o
VOFFSET arch/x86/boot/compressed/../voffset.h
CC arch/x86/boot/compressed/string.o
CC arch/x86/boot/compressed/cmdline.o
CC arch/x86/boot/compressed/error.o
OBJCOPY arch/x86/boot/compressed/vmlinux.bin
HOSTCC arch/x86/boot/compressed/mkpiggy
CC arch/x86/boot/compressed/cpuflags.o
CC arch/x86/boot/compressed/early_serial_console.o
CC arch/x86/boot/compressed/kaslr.o
CC arch/x86/boot/compressed/acpi.o
CC arch/x86/boot/compressed/efi.o
GZIP arch/x86/boot/compressed/vmlinux.bin.gz
CC arch/x86/boot/compressed/misc.o
MKPIGGY arch/x86/boot/compressed/piggy.S
AS arch/x86/boot/compressed/piggy.o
LD arch/x86/boot/compressed/vmlinux
ZOFFSET arch/x86/boot/zoffset.h
OBJCOPY arch/x86/boot/vmlinux.bin
AS arch/x86/boot/header.o
LD arch/x86/boot/setup.elf
OBJCOPY arch/x86/boot/setup.bin
BUILD arch/x86/boot/bzImage
Kernel: arch/x86/boot/bzImage is ready (#1)
run-parts: executing /workspace/ci/hooks/20-kernel-doc
+ SRC_DIR=/workspace/kernel
+ cd /workspace/kernel
+ find drivers/gpu/drm/xe/ -name '*.[ch]' -not -path 'drivers/gpu/drm/xe/display/*'
+ xargs ./scripts/kernel-doc -Werror -none include/uapi/drm/xe_drm.h
All hooks done
^ permalink raw reply [flat|nested] 54+ messages in thread
* ✗ CI.checksparse: warning for drm/xe/guc: Improve GuC log dumping and add to devcoredump (rev2)
2024-09-05 20:50 [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump John.C.Harrison
` (14 preceding siblings ...)
2024-09-05 21:13 ` ✓ CI.Hooks: " Patchwork
@ 2024-09-05 21:14 ` Patchwork
2024-09-05 22:06 ` ✗ CI.BAT: failure " Patchwork
` (2 subsequent siblings)
18 siblings, 0 replies; 54+ messages in thread
From: Patchwork @ 2024-09-05 21:14 UTC (permalink / raw)
To: john.c.harrison; +Cc: intel-xe
== Series Details ==
Series: drm/xe/guc: Improve GuC log dumping and add to devcoredump (rev2)
URL : https://patchwork.freedesktop.org/series/137985/
State : warning
== Summary ==
+ trap cleanup EXIT
+ KERNEL=/kernel
+ MT=/root/linux/maintainer-tools
+ git clone https://gitlab.freedesktop.org/drm/maintainer-tools /root/linux/maintainer-tools
Cloning into '/root/linux/maintainer-tools'...
warning: redirecting to https://gitlab.freedesktop.org/drm/maintainer-tools.git/
+ make -C /root/linux/maintainer-tools
make: Entering directory '/root/linux/maintainer-tools'
cc -O2 -g -Wextra -o remap-log remap-log.c
make: Leaving directory '/root/linux/maintainer-tools'
+ cd /kernel
+ git config --global --add safe.directory /kernel
+ /root/linux/maintainer-tools/dim sparse --fast 7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d
Sparse version: 0.6.1 (Ubuntu: 0.6.1-2build1)
Fast mode used, each commit won't be checked separately.
+ cleanup
++ stat -c %u:%g /kernel
+ chown -R 1003:1003 /kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* ✗ CI.BAT: failure for drm/xe/guc: Improve GuC log dumping and add to devcoredump (rev2)
2024-09-05 20:50 [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump John.C.Harrison
` (15 preceding siblings ...)
2024-09-05 21:14 ` ✗ CI.checksparse: warning " Patchwork
@ 2024-09-05 22:06 ` Patchwork
2024-09-08 0:02 ` ✗ CI.FULL: " Patchwork
2024-09-12 9:16 ` [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump Jani Nikula
18 siblings, 0 replies; 54+ messages in thread
From: Patchwork @ 2024-09-05 22:06 UTC (permalink / raw)
To: john.c.harrison; +Cc: intel-xe
[-- Attachment #1: Type: text/plain, Size: 1846 bytes --]
== Series Details ==
Series: drm/xe/guc: Improve GuC log dumping and add to devcoredump (rev2)
URL : https://patchwork.freedesktop.org/series/137985/
State : failure
== Summary ==
CI Bug Log - changes from xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d_BAT -> xe-pw-137985v2_BAT
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with xe-pw-137985v2_BAT absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in xe-pw-137985v2_BAT, please notify your bug team (I915-ci-infra@lists.freedesktop.org) to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (9 -> 9)
------------------------------
No changes in participating hosts
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in xe-pw-137985v2_BAT:
### IGT changes ###
#### Possible regressions ####
* igt@xe_exec_fault_mode@twice-invalid-fault:
- bat-pvc-2: [PASS][1] -> [ABORT][2]
[1]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/bat-pvc-2/igt@xe_exec_fault_mode@twice-invalid-fault.html
[2]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/bat-pvc-2/igt@xe_exec_fault_mode@twice-invalid-fault.html
Build changes
-------------
* Linux: xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d -> xe-pw-137985v2
IGT_8006: ae7f2bc0b99801a7ae369d4b5fda5c6b1c386eb1 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d: 7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d
xe-pw-137985v2: 137985v2
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/index.html
[-- Attachment #2: Type: text/html, Size: 2431 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function
2024-09-05 20:50 ` [PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function John.C.Harrison
@ 2024-09-06 1:54 ` Lucas De Marchi
2024-09-06 2:01 ` John Harrison
2024-09-10 19:33 ` Julia Filipchuk
1 sibling, 1 reply; 54+ messages in thread
From: Lucas De Marchi @ 2024-09-06 1:54 UTC (permalink / raw)
To: John.C.Harrison; +Cc: Intel-Xe
On Thu, Sep 05, 2024 at 01:50:58PM GMT, 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.
why are we not dumping the binary data directly to devcoredump?
Lucas De Marchi
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function
2024-09-06 1:54 ` Lucas De Marchi
@ 2024-09-06 2:01 ` John Harrison
2024-09-06 3:04 ` Lucas De Marchi
0 siblings, 1 reply; 54+ messages in thread
From: John Harrison @ 2024-09-06 2:01 UTC (permalink / raw)
To: Lucas De Marchi; +Cc: Intel-Xe
On 9/5/2024 18:54, Lucas De Marchi wrote:
> On Thu, Sep 05, 2024 at 01:50:58PM GMT, 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.
>
> why are we not dumping the binary data directly to devcoredump?
As per earlier comments, there is a WiFi driver or some such that does
exactly that. But all they are dumping is a binary blob.
We want the devcoredump file to still be human readable. That won't be
the case if you stuff binary data in the middle of it. Most obvious
problem - the zeros in the data will terminate your text file at that
point. Potentially bigger problem for end users - random fake ANSI codes
will destroy your terminal window if you try to cat the file to read it.
John.
>
> Lucas De Marchi
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function
2024-09-06 2:01 ` John Harrison
@ 2024-09-06 3:04 ` Lucas De Marchi
2024-09-07 2:06 ` John Harrison
0 siblings, 1 reply; 54+ messages in thread
From: Lucas De Marchi @ 2024-09-06 3:04 UTC (permalink / raw)
To: John Harrison; +Cc: Intel-Xe, Matthew Brost
On Thu, Sep 05, 2024 at 07:01:33PM GMT, John Harrison wrote:
>On 9/5/2024 18:54, Lucas De Marchi wrote:
>>On Thu, Sep 05, 2024 at 01:50:58PM GMT, 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.
>>
>>why are we not dumping the binary data directly to devcoredump?
>As per earlier comments, there is a WiFi driver or some such that does
>exactly that. But all they are dumping is a binary blob.
In your v5 I see you mentioned
drivers/net/wireless/ath/ath10k/coredump.c, but that is a precedence for
including it as is from the device rather converting it to ASCII85 or
something else. It seems odd to do that type of conversion in kernel
space when it could be perfectly done in userspace.
$ git grep ascii85.h
drivers/gpu/drm/i915/i915_gpu_error.c:#include <linux/ascii85.h>
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:#include <linux/ascii85.h>
drivers/gpu/drm/msm/adreno/adreno_gpu.c:#include <linux/ascii85.h>
drivers/gpu/drm/xe/xe_lrc.c:#include <linux/ascii85.h>
drivers/gpu/drm/xe/xe_vm.c:#include <linux/ascii85.h>
>
>We want the devcoredump file to still be human readable. That won't be
>the case if you stuff binary data in the middle of it. Most obvious
>problem - the zeros in the data will terminate your text file at that
>point. Potentially bigger problem for end users - random fake ANSI
>codes will destroy your terminal window if you try to cat the file to
>read it.
Users don't get a coredump and cat it to the terminal.
=(lk%A8`T7AKYH#FD,6++EqOABHUhsG%5H2ARoq#E$/V$Bl7Q+@<5pmBe<q;Bk;0mCj@.3DIal2FD5Q-+E_RBART+X@VfTuGA2/4Dfp.E@3BN0DfB9.+E1b0F(KAV+:8
Lucas De Marchi
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function
2024-09-06 3:04 ` Lucas De Marchi
@ 2024-09-07 2:06 ` John Harrison
2024-09-10 1:31 ` John Harrison
0 siblings, 1 reply; 54+ messages in thread
From: John Harrison @ 2024-09-07 2:06 UTC (permalink / raw)
To: Lucas De Marchi; +Cc: Intel-Xe, Matthew Brost
On 9/5/2024 20:04, Lucas De Marchi wrote:
> On Thu, Sep 05, 2024 at 07:01:33PM GMT, John Harrison wrote:
>> On 9/5/2024 18:54, Lucas De Marchi wrote:
>>> On Thu, Sep 05, 2024 at 01:50:58PM GMT, 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.
>>>
>>> why are we not dumping the binary data directly to devcoredump?
>> As per earlier comments, there is a WiFi driver or some such that
>> does exactly that. But all they are dumping is a binary blob.
>
> In your v5 I see you mentioned
> drivers/net/wireless/ath/ath10k/coredump.c, but that is a precedence for
> including it as is from the device rather converting it to ASCII85 or
> something else. It seems odd to do that type of conversion in kernel
> space when it could be perfectly done in userspace.
It really can't. An end user could maybe be expected to zip or tar a
coredump file before attaching it to a bug report but they are certainly
not going to try to ASCII85 encode random bits of it. Whereas, putting
that in the kernel means it is just there. It is done. And it is pretty
trivial - just call a helper function and it does everything for you.
Also, I very much doubt you can spew raw binary data via dmesg. Even if
the kernel would print it for you (which I doubt), the user tools like
syslogd and dmesg itself are going to filter it to make it ASCII safe.
The i915 error dumps have been ASCII85 encoded using the kernel's
ASCII85 encoding helper function since forever. This patch is just a
wrapper around the kernel's existing implementation in order to make it
more compatible with printing to dmesg. This is not creating a new
precedent. It already exists.
>
> $ git grep ascii85.h
> drivers/gpu/drm/i915/i915_gpu_error.c:#include <linux/ascii85.h>
> drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:#include <linux/ascii85.h>
> drivers/gpu/drm/msm/adreno/adreno_gpu.c:#include <linux/ascii85.h>
> drivers/gpu/drm/xe/xe_lrc.c:#include <linux/ascii85.h>
> drivers/gpu/drm/xe/xe_vm.c:#include <linux/ascii85.h>
And the list of drivers which dump raw binary data in a coredump file
is... ath10k. ASCII85 wins 3 to 1.
>
>>
>> We want the devcoredump file to still be human readable. That won't
>> be the case if you stuff binary data in the middle of it. Most
>> obvious problem - the zeros in the data will terminate your text file
>> at that point. Potentially bigger problem for end users - random fake
>> ANSI codes will destroy your terminal window if you try to cat the
>> file to read it.
>
> Users don't get a coredump and cat it to the terminal.
> =(lk%A8`T7AKYH#FD,6++EqOABHUhsG%5H2ARoq#E$/V$Bl7Q+@<5pmBe<q;Bk;0mCj@.3DIal2FD5Q-+E_RBART+X@VfTuGA2/4Dfp.E@3BN0DfB9.+E1b0F(KAV+:8
>
>
> Lucas De Marchi
They might. Either intentionally or accidentally. I've certainly done it
myself. And people will certainly want to look at it in any random
choice of text editor, pager, etc. 'cos you know, it is meant to be read
by humans. If it is full of binary data then that becomes even more
difficult than simply being full of ASCII gibberish. No matter what you
are doing, the ASCII version is safer and easier to look at the rest of
the file around it.
I don't understand why you are so desperate to have raw binary data in
the middle of a text file. The disadvantages are multiple but the only
advantage is a slightly smaller file. And the true route to smaller
files is to add compression like we have in i915.
John.
^ permalink raw reply [flat|nested] 54+ messages in thread
* ✗ CI.FULL: failure for drm/xe/guc: Improve GuC log dumping and add to devcoredump (rev2)
2024-09-05 20:50 [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump John.C.Harrison
` (16 preceding siblings ...)
2024-09-05 22:06 ` ✗ CI.BAT: failure " Patchwork
@ 2024-09-08 0:02 ` Patchwork
2024-09-12 9:16 ` [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump Jani Nikula
18 siblings, 0 replies; 54+ messages in thread
From: Patchwork @ 2024-09-08 0:02 UTC (permalink / raw)
To: john.c.harrison; +Cc: intel-xe
[-- Attachment #1: Type: text/plain, Size: 66894 bytes --]
== Series Details ==
Series: drm/xe/guc: Improve GuC log dumping and add to devcoredump (rev2)
URL : https://patchwork.freedesktop.org/series/137985/
State : failure
== Summary ==
CI Bug Log - changes from xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d_full -> xe-pw-137985v2_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with xe-pw-137985v2_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in xe-pw-137985v2_full, please notify your bug team (I915-ci-infra@lists.freedesktop.org) to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (4 -> 4)
------------------------------
No changes in participating hosts
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in xe-pw-137985v2_full:
### IGT changes ###
#### Possible regressions ####
* igt@xe_drm_fdinfo@utilization-others-full-load:
- shard-adlp: [PASS][1] -> [FAIL][2]
[1]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-adlp-8/igt@xe_drm_fdinfo@utilization-others-full-load.html
[2]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-adlp-1/igt@xe_drm_fdinfo@utilization-others-full-load.html
* igt@xe_exec_threads@threads-hang-userptr-invalidate:
- shard-dg2-set2: [PASS][3] -> [ABORT][4]
[3]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@xe_exec_threads@threads-hang-userptr-invalidate.html
[4]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@xe_exec_threads@threads-hang-userptr-invalidate.html
* igt@xe_gt_freq@throttle_basic_api:
- shard-lnl: [PASS][5] -> [FAIL][6]
[5]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-lnl-2/igt@xe_gt_freq@throttle_basic_api.html
[6]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-8/igt@xe_gt_freq@throttle_basic_api.html
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_flip@plain-flip-ts-check-interruptible@b-dp2:
- {shard-bmg}: [PASS][7] -> [DMESG-WARN][8]
[7]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-bmg-7/igt@kms_flip@plain-flip-ts-check-interruptible@b-dp2.html
[8]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-bmg-3/igt@kms_flip@plain-flip-ts-check-interruptible@b-dp2.html
* igt@kms_vblank@ts-continuation-idle-hang@pipe-d-hdmi-a-3:
- {shard-bmg}: NOTRUN -> [INCOMPLETE][9] +1 other test incomplete
[9]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-bmg-8/igt@kms_vblank@ts-continuation-idle-hang@pipe-d-hdmi-a-3.html
* igt@xe_exec_fault_mode@many-execqueues-invalid-fault:
- {shard-bmg}: [PASS][10] -> [ABORT][11] +5 other tests abort
[10]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-bmg-8/igt@xe_exec_fault_mode@many-execqueues-invalid-fault.html
[11]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-bmg-8/igt@xe_exec_fault_mode@many-execqueues-invalid-fault.html
Known issues
------------
Here are the changes found in xe-pw-137985v2_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@kms_atomic_transition@plane-all-modeset-transition-fencing@pipe-a-hdmi-a-6:
- shard-dg2-set2: [PASS][12] -> [FAIL][13] ([Intel XE#1426]) +1 other test fail
[12]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-435/igt@kms_atomic_transition@plane-all-modeset-transition-fencing@pipe-a-hdmi-a-6.html
[13]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@kms_atomic_transition@plane-all-modeset-transition-fencing@pipe-a-hdmi-a-6.html
* igt@kms_atomic_transition@plane-toggle-modeset-transition@pipe-a-edp-1:
- shard-lnl: [PASS][14] -> [FAIL][15] ([Intel XE#1426]) +1 other test fail
[14]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-lnl-1/igt@kms_atomic_transition@plane-toggle-modeset-transition@pipe-a-edp-1.html
[15]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-7/igt@kms_atomic_transition@plane-toggle-modeset-transition@pipe-a-edp-1.html
* igt@kms_big_fb@4-tiled-64bpp-rotate-90:
- shard-lnl: NOTRUN -> [SKIP][16] ([Intel XE#1407])
[16]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-4/igt@kms_big_fb@4-tiled-64bpp-rotate-90.html
* igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip:
- shard-adlp: NOTRUN -> [SKIP][17] ([Intel XE#1124] / [Intel XE#1201])
[17]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-adlp-4/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip.html
* igt@kms_big_fb@linear-32bpp-rotate-270:
- shard-dg2-set2: NOTRUN -> [SKIP][18] ([Intel XE#1201] / [Intel XE#316])
[18]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-463/igt@kms_big_fb@linear-32bpp-rotate-270.html
* igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip:
- shard-adlp: NOTRUN -> [FAIL][19] ([Intel XE#1231])
[19]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-adlp-4/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html
* igt@kms_big_fb@yf-tiled-64bpp-rotate-180:
- shard-lnl: NOTRUN -> [SKIP][20] ([Intel XE#1124]) +1 other test skip
[20]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-4/igt@kms_big_fb@yf-tiled-64bpp-rotate-180.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-0:
- shard-dg2-set2: NOTRUN -> [SKIP][21] ([Intel XE#1124] / [Intel XE#1201])
[21]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-463/igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-0.html
* igt@kms_big_joiner@basic:
- shard-adlp: NOTRUN -> [SKIP][22] ([Intel XE#1201] / [Intel XE#346])
[22]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-adlp-4/igt@kms_big_joiner@basic.html
* igt@kms_big_joiner@invalid-modeset:
- shard-dg2-set2: NOTRUN -> [SKIP][23] ([Intel XE#1201] / [Intel XE#346])
[23]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-463/igt@kms_big_joiner@invalid-modeset.html
* igt@kms_bw@linear-tiling-2-displays-2160x1440p:
- shard-dg2-set2: NOTRUN -> [SKIP][24] ([Intel XE#1201] / [Intel XE#367])
[24]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-463/igt@kms_bw@linear-tiling-2-displays-2160x1440p.html
* igt@kms_ccs@crc-primary-basic-4-tiled-dg2-rc-ccs-cc:
- shard-lnl: NOTRUN -> [SKIP][25] ([Intel XE#1399]) +1 other test skip
[25]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-4/igt@kms_ccs@crc-primary-basic-4-tiled-dg2-rc-ccs-cc.html
* igt@kms_chamelium_color@ctm-max:
- shard-dg2-set2: NOTRUN -> [SKIP][26] ([Intel XE#1201] / [Intel XE#306])
[26]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-463/igt@kms_chamelium_color@ctm-max.html
* igt@kms_chamelium_frames@hdmi-crc-fast:
- shard-lnl: NOTRUN -> [SKIP][27] ([Intel XE#373]) +1 other test skip
[27]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-4/igt@kms_chamelium_frames@hdmi-crc-fast.html
* igt@kms_chamelium_frames@vga-frame-dump:
- shard-adlp: NOTRUN -> [SKIP][28] ([Intel XE#1201] / [Intel XE#373])
[28]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-adlp-4/igt@kms_chamelium_frames@vga-frame-dump.html
* igt@kms_chamelium_hpd@dp-hpd-storm-disable:
- shard-dg2-set2: NOTRUN -> [SKIP][29] ([Intel XE#1201] / [Intel XE#373])
[29]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-463/igt@kms_chamelium_hpd@dp-hpd-storm-disable.html
* igt@kms_content_protection@dp-mst-type-0:
- shard-dg2-set2: NOTRUN -> [SKIP][30] ([Intel XE#1201] / [Intel XE#307]) +1 other test skip
[30]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-463/igt@kms_content_protection@dp-mst-type-0.html
* igt@kms_cursor_legacy@cursorb-vs-flipa-atomic:
- shard-lnl: NOTRUN -> [SKIP][31] ([Intel XE#309])
[31]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-4/igt@kms_cursor_legacy@cursorb-vs-flipa-atomic.html
* igt@kms_flip@2x-flip-vs-panning-interruptible:
- shard-lnl: NOTRUN -> [SKIP][32] ([Intel XE#1421])
[32]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-4/igt@kms_flip@2x-flip-vs-panning-interruptible.html
* igt@kms_flip_scaled_crc@flip-32bpp-yftileccs-to-64bpp-yftile-downscaling@pipe-a-default-mode:
- shard-lnl: NOTRUN -> [SKIP][33] ([Intel XE#1401]) +1 other test skip
[33]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-4/igt@kms_flip_scaled_crc@flip-32bpp-yftileccs-to-64bpp-yftile-downscaling@pipe-a-default-mode.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-downscaling:
- shard-lnl: NOTRUN -> [SKIP][34] ([Intel XE#1401] / [Intel XE#1745]) +1 other test skip
[34]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-4/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-downscaling.html
* igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-16bpp-yftile-downscaling:
- shard-adlp: NOTRUN -> [SKIP][35] ([Intel XE#1201] / [Intel XE#455]) +5 other tests skip
[35]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-adlp-4/igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-16bpp-yftile-downscaling.html
* igt@kms_flip_tiling@flip-change-tiling@pipe-c-hdmi-a-1-y-to-y:
- shard-adlp: [PASS][36] -> [FAIL][37] ([Intel XE#1874])
[36]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-adlp-2/igt@kms_flip_tiling@flip-change-tiling@pipe-c-hdmi-a-1-y-to-y.html
[37]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-adlp-8/igt@kms_flip_tiling@flip-change-tiling@pipe-c-hdmi-a-1-y-to-y.html
* igt@kms_frontbuffer_tracking@drrs-modesetfrombusy:
- shard-adlp: NOTRUN -> [SKIP][38] ([Intel XE#1201] / [Intel XE#651])
[38]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-adlp-4/igt@kms_frontbuffer_tracking@drrs-modesetfrombusy.html
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-fullscreen:
- shard-adlp: NOTRUN -> [SKIP][39] ([Intel XE#1201] / [Intel XE#656]) +6 other tests skip
[39]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-adlp-4/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-fullscreen.html
* igt@kms_frontbuffer_tracking@fbcdrrs-1p-primscrn-cur-indfb-move:
- shard-dg2-set2: NOTRUN -> [SKIP][40] ([Intel XE#1201] / [Intel XE#651]) +4 other tests skip
[40]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-463/igt@kms_frontbuffer_tracking@fbcdrrs-1p-primscrn-cur-indfb-move.html
* igt@kms_frontbuffer_tracking@fbcdrrs-1p-primscrn-cur-indfb-onoff:
- shard-lnl: NOTRUN -> [SKIP][41] ([Intel XE#651])
[41]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-4/igt@kms_frontbuffer_tracking@fbcdrrs-1p-primscrn-cur-indfb-onoff.html
* igt@kms_frontbuffer_tracking@fbcdrrs-2p-scndscrn-spr-indfb-onoff:
- shard-lnl: NOTRUN -> [SKIP][42] ([Intel XE#656]) +5 other tests skip
[42]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-4/igt@kms_frontbuffer_tracking@fbcdrrs-2p-scndscrn-spr-indfb-onoff.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-cur-indfb-move:
- shard-dg2-set2: NOTRUN -> [SKIP][43] ([Intel XE#1201] / [Intel XE#653])
[43]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-463/igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-cur-indfb-move.html
* igt@kms_frontbuffer_tracking@psr-indfb-scaledprimary:
- shard-adlp: NOTRUN -> [SKIP][44] ([Intel XE#1201] / [Intel XE#653])
[44]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-adlp-4/igt@kms_frontbuffer_tracking@psr-indfb-scaledprimary.html
* igt@kms_plane@plane-position-hole-dpms@pipe-b-plane-1:
- shard-lnl: [PASS][45] -> [DMESG-WARN][46] ([Intel XE#324]) +2 other tests dmesg-warn
[45]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-lnl-3/igt@kms_plane@plane-position-hole-dpms@pipe-b-plane-1.html
[46]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-3/igt@kms_plane@plane-position-hole-dpms@pipe-b-plane-1.html
* igt@kms_plane_multiple@tiling-yf:
- shard-dg2-set2: NOTRUN -> [SKIP][47] ([Intel XE#1201] / [Intel XE#455])
[47]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-463/igt@kms_plane_multiple@tiling-yf.html
* igt@kms_plane_scaling@planes-downscale-factor-0-5-upscale-factor-0-25:
- shard-lnl: NOTRUN -> [SKIP][48] ([Intel XE#2318]) +3 other tests skip
[48]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-4/igt@kms_plane_scaling@planes-downscale-factor-0-5-upscale-factor-0-25.html
* igt@kms_psr@fbc-psr2-cursor-plane-move:
- shard-adlp: NOTRUN -> [SKIP][49] ([Intel XE#1201] / [Intel XE#929]) +3 other tests skip
[49]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-adlp-4/igt@kms_psr@fbc-psr2-cursor-plane-move.html
* igt@kms_psr@pr-sprite-blt:
- shard-dg2-set2: NOTRUN -> [SKIP][50] ([Intel XE#1201] / [Intel XE#929]) +2 other tests skip
[50]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-463/igt@kms_psr@pr-sprite-blt.html
* igt@kms_tiled_display@basic-test-pattern:
- shard-lnl: NOTRUN -> [SKIP][51] ([Intel XE#362])
[51]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-4/igt@kms_tiled_display@basic-test-pattern.html
* igt@kms_universal_plane@cursor-fb-leak:
- shard-adlp: [PASS][52] -> [FAIL][53] ([Intel XE#771] / [Intel XE#899])
[52]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-adlp-1/igt@kms_universal_plane@cursor-fb-leak.html
[53]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-adlp-8/igt@kms_universal_plane@cursor-fb-leak.html
* igt@kms_universal_plane@cursor-fb-leak@pipe-c-hdmi-a-1:
- shard-adlp: [PASS][54] -> [FAIL][55] ([Intel XE#899])
[54]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-adlp-1/igt@kms_universal_plane@cursor-fb-leak@pipe-c-hdmi-a-1.html
[55]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-adlp-8/igt@kms_universal_plane@cursor-fb-leak@pipe-c-hdmi-a-1.html
* igt@kms_vblank@accuracy-idle:
- shard-dg2-set2: NOTRUN -> [INCOMPLETE][56] ([Intel XE#1195]) +1 other test incomplete
[56]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-463/igt@kms_vblank@accuracy-idle.html
* igt@kms_vrr@lobf@pipe-a-edp-1:
- shard-lnl: NOTRUN -> [FAIL][57] ([Intel XE#2443]) +1 other test fail
[57]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-4/igt@kms_vrr@lobf@pipe-a-edp-1.html
* igt@xe_copy_basic@mem-set-linear-0xfd:
- shard-dg2-set2: NOTRUN -> [SKIP][58] ([Intel XE#1126] / [Intel XE#1201])
[58]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-463/igt@xe_copy_basic@mem-set-linear-0xfd.html
* igt@xe_evict@evict-beng-mixed-many-threads-large:
- shard-adlp: NOTRUN -> [SKIP][59] ([Intel XE#1201] / [Intel XE#261])
[59]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-adlp-4/igt@xe_evict@evict-beng-mixed-many-threads-large.html
* igt@xe_evict@evict-beng-threads-small:
- shard-lnl: NOTRUN -> [SKIP][60] ([Intel XE#688]) +2 other tests skip
[60]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-4/igt@xe_evict@evict-beng-threads-small.html
* igt@xe_exec_basic@multigpu-many-execqueues-many-vm-userptr-invalidate-race:
- shard-adlp: NOTRUN -> [SKIP][61] ([Intel XE#1201] / [Intel XE#1392])
[61]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-adlp-4/igt@xe_exec_basic@multigpu-many-execqueues-many-vm-userptr-invalidate-race.html
* igt@xe_exec_fault_mode@once-bindexecqueue-rebind-prefetch:
- shard-dg2-set2: NOTRUN -> [SKIP][62] ([Intel XE#1201] / [Intel XE#288]) +1 other test skip
[62]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-463/igt@xe_exec_fault_mode@once-bindexecqueue-rebind-prefetch.html
* igt@xe_exec_fault_mode@once-bindexecqueue-userptr-invalidate-prefetch:
- shard-adlp: NOTRUN -> [SKIP][63] ([Intel XE#1201] / [Intel XE#288])
[63]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-adlp-4/igt@xe_exec_fault_mode@once-bindexecqueue-userptr-invalidate-prefetch.html
* igt@xe_exec_threads@threads-cm-fd-userptr-invalidate-race:
- shard-dg2-set2: [PASS][64] -> [INCOMPLETE][65] ([Intel XE#1169] / [Intel XE#1195] / [Intel XE#1356])
[64]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-436/igt@xe_exec_threads@threads-cm-fd-userptr-invalidate-race.html
[65]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-434/igt@xe_exec_threads@threads-cm-fd-userptr-invalidate-race.html
* igt@xe_module_load@many-reload:
- shard-adlp: [PASS][66] -> [TIMEOUT][67] ([Intel XE#1961] / [Intel XE#2026])
[66]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-adlp-1/igt@xe_module_load@many-reload.html
[67]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-adlp-8/igt@xe_module_load@many-reload.html
* igt@xe_oa@oa-unit-exclusive-stream-exec-q:
- shard-adlp: NOTRUN -> [SKIP][68] ([Intel XE#1201] / [Intel XE#2541])
[68]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-adlp-4/igt@xe_oa@oa-unit-exclusive-stream-exec-q.html
* igt@xe_peer2peer@write@write-gpua-vram01-gpub-system-p2p:
- shard-dg2-set2: NOTRUN -> [FAIL][69] ([Intel XE#1173]) +1 other test fail
[69]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-463/igt@xe_peer2peer@write@write-gpua-vram01-gpub-system-p2p.html
* igt@xe_pm@d3cold-mmap-system:
- shard-lnl: NOTRUN -> [SKIP][70] ([Intel XE#2284] / [Intel XE#366])
[70]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-4/igt@xe_pm@d3cold-mmap-system.html
* igt@xe_pm@s3-vm-bind-userptr:
- shard-dg2-set2: [PASS][71] -> [INCOMPLETE][72] ([Intel XE#1195] / [Intel XE#569])
[71]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-463/igt@xe_pm@s3-vm-bind-userptr.html
[72]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@xe_pm@s3-vm-bind-userptr.html
* igt@xe_pm@s4-d3hot-basic-exec:
- shard-adlp: [PASS][73] -> [ABORT][74] ([Intel XE#1358] / [Intel XE#1607])
[73]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-adlp-1/igt@xe_pm@s4-d3hot-basic-exec.html
[74]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-adlp-9/igt@xe_pm@s4-d3hot-basic-exec.html
* igt@xe_pm@s4-vm-bind-prefetch:
- shard-lnl: [PASS][75] -> [ABORT][76] ([Intel XE#1607] / [Intel XE#1794])
[75]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-lnl-7/igt@xe_pm@s4-vm-bind-prefetch.html
[76]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-2/igt@xe_pm@s4-vm-bind-prefetch.html
* igt@xe_pm@s4-vm-bind-unbind-all:
- shard-adlp: [PASS][77] -> [ABORT][78] ([Intel XE#1794])
[77]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-adlp-4/igt@xe_pm@s4-vm-bind-unbind-all.html
[78]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-adlp-9/igt@xe_pm@s4-vm-bind-unbind-all.html
#### Possible fixes ####
* igt@kms_atomic_transition@plane-all-modeset-transition@pipe-a-dp-2:
- {shard-bmg}: [FAIL][79] ([Intel XE#1426]) -> [PASS][80] +1 other test pass
[79]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-bmg-8/igt@kms_atomic_transition@plane-all-modeset-transition@pipe-a-dp-2.html
[80]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-bmg-1/igt@kms_atomic_transition@plane-all-modeset-transition@pipe-a-dp-2.html
* igt@kms_atomic_transition@plane-toggle-modeset-transition:
- shard-adlp: [FAIL][81] ([Intel XE#1426]) -> [PASS][82] +1 other test pass
[81]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-adlp-9/igt@kms_atomic_transition@plane-toggle-modeset-transition.html
[82]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-adlp-4/igt@kms_atomic_transition@plane-toggle-modeset-transition.html
* igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-hflip:
- shard-lnl: [FAIL][83] ([Intel XE#1659]) -> [PASS][84]
[83]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-lnl-3/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-hflip.html
[84]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-3/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-hflip.html
* igt@kms_ccs@crc-sprite-planes-basic-4-tiled-bmg-ccs@pipe-a-dp-2:
- {shard-bmg}: [FAIL][85] ([Intel XE#2436]) -> [PASS][86] +2 other tests pass
[85]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-bmg-3/igt@kms_ccs@crc-sprite-planes-basic-4-tiled-bmg-ccs@pipe-a-dp-2.html
[86]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-bmg-7/igt@kms_ccs@crc-sprite-planes-basic-4-tiled-bmg-ccs@pipe-a-dp-2.html
* igt@kms_flip@2x-flip-vs-panning-interruptible:
- shard-dg2-set2: [DMESG-WARN][87] ([Intel XE#877]) -> [PASS][88]
[87]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-435/igt@kms_flip@2x-flip-vs-panning-interruptible.html
[88]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-434/igt@kms_flip@2x-flip-vs-panning-interruptible.html
* igt@kms_flip@2x-flip-vs-panning-interruptible@bd-hdmi-a6-dp4:
- shard-dg2-set2: [DMESG-WARN][89] -> [PASS][90]
[89]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-435/igt@kms_flip@2x-flip-vs-panning-interruptible@bd-hdmi-a6-dp4.html
[90]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-434/igt@kms_flip@2x-flip-vs-panning-interruptible@bd-hdmi-a6-dp4.html
* igt@kms_flip@flip-vs-absolute-wf_vblank:
- shard-lnl: [FAIL][91] ([Intel XE#886]) -> [PASS][92] +1 other test pass
[91]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-lnl-1/igt@kms_flip@flip-vs-absolute-wf_vblank.html
[92]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-7/igt@kms_flip@flip-vs-absolute-wf_vblank.html
* igt@kms_flip_tiling@flip-change-tiling@pipe-c-hdmi-a-1-y-to-x:
- shard-adlp: [FAIL][93] ([Intel XE#1874]) -> [PASS][94] +2 other tests pass
[93]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-adlp-2/igt@kms_flip_tiling@flip-change-tiling@pipe-c-hdmi-a-1-y-to-x.html
[94]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-adlp-8/igt@kms_flip_tiling@flip-change-tiling@pipe-c-hdmi-a-1-y-to-x.html
* igt@kms_plane@plane-panning-bottom-right-suspend:
- shard-lnl: [INCOMPLETE][95] ([Intel XE#1616]) -> [PASS][96] +1 other test pass
[95]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-lnl-2/igt@kms_plane@plane-panning-bottom-right-suspend.html
[96]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-4/igt@kms_plane@plane-panning-bottom-right-suspend.html
* igt@kms_plane@plane-position-hole-dpms@pipe-b-plane-4:
- shard-lnl: [DMESG-WARN][97] ([Intel XE#324]) -> [PASS][98]
[97]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-lnl-3/igt@kms_plane@plane-position-hole-dpms@pipe-b-plane-4.html
[98]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-3/igt@kms_plane@plane-position-hole-dpms@pipe-b-plane-4.html
* igt@kms_pm_dc@dc6-dpms:
- shard-lnl: [FAIL][99] ([Intel XE#1430]) -> [PASS][100]
[99]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-lnl-3/igt@kms_pm_dc@dc6-dpms.html
[100]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-3/igt@kms_pm_dc@dc6-dpms.html
* igt@kms_universal_plane@cursor-fb-leak:
- {shard-bmg}: [FAIL][101] ([Intel XE#899]) -> [PASS][102] +1 other test pass
[101]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-bmg-3/igt@kms_universal_plane@cursor-fb-leak.html
[102]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-bmg-3/igt@kms_universal_plane@cursor-fb-leak.html
- shard-dg2-set2: [FAIL][103] ([Intel XE#771] / [Intel XE#899]) -> [PASS][104]
[103]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-433/igt@kms_universal_plane@cursor-fb-leak.html
[104]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@kms_universal_plane@cursor-fb-leak.html
* igt@kms_universal_plane@cursor-fb-leak@pipe-a-hdmi-a-6:
- shard-dg2-set2: [FAIL][105] ([Intel XE#899]) -> [PASS][106]
[105]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-433/igt@kms_universal_plane@cursor-fb-leak@pipe-a-hdmi-a-6.html
[106]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@kms_universal_plane@cursor-fb-leak@pipe-a-hdmi-a-6.html
* igt@kms_vrr@flip-basic:
- shard-lnl: [FAIL][107] ([Intel XE#1522]) -> [PASS][108] +1 other test pass
[107]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-lnl-2/igt@kms_vrr@flip-basic.html
[108]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-6/igt@kms_vrr@flip-basic.html
* igt@xe_drm_fdinfo@utilization-single-full-load-destroy-queue:
- {shard-bmg}: [FAIL][109] -> [PASS][110]
[109]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-bmg-1/igt@xe_drm_fdinfo@utilization-single-full-load-destroy-queue.html
[110]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-bmg-2/igt@xe_drm_fdinfo@utilization-single-full-load-destroy-queue.html
* igt@xe_evict@evict-mixed-many-threads-large:
- shard-dg2-set2: [TIMEOUT][111] ([Intel XE#1473]) -> [PASS][112]
[111]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-466/igt@xe_evict@evict-mixed-many-threads-large.html
[112]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-435/igt@xe_evict@evict-mixed-many-threads-large.html
* igt@xe_exec_threads@threads-mixed-userptr:
- {shard-bmg}: [DMESG-WARN][113] ([Intel XE#877]) -> [PASS][114] +4 other tests pass
[113]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-bmg-1/igt@xe_exec_threads@threads-mixed-userptr.html
[114]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-bmg-5/igt@xe_exec_threads@threads-mixed-userptr.html
* igt@xe_gt_freq@freq_reset_multiple:
- shard-lnl: [DMESG-FAIL][115] ([Intel XE#1620]) -> [PASS][116]
[115]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-lnl-2/igt@xe_gt_freq@freq_reset_multiple.html
[116]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-6/igt@xe_gt_freq@freq_reset_multiple.html
* igt@xe_pm@s3-basic-exec:
- shard-dg2-set2: [INCOMPLETE][117] ([Intel XE#1195] / [Intel XE#1358] / [Intel XE#569]) -> [PASS][118]
[117]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-434/igt@xe_pm@s3-basic-exec.html
[118]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-463/igt@xe_pm@s3-basic-exec.html
* igt@xe_pm@s3-vm-bind-userptr:
- {shard-bmg}: [INCOMPLETE][119] ([Intel XE#569]) -> [PASS][120]
[119]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-bmg-3/igt@xe_pm@s3-vm-bind-userptr.html
[120]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-bmg-8/igt@xe_pm@s3-vm-bind-userptr.html
* igt@xe_pm@s4-exec-after:
- shard-adlp: [ABORT][121] ([Intel XE#1358] / [Intel XE#1607]) -> [PASS][122]
[121]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-adlp-9/igt@xe_pm@s4-exec-after.html
[122]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-adlp-4/igt@xe_pm@s4-exec-after.html
* igt@xe_pm@s4-vm-bind-prefetch:
- {shard-bmg}: [DMESG-WARN][123] -> [PASS][124]
[123]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-bmg-1/igt@xe_pm@s4-vm-bind-prefetch.html
[124]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-bmg-5/igt@xe_pm@s4-vm-bind-prefetch.html
* igt@xe_pm_residency@toggle-gt-c6:
- shard-lnl: [FAIL][125] ([Intel XE#958]) -> [PASS][126]
[125]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-lnl-3/igt@xe_pm_residency@toggle-gt-c6.html
[126]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-lnl-5/igt@xe_pm_residency@toggle-gt-c6.html
#### Warnings ####
* igt@kms_big_fb@x-tiled-32bpp-rotate-90:
- shard-dg2-set2: [SKIP][127] ([Intel XE#1201] / [Intel XE#316]) -> [SKIP][128] ([Intel XE#316])
[127]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-433/igt@kms_big_fb@x-tiled-32bpp-rotate-90.html
[128]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@kms_big_fb@x-tiled-32bpp-rotate-90.html
* igt@kms_big_fb@x-tiled-8bpp-rotate-90:
- shard-dg2-set2: [SKIP][129] ([Intel XE#316]) -> [SKIP][130] ([Intel XE#1201] / [Intel XE#316]) +1 other test skip
[129]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@kms_big_fb@x-tiled-8bpp-rotate-90.html
[130]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@kms_big_fb@x-tiled-8bpp-rotate-90.html
* igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip:
- shard-adlp: [FAIL][131] ([Intel XE#1231]) -> [DMESG-FAIL][132] ([Intel XE#324]) +2 other tests dmesg-fail
[131]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-adlp-4/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip.html
[132]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-adlp-2/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip.html
* igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip:
- shard-adlp: [DMESG-FAIL][133] ([Intel XE#324]) -> [FAIL][134] ([Intel XE#1231])
[133]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-adlp-2/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html
[134]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-adlp-8/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html
* igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-0:
- shard-dg2-set2: [SKIP][135] ([Intel XE#1124] / [Intel XE#1201]) -> [SKIP][136] ([Intel XE#1124]) +4 other tests skip
[135]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-435/igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-0.html
[136]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-0.html
* igt@kms_big_fb@yf-tiled-32bpp-rotate-180:
- shard-dg2-set2: [SKIP][137] ([Intel XE#1124]) -> [SKIP][138] ([Intel XE#1124] / [Intel XE#1201]) +4 other tests skip
[137]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@kms_big_fb@yf-tiled-32bpp-rotate-180.html
[138]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@kms_big_fb@yf-tiled-32bpp-rotate-180.html
* igt@kms_big_joiner@basic:
- shard-dg2-set2: [SKIP][139] ([Intel XE#346]) -> [SKIP][140] ([Intel XE#1201] / [Intel XE#346])
[139]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@kms_big_joiner@basic.html
[140]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@kms_big_joiner@basic.html
* igt@kms_bw@connected-linear-tiling-1-displays-2160x1440p:
- shard-dg2-set2: [SKIP][141] ([Intel XE#1201] / [Intel XE#367]) -> [SKIP][142] ([Intel XE#367]) +2 other tests skip
[141]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-435/igt@kms_bw@connected-linear-tiling-1-displays-2160x1440p.html
[142]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@kms_bw@connected-linear-tiling-1-displays-2160x1440p.html
* igt@kms_bw@connected-linear-tiling-2-displays-1920x1080p:
- shard-dg2-set2: [SKIP][143] ([Intel XE#367]) -> [SKIP][144] ([Intel XE#1201] / [Intel XE#367]) +1 other test skip
[143]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@kms_bw@connected-linear-tiling-2-displays-1920x1080p.html
[144]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@kms_bw@connected-linear-tiling-2-displays-1920x1080p.html
* igt@kms_ccs@bad-rotation-90-4-tiled-lnl-ccs:
- shard-dg2-set2: [SKIP][145] ([Intel XE#1201] / [Intel XE#1252]) -> [SKIP][146] ([Intel XE#1252]) +1 other test skip
[145]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-435/igt@kms_ccs@bad-rotation-90-4-tiled-lnl-ccs.html
[146]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@kms_ccs@bad-rotation-90-4-tiled-lnl-ccs.html
* igt@kms_ccs@crc-primary-rotation-180-y-tiled-ccs@pipe-b-hdmi-a-6:
- shard-dg2-set2: [SKIP][147] ([Intel XE#1201] / [Intel XE#787]) -> [SKIP][148] ([Intel XE#787]) +34 other tests skip
[147]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-433/igt@kms_ccs@crc-primary-rotation-180-y-tiled-ccs@pipe-b-hdmi-a-6.html
[148]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@kms_ccs@crc-primary-rotation-180-y-tiled-ccs@pipe-b-hdmi-a-6.html
* igt@kms_ccs@crc-primary-rotation-180-y-tiled-gen12-mc-ccs:
- shard-dg2-set2: [SKIP][149] ([Intel XE#455] / [Intel XE#787]) -> [SKIP][150] ([Intel XE#1201] / [Intel XE#455] / [Intel XE#787]) +15 other tests skip
[149]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@kms_ccs@crc-primary-rotation-180-y-tiled-gen12-mc-ccs.html
[150]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@kms_ccs@crc-primary-rotation-180-y-tiled-gen12-mc-ccs.html
* igt@kms_ccs@missing-ccs-buffer-4-tiled-mtl-mc-ccs@pipe-d-dp-4:
- shard-dg2-set2: [SKIP][151] ([Intel XE#1201] / [Intel XE#455] / [Intel XE#787]) -> [SKIP][152] ([Intel XE#455] / [Intel XE#787]) +9 other tests skip
[151]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-433/igt@kms_ccs@missing-ccs-buffer-4-tiled-mtl-mc-ccs@pipe-d-dp-4.html
[152]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@kms_ccs@missing-ccs-buffer-4-tiled-mtl-mc-ccs@pipe-d-dp-4.html
* igt@kms_ccs@missing-ccs-buffer-4-tiled-mtl-rc-ccs@pipe-c-hdmi-a-6:
- shard-dg2-set2: [SKIP][153] ([Intel XE#787]) -> [SKIP][154] ([Intel XE#1201] / [Intel XE#787]) +55 other tests skip
[153]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@kms_ccs@missing-ccs-buffer-4-tiled-mtl-rc-ccs@pipe-c-hdmi-a-6.html
[154]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@kms_ccs@missing-ccs-buffer-4-tiled-mtl-rc-ccs@pipe-c-hdmi-a-6.html
* igt@kms_cdclk@plane-scaling@pipe-b-dp-4:
- shard-dg2-set2: [SKIP][155] ([Intel XE#1152]) -> [SKIP][156] ([Intel XE#1152] / [Intel XE#1201]) +3 other tests skip
[155]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@kms_cdclk@plane-scaling@pipe-b-dp-4.html
[156]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@kms_cdclk@plane-scaling@pipe-b-dp-4.html
* igt@kms_chamelium_color@ctm-0-25:
- shard-dg2-set2: [SKIP][157] ([Intel XE#1201] / [Intel XE#306]) -> [SKIP][158] ([Intel XE#306])
[157]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-435/igt@kms_chamelium_color@ctm-0-25.html
[158]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@kms_chamelium_color@ctm-0-25.html
* igt@kms_chamelium_edid@hdmi-edid-change-during-hibernate:
- shard-dg2-set2: [SKIP][159] ([Intel XE#373]) -> [SKIP][160] ([Intel XE#1201] / [Intel XE#373]) +4 other tests skip
[159]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@kms_chamelium_edid@hdmi-edid-change-during-hibernate.html
[160]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@kms_chamelium_edid@hdmi-edid-change-during-hibernate.html
* igt@kms_chamelium_edid@hdmi-edid-stress-resolution-4k:
- shard-dg2-set2: [SKIP][161] ([Intel XE#1201] / [Intel XE#373]) -> [SKIP][162] ([Intel XE#373]) +4 other tests skip
[161]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-435/igt@kms_chamelium_edid@hdmi-edid-stress-resolution-4k.html
[162]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@kms_chamelium_edid@hdmi-edid-stress-resolution-4k.html
* igt@kms_content_protection@dp-mst-lic-type-0:
- shard-dg2-set2: [SKIP][163] ([Intel XE#307]) -> [SKIP][164] ([Intel XE#1201] / [Intel XE#307])
[163]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@kms_content_protection@dp-mst-lic-type-0.html
[164]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@kms_content_protection@dp-mst-lic-type-0.html
* igt@kms_cursor_crc@cursor-random-32x10:
- shard-dg2-set2: [SKIP][165] ([Intel XE#1201] / [Intel XE#455]) -> [SKIP][166] ([Intel XE#455]) +3 other tests skip
[165]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-433/igt@kms_cursor_crc@cursor-random-32x10.html
[166]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@kms_cursor_crc@cursor-random-32x10.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- shard-dg2-set2: [SKIP][167] ([Intel XE#323]) -> [SKIP][168] ([Intel XE#1201] / [Intel XE#323])
[167]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
[168]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
* igt@kms_dsc@dsc-with-bpc-formats:
- shard-dg2-set2: [SKIP][169] ([Intel XE#455]) -> [SKIP][170] ([Intel XE#1201] / [Intel XE#455]) +5 other tests skip
[169]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@kms_dsc@dsc-with-bpc-formats.html
[170]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@kms_dsc@dsc-with-bpc-formats.html
* igt@kms_feature_discovery@chamelium:
- shard-dg2-set2: [SKIP][171] ([Intel XE#1201] / [Intel XE#701]) -> [SKIP][172] ([Intel XE#701])
[171]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-433/igt@kms_feature_discovery@chamelium.html
[172]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@kms_feature_discovery@chamelium.html
* igt@kms_frontbuffer_tracking@fbc-tiling-y:
- shard-dg2-set2: [SKIP][173] ([Intel XE#658]) -> [SKIP][174] ([Intel XE#1201] / [Intel XE#658]) +1 other test skip
[173]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@kms_frontbuffer_tracking@fbc-tiling-y.html
[174]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@kms_frontbuffer_tracking@fbc-tiling-y.html
* igt@kms_frontbuffer_tracking@fbcdrrs-2p-primscrn-pri-shrfb-draw-blt:
- shard-dg2-set2: [SKIP][175] ([Intel XE#651]) -> [SKIP][176] ([Intel XE#1201] / [Intel XE#651]) +13 other tests skip
[175]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@kms_frontbuffer_tracking@fbcdrrs-2p-primscrn-pri-shrfb-draw-blt.html
[176]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@kms_frontbuffer_tracking@fbcdrrs-2p-primscrn-pri-shrfb-draw-blt.html
* igt@kms_frontbuffer_tracking@fbcdrrs-rgb101010-draw-mmap-wc:
- shard-dg2-set2: [SKIP][177] ([Intel XE#1201] / [Intel XE#651]) -> [SKIP][178] ([Intel XE#651]) +14 other tests skip
[177]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-433/igt@kms_frontbuffer_tracking@fbcdrrs-rgb101010-draw-mmap-wc.html
[178]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@kms_frontbuffer_tracking@fbcdrrs-rgb101010-draw-mmap-wc.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-pri-indfb-draw-blt:
- shard-dg2-set2: [SKIP][179] ([Intel XE#1201] / [Intel XE#653]) -> [SKIP][180] ([Intel XE#653]) +14 other tests skip
[179]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-433/igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-pri-indfb-draw-blt.html
[180]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-pri-indfb-draw-blt.html
* igt@kms_frontbuffer_tracking@plane-fbc-rte:
- shard-dg2-set2: [SKIP][181] ([Intel XE#1158] / [Intel XE#1201]) -> [SKIP][182] ([Intel XE#1158])
[181]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-435/igt@kms_frontbuffer_tracking@plane-fbc-rte.html
[182]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@kms_frontbuffer_tracking@plane-fbc-rte.html
* igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-wc:
- shard-dg2-set2: [SKIP][183] ([Intel XE#653]) -> [SKIP][184] ([Intel XE#1201] / [Intel XE#653]) +13 other tests skip
[183]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-wc.html
[184]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-wc.html
* igt@kms_plane_scaling@plane-downscale-factor-0-25-with-modifiers:
- shard-dg2-set2: [SKIP][185] ([Intel XE#455] / [Intel XE#498]) -> [SKIP][186] ([Intel XE#1201] / [Intel XE#455] / [Intel XE#498]) +1 other test skip
[185]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@kms_plane_scaling@plane-downscale-factor-0-25-with-modifiers.html
[186]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@kms_plane_scaling@plane-downscale-factor-0-25-with-modifiers.html
* igt@kms_plane_scaling@plane-downscale-factor-0-25-with-modifiers@pipe-c-hdmi-a-6:
- shard-dg2-set2: [SKIP][187] ([Intel XE#498]) -> [SKIP][188] ([Intel XE#1201] / [Intel XE#498]) +2 other tests skip
[187]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@kms_plane_scaling@plane-downscale-factor-0-25-with-modifiers@pipe-c-hdmi-a-6.html
[188]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@kms_plane_scaling@plane-downscale-factor-0-25-with-modifiers@pipe-c-hdmi-a-6.html
* igt@kms_plane_scaling@planes-downscale-factor-0-25-upscale-factor-0-25:
- shard-dg2-set2: [SKIP][189] ([Intel XE#2318] / [Intel XE#455]) -> [SKIP][190] ([Intel XE#1201] / [Intel XE#2318] / [Intel XE#455]) +1 other test skip
[189]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@kms_plane_scaling@planes-downscale-factor-0-25-upscale-factor-0-25.html
[190]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@kms_plane_scaling@planes-downscale-factor-0-25-upscale-factor-0-25.html
* igt@kms_plane_scaling@planes-downscale-factor-0-25-upscale-factor-0-25@pipe-c-hdmi-a-6:
- shard-dg2-set2: [SKIP][191] ([Intel XE#2318]) -> [SKIP][192] ([Intel XE#1201] / [Intel XE#2318]) +2 other tests skip
[191]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@kms_plane_scaling@planes-downscale-factor-0-25-upscale-factor-0-25@pipe-c-hdmi-a-6.html
[192]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@kms_plane_scaling@planes-downscale-factor-0-25-upscale-factor-0-25@pipe-c-hdmi-a-6.html
* igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-25:
- shard-dg2-set2: [SKIP][193] ([Intel XE#1201] / [Intel XE#2318] / [Intel XE#455]) -> [SKIP][194] ([Intel XE#2318] / [Intel XE#455]) +1 other test skip
[193]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-435/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-25.html
[194]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-25.html
* igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-25@pipe-c-hdmi-a-6:
- shard-dg2-set2: [SKIP][195] ([Intel XE#1201] / [Intel XE#2318]) -> [SKIP][196] ([Intel XE#2318]) +2 other tests skip
[195]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-435/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-25@pipe-c-hdmi-a-6.html
[196]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-25@pipe-c-hdmi-a-6.html
* igt@kms_pm_backlight@basic-brightness:
- shard-dg2-set2: [SKIP][197] ([Intel XE#870]) -> [SKIP][198] ([Intel XE#1201] / [Intel XE#870])
[197]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@kms_pm_backlight@basic-brightness.html
[198]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@kms_pm_backlight@basic-brightness.html
* igt@kms_psr2_sf@fbc-cursor-plane-move-continuous-exceed-fully-sf:
- shard-dg2-set2: [SKIP][199] ([Intel XE#1201] / [Intel XE#1489]) -> [SKIP][200] ([Intel XE#1489]) +1 other test skip
[199]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-433/igt@kms_psr2_sf@fbc-cursor-plane-move-continuous-exceed-fully-sf.html
[200]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@kms_psr2_sf@fbc-cursor-plane-move-continuous-exceed-fully-sf.html
* igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-big-fb:
- shard-dg2-set2: [SKIP][201] ([Intel XE#1489]) -> [SKIP][202] ([Intel XE#1201] / [Intel XE#1489]) +1 other test skip
[201]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-big-fb.html
[202]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-big-fb.html
* igt@kms_psr2_su@page_flip-p010:
- shard-dg2-set2: [SKIP][203] ([Intel XE#1122] / [Intel XE#1201]) -> [SKIP][204] ([Intel XE#1122])
[203]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-433/igt@kms_psr2_su@page_flip-p010.html
[204]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@kms_psr2_su@page_flip-p010.html
* igt@kms_psr@fbc-psr2-sprite-plane-onoff:
- shard-dg2-set2: [SKIP][205] ([Intel XE#1201] / [Intel XE#929]) -> [SKIP][206] ([Intel XE#929]) +6 other tests skip
[205]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-435/igt@kms_psr@fbc-psr2-sprite-plane-onoff.html
[206]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@kms_psr@fbc-psr2-sprite-plane-onoff.html
* igt@kms_psr@pr-primary-page-flip:
- shard-dg2-set2: [SKIP][207] ([Intel XE#929]) -> [SKIP][208] ([Intel XE#1201] / [Intel XE#929]) +6 other tests skip
[207]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@kms_psr@pr-primary-page-flip.html
[208]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@kms_psr@pr-primary-page-flip.html
* igt@kms_rotation_crc@primary-yf-tiled-reflect-x-180:
- shard-dg2-set2: [SKIP][209] ([Intel XE#1127] / [Intel XE#1201]) -> [SKIP][210] ([Intel XE#1127]) +1 other test skip
[209]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-435/igt@kms_rotation_crc@primary-yf-tiled-reflect-x-180.html
[210]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@kms_rotation_crc@primary-yf-tiled-reflect-x-180.html
* igt@kms_rotation_crc@sprite-rotation-90:
- shard-dg2-set2: [SKIP][211] ([Intel XE#327]) -> [SKIP][212] ([Intel XE#1201] / [Intel XE#327])
[211]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@kms_rotation_crc@sprite-rotation-90.html
[212]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@kms_rotation_crc@sprite-rotation-90.html
* igt@kms_tiled_display@basic-test-pattern-with-chamelium:
- shard-dg2-set2: [SKIP][213] ([Intel XE#1201] / [Intel XE#362]) -> [SKIP][214] ([Intel XE#1201] / [Intel XE#1500])
[213]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-463/igt@kms_tiled_display@basic-test-pattern-with-chamelium.html
[214]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-435/igt@kms_tiled_display@basic-test-pattern-with-chamelium.html
* igt@kms_vrr@cmrr:
- shard-dg2-set2: [SKIP][215] ([Intel XE#1201] / [Intel XE#2168]) -> [SKIP][216] ([Intel XE#2168])
[215]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-433/igt@kms_vrr@cmrr.html
[216]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@kms_vrr@cmrr.html
* igt@kms_writeback@writeback-fb-id-xrgb2101010:
- shard-dg2-set2: [SKIP][217] ([Intel XE#1201] / [Intel XE#756]) -> [SKIP][218] ([Intel XE#756])
[217]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-435/igt@kms_writeback@writeback-fb-id-xrgb2101010.html
[218]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@kms_writeback@writeback-fb-id-xrgb2101010.html
* igt@sriov_basic@enable-vfs-bind-unbind-each-numvfs-all:
- shard-dg2-set2: [SKIP][219] ([Intel XE#1091]) -> [SKIP][220] ([Intel XE#1091] / [Intel XE#1201])
[219]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@sriov_basic@enable-vfs-bind-unbind-each-numvfs-all.html
[220]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@sriov_basic@enable-vfs-bind-unbind-each-numvfs-all.html
* igt@xe_compute_preempt@compute-preempt-many:
- shard-dg2-set2: [SKIP][221] ([Intel XE#1280] / [Intel XE#455]) -> [SKIP][222] ([Intel XE#1201] / [Intel XE#1280] / [Intel XE#455]) +1 other test skip
[221]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@xe_compute_preempt@compute-preempt-many.html
[222]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@xe_compute_preempt@compute-preempt-many.html
* igt@xe_compute_preempt@compute-threadgroup-preempt@engine-drm_xe_engine_class_compute:
- shard-dg2-set2: [SKIP][223] ([Intel XE#1201] / [Intel XE#1280] / [Intel XE#455]) -> [SKIP][224] ([Intel XE#1280] / [Intel XE#455]) +1 other test skip
[223]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-435/igt@xe_compute_preempt@compute-threadgroup-preempt@engine-drm_xe_engine_class_compute.html
[224]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@xe_compute_preempt@compute-threadgroup-preempt@engine-drm_xe_engine_class_compute.html
* igt@xe_copy_basic@mem-copy-linear-0xfd:
- shard-dg2-set2: [SKIP][225] ([Intel XE#1123]) -> [SKIP][226] ([Intel XE#1123] / [Intel XE#1201])
[225]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@xe_copy_basic@mem-copy-linear-0xfd.html
[226]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@xe_copy_basic@mem-copy-linear-0xfd.html
* igt@xe_exec_fault_mode@once-userptr-invalidate-race:
- shard-dg2-set2: [SKIP][227] ([Intel XE#1201] / [Intel XE#288]) -> [SKIP][228] ([Intel XE#288]) +11 other tests skip
[227]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-435/igt@xe_exec_fault_mode@once-userptr-invalidate-race.html
[228]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@xe_exec_fault_mode@once-userptr-invalidate-race.html
* igt@xe_exec_fault_mode@twice-userptr-invalidate-race:
- shard-dg2-set2: [SKIP][229] ([Intel XE#288]) -> [SKIP][230] ([Intel XE#1201] / [Intel XE#288]) +13 other tests skip
[229]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@xe_exec_fault_mode@twice-userptr-invalidate-race.html
[230]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@xe_exec_fault_mode@twice-userptr-invalidate-race.html
* igt@xe_exec_mix_modes@exec-simple-batch-store-dma-fence:
- shard-dg2-set2: [SKIP][231] ([Intel XE#1201] / [Intel XE#2360]) -> [SKIP][232] ([Intel XE#2360])
[231]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-433/igt@xe_exec_mix_modes@exec-simple-batch-store-dma-fence.html
[232]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@xe_exec_mix_modes@exec-simple-batch-store-dma-fence.html
* igt@xe_oa@create-destroy-userspace-config:
- shard-dg2-set2: [SKIP][233] ([Intel XE#2541]) -> [SKIP][234] ([Intel XE#1201] / [Intel XE#2541]) +3 other tests skip
[233]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@xe_oa@create-destroy-userspace-config.html
[234]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@xe_oa@create-destroy-userspace-config.html
* igt@xe_oa@non-zero-reason:
- shard-dg2-set2: [SKIP][235] ([Intel XE#1201] / [Intel XE#2541]) -> [SKIP][236] ([Intel XE#2541]) +2 other tests skip
[235]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-433/igt@xe_oa@non-zero-reason.html
[236]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@xe_oa@non-zero-reason.html
* igt@xe_pm@s2idle-d3cold-basic-exec:
- shard-dg2-set2: [SKIP][237] ([Intel XE#1201] / [Intel XE#2284] / [Intel XE#366]) -> [SKIP][238] ([Intel XE#2284] / [Intel XE#366])
[237]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-433/igt@xe_pm@s2idle-d3cold-basic-exec.html
[238]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@xe_pm@s2idle-d3cold-basic-exec.html
* igt@xe_pm@s3-d3cold-basic-exec:
- shard-dg2-set2: [SKIP][239] ([Intel XE#2284] / [Intel XE#366]) -> [SKIP][240] ([Intel XE#1201] / [Intel XE#2284] / [Intel XE#366])
[239]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@xe_pm@s3-d3cold-basic-exec.html
[240]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@xe_pm@s3-d3cold-basic-exec.html
* igt@xe_query@multigpu-query-invalid-cs-cycles:
- shard-dg2-set2: [SKIP][241] ([Intel XE#944]) -> [SKIP][242] ([Intel XE#1201] / [Intel XE#944]) +1 other test skip
[241]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-432/igt@xe_query@multigpu-query-invalid-cs-cycles.html
[242]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-433/igt@xe_query@multigpu-query-invalid-cs-cycles.html
* igt@xe_query@multigpu-query-mem-usage:
- shard-dg2-set2: [SKIP][243] ([Intel XE#1201] / [Intel XE#944]) -> [SKIP][244] ([Intel XE#944])
[243]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d/shard-dg2-433/igt@xe_query@multigpu-query-mem-usage.html
[244]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/shard-dg2-432/igt@xe_query@multigpu-query-mem-usage.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[Intel XE#1091]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1091
[Intel XE#1122]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1122
[Intel XE#1123]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1123
[Intel XE#1124]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1124
[Intel XE#1126]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1126
[Intel XE#1127]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1127
[Intel XE#1152]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1152
[Intel XE#1158]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1158
[Intel XE#1169]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1169
[Intel XE#1173]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1173
[Intel XE#1195]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1195
[Intel XE#1201]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1201
[Intel XE#1231]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1231
[Intel XE#1252]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1252
[Intel XE#1280]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1280
[Intel XE#1356]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1356
[Intel XE#1358]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1358
[Intel XE#1392]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1392
[Intel XE#1399]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1399
[Intel XE#1401]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1401
[Intel XE#1407]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1407
[Intel XE#1421]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1421
[Intel XE#1426]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1426
[Intel XE#1430]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1430
[Intel XE#1473]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1473
[Intel XE#1489]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1489
[Intel XE#1500]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1500
[Intel XE#1503]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1503
[Intel XE#1522]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1522
[Intel XE#1607]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1607
[Intel XE#1616]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1616
[Intel XE#1620]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1620
[Intel XE#1638]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1638
[Intel XE#1659]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1659
[Intel XE#1745]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1745
[Intel XE#1794]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1794
[Intel XE#1874]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1874
[Intel XE#1961]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1961
[Intel XE#2026]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2026
[Intel XE#2168]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2168
[Intel XE#2251]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2251
[Intel XE#2284]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2284
[Intel XE#2311]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2311
[Intel XE#2313]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2313
[Intel XE#2318]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2318
[Intel XE#2327]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2327
[Intel XE#2333]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2333
[Intel XE#2360]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2360
[Intel XE#2380]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2380
[Intel XE#2426]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2426
[Intel XE#2436]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2436
[Intel XE#2443]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2443
[Intel XE#2509]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2509
[Intel XE#2514]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2514
[Intel XE#2541]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2541
[Intel XE#261]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/261
[Intel XE#288]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/288
[Intel XE#306]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/306
[Intel XE#307]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/307
[Intel XE#309]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/309
[Intel XE#316]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/316
[Intel XE#323]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/323
[Intel XE#324]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/324
[Intel XE#327]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/327
[Intel XE#346]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/346
[Intel XE#362]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/362
[Intel XE#366]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/366
[Intel XE#367]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/367
[Intel XE#373]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/373
[Intel XE#455]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/455
[Intel XE#498]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/498
[Intel XE#569]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/569
[Intel XE#651]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/651
[Intel XE#653]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/653
[Intel XE#656]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/656
[Intel XE#658]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/658
[Intel XE#688]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/688
[Intel XE#701]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/701
[Intel XE#756]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/756
[Intel XE#771]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/771
[Intel XE#787]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/787
[Intel XE#827]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/827
[Intel XE#870]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/870
[Intel XE#877]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/877
[Intel XE#886]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/886
[Intel XE#899]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/899
[Intel XE#929]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/929
[Intel XE#944]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/944
[Intel XE#958]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/958
Build changes
-------------
* Linux: xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d -> xe-pw-137985v2
IGT_8006: ae7f2bc0b99801a7ae369d4b5fda5c6b1c386eb1 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
xe-1901-7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d: 7f3ffaf88a3a1b3e29416488fb4e58fd551cd89d
xe-pw-137985v2: 137985v2
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-137985v2/index.html
[-- Attachment #2: Type: text/html, Size: 85705 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function
2024-09-07 2:06 ` John Harrison
@ 2024-09-10 1:31 ` John Harrison
2024-09-10 19:43 ` Lucas De Marchi
0 siblings, 1 reply; 54+ messages in thread
From: John Harrison @ 2024-09-10 1:31 UTC (permalink / raw)
To: Lucas De Marchi; +Cc: Intel-Xe, Matthew Brost
On 9/6/2024 19:06, John Harrison wrote:
> On 9/5/2024 20:04, Lucas De Marchi wrote:
>> On Thu, Sep 05, 2024 at 07:01:33PM GMT, John Harrison wrote:
>>> On 9/5/2024 18:54, Lucas De Marchi wrote:
>>>> On Thu, Sep 05, 2024 at 01:50:58PM GMT, 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.
>>>>
>>>> why are we not dumping the binary data directly to devcoredump?
>>> As per earlier comments, there is a WiFi driver or some such that
>>> does exactly that. But all they are dumping is a binary blob.
>>
>> In your v5 I see you mentioned
>> drivers/net/wireless/ath/ath10k/coredump.c, but that is a precedence for
>> including it as is from the device rather converting it to ASCII85 or
>> something else. It seems odd to do that type of conversion in kernel
>> space when it could be perfectly done in userspace.
> It really can't. An end user could maybe be expected to zip or tar a
> coredump file before attaching it to a bug report but they are
> certainly not going to try to ASCII85 encode random bits of it.
> Whereas, putting that in the kernel means it is just there. It is
> done. And it is pretty trivial - just call a helper function and it
> does everything for you. Also, I very much doubt you can spew raw
> binary data via dmesg. Even if the kernel would print it for you
> (which I doubt), the user tools like syslogd and dmesg itself are
> going to filter it to make it ASCII safe.
>
> The i915 error dumps have been ASCII85 encoded using the kernel's
> ASCII85 encoding helper function since forever. This patch is just a
> wrapper around the kernel's existing implementation in order to make
> it more compatible with printing to dmesg. This is not creating a new
> precedent. It already exists.
>
>>
>> $ git grep ascii85.h
>> drivers/gpu/drm/i915/i915_gpu_error.c:#include <linux/ascii85.h>
>> drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:#include <linux/ascii85.h>
>> drivers/gpu/drm/msm/adreno/adreno_gpu.c:#include <linux/ascii85.h>
>> drivers/gpu/drm/xe/xe_lrc.c:#include <linux/ascii85.h>
>> drivers/gpu/drm/xe/xe_vm.c:#include <linux/ascii85.h>
> And the list of drivers which dump raw binary data in a coredump file
> is... ath10k. ASCII85 wins 3 to 1.
>
>
>>
>>>
>>> We want the devcoredump file to still be human readable. That won't
>>> be the case if you stuff binary data in the middle of it. Most
>>> obvious problem - the zeros in the data will terminate your text
>>> file at that point. Potentially bigger problem for end users -
>>> random fake ANSI codes will destroy your terminal window if you try
>>> to cat the file to read it.
>>
>> Users don't get a coredump and cat it to the terminal.
>> =(lk%A8`T7AKYH#FD,6++EqOABHUhsG%5H2ARoq#E$/V$Bl7Q+@<5pmBe<q;Bk;0mCj@.3DIal2FD5Q-+E_RBART+X@VfTuGA2/4Dfp.E@3BN0DfB9.+E1b0F(KAV+:8
>>
>>
>> Lucas De Marchi
> They might. Either intentionally or accidentally. I've certainly done
> it myself. And people will certainly want to look at it in any random
> choice of text editor, pager, etc. 'cos you know, it is meant to be
> read by humans. If it is full of binary data then that becomes even
> more difficult than simply being full of ASCII gibberish. No matter
> what you are doing, the ASCII version is safer and easier to look at
> the rest of the file around it.
>
> I don't understand why you are so desperate to have raw binary data in
> the middle of a text file. The disadvantages are multiple but the only
> advantage is a slightly smaller file. And the true route to smaller
> files is to add compression like we have in i915.
>
> John.
>
PS: Also meant to add that one of the important uses cases for dumping
logs to dmesg is for the really hard to repro bugs that show up in CI
extremely rarely. We get the driver to dump an error capture to dmesg
and pull that out from the CI logs. Even if you could get binary data
through dmesg, pretty sure the CI tools would also not be happy with it.
Anything non-printable will get munged for sure when turning it into a
web page.
John.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 01/10] drm/xe/guc: Remove spurious line feed in debug print
2024-09-05 20:50 ` [PATCH v7 01/10] drm/xe/guc: Remove spurious line feed in debug print John.C.Harrison
@ 2024-09-10 19:32 ` Julia Filipchuk
0 siblings, 0 replies; 54+ messages in thread
From: Julia Filipchuk @ 2024-09-10 19:32 UTC (permalink / raw)
To: John.C.Harrison, Intel-Xe; +Cc: Michal Wajdeczko
Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 02/10] drm/xe/devcoredump: Add a section heading for the submission backend
2024-09-05 20:50 ` [PATCH v7 02/10] drm/xe/devcoredump: Add a section heading for the submission backend John.C.Harrison
@ 2024-09-10 19:33 ` Julia Filipchuk
0 siblings, 0 replies; 54+ messages in thread
From: Julia Filipchuk @ 2024-09-10 19:33 UTC (permalink / raw)
To: John.C.Harrison, Intel-Xe
Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function
2024-09-05 20:50 ` [PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function John.C.Harrison
2024-09-06 1:54 ` Lucas De Marchi
@ 2024-09-10 19:33 ` Julia Filipchuk
2024-09-11 1:27 ` John Harrison
1 sibling, 1 reply; 54+ messages in thread
From: Julia Filipchuk @ 2024-09-10 19:33 UTC (permalink / raw)
To: John.C.Harrison, Intel-Xe
> + if (prefix) {
> + strscpy(line_buff, prefix, DMESG_MAX_LINE_LEN - MIN_SPACE - 3);
> + line_pos = strlen(line_buff);
> +
> + line_buff[line_pos++] = ':';
> + line_buff[line_pos++] = ' ';
> + }
Since 2 characters are added to the end of prefix should the computation
for n be "DMESG_MAX_LINE_LEN - MIN_SPACE - 2"? MIN_SPACE already
accounts for space of trailing newline and null terminator.
Also, prefix is only added to the first line. Is that the intended behavior?
> + strscpy(line_buff + line_pos, ascii85_encode(val, buff),
> + DMESG_MAX_LINE_LEN - line_pos);
> + line_pos += strlen(line_buff + line_pos);
Since space for ASCII85_BUFSZ bytes is guaranteed by checks against
MIN_SPACE output of strscpy can be used to increment line_pos. Although
I do like this safer style that would work even if the checks failed.
> +#undef MIN_SPACE
Suggest to also #undef DMESG_MAX_LINE_LEN here.
Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function
2024-09-10 1:31 ` John Harrison
@ 2024-09-10 19:43 ` Lucas De Marchi
2024-09-10 20:17 ` John Harrison
0 siblings, 1 reply; 54+ messages in thread
From: Lucas De Marchi @ 2024-09-10 19:43 UTC (permalink / raw)
To: John Harrison; +Cc: Intel-Xe, Matthew Brost
On Mon, Sep 09, 2024 at 06:31:41PM GMT, John Harrison wrote:
>On 9/6/2024 19:06, John Harrison wrote:
>>On 9/5/2024 20:04, Lucas De Marchi wrote:
>>>On Thu, Sep 05, 2024 at 07:01:33PM GMT, John Harrison wrote:
>>>>On 9/5/2024 18:54, Lucas De Marchi wrote:
>>>>>On Thu, Sep 05, 2024 at 01:50:58PM GMT,
>>>>>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.
>>>>>
>>>>>why are we not dumping the binary data directly to devcoredump?
>>>>As per earlier comments, there is a WiFi driver or some such
>>>>that does exactly that. But all they are dumping is a binary
>>>>blob.
>>>
>>>In your v5 I see you mentioned
>>>drivers/net/wireless/ath/ath10k/coredump.c, but that is a precedence for
>>>including it as is from the device rather converting it to ASCII85 or
>>>something else. It seems odd to do that type of conversion in kernel
>>>space when it could be perfectly done in userspace.
>>It really can't. An end user could maybe be expected to zip or tar a
>>coredump file before attaching it to a bug report but they are
>>certainly not going to try to ASCII85 encode random bits of it.
>>Whereas, putting that in the kernel means it is just there. It is
>>done. And it is pretty trivial - just call a helper function and it
>>does everything for you. Also, I very much doubt you can spew raw
>>binary data via dmesg. Even if the kernel would print it for you
>>(which I doubt), the user tools like syslogd and dmesg itself are
>>going to filter it to make it ASCII safe.
>>
>>The i915 error dumps have been ASCII85 encoded using the kernel's
>>ASCII85 encoding helper function since forever. This patch is just a
>>wrapper around the kernel's existing implementation in order to make
>>it more compatible with printing to dmesg. This is not creating a
>>new precedent. It already exists.
>>
>>>
>>>$ git grep ascii85.h
>>>drivers/gpu/drm/i915/i915_gpu_error.c:#include <linux/ascii85.h>
>>>drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:#include <linux/ascii85.h>
>>>drivers/gpu/drm/msm/adreno/adreno_gpu.c:#include <linux/ascii85.h>
>>>drivers/gpu/drm/xe/xe_lrc.c:#include <linux/ascii85.h>
>>>drivers/gpu/drm/xe/xe_vm.c:#include <linux/ascii85.h>
>>And the list of drivers which dump raw binary data in a coredump
>>file is... ath10k. ASCII85 wins 3 to 1.
>>
>>
>>>
>>>>
>>>>We want the devcoredump file to still be human readable. That
>>>>won't be the case if you stuff binary data in the middle of it.
>>>>Most obvious problem - the zeros in the data will terminate your
>>>>text file at that point. Potentially bigger problem for end
>>>>users - random fake ANSI codes will destroy your terminal window
>>>>if you try to cat the file to read it.
>>>
>>>Users don't get a coredump and cat it to the terminal.
>>>=(lk%A8`T7AKYH#FD,6++EqOABHUhsG%5H2ARoq#E$/V$Bl7Q+@<5pmBe<q;Bk;0mCj@.3DIal2FD5Q-+E_RBART+X@VfTuGA2/4Dfp.E@3BN0DfB9.+E1b0F(KAV+:8
>>>
>>>
>>>Lucas De Marchi
>>They might. Either intentionally or accidentally. I've certainly
>>done it myself. And people will certainly want to look at it in any
>>random choice of text editor, pager, etc. 'cos you know, it is meant
>>to be read by humans. If it is full of binary data then that becomes
>>even more difficult than simply being full of ASCII gibberish. No
>>matter what you are doing, the ASCII version is safer and easier to
>>look at the rest of the file around it.
>>
>>I don't understand why you are so desperate to have raw binary data
>>in the middle of a text file. The disadvantages are multiple but the
>>only advantage is a slightly smaller file. And the true route to
>>smaller files is to add compression like we have in i915.
>>
>>John.
>>
>PS: Also meant to add that one of the important uses cases for dumping
>logs to dmesg is for the really hard to repro bugs that show up in CI
>extremely rarely. We get the driver to dump an error capture to dmesg
>and pull that out from the CI logs. Even if you could get binary data
>through dmesg, pretty sure the CI tools would also not be happy with
>it. Anything non-printable will get munged for sure when turning it
>into a web page.
I think that's the main source of confusion on what we are discussing.
I was not talking about dmesg at all. I'm only complaining about feeding
ascii85-encoded data into a *devcoredump* when apparently there isn't a
good reason to do so. I'd rather copy the binary data to the
devcoredump.
For dmesg, there's a reason to encode it as you pointed out... but
no users shouldn't actually see it - we should be getting all of those
cases in CI. For the escape scenarios, yeah... better having it
ascii85-encoded.
What you are adding to devcoredump also doesn't even seem to be an
ascii85 representation, but a multiple lines that should be concatenated
to form the ascii85 representation. For dmesg it makes sense. Not for
devcoredump. We should also probabaly need a length field (correctly
accounting for the additional characters for each line) so we don't
have an implicit dependency on what's the next field to know how much to
parse.
Lucas De Marchi
>
>John.
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function
2024-09-10 19:43 ` Lucas De Marchi
@ 2024-09-10 20:17 ` John Harrison
2024-09-11 19:12 ` Lucas De Marchi
0 siblings, 1 reply; 54+ messages in thread
From: John Harrison @ 2024-09-10 20:17 UTC (permalink / raw)
To: Lucas De Marchi; +Cc: Intel-Xe, Matthew Brost
On 9/10/2024 12:43, Lucas De Marchi wrote:
> On Mon, Sep 09, 2024 at 06:31:41PM GMT, John Harrison wrote:
>> On 9/6/2024 19:06, John Harrison wrote:
>>> On 9/5/2024 20:04, Lucas De Marchi wrote:
>>>> On Thu, Sep 05, 2024 at 07:01:33PM GMT, John Harrison wrote:
>>>>> On 9/5/2024 18:54, Lucas De Marchi wrote:
>>>>>> On Thu, Sep 05, 2024 at 01:50:58PM GMT, 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.
>>>>>>
>>>>>> why are we not dumping the binary data directly to devcoredump?
>>>>> As per earlier comments, there is a WiFi driver or some such that
>>>>> does exactly that. But all they are dumping is a binary blob.
>>>>
>>>> In your v5 I see you mentioned
>>>> drivers/net/wireless/ath/ath10k/coredump.c, but that is a
>>>> precedence for
>>>> including it as is from the device rather converting it to ASCII85 or
>>>> something else. It seems odd to do that type of conversion in kernel
>>>> space when it could be perfectly done in userspace.
>>> It really can't. An end user could maybe be expected to zip or tar a
>>> coredump file before attaching it to a bug report but they are
>>> certainly not going to try to ASCII85 encode random bits of it.
>>> Whereas, putting that in the kernel means it is just there. It is
>>> done. And it is pretty trivial - just call a helper function and it
>>> does everything for you. Also, I very much doubt you can spew raw
>>> binary data via dmesg. Even if the kernel would print it for you
>>> (which I doubt), the user tools like syslogd and dmesg itself are
>>> going to filter it to make it ASCII safe.
>>>
>>> The i915 error dumps have been ASCII85 encoded using the kernel's
>>> ASCII85 encoding helper function since forever. This patch is just a
>>> wrapper around the kernel's existing implementation in order to make
>>> it more compatible with printing to dmesg. This is not creating a
>>> new precedent. It already exists.
>>>
>>>>
>>>> $ git grep ascii85.h
>>>> drivers/gpu/drm/i915/i915_gpu_error.c:#include <linux/ascii85.h>
>>>> drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:#include <linux/ascii85.h>
>>>> drivers/gpu/drm/msm/adreno/adreno_gpu.c:#include <linux/ascii85.h>
>>>> drivers/gpu/drm/xe/xe_lrc.c:#include <linux/ascii85.h>
>>>> drivers/gpu/drm/xe/xe_vm.c:#include <linux/ascii85.h>
>>> And the list of drivers which dump raw binary data in a coredump
>>> file is... ath10k. ASCII85 wins 3 to 1.
>>>
>>>
>>>>
>>>>>
>>>>> We want the devcoredump file to still be human readable. That
>>>>> won't be the case if you stuff binary data in the middle of it.
>>>>> Most obvious problem - the zeros in the data will terminate your
>>>>> text file at that point. Potentially bigger problem for end users
>>>>> - random fake ANSI codes will destroy your terminal window if you
>>>>> try to cat the file to read it.
>>>>
>>>> Users don't get a coredump and cat it to the terminal.
>>>> =(lk%A8`T7AKYH#FD,6++EqOABHUhsG%5H2ARoq#E$/V$Bl7Q+@<5pmBe<q;Bk;0mCj@.3DIal2FD5Q-+E_RBART+X@VfTuGA2/4Dfp.E@3BN0DfB9.+E1b0F(KAV+:8
>>>>
>>>>
>>>>
>>>> Lucas De Marchi
>>> They might. Either intentionally or accidentally. I've certainly
>>> done it myself. And people will certainly want to look at it in any
>>> random choice of text editor, pager, etc. 'cos you know, it is meant
>>> to be read by humans. If it is full of binary data then that becomes
>>> even more difficult than simply being full of ASCII gibberish. No
>>> matter what you are doing, the ASCII version is safer and easier to
>>> look at the rest of the file around it.
>>>
>>> I don't understand why you are so desperate to have raw binary data
>>> in the middle of a text file. The disadvantages are multiple but the
>>> only advantage is a slightly smaller file. And the true route to
>>> smaller files is to add compression like we have in i915.
>>>
>>> John.
>>>
>> PS: Also meant to add that one of the important uses cases for
>> dumping logs to dmesg is for the really hard to repro bugs that show
>> up in CI extremely rarely. We get the driver to dump an error capture
>> to dmesg and pull that out from the CI logs. Even if you could get
>> binary data through dmesg, pretty sure the CI tools would also not be
>> happy with it. Anything non-printable will get munged for sure when
>> turning it into a web page.
>
> I think that's the main source of confusion on what we are discussing.
> I was not talking about dmesg at all. I'm only complaining about feeding
> ascii85-encoded data into a *devcoredump* when apparently there isn't a
> good reason to do so. I'd rather copy the binary data to the
> devcoredump.
But the intent is to dump a devcoredump to dmesg. It makes much sense to
have a single implementation that can be used for multiple purposes.
Otherwise you are duplicating a lot of code unnecessarily.
And I still think it is a *very* bad idea to be including binary data in
a text file. The devcoredump is supposed to be human readable. It is
supposed to be obtained by end users and passed around. Having binary
data in there just makes everything more complex and error prone. We
want this to be as simple, easy and safe as possible.
>
> For dmesg, there's a reason to encode it as you pointed out... but
> no users shouldn't actually see it - we should be getting all of those
> cases in CI. For the escape scenarios, yeah... better having it
> ascii85-encoded.
>
> What you are adding to devcoredump also doesn't even seem to be an
> ascii85 representation, but a multiple lines that should be concatenated
> to form the ascii85 representation. For dmesg it makes sense. Not for
> devcoredump. We should also probabaly need a length field (correctly
> accounting for the additional characters for each line) so we don't
> have an implicit dependency on what's the next field to know how much to
> parse.
The decoding is pretty trivial given that line feeds are not part of the
ASCII85 character set and so can just be dropped. Besides The output is
already not 'pure' ASCII85 because the ASCII85 data is embedded within a
devcoredump. There is all sorts of other text about, including on the
start of the line. There are multiple ASCII85 blobs in there that need
to be decoded separately. This is nothing new to my patch set. All of
that is already there. And as per comments on the previous devcoredump
patches from Matthew B, the object data can many hundreds of MBs in
size. Yet no-one batted an eyelid when that was added. So why the sudden
paranoia about adding a couple of MB of GuC log in the same form?
And again, arbitrarily long lines (potentially many thousands of
characters wide) in a text file can cause problems. Having it line
wrapped gets rid of those potential problems and so is safer. Anything
that reduces the risk of an error report being broken is a good thing
IMHO. Robustness is worthwhile!
John.
>
> Lucas De Marchi
>
>>
>> John.
>>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 07/10] drm/xe/guc: Dead CT helper
2024-09-05 20:51 ` [PATCH v7 07/10] drm/xe/guc: Dead CT helper John.C.Harrison
@ 2024-09-11 0:09 ` John Harrison
2024-09-11 19:55 ` Julia Filipchuk
1 sibling, 0 replies; 54+ messages in thread
From: John Harrison @ 2024-09-11 0:09 UTC (permalink / raw)
To: Intel-Xe
On 9/5/2024 13:51, John.C.Harrison@Intel.com wrote:
> From: John Harrison <John.C.Harrison@Intel.com>
>
> Add a worker function helper for asynchronously dumping state when an
> internal/fatal error is detected in CT processing. Being asynchronous
> is required to avoid deadlocks and scheduling-while-atomic or
> process-stalled-for-too-long issues. Also check for a bunch more error
> conditions and improve the handling of some existing checks.
>
> v2: Use compile time CONFIG check for new (but not directly CT_DEAD
> related) checks and use unsigned int for a bitmask, rename
> CT_DEAD_RESET to CT_DEAD_REARM and add some explaining comments,
> rename 'hxg' macro parameter to 'ctb' - review feedback from Michal W.
> Drop CT_DEAD_ALIVE as no need for a bitfield define to just set the
> entire mask to zero.
> v3: Fix kerneldoc
> v4: Nullify some floating pointers after free.
> v5: Add section headings and device info to make the state dump look
> more like a devcoredump to allow parsing by the same tools (eventual
> aim is to just call the devcoredump code itself, but that currently
> requires an xe_sched_job, which is not available in the CT code).
>
> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> ---
> .../drm/xe/abi/guc_communication_ctb_abi.h | 1 +
> drivers/gpu/drm/xe/xe_guc.c | 2 +-
> drivers/gpu/drm/xe/xe_guc_ct.c | 280 ++++++++++++++++--
> drivers/gpu/drm/xe/xe_guc_ct.h | 2 +-
> drivers/gpu/drm/xe/xe_guc_ct_types.h | 23 ++
> 5 files changed, 280 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/abi/guc_communication_ctb_abi.h b/drivers/gpu/drm/xe/abi/guc_communication_ctb_abi.h
> index 8f86a16dc577..f58198cf2cf6 100644
> --- a/drivers/gpu/drm/xe/abi/guc_communication_ctb_abi.h
> +++ b/drivers/gpu/drm/xe/abi/guc_communication_ctb_abi.h
> @@ -52,6 +52,7 @@ struct guc_ct_buffer_desc {
> #define GUC_CTB_STATUS_OVERFLOW (1 << 0)
> #define GUC_CTB_STATUS_UNDERFLOW (1 << 1)
> #define GUC_CTB_STATUS_MISMATCH (1 << 2)
> +#define GUC_CTB_STATUS_DISABLED (1 << 3)
> u32 reserved[13];
> } __packed;
> static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
> diff --git a/drivers/gpu/drm/xe/xe_guc.c b/drivers/gpu/drm/xe/xe_guc.c
> index 34cdb08b6e27..3fef24c965c4 100644
> --- a/drivers/gpu/drm/xe/xe_guc.c
> +++ b/drivers/gpu/drm/xe/xe_guc.c
> @@ -1176,7 +1176,7 @@ void xe_guc_print_info(struct xe_guc *guc, struct drm_printer *p)
>
> xe_force_wake_put(gt_to_fw(gt), XE_FW_GT);
>
> - xe_guc_ct_print(&guc->ct, p, false);
> + xe_guc_ct_print(&guc->ct, p);
> xe_guc_submit_print(guc, p);
> }
>
> diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c
> index a63fe0a9077a..e31b1f0b855f 100644
> --- a/drivers/gpu/drm/xe/xe_guc_ct.c
> +++ b/drivers/gpu/drm/xe/xe_guc_ct.c
> @@ -25,12 +25,57 @@
> #include "xe_gt_sriov_pf_monitor.h"
> #include "xe_gt_tlb_invalidation.h"
> #include "xe_guc.h"
> +#include "xe_guc_log.h"
> #include "xe_guc_relay.h"
> #include "xe_guc_submit.h"
> #include "xe_map.h"
> #include "xe_pm.h"
> #include "xe_trace_guc.h"
>
> +#if IS_ENABLED(CONFIG_DRM_XE_DEBUG)
> +enum {
> + CT_DEAD_REARM, /* 0x0001 - not an error condition */
> + CT_DEAD_SETUP, /* 0x0002 */
> + CT_DEAD_H2G_WRITE, /* 0x0004 */
> + CT_DEAD_H2G_HAS_ROOM, /* 0x0008 */
> + CT_DEAD_G2H_READ, /* 0x0010 */
> + CT_DEAD_G2H_RECV, /* 0x0020 */
> + CT_DEAD_G2H_RELEASE, /* 0x0040 */
> + CT_DEAD_DEADLOCK, /* 0x0080 */
> + CT_DEAD_PROCESS_FAILED, /* 0x0100 */
> + CT_DEAD_FAST_G2H, /* 0x0200 */
> + CT_DEAD_PARSE_G2H_RESPONSE, /* 0x0400 */
> + CT_DEAD_PARSE_G2H_UNKNOWN, /* 0x0800 */
> + CT_DEAD_PARSE_G2H_ORIGIN, /* 0x1000 */
> + CT_DEAD_PARSE_G2H_TYPE, /* 0x2000 */
> +};
> +
> +static void ct_dead_worker_func(struct work_struct *w);
> +
> +#define CT_DEAD(ct, ctb, reason_code) \
> + do { \
> + struct guc_ctb *_ctb = (ctb); \
> + if (_ctb) \
> + _ctb->info.broken = true; \
> + if (!(ct)->dead.reported) { \
> + struct xe_guc *guc = ct_to_guc(ct); \
> + spin_lock_irq(&ct->dead.lock); \
This needs to be spin_lock_irqsave because CT_DEAD can be called inside
an ISR. Without the save/restore, it will explicitly enable interrupts
again and, as seen in the CI failure, that causes a WARNING:
irq 210 handler dg1_irq_handler+0x0/0x240 [xe] enabled interrupts
John.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 04/10] drm/xe/guc: Copy GuC log prior to dumping
2024-09-05 20:50 ` [PATCH v7 04/10] drm/xe/guc: Copy GuC log prior to dumping John.C.Harrison
@ 2024-09-11 0:48 ` Julia Filipchuk
0 siblings, 0 replies; 54+ messages in thread
From: Julia Filipchuk @ 2024-09-11 0:48 UTC (permalink / raw)
To: John.C.Harrison, Intel-Xe
Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 05/10] drm/xe/guc: Use a two stage dump for GuC logs and add more info
2024-09-05 20:51 ` [PATCH v7 05/10] drm/xe/guc: Use a two stage dump for GuC logs and add more info John.C.Harrison
@ 2024-09-11 0:48 ` Julia Filipchuk
2024-09-11 1:14 ` John Harrison
0 siblings, 1 reply; 54+ messages in thread
From: Julia Filipchuk @ 2024-09-11 0:48 UTC (permalink / raw)
To: John.C.Harrison, Intel-Xe
> +/**
> + * xe_guc_log_snapshot_capture - create a new snapshot copy the GuC log for later dumping
> * @log: GuC log structure
> - * @p: the printer object to output to
> + * @atomic: is the call inside an atomic section of some kind?
> + *
> + * Return: pointer to a newly allocated snapshot object or null if out of memory. Caller is
> + * responsible for calling xe_guc_log_snapshot_free when done with the snapshot.
> */
> -void xe_guc_log_print(struct xe_guc_log *log, struct drm_printer *p)
> +struct xe_guc_log_snapshot *xe_guc_log_snapshot_capture(struct xe_guc_log *log, bool atomic)
> {
> + struct xe_guc_log_snapshot *snapshot;
> struct xe_device *xe = log_to_xe(log);
> - size_t size;
> - void *copy;
> + struct xe_guc *guc = log_to_guc(log);
> + struct xe_gt *gt = log_to_gt(log);
> + size_t remain;
> + int i, err;
>
> if (!log->bo) {
> - drm_puts(p, "GuC log buffer not allocated");
> - return;
> + xe_gt_err(gt, "GuC log buffer not allocated\n");
> + return NULL;
> +> +
> + snapshot = xe_guc_log_snapshot_alloc(log, atomic);
> + if (!snapshot) {
> + xe_gt_err(gt, "GuC log snapshot not allocated\n");
> + return NULL;
> }
It seems err is not yet set in this context. So it would be a random
stack value leaked? Or are there macros setting err I am not aware of here?
> #define xe_gt_err(_gt, _fmt, ...) \
> xe_gt_printk((_gt), err, _fmt, ##__VA_ARGS__)
Suggest to zero the "int err;" allocation. Or set explicitly.
In general why is xe_gt_err used here over drm_puts? Is it a more
specific error handler in this context?
>
> - size = log->bo->size;
> + remain = snapshot->size;
> + for (i = 0; i < snapshot->num_chunks; i++) {
> + size_t size = min(GUC_LOG_CHUNK_SIZE, remain);
> +
> + xe_map_memcpy_from(xe, snapshot->copy[i], &log->bo->vmap,
> + i * GUC_LOG_CHUNK_SIZE, size);Suggest cast i to size_t. Is the "i * GUC_LOG_CHUNK_SIZE" implicit
conversion fine?
> + remain -= size;
> + }
> +
> + err = xe_force_wake_get(gt_to_fw(gt), XE_FW_GT);
> + if (err) {
> + snapshot->stamp = ~0;
Is this a convention for timestamps when failed?
> + drm_printf(p, "GuC firmware: %s\n", snapshot->path);
> + drm_printf(p, "GuC version %u.%u.%u (wanted %u.%u.%u)\n",
> + snapshot->ver_found.major, snapshot->ver_found.minor, snapshot->ver_found.patch,
> + snapshot->ver_want.major, snapshot->ver_want.minor, snapshot->ver_want.patch);
Missing colon for "GuC version" print format string.
Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 05/10] drm/xe/guc: Use a two stage dump for GuC logs and add more info
2024-09-11 0:48 ` Julia Filipchuk
@ 2024-09-11 1:14 ` John Harrison
0 siblings, 0 replies; 54+ messages in thread
From: John Harrison @ 2024-09-11 1:14 UTC (permalink / raw)
To: Julia Filipchuk, Intel-Xe
On 9/10/2024 17:48, Julia Filipchuk wrote:
>> +/**
>> + * xe_guc_log_snapshot_capture - create a new snapshot copy the GuC log for later dumping
>> * @log: GuC log structure
>> - * @p: the printer object to output to
>> + * @atomic: is the call inside an atomic section of some kind?
>> + *
>> + * Return: pointer to a newly allocated snapshot object or null if out of memory. Caller is
>> + * responsible for calling xe_guc_log_snapshot_free when done with the snapshot.
>> */
>> -void xe_guc_log_print(struct xe_guc_log *log, struct drm_printer *p)
>> +struct xe_guc_log_snapshot *xe_guc_log_snapshot_capture(struct xe_guc_log *log, bool atomic)
>> {
>> + struct xe_guc_log_snapshot *snapshot;
>> struct xe_device *xe = log_to_xe(log);
>> - size_t size;
>> - void *copy;
>> + struct xe_guc *guc = log_to_guc(log);
>> + struct xe_gt *gt = log_to_gt(log);
>> + size_t remain;
>> + int i, err;
>>
>> if (!log->bo) {
>> - drm_puts(p, "GuC log buffer not allocated");
>> - return;
>> + xe_gt_err(gt, "GuC log buffer not allocated\n");
>> + return NULL;
>> +> +
>> + snapshot = xe_guc_log_snapshot_alloc(log, atomic);
>> + if (!snapshot) {
>> + xe_gt_err(gt, "GuC log snapshot not allocated\n");
>> + return NULL;
>> }
> It seems err is not yet set in this context. So it would be a random
> stack value leaked? Or are there macros setting err I am not aware of here?
>> #define xe_gt_err(_gt, _fmt, ...) \
>> xe_gt_printk((_gt), err, _fmt, ##__VA_ARGS__)
> Suggest to zero the "int err;" allocation. Or set explicitly.
>
> In general why is xe_gt_err used here over drm_puts? Is it a more
> specific error handler in this context?
The 'err' inside the xe_gt_err macro is not a local variable from
outside the macro. It is used to generate the next function call down -
"drm_err". There is no drm_puts any more because this function is now
just an allocator, not a printer. So there is no print stream to call
drm_puts on.
>
>
>>
>> - size = log->bo->size;
>> + remain = snapshot->size;
>> + for (i = 0; i < snapshot->num_chunks; i++) {
>> + size_t size = min(GUC_LOG_CHUNK_SIZE, remain);
>> +
>> + xe_map_memcpy_from(xe, snapshot->copy[i], &log->bo->vmap,
>> + i * GUC_LOG_CHUNK_SIZE, size);Suggest cast i to size_t. Is the "i * GUC_LOG_CHUNK_SIZE" implicit
> conversion fine?
It would only be an issue if the GuC log buffer were over 2GB in size.
However, the log is limited to 16MB by the GuC interface spec. So there
is no possibility of 32bit overflow.
>
>> + remain -= size;
>> + }
>> +
>> + err = xe_force_wake_get(gt_to_fw(gt), XE_FW_GT);
>> + if (err) {
>> + snapshot->stamp = ~0;
> Is this a convention for timestamps when failed?
Not sure if there is a convention as such, but ~0 seems even less likely
to be valid than zero. And one has to pick something (or add in the
extra complication of a 'is_stamp_valid' flag).
>
>
>> + drm_printf(p, "GuC firmware: %s\n", snapshot->path);
>> + drm_printf(p, "GuC version %u.%u.%u (wanted %u.%u.%u)\n",
>> + snapshot->ver_found.major, snapshot->ver_found.minor, snapshot->ver_found.patch,
>> + snapshot->ver_want.major, snapshot->ver_want.minor, snapshot->ver_want.patch);
> Missing colon for "GuC version" print format string.
Yup.
>
>
> Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com>
Note that you shouldn't really give an r-b when you have so many
questions / changes requested.
John.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function
2024-09-10 19:33 ` Julia Filipchuk
@ 2024-09-11 1:27 ` John Harrison
0 siblings, 0 replies; 54+ messages in thread
From: John Harrison @ 2024-09-11 1:27 UTC (permalink / raw)
To: Julia Filipchuk, Intel-Xe
On 9/10/2024 12:33, Julia Filipchuk wrote:
>> + if (prefix) {
>> + strscpy(line_buff, prefix, DMESG_MAX_LINE_LEN - MIN_SPACE - 3);
>> + line_pos = strlen(line_buff);
>> +
>> + line_buff[line_pos++] = ':';
>> + line_buff[line_pos++] = ' ';
>> + }
> Since 2 characters are added to the end of prefix should the computation
> for n be "DMESG_MAX_LINE_LEN - MIN_SPACE - 2"? MIN_SPACE already
> accounts for space of trailing newline and null terminator.
Yeah, I think that is left over from when this was adding three extra
characters rather than just two.
>
> Also, prefix is only added to the first line. Is that the intended behavior?
Yes. The first line tells you what the dump is. Then you just have a
continuous dump with no interrupts other than the line breaks which can
be fed directly into a decoder.
>
>
>> + strscpy(line_buff + line_pos, ascii85_encode(val, buff),
>> + DMESG_MAX_LINE_LEN - line_pos);
>> + line_pos += strlen(line_buff + line_pos);
> Since space for ASCII85_BUFSZ bytes is guaranteed by checks against
> MIN_SPACE output of strscpy can be used to increment line_pos. Although
> I do like this safer style that would work even if the checks failed.
>
>> +#undef MIN_SPACE
> Suggest to also #undef DMESG_MAX_LINE_LEN here.
Yup.
John.
>
>
> Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com>
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function
2024-09-10 20:17 ` John Harrison
@ 2024-09-11 19:12 ` Lucas De Marchi
2024-09-11 19:30 ` Souza, Jose
2024-09-11 19:31 ` John Harrison
0 siblings, 2 replies; 54+ messages in thread
From: Lucas De Marchi @ 2024-09-11 19:12 UTC (permalink / raw)
To: John Harrison; +Cc: Intel-Xe, Matthew Brost, José Roberto de Souza
On Tue, Sep 10, 2024 at 01:17:11PM GMT, John Harrison wrote:
>On 9/10/2024 12:43, Lucas De Marchi wrote:
>>On Mon, Sep 09, 2024 at 06:31:41PM GMT, John Harrison wrote:
>>>On 9/6/2024 19:06, John Harrison wrote:
>>>>On 9/5/2024 20:04, Lucas De Marchi wrote:
>>>>>On Thu, Sep 05, 2024 at 07:01:33PM GMT, John Harrison wrote:
>>>>>>On 9/5/2024 18:54, Lucas De Marchi wrote:
>>>>>>>On Thu, Sep 05, 2024 at 01:50:58PM GMT,
>>>>>>>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.
>>>>>>>
>>>>>>>why are we not dumping the binary data directly to devcoredump?
>>>>>>As per earlier comments, there is a WiFi driver or some such
>>>>>>that does exactly that. But all they are dumping is a binary
>>>>>>blob.
>>>>>
>>>>>In your v5 I see you mentioned
>>>>>drivers/net/wireless/ath/ath10k/coredump.c, but that is a
>>>>>precedence for
>>>>>including it as is from the device rather converting it to ASCII85 or
>>>>>something else. It seems odd to do that type of conversion in kernel
>>>>>space when it could be perfectly done in userspace.
>>>>It really can't. An end user could maybe be expected to zip or
>>>>tar a coredump file before attaching it to a bug report but they
>>>>are certainly not going to try to ASCII85 encode random bits of
>>>>it. Whereas, putting that in the kernel means it is just there.
>>>>It is done. And it is pretty trivial - just call a helper
>>>>function and it does everything for you. Also, I very much doubt
>>>>you can spew raw binary data via dmesg. Even if the kernel would
>>>>print it for you (which I doubt), the user tools like syslogd
>>>>and dmesg itself are going to filter it to make it ASCII safe.
>>>>
>>>>The i915 error dumps have been ASCII85 encoded using the
>>>>kernel's ASCII85 encoding helper function since forever. This
>>>>patch is just a wrapper around the kernel's existing
>>>>implementation in order to make it more compatible with printing
>>>>to dmesg. This is not creating a new precedent. It already
>>>>exists.
>>>>
>>>>>
>>>>>$ git grep ascii85.h
>>>>>drivers/gpu/drm/i915/i915_gpu_error.c:#include <linux/ascii85.h>
>>>>>drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:#include <linux/ascii85.h>
>>>>>drivers/gpu/drm/msm/adreno/adreno_gpu.c:#include <linux/ascii85.h>
>>>>>drivers/gpu/drm/xe/xe_lrc.c:#include <linux/ascii85.h>
>>>>>drivers/gpu/drm/xe/xe_vm.c:#include <linux/ascii85.h>
>>>>And the list of drivers which dump raw binary data in a coredump
>>>>file is... ath10k. ASCII85 wins 3 to 1.
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>We want the devcoredump file to still be human readable.
>>>>>>That won't be the case if you stuff binary data in the
>>>>>>middle of it. Most obvious problem - the zeros in the data
>>>>>>will terminate your text file at that point. Potentially
>>>>>>bigger problem for end users - random fake ANSI codes will
>>>>>>destroy your terminal window if you try to cat the file to
>>>>>>read it.
>>>>>
>>>>>Users don't get a coredump and cat it to the terminal.
>>>>>=(lk%A8`T7AKYH#FD,6++EqOABHUhsG%5H2ARoq#E$/V$Bl7Q+@<5pmBe<q;Bk;0mCj@.3DIal2FD5Q-+E_RBART+X@VfTuGA2/4Dfp.E@3BN0DfB9.+E1b0F(KAV+:8
>>>>>
>>>>>
>>>>>
>>>>>Lucas De Marchi
>>>>They might. Either intentionally or accidentally. I've certainly
>>>>done it myself. And people will certainly want to look at it in
>>>>any random choice of text editor, pager, etc. 'cos you know, it
>>>>is meant to be read by humans. If it is full of binary data then
>>>>that becomes even more difficult than simply being full of ASCII
>>>>gibberish. No matter what you are doing, the ASCII version is
>>>>safer and easier to look at the rest of the file around it.
>>>>
>>>>I don't understand why you are so desperate to have raw binary
>>>>data in the middle of a text file. The disadvantages are
>>>>multiple but the only advantage is a slightly smaller file. And
>>>>the true route to smaller files is to add compression like we
>>>>have in i915.
>>>>
>>>>John.
>>>>
>>>PS: Also meant to add that one of the important uses cases for
>>>dumping logs to dmesg is for the really hard to repro bugs that
>>>show up in CI extremely rarely. We get the driver to dump an error
>>>capture to dmesg and pull that out from the CI logs. Even if you
>>>could get binary data through dmesg, pretty sure the CI tools
>>>would also not be happy with it. Anything non-printable will get
>>>munged for sure when turning it into a web page.
>>
>>I think that's the main source of confusion on what we are discussing.
>>I was not talking about dmesg at all. I'm only complaining about feeding
>>ascii85-encoded data into a *devcoredump* when apparently there isn't a
>>good reason to do so. I'd rather copy the binary data to the
>>devcoredump.
>But the intent is to dump a devcoredump to dmesg. It makes much sense
It seems like an awful idea to dump hundreds of MB to dmesg. When we
talked about printing to dmesg it was about **GuC log** and on very
initial states of driver probe where we didn't actually have a good
interface for that. And the log wouldn't be so big. If we can already
capture the devcoredump, what would be the reason to dump to dmesg
(other than the non-valid "our CI captures dmesg, and doesn't
capture devcoredump", which should be fixed).
If any sysadmin have their serial console flooded by such garbage there
are 2 reactions: 1) someone got in control of my machine; 2) something
went really bad with this machine. It's not "fear not, wait for it to
complete, it's just normal debug data I will attach to an issue in
gitlab". And I'm mentioning a serial console here due to that
cond_resched() added, which is only needed because you are trying to do
in kernel space what should be in userspace.
Oh well... looking at this the main reason to use ascii85 I can see is
because we already have parts of *our* devcoredump using it, and
userspace relying on that. That's new to me. Let's stop bringing dmesg
into this discussion.
>to have a single implementation that can be used for multiple
>purposes. Otherwise you are duplicating a lot of code unnecessarily.
>
>And I still think it is a *very* bad idea to be including binary data
>in a text file. The devcoredump is supposed to be human readable. It
no, it's not. devcoredump doesn't dictate the format, it's up to the
drivers to do that. See their documentation.
>is supposed to be obtained by end users and passed around. Having
>binary data in there just makes everything more complex and error
>prone. We want this to be as simple, easy and safe as possible.
>
>>
>>For dmesg, there's a reason to encode it as you pointed out... but
>>no users shouldn't actually see it - we should be getting all of those
>>cases in CI. For the escape scenarios, yeah... better having it
>>ascii85-encoded.
>>
>>What you are adding to devcoredump also doesn't even seem to be an
>>ascii85 representation, but a multiple lines that should be concatenated
>>to form the ascii85 representation. For dmesg it makes sense. Not for
>>devcoredump. We should also probabaly need a length field (correctly
>>accounting for the additional characters for each line) so we don't
>>have an implicit dependency on what's the next field to know how much to
>>parse.
>The decoding is pretty trivial given that line feeds are not part of
>the ASCII85 character set and so can just be dropped. Besides The
>output is already not 'pure' ASCII85 because the ASCII85 data is
>embedded within a devcoredump. There is all sorts of other text about,
>including on the start of the line. There are multiple ASCII85 blobs
>in there that need to be decoded separately. This is nothing new to my
>patch set. All of that is already there. And as per comments on the
>previous devcoredump patches from Matthew B, the object data can many
>hundreds of MBs in size. Yet no-one batted an eyelid when that was
>added. So why the sudden paranoia about adding a couple of MB of GuC
>log in the same form?
I suppose you are talking about commit 4d5242a003bb ("drm/xe: Implement capture of
HWSP and HWCTX"). Probably because I haven't seen that commit doing an
ascii85 encoding before, otherwise I'd have similar review feedback.
Looking at this just now, so I will also have to balance the previous
users and existing userspace consuming it.
+José, would it be ok from the userspace POV to start adding the \n?
Then we can at least have all fields in our devcoredump to follow the
same format. Are these the decoder parts on the mesa side?
src/intel/tools/aubinator_error_decode.c
src/intel/tools/error2hangdump.c?
From a quick look, read_xe_data_file() already continues the previous
topic when it reads a newline, but the parsers for HWCTX and HWSP
seems to expect to to have the entire topic in a single line. But I may
be missing something.
Lucas De Marchi
>
>And again, arbitrarily long lines (potentially many thousands of
>characters wide) in a text file can cause problems. Having it line
>wrapped gets rid of those potential problems and so is safer. Anything
>that reduces the risk of an error report being broken is a good thing
>IMHO. Robustness is worthwhile!
>
>John.
>
>>
>>Lucas De Marchi
>>
>>>
>>>John.
>>>
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function
2024-09-11 19:12 ` Lucas De Marchi
@ 2024-09-11 19:30 ` Souza, Jose
2024-09-11 19:35 ` John Harrison
2024-09-11 19:31 ` John Harrison
1 sibling, 1 reply; 54+ messages in thread
From: Souza, Jose @ 2024-09-11 19:30 UTC (permalink / raw)
To: Harrison, John C, De Marchi, Lucas
Cc: Intel-Xe@lists.freedesktop.org, Brost, Matthew
On Wed, 2024-09-11 at 14:12 -0500, Lucas De Marchi wrote:
> On Tue, Sep 10, 2024 at 01:17:11PM GMT, John Harrison wrote:
> > On 9/10/2024 12:43, Lucas De Marchi wrote:
> > > On Mon, Sep 09, 2024 at 06:31:41PM GMT, John Harrison wrote:
> > > > On 9/6/2024 19:06, John Harrison wrote:
> > > > > On 9/5/2024 20:04, Lucas De Marchi wrote:
> > > > > > On Thu, Sep 05, 2024 at 07:01:33PM GMT, John Harrison wrote:
> > > > > > > On 9/5/2024 18:54, Lucas De Marchi wrote:
> > > > > > > > On Thu, Sep 05, 2024 at 01:50:58PM GMT,
> > > > > > > > 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.
> > > > > > > >
> > > > > > > > why are we not dumping the binary data directly to devcoredump?
> > > > > > > As per earlier comments, there is a WiFi driver or some such
> > > > > > > that does exactly that. But all they are dumping is a binary
> > > > > > > blob.
> > > > > >
> > > > > > In your v5 I see you mentioned
> > > > > > drivers/net/wireless/ath/ath10k/coredump.c, but that is a
> > > > > > precedence for
> > > > > > including it as is from the device rather converting it to ASCII85 or
> > > > > > something else. It seems odd to do that type of conversion in kernel
> > > > > > space when it could be perfectly done in userspace.
> > > > > It really can't. An end user could maybe be expected to zip or
> > > > > tar a coredump file before attaching it to a bug report but they
> > > > > are certainly not going to try to ASCII85 encode random bits of
> > > > > it. Whereas, putting that in the kernel means it is just there.
> > > > > It is done. And it is pretty trivial - just call a helper
> > > > > function and it does everything for you. Also, I very much doubt
> > > > > you can spew raw binary data via dmesg. Even if the kernel would
> > > > > print it for you (which I doubt), the user tools like syslogd
> > > > > and dmesg itself are going to filter it to make it ASCII safe.
> > > > >
> > > > > The i915 error dumps have been ASCII85 encoded using the
> > > > > kernel's ASCII85 encoding helper function since forever. This
> > > > > patch is just a wrapper around the kernel's existing
> > > > > implementation in order to make it more compatible with printing
> > > > > to dmesg. This is not creating a new precedent. It already
> > > > > exists.
> > > > >
> > > > > >
> > > > > > $ git grep ascii85.h
> > > > > > drivers/gpu/drm/i915/i915_gpu_error.c:#include <linux/ascii85.h>
> > > > > > drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:#include <linux/ascii85.h>
> > > > > > drivers/gpu/drm/msm/adreno/adreno_gpu.c:#include <linux/ascii85.h>
> > > > > > drivers/gpu/drm/xe/xe_lrc.c:#include <linux/ascii85.h>
> > > > > > drivers/gpu/drm/xe/xe_vm.c:#include <linux/ascii85.h>
> > > > > And the list of drivers which dump raw binary data in a coredump
> > > > > file is... ath10k. ASCII85 wins 3 to 1.
> > > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > We want the devcoredump file to still be human readable.
> > > > > > > That won't be the case if you stuff binary data in the
> > > > > > > middle of it. Most obvious problem - the zeros in the data
> > > > > > > will terminate your text file at that point. Potentially
> > > > > > > bigger problem for end users - random fake ANSI codes will
> > > > > > > destroy your terminal window if you try to cat the file to
> > > > > > > read it.
> > > > > >
> > > > > > Users don't get a coredump and cat it to the terminal.
> > > > > > =(lk%A8`T7AKYH#FD,6++EqOABHUhsG%5H2ARoq#E$/V$Bl7Q+@<5pmBe<q;Bk;0mCj@.3DIal2FD5Q-+E_RBART+X@VfTuGA2/4Dfp.E@3BN0DfB9.+E1b0F(KAV+:8
> > > > > >
> > > > > >
> > > > > >
> > > > > > Lucas De Marchi
> > > > > They might. Either intentionally or accidentally. I've certainly
> > > > > done it myself. And people will certainly want to look at it in
> > > > > any random choice of text editor, pager, etc. 'cos you know, it
> > > > > is meant to be read by humans. If it is full of binary data then
> > > > > that becomes even more difficult than simply being full of ASCII
> > > > > gibberish. No matter what you are doing, the ASCII version is
> > > > > safer and easier to look at the rest of the file around it.
> > > > >
> > > > > I don't understand why you are so desperate to have raw binary
> > > > > data in the middle of a text file. The disadvantages are
> > > > > multiple but the only advantage is a slightly smaller file. And
> > > > > the true route to smaller files is to add compression like we
> > > > > have in i915.
> > > > >
> > > > > John.
> > > > >
> > > > PS: Also meant to add that one of the important uses cases for
> > > > dumping logs to dmesg is for the really hard to repro bugs that
> > > > show up in CI extremely rarely. We get the driver to dump an error
> > > > capture to dmesg and pull that out from the CI logs. Even if you
> > > > could get binary data through dmesg, pretty sure the CI tools
> > > > would also not be happy with it. Anything non-printable will get
> > > > munged for sure when turning it into a web page.
> > >
> > > I think that's the main source of confusion on what we are discussing.
> > > I was not talking about dmesg at all. I'm only complaining about feeding
> > > ascii85-encoded data into a *devcoredump* when apparently there isn't a
> > > good reason to do so. I'd rather copy the binary data to the
> > > devcoredump.
> > But the intent is to dump a devcoredump to dmesg. It makes much sense
>
> It seems like an awful idea to dump hundreds of MB to dmesg. When we
> talked about printing to dmesg it was about **GuC log** and on very
> initial states of driver probe where we didn't actually have a good
> interface for that. And the log wouldn't be so big. If we can already
> capture the devcoredump, what would be the reason to dump to dmesg
> (other than the non-valid "our CI captures dmesg, and doesn't
> capture devcoredump", which should be fixed).
>
> If any sysadmin have their serial console flooded by such garbage there
> are 2 reactions: 1) someone got in control of my machine; 2) something
> went really bad with this machine. It's not "fear not, wait for it to
> complete, it's just normal debug data I will attach to an issue in
> gitlab". And I'm mentioning a serial console here due to that
> cond_resched() added, which is only needed because you are trying to do
> in kernel space what should be in userspace.
>
> Oh well... looking at this the main reason to use ascii85 I can see is
> because we already have parts of *our* devcoredump using it, and
> userspace relying on that. That's new to me. Let's stop bringing dmesg
> into this discussion.
>
> > to have a single implementation that can be used for multiple
> > purposes. Otherwise you are duplicating a lot of code unnecessarily.
> >
> > And I still think it is a *very* bad idea to be including binary data
> > in a text file. The devcoredump is supposed to be human readable. It
>
> no, it's not. devcoredump doesn't dictate the format, it's up to the
> drivers to do that. See their documentation.
>
> > is supposed to be obtained by end users and passed around. Having
> > binary data in there just makes everything more complex and error
> > prone. We want this to be as simple, easy and safe as possible.
> >
> > >
> > > For dmesg, there's a reason to encode it as you pointed out... but
> > > no users shouldn't actually see it - we should be getting all of those
> > > cases in CI. For the escape scenarios, yeah... better having it
> > > ascii85-encoded.
> > >
> > > What you are adding to devcoredump also doesn't even seem to be an
> > > ascii85 representation, but a multiple lines that should be concatenated
> > > to form the ascii85 representation. For dmesg it makes sense. Not for
> > > devcoredump. We should also probabaly need a length field (correctly
> > > accounting for the additional characters for each line) so we don't
> > > have an implicit dependency on what's the next field to know how much to
> > > parse.
> > The decoding is pretty trivial given that line feeds are not part of
> > the ASCII85 character set and so can just be dropped. Besides The
> > output is already not 'pure' ASCII85 because the ASCII85 data is
> > embedded within a devcoredump. There is all sorts of other text about,
> > including on the start of the line. There are multiple ASCII85 blobs
> > in there that need to be decoded separately. This is nothing new to my
> > patch set. All of that is already there. And as per comments on the
> > previous devcoredump patches from Matthew B, the object data can many
> > hundreds of MBs in size. Yet no-one batted an eyelid when that was
> > added. So why the sudden paranoia about adding a couple of MB of GuC
> > log in the same form?
>
> I suppose you are talking about commit 4d5242a003bb ("drm/xe: Implement capture of
> HWSP and HWCTX"). Probably because I haven't seen that commit doing an
> ascii85 encoding before, otherwise I'd have similar review feedback.
>
> Looking at this just now, so I will also have to balance the previous
> users and existing userspace consuming it.
>
> +José, would it be ok from the userspace POV to start adding the \n?
> Then we can at least have all fields in our devcoredump to follow the
> same format. Are these the decoder parts on the mesa side?
>
> src/intel/tools/aubinator_error_decode.c
> src/intel/tools/error2hangdump.c?
>
> From a quick look, read_xe_data_file() already continues the previous
> topic when it reads a newline, but the parsers for HWCTX and HWSP
> seems to expect to to have the entire topic in a single line. But I may
> be missing something.
Sorry I'm not following up this thread.
Add a '\n' where exactly?
>
> Lucas De Marchi
>
> >
> > And again, arbitrarily long lines (potentially many thousands of
> > characters wide) in a text file can cause problems. Having it line
> > wrapped gets rid of those potential problems and so is safer. Anything
> > that reduces the risk of an error report being broken is a good thing
> > IMHO. Robustness is worthwhile!
> >
> > John.
> >
> > >
> > > Lucas De Marchi
> > >
> > > >
> > > > John.
> > > >
> >
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function
2024-09-11 19:12 ` Lucas De Marchi
2024-09-11 19:30 ` Souza, Jose
@ 2024-09-11 19:31 ` John Harrison
1 sibling, 0 replies; 54+ messages in thread
From: John Harrison @ 2024-09-11 19:31 UTC (permalink / raw)
To: Lucas De Marchi; +Cc: Intel-Xe, Matthew Brost, José Roberto de Souza
On 9/11/2024 12:12, Lucas De Marchi wrote:
> On Tue, Sep 10, 2024 at 01:17:11PM GMT, John Harrison wrote:
>> On 9/10/2024 12:43, Lucas De Marchi wrote:
>>> On Mon, Sep 09, 2024 at 06:31:41PM GMT, John Harrison wrote:
>>>> On 9/6/2024 19:06, John Harrison wrote:
>>>>> On 9/5/2024 20:04, Lucas De Marchi wrote:
>>>>>> On Thu, Sep 05, 2024 at 07:01:33PM GMT, John Harrison wrote:
>>>>>>> On 9/5/2024 18:54, Lucas De Marchi wrote:
>>>>>>>> On Thu, Sep 05, 2024 at 01:50:58PM GMT,
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> why are we not dumping the binary data directly to devcoredump?
>>>>>>> As per earlier comments, there is a WiFi driver or some such
>>>>>>> that does exactly that. But all they are dumping is a binary blob.
>>>>>>
>>>>>> In your v5 I see you mentioned
>>>>>> drivers/net/wireless/ath/ath10k/coredump.c, but that is a
>>>>>> precedence for
>>>>>> including it as is from the device rather converting it to
>>>>>> ASCII85 or
>>>>>> something else. It seems odd to do that type of conversion in kernel
>>>>>> space when it could be perfectly done in userspace.
>>>>> It really can't. An end user could maybe be expected to zip or tar
>>>>> a coredump file before attaching it to a bug report but they are
>>>>> certainly not going to try to ASCII85 encode random bits of it.
>>>>> Whereas, putting that in the kernel means it is just there. It is
>>>>> done. And it is pretty trivial - just call a helper function and
>>>>> it does everything for you. Also, I very much doubt you can spew
>>>>> raw binary data via dmesg. Even if the kernel would print it for
>>>>> you (which I doubt), the user tools like syslogd and dmesg itself
>>>>> are going to filter it to make it ASCII safe.
>>>>>
>>>>> The i915 error dumps have been ASCII85 encoded using the kernel's
>>>>> ASCII85 encoding helper function since forever. This patch is just
>>>>> a wrapper around the kernel's existing implementation in order to
>>>>> make it more compatible with printing to dmesg. This is not
>>>>> creating a new precedent. It already exists.
>>>>>
>>>>>>
>>>>>> $ git grep ascii85.h
>>>>>> drivers/gpu/drm/i915/i915_gpu_error.c:#include <linux/ascii85.h>
>>>>>> drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:#include
>>>>>> <linux/ascii85.h>
>>>>>> drivers/gpu/drm/msm/adreno/adreno_gpu.c:#include <linux/ascii85.h>
>>>>>> drivers/gpu/drm/xe/xe_lrc.c:#include <linux/ascii85.h>
>>>>>> drivers/gpu/drm/xe/xe_vm.c:#include <linux/ascii85.h>
>>>>> And the list of drivers which dump raw binary data in a coredump
>>>>> file is... ath10k. ASCII85 wins 3 to 1.
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> We want the devcoredump file to still be human readable. That
>>>>>>> won't be the case if you stuff binary data in the middle of it.
>>>>>>> Most obvious problem - the zeros in the data will terminate your
>>>>>>> text file at that point. Potentially bigger problem for end
>>>>>>> users - random fake ANSI codes will destroy your terminal window
>>>>>>> if you try to cat the file to read it.
>>>>>>
>>>>>> Users don't get a coredump and cat it to the terminal.
>>>>>> =(lk%A8`T7AKYH#FD,6++EqOABHUhsG%5H2ARoq#E$/V$Bl7Q+@<5pmBe<q;Bk;0mCj@.3DIal2FD5Q-+E_RBART+X@VfTuGA2/4Dfp.E@3BN0DfB9.+E1b0F(KAV+:8
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Lucas De Marchi
>>>>> They might. Either intentionally or accidentally. I've certainly
>>>>> done it myself. And people will certainly want to look at it in
>>>>> any random choice of text editor, pager, etc. 'cos you know, it is
>>>>> meant to be read by humans. If it is full of binary data then that
>>>>> becomes even more difficult than simply being full of ASCII
>>>>> gibberish. No matter what you are doing, the ASCII version is
>>>>> safer and easier to look at the rest of the file around it.
>>>>>
>>>>> I don't understand why you are so desperate to have raw binary
>>>>> data in the middle of a text file. The disadvantages are multiple
>>>>> but the only advantage is a slightly smaller file. And the true
>>>>> route to smaller files is to add compression like we have in i915.
>>>>>
>>>>> John.
>>>>>
>>>> PS: Also meant to add that one of the important uses cases for
>>>> dumping logs to dmesg is for the really hard to repro bugs that
>>>> show up in CI extremely rarely. We get the driver to dump an error
>>>> capture to dmesg and pull that out from the CI logs. Even if you
>>>> could get binary data through dmesg, pretty sure the CI tools would
>>>> also not be happy with it. Anything non-printable will get munged
>>>> for sure when turning it into a web page.
>>>
>>> I think that's the main source of confusion on what we are discussing.
>>> I was not talking about dmesg at all. I'm only complaining about
>>> feeding
>>> ascii85-encoded data into a *devcoredump* when apparently there isn't a
>>> good reason to do so. I'd rather copy the binary data to the
>>> devcoredump.
>> But the intent is to dump a devcoredump to dmesg. It makes much sense
>
> It seems like an awful idea to dump hundreds of MB to dmesg. When we
> talked about printing to dmesg it was about **GuC log** and on very
> initial states of driver probe where we didn't actually have a good
> interface for that. And the log wouldn't be so big. If we can already
> capture the devcoredump, what would be the reason to dump to dmesg
> (other than the non-valid "our CI captures dmesg, and doesn't
> capture devcoredump", which should be fixed).
>
> If any sysadmin have their serial console flooded by such garbage there
> are 2 reactions: 1) someone got in control of my machine; 2) something
> went really bad with this machine. It's not "fear not, wait for it to
> complete, it's just normal debug data I will attach to an issue in
> gitlab". And I'm mentioning a serial console here due to that
> cond_resched() added, which is only needed because you are trying to do
> in kernel space what should be in userspace.
>
> Oh well... looking at this the main reason to use ascii85 I can see is
> because we already have parts of *our* devcoredump using it, and
> userspace relying on that. That's new to me. Let's stop bringing dmesg
> into this discussion.
You are missing the point.
The construction of a devcoredump file is the best form of crash
analysis we have. There is no point trying to re-invent that with
partial versions that only include some of the information in random
different situations. No matter where the crash has happened or been
detected, a devcoredump file should be the correct way to debug it.
Conversely, that means making devcoredump as useful as possible by
adding in all the important things we might need to debug a problem.
In other words, we want everything in the devcoredump code path and we
want no other code paths that are duplicated sub-parts of devcoredump.
That is part 1.
As a follow up to that, there is the problem that not all hangs occur at
points where it is possible to get a devcoredump out via sysfs. Module
load time, kernel selftests, presi, etc. There are many valid reasons
why sysfs is not the best answer in all situations. For those
situations, dmesg is the simplest, most convenient and most reliable
option. Therefore, we want to be able to send a devcoredump capture to
dmesg.
That is part 2.
This patch set is addressing part 1 (add the GuC log and other useful
stuff to devcoredump) and is preparing the way for part 2 (there are
still problems with not have an xe scheduler job meaning you can't
actually create a devcoredump in the first place).
I absolutely do not expect to ever dump a devcoredump to dmesg when
sysfs is available. A sysadmin should never see a devcoredump being
spewed to dmesg whether large or small. However, there are many reasons
why developers and/or CI will need that facility. And it is infinitely
preferable to have that facility available in the driver ready to be
used than to have to carry a bucket load of patches in private branches.
>
>> to have a single implementation that can be used for multiple
>> purposes. Otherwise you are duplicating a lot of code unnecessarily.
>>
>> And I still think it is a *very* bad idea to be including binary data
>> in a text file. The devcoredump is supposed to be human readable. It
>
> no, it's not. devcoredump doesn't dictate the format, it's up to the
> drivers to do that. See their documentation.
But *our* devcoredump is supposed to readable by a human. We put lots of
things in there that developers want to quickly look at to get an idea
of what happened. So why would we want our driver to dictate a format
that mixes binary blobs with human readable text? That is the worst of
all worlds and a right pain for anyone trying to work with a devcoredump
file - developer or end user.
John.
>
>> is supposed to be obtained by end users and passed around. Having
>> binary data in there just makes everything more complex and error
>> prone. We want this to be as simple, easy and safe as possible.
>>
>>>
>>> For dmesg, there's a reason to encode it as you pointed out... but
>>> no users shouldn't actually see it - we should be getting all of those
>>> cases in CI. For the escape scenarios, yeah... better having it
>>> ascii85-encoded.
>>>
>>> What you are adding to devcoredump also doesn't even seem to be an
>>> ascii85 representation, but a multiple lines that should be
>>> concatenated
>>> to form the ascii85 representation. For dmesg it makes sense. Not for
>>> devcoredump. We should also probabaly need a length field (correctly
>>> accounting for the additional characters for each line) so we don't
>>> have an implicit dependency on what's the next field to know how
>>> much to
>>> parse.
>> The decoding is pretty trivial given that line feeds are not part of
>> the ASCII85 character set and so can just be dropped. Besides The
>> output is already not 'pure' ASCII85 because the ASCII85 data is
>> embedded within a devcoredump. There is all sorts of other text
>> about, including on the start of the line. There are multiple ASCII85
>> blobs in there that need to be decoded separately. This is nothing
>> new to my patch set. All of that is already there. And as per
>> comments on the previous devcoredump patches from Matthew B, the
>> object data can many hundreds of MBs in size. Yet no-one batted an
>> eyelid when that was added. So why the sudden paranoia about adding a
>> couple of MB of GuC log in the same form?
>
> I suppose you are talking about commit 4d5242a003bb ("drm/xe:
> Implement capture of
> HWSP and HWCTX"). Probably because I haven't seen that commit doing an
> ascii85 encoding before, otherwise I'd have similar review feedback.
>
> Looking at this just now, so I will also have to balance the previous
> users and existing userspace consuming it.
>
> +José, would it be ok from the userspace POV to start adding the \n?
> Then we can at least have all fields in our devcoredump to follow the
> same format. Are these the decoder parts on the mesa side?
>
> src/intel/tools/aubinator_error_decode.c
> src/intel/tools/error2hangdump.c?
>
> From a quick look, read_xe_data_file() already continues the previous
> topic when it reads a newline, but the parsers for HWCTX and HWSP
> seems to expect to to have the entire topic in a single line. But I may
> be missing something.
>
> Lucas De Marchi
>
>>
>> And again, arbitrarily long lines (potentially many thousands of
>> characters wide) in a text file can cause problems. Having it line
>> wrapped gets rid of those potential problems and so is safer.
>> Anything that reduces the risk of an error report being broken is a
>> good thing IMHO. Robustness is worthwhile!
>>
>> John.
>>
>>>
>>> Lucas De Marchi
>>>
>>>>
>>>> John.
>>>>
>>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function
2024-09-11 19:30 ` Souza, Jose
@ 2024-09-11 19:35 ` John Harrison
2024-09-11 19:54 ` Souza, Jose
0 siblings, 1 reply; 54+ messages in thread
From: John Harrison @ 2024-09-11 19:35 UTC (permalink / raw)
To: Souza, Jose, De Marchi, Lucas
Cc: Intel-Xe@lists.freedesktop.org, Brost, Matthew
On 9/11/2024 12:30, Souza, Jose wrote:
> On Wed, 2024-09-11 at 14:12 -0500, Lucas De Marchi wrote:
>> On Tue, Sep 10, 2024 at 01:17:11PM GMT, John Harrison wrote:
>>> On 9/10/2024 12:43, Lucas De Marchi wrote:
>>>> On Mon, Sep 09, 2024 at 06:31:41PM GMT, John Harrison wrote:
>>>>> On 9/6/2024 19:06, John Harrison wrote:
>>>>>> On 9/5/2024 20:04, Lucas De Marchi wrote:
>>>>>>> On Thu, Sep 05, 2024 at 07:01:33PM GMT, John Harrison wrote:
>>>>>>>> On 9/5/2024 18:54, Lucas De Marchi wrote:
>>>>>>>>> On Thu, Sep 05, 2024 at 01:50:58PM GMT,
>>>>>>>>> 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.
>>>>>>>>> why are we not dumping the binary data directly to devcoredump?
>>>>>>>> As per earlier comments, there is a WiFi driver or some such
>>>>>>>> that does exactly that. But all they are dumping is a binary
>>>>>>>> blob.
>>>>>>> In your v5 I see you mentioned
>>>>>>> drivers/net/wireless/ath/ath10k/coredump.c, but that is a
>>>>>>> precedence for
>>>>>>> including it as is from the device rather converting it to ASCII85 or
>>>>>>> something else. It seems odd to do that type of conversion in kernel
>>>>>>> space when it could be perfectly done in userspace.
>>>>>> It really can't. An end user could maybe be expected to zip or
>>>>>> tar a coredump file before attaching it to a bug report but they
>>>>>> are certainly not going to try to ASCII85 encode random bits of
>>>>>> it. Whereas, putting that in the kernel means it is just there.
>>>>>> It is done. And it is pretty trivial - just call a helper
>>>>>> function and it does everything for you. Also, I very much doubt
>>>>>> you can spew raw binary data via dmesg. Even if the kernel would
>>>>>> print it for you (which I doubt), the user tools like syslogd
>>>>>> and dmesg itself are going to filter it to make it ASCII safe.
>>>>>>
>>>>>> The i915 error dumps have been ASCII85 encoded using the
>>>>>> kernel's ASCII85 encoding helper function since forever. This
>>>>>> patch is just a wrapper around the kernel's existing
>>>>>> implementation in order to make it more compatible with printing
>>>>>> to dmesg. This is not creating a new precedent. It already
>>>>>> exists.
>>>>>>
>>>>>>> $ git grep ascii85.h
>>>>>>> drivers/gpu/drm/i915/i915_gpu_error.c:#include <linux/ascii85.h>
>>>>>>> drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:#include <linux/ascii85.h>
>>>>>>> drivers/gpu/drm/msm/adreno/adreno_gpu.c:#include <linux/ascii85.h>
>>>>>>> drivers/gpu/drm/xe/xe_lrc.c:#include <linux/ascii85.h>
>>>>>>> drivers/gpu/drm/xe/xe_vm.c:#include <linux/ascii85.h>
>>>>>> And the list of drivers which dump raw binary data in a coredump
>>>>>> file is... ath10k. ASCII85 wins 3 to 1.
>>>>>>
>>>>>>
>>>>>>>> We want the devcoredump file to still be human readable.
>>>>>>>> That won't be the case if you stuff binary data in the
>>>>>>>> middle of it. Most obvious problem - the zeros in the data
>>>>>>>> will terminate your text file at that point. Potentially
>>>>>>>> bigger problem for end users - random fake ANSI codes will
>>>>>>>> destroy your terminal window if you try to cat the file to
>>>>>>>> read it.
>>>>>>> Users don't get a coredump and cat it to the terminal.
>>>>>>> =(lk%A8`T7AKYH#FD,6++EqOABHUhsG%5H2ARoq#E$/V$Bl7Q+@<5pmBe<q;Bk;0mCj@.3DIal2FD5Q-+E_RBART+X@VfTuGA2/4Dfp.E@3BN0DfB9.+E1b0F(KAV+:8
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Lucas De Marchi
>>>>>> They might. Either intentionally or accidentally. I've certainly
>>>>>> done it myself. And people will certainly want to look at it in
>>>>>> any random choice of text editor, pager, etc. 'cos you know, it
>>>>>> is meant to be read by humans. If it is full of binary data then
>>>>>> that becomes even more difficult than simply being full of ASCII
>>>>>> gibberish. No matter what you are doing, the ASCII version is
>>>>>> safer and easier to look at the rest of the file around it.
>>>>>>
>>>>>> I don't understand why you are so desperate to have raw binary
>>>>>> data in the middle of a text file. The disadvantages are
>>>>>> multiple but the only advantage is a slightly smaller file. And
>>>>>> the true route to smaller files is to add compression like we
>>>>>> have in i915.
>>>>>>
>>>>>> John.
>>>>>>
>>>>> PS: Also meant to add that one of the important uses cases for
>>>>> dumping logs to dmesg is for the really hard to repro bugs that
>>>>> show up in CI extremely rarely. We get the driver to dump an error
>>>>> capture to dmesg and pull that out from the CI logs. Even if you
>>>>> could get binary data through dmesg, pretty sure the CI tools
>>>>> would also not be happy with it. Anything non-printable will get
>>>>> munged for sure when turning it into a web page.
>>>> I think that's the main source of confusion on what we are discussing.
>>>> I was not talking about dmesg at all. I'm only complaining about feeding
>>>> ascii85-encoded data into a *devcoredump* when apparently there isn't a
>>>> good reason to do so. I'd rather copy the binary data to the
>>>> devcoredump.
>>> But the intent is to dump a devcoredump to dmesg. It makes much sense
>> It seems like an awful idea to dump hundreds of MB to dmesg. When we
>> talked about printing to dmesg it was about **GuC log** and on very
>> initial states of driver probe where we didn't actually have a good
>> interface for that. And the log wouldn't be so big. If we can already
>> capture the devcoredump, what would be the reason to dump to dmesg
>> (other than the non-valid "our CI captures dmesg, and doesn't
>> capture devcoredump", which should be fixed).
>>
>> If any sysadmin have their serial console flooded by such garbage there
>> are 2 reactions: 1) someone got in control of my machine; 2) something
>> went really bad with this machine. It's not "fear not, wait for it to
>> complete, it's just normal debug data I will attach to an issue in
>> gitlab". And I'm mentioning a serial console here due to that
>> cond_resched() added, which is only needed because you are trying to do
>> in kernel space what should be in userspace.
>>
>> Oh well... looking at this the main reason to use ascii85 I can see is
>> because we already have parts of *our* devcoredump using it, and
>> userspace relying on that. That's new to me. Let's stop bringing dmesg
>> into this discussion.
>>
>>> to have a single implementation that can be used for multiple
>>> purposes. Otherwise you are duplicating a lot of code unnecessarily.
>>>
>>> And I still think it is a *very* bad idea to be including binary data
>>> in a text file. The devcoredump is supposed to be human readable. It
>> no, it's not. devcoredump doesn't dictate the format, it's up to the
>> drivers to do that. See their documentation.
>>
>>> is supposed to be obtained by end users and passed around. Having
>>> binary data in there just makes everything more complex and error
>>> prone. We want this to be as simple, easy and safe as possible.
>>>
>>>> For dmesg, there's a reason to encode it as you pointed out... but
>>>> no users shouldn't actually see it - we should be getting all of those
>>>> cases in CI. For the escape scenarios, yeah... better having it
>>>> ascii85-encoded.
>>>>
>>>> What you are adding to devcoredump also doesn't even seem to be an
>>>> ascii85 representation, but a multiple lines that should be concatenated
>>>> to form the ascii85 representation. For dmesg it makes sense. Not for
>>>> devcoredump. We should also probabaly need a length field (correctly
>>>> accounting for the additional characters for each line) so we don't
>>>> have an implicit dependency on what's the next field to know how much to
>>>> parse.
>>> The decoding is pretty trivial given that line feeds are not part of
>>> the ASCII85 character set and so can just be dropped. Besides The
>>> output is already not 'pure' ASCII85 because the ASCII85 data is
>>> embedded within a devcoredump. There is all sorts of other text about,
>>> including on the start of the line. There are multiple ASCII85 blobs
>>> in there that need to be decoded separately. This is nothing new to my
>>> patch set. All of that is already there. And as per comments on the
>>> previous devcoredump patches from Matthew B, the object data can many
>>> hundreds of MBs in size. Yet no-one batted an eyelid when that was
>>> added. So why the sudden paranoia about adding a couple of MB of GuC
>>> log in the same form?
>> I suppose you are talking about commit 4d5242a003bb ("drm/xe: Implement capture of
>> HWSP and HWCTX"). Probably because I haven't seen that commit doing an
>> ascii85 encoding before, otherwise I'd have similar review feedback.
>>
>> Looking at this just now, so I will also have to balance the previous
>> users and existing userspace consuming it.
>>
>> +José, would it be ok from the userspace POV to start adding the \n?
>> Then we can at least have all fields in our devcoredump to follow the
>> same format. Are these the decoder parts on the mesa side?
>>
>> src/intel/tools/aubinator_error_decode.c
>> src/intel/tools/error2hangdump.c?
>>
>> From a quick look, read_xe_data_file() already continues the previous
>> topic when it reads a newline, but the parsers for HWCTX and HWSP
>> seems to expect to to have the entire topic in a single line. But I may
>> be missing something.
> Sorry I'm not following up this thread.
> Add a '\n' where exactly?
To break very long ASCII85 streams across multiple lines. That will
allow the devcoredump file to output via dmesg for the situations where
reading from sysfs is not possible.
This patch is adding an ASCII85 encoding helper that is more friendly to
output via dmesg. The patch does not currently change the existing
ASCII85 encodings of VMs and hw contexts. However, the intention would
be to update that code to use this helper eventually.
John.
>
>> Lucas De Marchi
>>
>>> And again, arbitrarily long lines (potentially many thousands of
>>> characters wide) in a text file can cause problems. Having it line
>>> wrapped gets rid of those potential problems and so is safer. Anything
>>> that reduces the risk of an error report being broken is a good thing
>>> IMHO. Robustness is worthwhile!
>>>
>>> John.
>>>
>>>> Lucas De Marchi
>>>>
>>>>> John.
>>>>>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function
2024-09-11 19:35 ` John Harrison
@ 2024-09-11 19:54 ` Souza, Jose
2024-09-11 19:59 ` John Harrison
0 siblings, 1 reply; 54+ messages in thread
From: Souza, Jose @ 2024-09-11 19:54 UTC (permalink / raw)
To: Harrison, John C, De Marchi, Lucas
Cc: Intel-Xe@lists.freedesktop.org, Brost, Matthew
On Wed, 2024-09-11 at 12:35 -0700, John Harrison wrote:
> On 9/11/2024 12:30, Souza, Jose wrote:
> > On Wed, 2024-09-11 at 14:12 -0500, Lucas De Marchi wrote:
> > > On Tue, Sep 10, 2024 at 01:17:11PM GMT, John Harrison wrote:
> > > > On 9/10/2024 12:43, Lucas De Marchi wrote:
> > > > > On Mon, Sep 09, 2024 at 06:31:41PM GMT, John Harrison wrote:
> > > > > > On 9/6/2024 19:06, John Harrison wrote:
> > > > > > > On 9/5/2024 20:04, Lucas De Marchi wrote:
> > > > > > > > On Thu, Sep 05, 2024 at 07:01:33PM GMT, John Harrison wrote:
> > > > > > > > > On 9/5/2024 18:54, Lucas De Marchi wrote:
> > > > > > > > > > On Thu, Sep 05, 2024 at 01:50:58PM GMT,
> > > > > > > > > > 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.
> > > > > > > > > > why are we not dumping the binary data directly to devcoredump?
> > > > > > > > > As per earlier comments, there is a WiFi driver or some such
> > > > > > > > > that does exactly that. But all they are dumping is a binary
> > > > > > > > > blob.
> > > > > > > > In your v5 I see you mentioned
> > > > > > > > drivers/net/wireless/ath/ath10k/coredump.c, but that is a
> > > > > > > > precedence for
> > > > > > > > including it as is from the device rather converting it to ASCII85 or
> > > > > > > > something else. It seems odd to do that type of conversion in kernel
> > > > > > > > space when it could be perfectly done in userspace.
> > > > > > > It really can't. An end user could maybe be expected to zip or
> > > > > > > tar a coredump file before attaching it to a bug report but they
> > > > > > > are certainly not going to try to ASCII85 encode random bits of
> > > > > > > it. Whereas, putting that in the kernel means it is just there.
> > > > > > > It is done. And it is pretty trivial - just call a helper
> > > > > > > function and it does everything for you. Also, I very much doubt
> > > > > > > you can spew raw binary data via dmesg. Even if the kernel would
> > > > > > > print it for you (which I doubt), the user tools like syslogd
> > > > > > > and dmesg itself are going to filter it to make it ASCII safe.
> > > > > > >
> > > > > > > The i915 error dumps have been ASCII85 encoded using the
> > > > > > > kernel's ASCII85 encoding helper function since forever. This
> > > > > > > patch is just a wrapper around the kernel's existing
> > > > > > > implementation in order to make it more compatible with printing
> > > > > > > to dmesg. This is not creating a new precedent. It already
> > > > > > > exists.
> > > > > > >
> > > > > > > > $ git grep ascii85.h
> > > > > > > > drivers/gpu/drm/i915/i915_gpu_error.c:#include <linux/ascii85.h>
> > > > > > > > drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:#include <linux/ascii85.h>
> > > > > > > > drivers/gpu/drm/msm/adreno/adreno_gpu.c:#include <linux/ascii85.h>
> > > > > > > > drivers/gpu/drm/xe/xe_lrc.c:#include <linux/ascii85.h>
> > > > > > > > drivers/gpu/drm/xe/xe_vm.c:#include <linux/ascii85.h>
> > > > > > > And the list of drivers which dump raw binary data in a coredump
> > > > > > > file is... ath10k. ASCII85 wins 3 to 1.
> > > > > > >
> > > > > > >
> > > > > > > > > We want the devcoredump file to still be human readable.
> > > > > > > > > That won't be the case if you stuff binary data in the
> > > > > > > > > middle of it. Most obvious problem - the zeros in the data
> > > > > > > > > will terminate your text file at that point. Potentially
> > > > > > > > > bigger problem for end users - random fake ANSI codes will
> > > > > > > > > destroy your terminal window if you try to cat the file to
> > > > > > > > > read it.
> > > > > > > > Users don't get a coredump and cat it to the terminal.
> > > > > > > > =(lk%A8`T7AKYH#FD,6++EqOABHUhsG%5H2ARoq#E$/V$Bl7Q+@<5pmBe<q;Bk;0mCj@.3DIal2FD5Q-+E_RBART+X@VfTuGA2/4Dfp.E@3BN0DfB9.+E1b0F(KAV+:8
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Lucas De Marchi
> > > > > > > They might. Either intentionally or accidentally. I've certainly
> > > > > > > done it myself. And people will certainly want to look at it in
> > > > > > > any random choice of text editor, pager, etc. 'cos you know, it
> > > > > > > is meant to be read by humans. If it is full of binary data then
> > > > > > > that becomes even more difficult than simply being full of ASCII
> > > > > > > gibberish. No matter what you are doing, the ASCII version is
> > > > > > > safer and easier to look at the rest of the file around it.
> > > > > > >
> > > > > > > I don't understand why you are so desperate to have raw binary
> > > > > > > data in the middle of a text file. The disadvantages are
> > > > > > > multiple but the only advantage is a slightly smaller file. And
> > > > > > > the true route to smaller files is to add compression like we
> > > > > > > have in i915.
> > > > > > >
> > > > > > > John.
> > > > > > >
> > > > > > PS: Also meant to add that one of the important uses cases for
> > > > > > dumping logs to dmesg is for the really hard to repro bugs that
> > > > > > show up in CI extremely rarely. We get the driver to dump an error
> > > > > > capture to dmesg and pull that out from the CI logs. Even if you
> > > > > > could get binary data through dmesg, pretty sure the CI tools
> > > > > > would also not be happy with it. Anything non-printable will get
> > > > > > munged for sure when turning it into a web page.
> > > > > I think that's the main source of confusion on what we are discussing.
> > > > > I was not talking about dmesg at all. I'm only complaining about feeding
> > > > > ascii85-encoded data into a *devcoredump* when apparently there isn't a
> > > > > good reason to do so. I'd rather copy the binary data to the
> > > > > devcoredump.
> > > > But the intent is to dump a devcoredump to dmesg. It makes much sense
> > > It seems like an awful idea to dump hundreds of MB to dmesg. When we
> > > talked about printing to dmesg it was about **GuC log** and on very
> > > initial states of driver probe where we didn't actually have a good
> > > interface for that. And the log wouldn't be so big. If we can already
> > > capture the devcoredump, what would be the reason to dump to dmesg
> > > (other than the non-valid "our CI captures dmesg, and doesn't
> > > capture devcoredump", which should be fixed).
> > >
> > > If any sysadmin have their serial console flooded by such garbage there
> > > are 2 reactions: 1) someone got in control of my machine; 2) something
> > > went really bad with this machine. It's not "fear not, wait for it to
> > > complete, it's just normal debug data I will attach to an issue in
> > > gitlab". And I'm mentioning a serial console here due to that
> > > cond_resched() added, which is only needed because you are trying to do
> > > in kernel space what should be in userspace.
> > >
> > > Oh well... looking at this the main reason to use ascii85 I can see is
> > > because we already have parts of *our* devcoredump using it, and
> > > userspace relying on that. That's new to me. Let's stop bringing dmesg
> > > into this discussion.
> > >
> > > > to have a single implementation that can be used for multiple
> > > > purposes. Otherwise you are duplicating a lot of code unnecessarily.
> > > >
> > > > And I still think it is a *very* bad idea to be including binary data
> > > > in a text file. The devcoredump is supposed to be human readable. It
> > > no, it's not. devcoredump doesn't dictate the format, it's up to the
> > > drivers to do that. See their documentation.
> > >
> > > > is supposed to be obtained by end users and passed around. Having
> > > > binary data in there just makes everything more complex and error
> > > > prone. We want this to be as simple, easy and safe as possible.
> > > >
> > > > > For dmesg, there's a reason to encode it as you pointed out... but
> > > > > no users shouldn't actually see it - we should be getting all of those
> > > > > cases in CI. For the escape scenarios, yeah... better having it
> > > > > ascii85-encoded.
> > > > >
> > > > > What you are adding to devcoredump also doesn't even seem to be an
> > > > > ascii85 representation, but a multiple lines that should be concatenated
> > > > > to form the ascii85 representation. For dmesg it makes sense. Not for
> > > > > devcoredump. We should also probabaly need a length field (correctly
> > > > > accounting for the additional characters for each line) so we don't
> > > > > have an implicit dependency on what's the next field to know how much to
> > > > > parse.
> > > > The decoding is pretty trivial given that line feeds are not part of
> > > > the ASCII85 character set and so can just be dropped. Besides The
> > > > output is already not 'pure' ASCII85 because the ASCII85 data is
> > > > embedded within a devcoredump. There is all sorts of other text about,
> > > > including on the start of the line. There are multiple ASCII85 blobs
> > > > in there that need to be decoded separately. This is nothing new to my
> > > > patch set. All of that is already there. And as per comments on the
> > > > previous devcoredump patches from Matthew B, the object data can many
> > > > hundreds of MBs in size. Yet no-one batted an eyelid when that was
> > > > added. So why the sudden paranoia about adding a couple of MB of GuC
> > > > log in the same form?
> > > I suppose you are talking about commit 4d5242a003bb ("drm/xe: Implement capture of
> > > HWSP and HWCTX"). Probably because I haven't seen that commit doing an
> > > ascii85 encoding before, otherwise I'd have similar review feedback.
> > >
> > > Looking at this just now, so I will also have to balance the previous
> > > users and existing userspace consuming it.
> > >
> > > +José, would it be ok from the userspace POV to start adding the \n?
> > > Then we can at least have all fields in our devcoredump to follow the
> > > same format. Are these the decoder parts on the mesa side?
> > >
> > > src/intel/tools/aubinator_error_decode.c
> > > src/intel/tools/error2hangdump.c?
> > >
> > > From a quick look, read_xe_data_file() already continues the previous
> > > topic when it reads a newline, but the parsers for HWCTX and HWSP
> > > seems to expect to to have the entire topic in a single line. But I may
> > > be missing something.
> > Sorry I'm not following up this thread.
> > Add a '\n' where exactly?
> To break very long ASCII85 streams across multiple lines. That will
> allow the devcoredump file to output via dmesg for the situations where
> reading from sysfs is not possible.
>
> This patch is adding an ASCII85 encoding helper that is more friendly to
> output via dmesg. The patch does not currently change the existing
> ASCII85 encodings of VMs and hw contexts. However, the intention would
> be to update that code to use this helper eventually.
It will break the parser and I don't think we are allowed to break it at this point.
What I can suggest is add another sysfs with a coredump that skips the binary dumps so it is readable by humans.
>
> John.
>
> >
> > > Lucas De Marchi
> > >
> > > > And again, arbitrarily long lines (potentially many thousands of
> > > > characters wide) in a text file can cause problems. Having it line
> > > > wrapped gets rid of those potential problems and so is safer. Anything
> > > > that reduces the risk of an error report being broken is a good thing
> > > > IMHO. Robustness is worthwhile!
> > > >
> > > > John.
> > > >
> > > > > Lucas De Marchi
> > > > >
> > > > > > John.
> > > > > >
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 07/10] drm/xe/guc: Dead CT helper
2024-09-05 20:51 ` [PATCH v7 07/10] drm/xe/guc: Dead CT helper John.C.Harrison
2024-09-11 0:09 ` John Harrison
@ 2024-09-11 19:55 ` Julia Filipchuk
2024-09-11 20:13 ` John Harrison
1 sibling, 1 reply; 54+ messages in thread
From: Julia Filipchuk @ 2024-09-11 19:55 UTC (permalink / raw)
To: John.C.Harrison, Intel-Xe
On 9/5/2024 1:51 PM, John.C.Harrison@Intel.com wrote:
> From: John Harrison <John.C.Harrison@Intel.com>
>
> Add a worker function helper for asynchronously dumping state when an
> internal/fatal error is detected in CT processing. Being asynchronous
> is required to avoid deadlocks and scheduling-while-atomic or
> process-stalled-for-too-long issues. Also check for a bunch more error
> conditions and improve the handling of some existing checks.
>
> v2: Use compile time CONFIG check for new (but not directly CT_DEAD
> related) checks and use unsigned int for a bitmask, rename
> CT_DEAD_RESET to CT_DEAD_REARM and add some explaining comments,
> rename 'hxg' macro parameter to 'ctb' - review feedback from Michal W.
> Drop CT_DEAD_ALIVE as no need for a bitfield define to just set the
> entire mask to zero.
> v3: Fix kerneldoc
> v4: Nullify some floating pointers after free.
> v5: Add section headings and device info to make the state dump look
> more like a devcoredump to allow parsing by the same tools (eventual
> aim is to just call the devcoredump code itself, but that currently
> requires an xe_sched_job, which is not available in the CT code).
>
> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> ---
> .../drm/xe/abi/guc_communication_ctb_abi.h | 1 +
> drivers/gpu/drm/xe/xe_guc.c | 2 +-
> drivers/gpu/drm/xe/xe_guc_ct.c | 280 ++++++++++++++++--
> drivers/gpu/drm/xe/xe_guc_ct.h | 2 +-
> drivers/gpu/drm/xe/xe_guc_ct_types.h | 23 ++
> 5 files changed, 280 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/abi/guc_communication_ctb_abi.h b/drivers/gpu/drm/xe/abi/guc_communication_ctb_abi.h
> index 8f86a16dc577..f58198cf2cf6 100644
> --- a/drivers/gpu/drm/xe/abi/guc_communication_ctb_abi.h
> +++ b/drivers/gpu/drm/xe/abi/guc_communication_ctb_abi.h
> @@ -52,6 +52,7 @@ struct guc_ct_buffer_desc {
> #define GUC_CTB_STATUS_OVERFLOW (1 << 0)
> #define GUC_CTB_STATUS_UNDERFLOW (1 << 1)
> #define GUC_CTB_STATUS_MISMATCH (1 << 2)
> +#define GUC_CTB_STATUS_DISABLED (1 << 3)
> u32 reserved[13];
> } __packed;
> static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
> diff --git a/drivers/gpu/drm/xe/xe_guc.c b/drivers/gpu/drm/xe/xe_guc.c
> index 34cdb08b6e27..3fef24c965c4 100644
> --- a/drivers/gpu/drm/xe/xe_guc.c
> +++ b/drivers/gpu/drm/xe/xe_guc.c
> @@ -1176,7 +1176,7 @@ void xe_guc_print_info(struct xe_guc *guc, struct drm_printer *p)
>
> xe_force_wake_put(gt_to_fw(gt), XE_FW_GT);
>
> - xe_guc_ct_print(&guc->ct, p, false);
> + xe_guc_ct_print(&guc->ct, p);
> xe_guc_submit_print(guc, p);
> }
>
> diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c
> index a63fe0a9077a..e31b1f0b855f 100644
> --- a/drivers/gpu/drm/xe/xe_guc_ct.c
> +++ b/drivers/gpu/drm/xe/xe_guc_ct.c
> @@ -25,12 +25,57 @@
> #include "xe_gt_sriov_pf_monitor.h"
> #include "xe_gt_tlb_invalidation.h"
> #include "xe_guc.h"
> +#include "xe_guc_log.h"
> #include "xe_guc_relay.h"
> #include "xe_guc_submit.h"
> #include "xe_map.h"
> #include "xe_pm.h"
> #include "xe_trace_guc.h"
>
> +#if IS_ENABLED(CONFIG_DRM_XE_DEBUG)
> +enum {
> + CT_DEAD_REARM, /* 0x0001 - not an error condition */
> + CT_DEAD_SETUP, /* 0x0002 */
> + CT_DEAD_H2G_WRITE, /* 0x0004 */
> + CT_DEAD_H2G_HAS_ROOM, /* 0x0008 */
> + CT_DEAD_G2H_READ, /* 0x0010 */
> + CT_DEAD_G2H_RECV, /* 0x0020 */
> + CT_DEAD_G2H_RELEASE, /* 0x0040 */
> + CT_DEAD_DEADLOCK, /* 0x0080 */
> + CT_DEAD_PROCESS_FAILED, /* 0x0100 */
> + CT_DEAD_FAST_G2H, /* 0x0200 */
> + CT_DEAD_PARSE_G2H_RESPONSE, /* 0x0400 */
> + CT_DEAD_PARSE_G2H_UNKNOWN, /* 0x0800 */
> + CT_DEAD_PARSE_G2H_ORIGIN, /* 0x1000 */
> + CT_DEAD_PARSE_G2H_TYPE, /* 0x2000 */
> +};
> +
> +static void ct_dead_worker_func(struct work_struct *w);
> +
> +#define CT_DEAD(ct, ctb, reason_code) \
> + do { \
> + struct guc_ctb *_ctb = (ctb); \
> + if (_ctb) \
> + _ctb->info.broken = true; \
> + if (!(ct)->dead.reported) { \
Do we need to worry about a second dead ct causing conflict with quick
back-to-back CT_DEAD? Suggest to set reported here and to clear it only
from worker thread. Snapshot can be used instead of reported to
determine if it has been printed (in worker_func).
Should the snapshot be taken in the "CT_DEAD_REARM" case?
> + struct xe_guc *guc = ct_to_guc(ct); \
> + spin_lock_irq(&ct->dead.lock); \
> + (ct)->dead.reason |= 1 << CT_DEAD_##reason_code; \
Does this field need to be cleared or does this accumulate reasons CT died?
> + (ct)->dead.snapshot_log = xe_guc_log_snapshot_capture(&guc->log, true); \
> + (ct)->dead.snapshot_ct = xe_guc_ct_snapshot_capture((ct), true); \
> + spin_unlock_irq(&ct->dead.lock); \
> + queue_work(system_unbound_wq, &(ct)->dead.worker); \
> + } \
> + } while (0)
> +#else
> +#define CT_DEAD(ct, ctb, reason) \
> + do { \
> + struct guc_ctb *_ctb = (ctb); \
> + if (_ctb) \
> + _ctb->info.broken = true; \
> + } while (0)
> +#endif
> +
> /* Used when a CT send wants to block and / or receive data */
> struct g2h_fence {
> u32 *response_buffer;
> @@ -183,6 +228,10 @@ int xe_guc_ct_init(struct xe_guc_ct *ct)
> xa_init(&ct->fence_lookup);
> INIT_WORK(&ct->g2h_worker, g2h_worker_func);
> INIT_DELAYED_WORK(&ct->safe_mode_worker, safe_mode_worker_func);
> +#if IS_ENABLED(CONFIG_DRM_XE_DEBUG)
> + spin_lock_init(&ct->dead.lock);
> + INIT_WORK(&ct->dead.worker, ct_dead_worker_func);
> +#endif
> init_waitqueue_head(&ct->wq);
> init_waitqueue_head(&ct->g2h_fence_wq);
>
> @@ -419,10 +468,22 @@ int xe_guc_ct_enable(struct xe_guc_ct *ct)
> if (ct_needs_safe_mode(ct))
> ct_enter_safe_mode(ct);
>
> +#if IS_ENABLED(CONFIG_DRM_XE_DEBUG)
> + /*
> + * The CT has now been reset so the dumper can be re-armed
> + * after any existing dead state has been dumped.
> + */
> + spin_lock_irq(&ct->dead.lock);
> + if (ct->dead.reason)
> + ct->dead.reason |= CT_DEAD_REARM;
> + spin_unlock_irq(&ct->dead.lock);
> +#endif
> +
> return 0;
>
> err_out:
> xe_gt_err(gt, "Failed to enable GuC CT (%pe)\n", ERR_PTR(err));
> + CT_DEAD(ct, NULL, SETUP);
>
> return err;
> }
> @@ -773,8 +895,13 @@ static int guc_ct_send_locked(struct xe_guc_ct *ct, const u32 *action, u32 len,
> goto broken;
> #undef g2h_avail
>
> - if (dequeue_one_g2h(ct) < 0)
> + ret = dequeue_one_g2h(ct);
> + if (ret < 0) {
> + if (ret != -ECANCELED)
> + xe_gt_err(ct_to_gt(ct), "CTB receive failed (%pe)",
> + ERR_PTR(ret));
Is it correct there is no success condition here? Would canceled case
need to route to try_again?
> goto broken;
> + }
>
> goto try_again;
> }
> +
> +static void ct_dead_worker_func(struct work_struct *w)
> +{
> + struct xe_guc_ct *ct = container_of(w, struct xe_guc_ct, dead.worker);
> +
> + if (!ct->dead.reported) {
> + ct->dead.reported = true;> + ct_dead_print(&ct->dead);
> + }
Would this guard work against quick back-to-back CT_DEAD calls? This may
not happen? Suggest to move 'ct->dead.reported = true;' into the CT_DEAD
macro. Relates to CT_DEAD macro above.
Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function
2024-09-11 19:54 ` Souza, Jose
@ 2024-09-11 19:59 ` John Harrison
2024-09-12 13:57 ` Rodrigo Vivi
0 siblings, 1 reply; 54+ messages in thread
From: John Harrison @ 2024-09-11 19:59 UTC (permalink / raw)
To: Souza, Jose, De Marchi, Lucas
Cc: Intel-Xe@lists.freedesktop.org, Brost, Matthew
On 9/11/2024 12:54, Souza, Jose wrote:
> On Wed, 2024-09-11 at 12:35 -0700, John Harrison wrote:
>> On 9/11/2024 12:30, Souza, Jose wrote:
>>> On Wed, 2024-09-11 at 14:12 -0500, Lucas De Marchi wrote:
>>>> On Tue, Sep 10, 2024 at 01:17:11PM GMT, John Harrison wrote:
>>>>> On 9/10/2024 12:43, Lucas De Marchi wrote:
>>>>>> On Mon, Sep 09, 2024 at 06:31:41PM GMT, John Harrison wrote:
>>>>>>> On 9/6/2024 19:06, John Harrison wrote:
>>>>>>>> On 9/5/2024 20:04, Lucas De Marchi wrote:
>>>>>>>>> On Thu, Sep 05, 2024 at 07:01:33PM GMT, John Harrison wrote:
>>>>>>>>>> On 9/5/2024 18:54, Lucas De Marchi wrote:
>>>>>>>>>>> On Thu, Sep 05, 2024 at 01:50:58PM GMT,
>>>>>>>>>>> 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.
>>>>>>>>>>> why are we not dumping the binary data directly to devcoredump?
>>>>>>>>>> As per earlier comments, there is a WiFi driver or some such
>>>>>>>>>> that does exactly that. But all they are dumping is a binary
>>>>>>>>>> blob.
>>>>>>>>> In your v5 I see you mentioned
>>>>>>>>> drivers/net/wireless/ath/ath10k/coredump.c, but that is a
>>>>>>>>> precedence for
>>>>>>>>> including it as is from the device rather converting it to ASCII85 or
>>>>>>>>> something else. It seems odd to do that type of conversion in kernel
>>>>>>>>> space when it could be perfectly done in userspace.
>>>>>>>> It really can't. An end user could maybe be expected to zip or
>>>>>>>> tar a coredump file before attaching it to a bug report but they
>>>>>>>> are certainly not going to try to ASCII85 encode random bits of
>>>>>>>> it. Whereas, putting that in the kernel means it is just there.
>>>>>>>> It is done. And it is pretty trivial - just call a helper
>>>>>>>> function and it does everything for you. Also, I very much doubt
>>>>>>>> you can spew raw binary data via dmesg. Even if the kernel would
>>>>>>>> print it for you (which I doubt), the user tools like syslogd
>>>>>>>> and dmesg itself are going to filter it to make it ASCII safe.
>>>>>>>>
>>>>>>>> The i915 error dumps have been ASCII85 encoded using the
>>>>>>>> kernel's ASCII85 encoding helper function since forever. This
>>>>>>>> patch is just a wrapper around the kernel's existing
>>>>>>>> implementation in order to make it more compatible with printing
>>>>>>>> to dmesg. This is not creating a new precedent. It already
>>>>>>>> exists.
>>>>>>>>
>>>>>>>>> $ git grep ascii85.h
>>>>>>>>> drivers/gpu/drm/i915/i915_gpu_error.c:#include <linux/ascii85.h>
>>>>>>>>> drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:#include <linux/ascii85.h>
>>>>>>>>> drivers/gpu/drm/msm/adreno/adreno_gpu.c:#include <linux/ascii85.h>
>>>>>>>>> drivers/gpu/drm/xe/xe_lrc.c:#include <linux/ascii85.h>
>>>>>>>>> drivers/gpu/drm/xe/xe_vm.c:#include <linux/ascii85.h>
>>>>>>>> And the list of drivers which dump raw binary data in a coredump
>>>>>>>> file is... ath10k. ASCII85 wins 3 to 1.
>>>>>>>>
>>>>>>>>
>>>>>>>>>> We want the devcoredump file to still be human readable.
>>>>>>>>>> That won't be the case if you stuff binary data in the
>>>>>>>>>> middle of it. Most obvious problem - the zeros in the data
>>>>>>>>>> will terminate your text file at that point. Potentially
>>>>>>>>>> bigger problem for end users - random fake ANSI codes will
>>>>>>>>>> destroy your terminal window if you try to cat the file to
>>>>>>>>>> read it.
>>>>>>>>> Users don't get a coredump and cat it to the terminal.
>>>>>>>>> =(lk%A8`T7AKYH#FD,6++EqOABHUhsG%5H2ARoq#E$/V$Bl7Q+@<5pmBe<q;Bk;0mCj@.3DIal2FD5Q-+E_RBART+X@VfTuGA2/4Dfp.E@3BN0DfB9.+E1b0F(KAV+:8
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Lucas De Marchi
>>>>>>>> They might. Either intentionally or accidentally. I've certainly
>>>>>>>> done it myself. And people will certainly want to look at it in
>>>>>>>> any random choice of text editor, pager, etc. 'cos you know, it
>>>>>>>> is meant to be read by humans. If it is full of binary data then
>>>>>>>> that becomes even more difficult than simply being full of ASCII
>>>>>>>> gibberish. No matter what you are doing, the ASCII version is
>>>>>>>> safer and easier to look at the rest of the file around it.
>>>>>>>>
>>>>>>>> I don't understand why you are so desperate to have raw binary
>>>>>>>> data in the middle of a text file. The disadvantages are
>>>>>>>> multiple but the only advantage is a slightly smaller file. And
>>>>>>>> the true route to smaller files is to add compression like we
>>>>>>>> have in i915.
>>>>>>>>
>>>>>>>> John.
>>>>>>>>
>>>>>>> PS: Also meant to add that one of the important uses cases for
>>>>>>> dumping logs to dmesg is for the really hard to repro bugs that
>>>>>>> show up in CI extremely rarely. We get the driver to dump an error
>>>>>>> capture to dmesg and pull that out from the CI logs. Even if you
>>>>>>> could get binary data through dmesg, pretty sure the CI tools
>>>>>>> would also not be happy with it. Anything non-printable will get
>>>>>>> munged for sure when turning it into a web page.
>>>>>> I think that's the main source of confusion on what we are discussing.
>>>>>> I was not talking about dmesg at all. I'm only complaining about feeding
>>>>>> ascii85-encoded data into a *devcoredump* when apparently there isn't a
>>>>>> good reason to do so. I'd rather copy the binary data to the
>>>>>> devcoredump.
>>>>> But the intent is to dump a devcoredump to dmesg. It makes much sense
>>>> It seems like an awful idea to dump hundreds of MB to dmesg. When we
>>>> talked about printing to dmesg it was about **GuC log** and on very
>>>> initial states of driver probe where we didn't actually have a good
>>>> interface for that. And the log wouldn't be so big. If we can already
>>>> capture the devcoredump, what would be the reason to dump to dmesg
>>>> (other than the non-valid "our CI captures dmesg, and doesn't
>>>> capture devcoredump", which should be fixed).
>>>>
>>>> If any sysadmin have their serial console flooded by such garbage there
>>>> are 2 reactions: 1) someone got in control of my machine; 2) something
>>>> went really bad with this machine. It's not "fear not, wait for it to
>>>> complete, it's just normal debug data I will attach to an issue in
>>>> gitlab". And I'm mentioning a serial console here due to that
>>>> cond_resched() added, which is only needed because you are trying to do
>>>> in kernel space what should be in userspace.
>>>>
>>>> Oh well... looking at this the main reason to use ascii85 I can see is
>>>> because we already have parts of *our* devcoredump using it, and
>>>> userspace relying on that. That's new to me. Let's stop bringing dmesg
>>>> into this discussion.
>>>>
>>>>> to have a single implementation that can be used for multiple
>>>>> purposes. Otherwise you are duplicating a lot of code unnecessarily.
>>>>>
>>>>> And I still think it is a *very* bad idea to be including binary data
>>>>> in a text file. The devcoredump is supposed to be human readable. It
>>>> no, it's not. devcoredump doesn't dictate the format, it's up to the
>>>> drivers to do that. See their documentation.
>>>>
>>>>> is supposed to be obtained by end users and passed around. Having
>>>>> binary data in there just makes everything more complex and error
>>>>> prone. We want this to be as simple, easy and safe as possible.
>>>>>
>>>>>> For dmesg, there's a reason to encode it as you pointed out... but
>>>>>> no users shouldn't actually see it - we should be getting all of those
>>>>>> cases in CI. For the escape scenarios, yeah... better having it
>>>>>> ascii85-encoded.
>>>>>>
>>>>>> What you are adding to devcoredump also doesn't even seem to be an
>>>>>> ascii85 representation, but a multiple lines that should be concatenated
>>>>>> to form the ascii85 representation. For dmesg it makes sense. Not for
>>>>>> devcoredump. We should also probabaly need a length field (correctly
>>>>>> accounting for the additional characters for each line) so we don't
>>>>>> have an implicit dependency on what's the next field to know how much to
>>>>>> parse.
>>>>> The decoding is pretty trivial given that line feeds are not part of
>>>>> the ASCII85 character set and so can just be dropped. Besides The
>>>>> output is already not 'pure' ASCII85 because the ASCII85 data is
>>>>> embedded within a devcoredump. There is all sorts of other text about,
>>>>> including on the start of the line. There are multiple ASCII85 blobs
>>>>> in there that need to be decoded separately. This is nothing new to my
>>>>> patch set. All of that is already there. And as per comments on the
>>>>> previous devcoredump patches from Matthew B, the object data can many
>>>>> hundreds of MBs in size. Yet no-one batted an eyelid when that was
>>>>> added. So why the sudden paranoia about adding a couple of MB of GuC
>>>>> log in the same form?
>>>> I suppose you are talking about commit 4d5242a003bb ("drm/xe: Implement capture of
>>>> HWSP and HWCTX"). Probably because I haven't seen that commit doing an
>>>> ascii85 encoding before, otherwise I'd have similar review feedback.
>>>>
>>>> Looking at this just now, so I will also have to balance the previous
>>>> users and existing userspace consuming it.
>>>>
>>>> +José, would it be ok from the userspace POV to start adding the \n?
>>>> Then we can at least have all fields in our devcoredump to follow the
>>>> same format. Are these the decoder parts on the mesa side?
>>>>
>>>> src/intel/tools/aubinator_error_decode.c
>>>> src/intel/tools/error2hangdump.c?
>>>>
>>>> From a quick look, read_xe_data_file() already continues the previous
>>>> topic when it reads a newline, but the parsers for HWCTX and HWSP
>>>> seems to expect to to have the entire topic in a single line. But I may
>>>> be missing something.
>>> Sorry I'm not following up this thread.
>>> Add a '\n' where exactly?
>> To break very long ASCII85 streams across multiple lines. That will
>> allow the devcoredump file to output via dmesg for the situations where
>> reading from sysfs is not possible.
>>
>> This patch is adding an ASCII85 encoding helper that is more friendly to
>> output via dmesg. The patch does not currently change the existing
>> ASCII85 encodings of VMs and hw contexts. However, the intention would
>> be to update that code to use this helper eventually.
> It will break the parser and I don't think we are allowed to break it at this point.
The intent has always been to add compression as we had in i915. That
will presumably also break the parser. Although I'm not seeing how a
debug log parser counts as critical user space that must not ever be broken.
> What I can suggest is add another sysfs with a coredump that skips the binary dumps so it is readable by humans.
That will just lead to confusion and problems with people sending the
wrong file. This needs to be kept as simple and error-proof as possible.
John.
>
>> John.
>>
>>>> Lucas De Marchi
>>>>
>>>>> And again, arbitrarily long lines (potentially many thousands of
>>>>> characters wide) in a text file can cause problems. Having it line
>>>>> wrapped gets rid of those potential problems and so is safer. Anything
>>>>> that reduces the risk of an error report being broken is a good thing
>>>>> IMHO. Robustness is worthwhile!
>>>>>
>>>>> John.
>>>>>
>>>>>> Lucas De Marchi
>>>>>>
>>>>>>> John.
>>>>>>>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 08/10] drm/xe/guc: Dump entire CTB on errors
2024-09-05 20:51 ` [PATCH v7 08/10] drm/xe/guc: Dump entire CTB on errors John.C.Harrison
@ 2024-09-11 20:12 ` Julia Filipchuk
0 siblings, 0 replies; 54+ messages in thread
From: Julia Filipchuk @ 2024-09-11 20:12 UTC (permalink / raw)
To: John.C.Harrison, Intel-Xe
Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 07/10] drm/xe/guc: Dead CT helper
2024-09-11 19:55 ` Julia Filipchuk
@ 2024-09-11 20:13 ` John Harrison
2024-09-11 20:57 ` Julia Filipchuk
0 siblings, 1 reply; 54+ messages in thread
From: John Harrison @ 2024-09-11 20:13 UTC (permalink / raw)
To: Julia Filipchuk, Intel-Xe
On 9/11/2024 12:55, Julia Filipchuk wrote:
> On 9/5/2024 1:51 PM, John.C.Harrison@Intel.com wrote:
>> From: John Harrison <John.C.Harrison@Intel.com>
>>
>> Add a worker function helper for asynchronously dumping state when an
>> internal/fatal error is detected in CT processing. Being asynchronous
>> is required to avoid deadlocks and scheduling-while-atomic or
>> process-stalled-for-too-long issues. Also check for a bunch more error
>> conditions and improve the handling of some existing checks.
>>
>> v2: Use compile time CONFIG check for new (but not directly CT_DEAD
>> related) checks and use unsigned int for a bitmask, rename
>> CT_DEAD_RESET to CT_DEAD_REARM and add some explaining comments,
>> rename 'hxg' macro parameter to 'ctb' - review feedback from Michal W.
>> Drop CT_DEAD_ALIVE as no need for a bitfield define to just set the
>> entire mask to zero.
>> v3: Fix kerneldoc
>> v4: Nullify some floating pointers after free.
>> v5: Add section headings and device info to make the state dump look
>> more like a devcoredump to allow parsing by the same tools (eventual
>> aim is to just call the devcoredump code itself, but that currently
>> requires an xe_sched_job, which is not available in the CT code).
>>
>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>> ---
>> .../drm/xe/abi/guc_communication_ctb_abi.h | 1 +
>> drivers/gpu/drm/xe/xe_guc.c | 2 +-
>> drivers/gpu/drm/xe/xe_guc_ct.c | 280 ++++++++++++++++--
>> drivers/gpu/drm/xe/xe_guc_ct.h | 2 +-
>> drivers/gpu/drm/xe/xe_guc_ct_types.h | 23 ++
>> 5 files changed, 280 insertions(+), 28 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/xe/abi/guc_communication_ctb_abi.h b/drivers/gpu/drm/xe/abi/guc_communication_ctb_abi.h
>> index 8f86a16dc577..f58198cf2cf6 100644
>> --- a/drivers/gpu/drm/xe/abi/guc_communication_ctb_abi.h
>> +++ b/drivers/gpu/drm/xe/abi/guc_communication_ctb_abi.h
>> @@ -52,6 +52,7 @@ struct guc_ct_buffer_desc {
>> #define GUC_CTB_STATUS_OVERFLOW (1 << 0)
>> #define GUC_CTB_STATUS_UNDERFLOW (1 << 1)
>> #define GUC_CTB_STATUS_MISMATCH (1 << 2)
>> +#define GUC_CTB_STATUS_DISABLED (1 << 3)
>> u32 reserved[13];
>> } __packed;
>> static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
>> diff --git a/drivers/gpu/drm/xe/xe_guc.c b/drivers/gpu/drm/xe/xe_guc.c
>> index 34cdb08b6e27..3fef24c965c4 100644
>> --- a/drivers/gpu/drm/xe/xe_guc.c
>> +++ b/drivers/gpu/drm/xe/xe_guc.c
>> @@ -1176,7 +1176,7 @@ void xe_guc_print_info(struct xe_guc *guc, struct drm_printer *p)
>>
>> xe_force_wake_put(gt_to_fw(gt), XE_FW_GT);
>>
>> - xe_guc_ct_print(&guc->ct, p, false);
>> + xe_guc_ct_print(&guc->ct, p);
>> xe_guc_submit_print(guc, p);
>> }
>>
>> diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c
>> index a63fe0a9077a..e31b1f0b855f 100644
>> --- a/drivers/gpu/drm/xe/xe_guc_ct.c
>> +++ b/drivers/gpu/drm/xe/xe_guc_ct.c
>> @@ -25,12 +25,57 @@
>> #include "xe_gt_sriov_pf_monitor.h"
>> #include "xe_gt_tlb_invalidation.h"
>> #include "xe_guc.h"
>> +#include "xe_guc_log.h"
>> #include "xe_guc_relay.h"
>> #include "xe_guc_submit.h"
>> #include "xe_map.h"
>> #include "xe_pm.h"
>> #include "xe_trace_guc.h"
>>
>> +#if IS_ENABLED(CONFIG_DRM_XE_DEBUG)
>> +enum {
>> + CT_DEAD_REARM, /* 0x0001 - not an error condition */
>> + CT_DEAD_SETUP, /* 0x0002 */
>> + CT_DEAD_H2G_WRITE, /* 0x0004 */
>> + CT_DEAD_H2G_HAS_ROOM, /* 0x0008 */
>> + CT_DEAD_G2H_READ, /* 0x0010 */
>> + CT_DEAD_G2H_RECV, /* 0x0020 */
>> + CT_DEAD_G2H_RELEASE, /* 0x0040 */
>> + CT_DEAD_DEADLOCK, /* 0x0080 */
>> + CT_DEAD_PROCESS_FAILED, /* 0x0100 */
>> + CT_DEAD_FAST_G2H, /* 0x0200 */
>> + CT_DEAD_PARSE_G2H_RESPONSE, /* 0x0400 */
>> + CT_DEAD_PARSE_G2H_UNKNOWN, /* 0x0800 */
>> + CT_DEAD_PARSE_G2H_ORIGIN, /* 0x1000 */
>> + CT_DEAD_PARSE_G2H_TYPE, /* 0x2000 */
>> +};
>> +
>> +static void ct_dead_worker_func(struct work_struct *w);
>> +
>> +#define CT_DEAD(ct, ctb, reason_code) \
>> + do { \
>> + struct guc_ctb *_ctb = (ctb); \
>> + if (_ctb) \
>> + _ctb->info.broken = true; \
>> + if (!(ct)->dead.reported) { \
> Do we need to worry about a second dead ct causing conflict with quick
> back-to-back CT_DEAD? Suggest to set reported here and to clear it only
> from worker thread. Snapshot can be used instead of reported to
> determine if it has been printed (in worker_func).
No. We are only really interested in the intial cause of a problem.
Subsequent failures are likely to be caused by the first. So once a
report has been printed, we just ignore any further failures until a
reset has happened.
> Should the snapshot be taken in the "CT_DEAD_REARM" case?
No. That is the reset that turns the reporting system back on. I.e. it
re-arms the reporting trigger.
>> + struct xe_guc *guc = ct_to_guc(ct); \
>> + spin_lock_irq(&ct->dead.lock); \
>> + (ct)->dead.reason |= 1 << CT_DEAD_##reason_code; \
> Does this field need to be cleared or does this accumulate reasons CT died?
This is to accumulate in the case of multiple errors in rapid succession
(i.e. before it has managed to do the dump) to account for the
possibility that the errors might not be noticed in the order they
really happened. So it accumulates everything up to the first dump and
then goes quite.
>
>> + (ct)->dead.snapshot_log = xe_guc_log_snapshot_capture(&guc->log, true); \
>> + (ct)->dead.snapshot_ct = xe_guc_ct_snapshot_capture((ct), true); \
>> + spin_unlock_irq(&ct->dead.lock); \
>> + queue_work(system_unbound_wq, &(ct)->dead.worker); \
>> + } \
>> + } while (0)
>> +#else
>> +#define CT_DEAD(ct, ctb, reason) \
>> + do { \
>> + struct guc_ctb *_ctb = (ctb); \
>> + if (_ctb) \
>> + _ctb->info.broken = true; \
>> + } while (0)
>> +#endif
>> +
>> /* Used when a CT send wants to block and / or receive data */
>> struct g2h_fence {
>> u32 *response_buffer;
>> @@ -183,6 +228,10 @@ int xe_guc_ct_init(struct xe_guc_ct *ct)
>> xa_init(&ct->fence_lookup);
>> INIT_WORK(&ct->g2h_worker, g2h_worker_func);
>> INIT_DELAYED_WORK(&ct->safe_mode_worker, safe_mode_worker_func);
>> +#if IS_ENABLED(CONFIG_DRM_XE_DEBUG)
>> + spin_lock_init(&ct->dead.lock);
>> + INIT_WORK(&ct->dead.worker, ct_dead_worker_func);
>> +#endif
>> init_waitqueue_head(&ct->wq);
>> init_waitqueue_head(&ct->g2h_fence_wq);
>>
>> @@ -419,10 +468,22 @@ int xe_guc_ct_enable(struct xe_guc_ct *ct)
>> if (ct_needs_safe_mode(ct))
>> ct_enter_safe_mode(ct);
>>
>> +#if IS_ENABLED(CONFIG_DRM_XE_DEBUG)
>> + /*
>> + * The CT has now been reset so the dumper can be re-armed
>> + * after any existing dead state has been dumped.
>> + */
>> + spin_lock_irq(&ct->dead.lock);
>> + if (ct->dead.reason)
>> + ct->dead.reason |= CT_DEAD_REARM;
>> + spin_unlock_irq(&ct->dead.lock);
>> +#endif
>> +
>> return 0;
>>
>> err_out:
>> xe_gt_err(gt, "Failed to enable GuC CT (%pe)\n", ERR_PTR(err));
>> + CT_DEAD(ct, NULL, SETUP);
>>
>> return err;
>> }
>> @@ -773,8 +895,13 @@ static int guc_ct_send_locked(struct xe_guc_ct *ct, const u32 *action, u32 len,
>> goto broken;
>> #undef g2h_avail
>>
>> - if (dequeue_one_g2h(ct) < 0)
>> + ret = dequeue_one_g2h(ct);
>> + if (ret < 0) {
>> + if (ret != -ECANCELED)
>> + xe_gt_err(ct_to_gt(ct), "CTB receive failed (%pe)",
>> + ERR_PTR(ret));
> Is it correct there is no success condition here? Would canceled case
> need to route to try_again?
Not sure what you mean. This whole block is inside an EBUSY error path.
As part of the retry, it is trying to make space by clearing out G2H
entries. The ECANCELED error is because a reset or something known
happened, therefore there is no need to re-report it. If the dequeue was
successful then it continues with the retry by hitting the "goto try_again".
>> goto broken;
>> + }
>>
>> goto try_again;
>> }
>
>
>
>
>> +
>> +static void ct_dead_worker_func(struct work_struct *w)
>> +{
>> + struct xe_guc_ct *ct = container_of(w, struct xe_guc_ct, dead.worker);
>> +
>> + if (!ct->dead.reported) {
>> + ct->dead.reported = true;> + ct_dead_print(&ct->dead);
>> + }
> Would this guard work against quick back-to-back CT_DEAD calls? This may
> not happen? Suggest to move 'ct->dead.reported = true;' into the CT_DEAD
> macro. Relates to CT_DEAD macro above.
As above, there is no concern about wanting to do back to back dumps.
Once a dump has happened, there is no point printing anything further
until a GT reset has happened. At which point everything is re-enabled.
>
>
> Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com>
>
Again, you should not give an r-b when there are many concerns being
raised. An r-b says you approve of the code as it is and are happy for
it to be merged.
John.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 09/10] drm/xe/guc: Add GuC log to devcoredump captures
2024-09-05 20:51 ` [PATCH v7 09/10] drm/xe/guc: Add GuC log to devcoredump captures John.C.Harrison
@ 2024-09-11 20:25 ` Julia Filipchuk
0 siblings, 0 replies; 54+ messages in thread
From: Julia Filipchuk @ 2024-09-11 20:25 UTC (permalink / raw)
To: John.C.Harrison, Intel-Xe
LGTM
Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 10/10] drm/xe/guc: Add a helper function for dumping GuC log to dmesg
2024-09-05 20:51 ` [PATCH v7 10/10] drm/xe/guc: Add a helper function for dumping GuC log to dmesg John.C.Harrison
@ 2024-09-11 20:36 ` Julia Filipchuk
2024-09-11 20:41 ` John Harrison
0 siblings, 1 reply; 54+ messages in thread
From: Julia Filipchuk @ 2024-09-11 20:36 UTC (permalink / raw)
To: John.C.Harrison, Intel-Xe
> @@ -214,6 +214,24 @@ void xe_guc_log_snapshot_print(struct xe_guc_log_snapshot *snapshot, struct drm_
> }
> }
>
> +/**
> + * xe_guc_log_print_dmesg - dump a copy of the GuC log to dmesg
> + * @log: GuC log structure
> + */
> +void xe_guc_log_print_dmesg(struct xe_guc_log *log)
> +{
> + struct xe_gt *gt = log_to_gt(log);
> + static int g_count;
> + struct drm_printer ip = xe_gt_info_printer(gt);
> + struct drm_printer lp = drm_line_printer(&ip, "Capture", ++g_count);
Increment of non-assigned value "g_count". It is static so zero
allocated but suggest to assign to 0 for clarity.
Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 10/10] drm/xe/guc: Add a helper function for dumping GuC log to dmesg
2024-09-11 20:36 ` Julia Filipchuk
@ 2024-09-11 20:41 ` John Harrison
0 siblings, 0 replies; 54+ messages in thread
From: John Harrison @ 2024-09-11 20:41 UTC (permalink / raw)
To: Julia Filipchuk, Intel-Xe
[-- Attachment #1: Type: text/plain, Size: 863 bytes --]
On 9/11/2024 13:36, Julia Filipchuk wrote:
>> @@ -214,6 +214,24 @@ void xe_guc_log_snapshot_print(struct xe_guc_log_snapshot *snapshot, struct drm_
>> }
>> }
>>
>> +/**
>> + * xe_guc_log_print_dmesg - dump a copy of the GuC log to dmesg
>> + * @log: GuC log structure
>> + */
>> +void xe_guc_log_print_dmesg(struct xe_guc_log *log)
>> +{
>> + struct xe_gt *gt = log_to_gt(log);
>> + static int g_count;
>> + struct drm_printer ip = xe_gt_info_printer(gt);
>> + struct drm_printer lp = drm_line_printer(&ip, "Capture", ++g_count);
> Increment of non-assigned value "g_count". It is static so zero
> allocated but suggest to assign to 0 for clarity.
Assigning a static to zero will cause the checkpatch tool to complain
that you are unnecessarily providing a value that is the default.
John.
>
> Reviewed-by: Julia Filipchuk<julia.filipchuk@intel.com>
>
[-- Attachment #2: Type: text/html, Size: 1554 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 07/10] drm/xe/guc: Dead CT helper
2024-09-11 20:13 ` John Harrison
@ 2024-09-11 20:57 ` Julia Filipchuk
0 siblings, 0 replies; 54+ messages in thread
From: Julia Filipchuk @ 2024-09-11 20:57 UTC (permalink / raw)
To: John Harrison, Intel-Xe
On 9/11/2024 1:13 PM, John Harrison wrote:
> On 9/11/2024 12:55, Julia Filipchuk wrote:
>> On 9/5/2024 1:51 PM, John.C.Harrison@Intel.com wrote:
>>> From: John Harrison <John.C.Harrison@Intel.com>
>>>
>>> Add a worker function helper for asynchronously dumping state when an
>>> internal/fatal error is detected in CT processing. Being asynchronous
>>> is required to avoid deadlocks and scheduling-while-atomic or
>>> process-stalled-for-too-long issues. Also check for a bunch more error
>>> conditions and improve the handling of some existing checks.
>>>
>>> v2: Use compile time CONFIG check for new (but not directly CT_DEAD
>>> related) checks and use unsigned int for a bitmask, rename
>>> CT_DEAD_RESET to CT_DEAD_REARM and add some explaining comments,
>>> rename 'hxg' macro parameter to 'ctb' - review feedback from Michal W.
>>> Drop CT_DEAD_ALIVE as no need for a bitfield define to just set the
>>> entire mask to zero.
>>> v3: Fix kerneldoc
>>> v4: Nullify some floating pointers after free.
>>> v5: Add section headings and device info to make the state dump look
>>> more like a devcoredump to allow parsing by the same tools (eventual
>>> aim is to just call the devcoredump code itself, but that currently
>>> requires an xe_sched_job, which is not available in the CT code).
>>>
>>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>>> ---
>>> .../drm/xe/abi/guc_communication_ctb_abi.h | 1 +
>>> drivers/gpu/drm/xe/xe_guc.c | 2 +-
>>> drivers/gpu/drm/xe/xe_guc_ct.c | 280 ++++++++++++++++--
>>> drivers/gpu/drm/xe/xe_guc_ct.h | 2 +-
>>> drivers/gpu/drm/xe/xe_guc_ct_types.h | 23 ++
>>> 5 files changed, 280 insertions(+), 28 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/xe/abi/guc_communication_ctb_abi.h b/
>>> drivers/gpu/drm/xe/abi/guc_communication_ctb_abi.h
>>> index 8f86a16dc577..f58198cf2cf6 100644
>>> --- a/drivers/gpu/drm/xe/abi/guc_communication_ctb_abi.h
>>> +++ b/drivers/gpu/drm/xe/abi/guc_communication_ctb_abi.h
>>> @@ -52,6 +52,7 @@ struct guc_ct_buffer_desc {
>>> #define GUC_CTB_STATUS_OVERFLOW (1 << 0)
>>> #define GUC_CTB_STATUS_UNDERFLOW (1 << 1)
>>> #define GUC_CTB_STATUS_MISMATCH (1 << 2)
>>> +#define GUC_CTB_STATUS_DISABLED (1 << 3)
>>> u32 reserved[13];
>>> } __packed;
>>> static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
>>> diff --git a/drivers/gpu/drm/xe/xe_guc.c b/drivers/gpu/drm/xe/xe_guc.c
>>> index 34cdb08b6e27..3fef24c965c4 100644
>>> --- a/drivers/gpu/drm/xe/xe_guc.c
>>> +++ b/drivers/gpu/drm/xe/xe_guc.c
>>> @@ -1176,7 +1176,7 @@ void xe_guc_print_info(struct xe_guc *guc,
>>> struct drm_printer *p)
>>> xe_force_wake_put(gt_to_fw(gt), XE_FW_GT);
>>> - xe_guc_ct_print(&guc->ct, p, false);
>>> + xe_guc_ct_print(&guc->ct, p);
>>> xe_guc_submit_print(guc, p);
>>> }
>>> diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/
>>> xe_guc_ct.c
>>> index a63fe0a9077a..e31b1f0b855f 100644
>>> --- a/drivers/gpu/drm/xe/xe_guc_ct.c
>>> +++ b/drivers/gpu/drm/xe/xe_guc_ct.c
>>> @@ -25,12 +25,57 @@
>>> #include "xe_gt_sriov_pf_monitor.h"
>>> #include "xe_gt_tlb_invalidation.h"
>>> #include "xe_guc.h"
>>> +#include "xe_guc_log.h"
>>> #include "xe_guc_relay.h"
>>> #include "xe_guc_submit.h"
>>> #include "xe_map.h"
>>> #include "xe_pm.h"
>>> #include "xe_trace_guc.h"
>>> +#if IS_ENABLED(CONFIG_DRM_XE_DEBUG)
>>> +enum {
>>> + CT_DEAD_REARM, /* 0x0001 - not an error condition */
>>> + CT_DEAD_SETUP, /* 0x0002 */
>>> + CT_DEAD_H2G_WRITE, /* 0x0004 */
>>> + CT_DEAD_H2G_HAS_ROOM, /* 0x0008 */
>>> + CT_DEAD_G2H_READ, /* 0x0010 */
>>> + CT_DEAD_G2H_RECV, /* 0x0020 */
>>> + CT_DEAD_G2H_RELEASE, /* 0x0040 */
>>> + CT_DEAD_DEADLOCK, /* 0x0080 */
>>> + CT_DEAD_PROCESS_FAILED, /* 0x0100 */
>>> + CT_DEAD_FAST_G2H, /* 0x0200 */
>>> + CT_DEAD_PARSE_G2H_RESPONSE, /* 0x0400 */
>>> + CT_DEAD_PARSE_G2H_UNKNOWN, /* 0x0800 */
>>> + CT_DEAD_PARSE_G2H_ORIGIN, /* 0x1000 */
>>> + CT_DEAD_PARSE_G2H_TYPE, /* 0x2000 */
>>> +};
>>> +
>>> +static void ct_dead_worker_func(struct work_struct *w);
>>> +
>>> +#define CT_DEAD(ct, ctb, reason_code) \
>>> + do { \
>>> + struct guc_ctb *_ctb = (ctb); \
>>> + if (_ctb) \
>>> + _ctb->info.broken = true; \
>>> + if (!(ct)->dead.reported) { \
>> Do we need to worry about a second dead ct causing conflict with quick
>> back-to-back CT_DEAD? Suggest to set reported here and to clear it only
>> from worker thread. Snapshot can be used instead of reported to
>> determine if it has been printed (in worker_func).
> No. We are only really interested in the intial cause of a problem.
> Subsequent failures are likely to be caused by the first. So once a
> report has been printed, we just ignore any further failures until a
> reset has happened.
>
>> Should the snapshot be taken in the "CT_DEAD_REARM" case?
> No. That is the reset that turns the reporting system back on. I.e. it
> re-arms the reporting trigger.
>>> + struct xe_guc *guc = ct_to_guc(ct); \
>>> + spin_lock_irq(&ct->dead.lock); \
>>> + (ct)->dead.reason |= 1 <<
>>> CT_DEAD_##reason_code; \
>> Does this field need to be cleared or does this accumulate reasons CT
>> died?
> This is to accumulate in the case of multiple errors in rapid succession
> (i.e. before it has managed to do the dump) to account for the
> possibility that the errors might not be noticed in the order they
> really happened. So it accumulates everything up to the first dump and
> then goes quite.
In this case of multiple errors accumulated before being printed the
first time (and dead.reported set true) the snapshots would leak when
overwritten. This seems like an issue.
>
>>
>>> + (ct)->dead.snapshot_log =
>>> xe_guc_log_snapshot_capture(&guc->log, true); \
>>> + (ct)->dead.snapshot_ct =
>>> xe_guc_ct_snapshot_capture((ct), true); \
>>> + spin_unlock_irq(&ct->dead.lock); \
>>> + queue_work(system_unbound_wq, &(ct)-
>>> >dead.worker); \
>>> + } \
>>> + } while (0)
>>> +#else
>>> +#define CT_DEAD(ct, ctb, reason) \
>>> + do { \
>>> + struct guc_ctb *_ctb = (ctb); \
>>> + if (_ctb) \
>>> + _ctb->info.broken = true; \
>>> + } while (0)
>>> +#endif
>>> +
>>> /* Used when a CT send wants to block and / or receive data */
>>> struct g2h_fence {
>>> u32 *response_buffer;
>>> @@ -183,6 +228,10 @@ int xe_guc_ct_init(struct xe_guc_ct *ct)
>>> xa_init(&ct->fence_lookup);
>>> INIT_WORK(&ct->g2h_worker, g2h_worker_func);
>>> INIT_DELAYED_WORK(&ct->safe_mode_worker, safe_mode_worker_func);
>>> +#if IS_ENABLED(CONFIG_DRM_XE_DEBUG)
>>> + spin_lock_init(&ct->dead.lock);
>>> + INIT_WORK(&ct->dead.worker, ct_dead_worker_func);
>>> +#endif
>>> init_waitqueue_head(&ct->wq);
>>> init_waitqueue_head(&ct->g2h_fence_wq);
>>> @@ -419,10 +468,22 @@ int xe_guc_ct_enable(struct xe_guc_ct *ct)
>>> if (ct_needs_safe_mode(ct))
>>> ct_enter_safe_mode(ct);
>>> +#if IS_ENABLED(CONFIG_DRM_XE_DEBUG)
>>> + /*
>>> + * The CT has now been reset so the dumper can be re-armed
>>> + * after any existing dead state has been dumped.
>>> + */
>>> + spin_lock_irq(&ct->dead.lock);
>>> + if (ct->dead.reason)
>>> + ct->dead.reason |= CT_DEAD_REARM;
>>> + spin_unlock_irq(&ct->dead.lock);
>>> +#endif
>>> +
>>> return 0;
>>> err_out:
>>> xe_gt_err(gt, "Failed to enable GuC CT (%pe)\n", ERR_PTR(err));
>>> + CT_DEAD(ct, NULL, SETUP);
>>> return err;
>>> }
>>> @@ -773,8 +895,13 @@ static int guc_ct_send_locked(struct xe_guc_ct
>>> *ct, const u32 *action, u32 len,
>>> goto broken;
>>> #undef g2h_avail
>>> - if (dequeue_one_g2h(ct) < 0)
>>> + ret = dequeue_one_g2h(ct);
>>> + if (ret < 0) {
>>> + if (ret != -ECANCELED)
>>> + xe_gt_err(ct_to_gt(ct), "CTB receive failed (%pe)",
>>> + ERR_PTR(ret));
>> Is it correct there is no success condition here? Would canceled case
>> need to route to try_again?
> Not sure what you mean. This whole block is inside an EBUSY error path.
> As part of the retry, it is trying to make space by clearing out G2H
> entries. The ECANCELED error is because a reset or something known
> happened, therefore there is no need to re-report it. If the dequeue was
> successful then it continues with the retry by hitting the "goto
> try_again".
Makes sense.
>
>>> goto broken;
>>> + }
>>> goto try_again;
>>> }
>>
>>
>>
>>
>>> +
>>> +static void ct_dead_worker_func(struct work_struct *w)
>>> +{
>>> + struct xe_guc_ct *ct = container_of(w, struct xe_guc_ct,
>>> dead.worker);
>>> +
>>> + if (!ct->dead.reported) {
>>> + ct->dead.reported = true;> + ct_dead_print(&ct->dead);
>>> + }
>> Would this guard work against quick back-to-back CT_DEAD calls? This may
>> not happen? Suggest to move 'ct->dead.reported = true;' into the CT_DEAD
>> macro. Relates to CT_DEAD macro above.
> As above, there is no concern about wanting to do back to back dumps.
> Once a dump has happened, there is no point printing anything further
> until a GT reset has happened. At which point everything is re-enabled.
>
>>
>>
>> Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com>
>>
> Again, you should not give an r-b when there are many concerns being
> raised. An r-b says you approve of the code as it is and are happy for
> it to be merged.
>
> John.
>
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump
2024-09-05 20:50 [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump John.C.Harrison
` (17 preceding siblings ...)
2024-09-08 0:02 ` ✗ CI.FULL: " Patchwork
@ 2024-09-12 9:16 ` Jani Nikula
2024-09-12 18:50 ` John Harrison
18 siblings, 1 reply; 54+ messages in thread
From: Jani Nikula @ 2024-09-12 9:16 UTC (permalink / raw)
To: John.C.Harrison, Intel-Xe; +Cc: John Harrison
On Thu, 05 Sep 2024, John.C.Harrison@Intel.com wrote:
> Michal Wajdeczko (1):
> drm/print: Introduce drm_line_printer
Given the discussion around other parts, it might be prudent to just
upstream this separately via drm-misc.
BR,
Jani.
--
Jani Nikula, Intel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function
2024-09-11 19:59 ` John Harrison
@ 2024-09-12 13:57 ` Rodrigo Vivi
2024-09-12 18:06 ` John Harrison
0 siblings, 1 reply; 54+ messages in thread
From: Rodrigo Vivi @ 2024-09-12 13:57 UTC (permalink / raw)
To: John Harrison
Cc: Souza, Jose, De Marchi, Lucas, Intel-Xe@lists.freedesktop.org,
Brost, Matthew
On Wed, Sep 11, 2024 at 12:59:54PM -0700, John Harrison wrote:
> On 9/11/2024 12:54, Souza, Jose wrote:
> > On Wed, 2024-09-11 at 12:35 -0700, John Harrison wrote:
> > > On 9/11/2024 12:30, Souza, Jose wrote:
> > > > On Wed, 2024-09-11 at 14:12 -0500, Lucas De Marchi wrote:
> > > > > On Tue, Sep 10, 2024 at 01:17:11PM GMT, John Harrison wrote:
> > > > > > On 9/10/2024 12:43, Lucas De Marchi wrote:
> > > > > > > On Mon, Sep 09, 2024 at 06:31:41PM GMT, John Harrison wrote:
> > > > > > > > On 9/6/2024 19:06, John Harrison wrote:
> > > > > > > > > On 9/5/2024 20:04, Lucas De Marchi wrote:
> > > > > > > > > > On Thu, Sep 05, 2024 at 07:01:33PM GMT, John Harrison wrote:
> > > > > > > > > > > On 9/5/2024 18:54, Lucas De Marchi wrote:
> > > > > > > > > > > > On Thu, Sep 05, 2024 at 01:50:58PM GMT,
> > > > > > > > > > > > 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.
> > > > > > > > > > > > why are we not dumping the binary data directly to devcoredump?
> > > > > > > > > > > As per earlier comments, there is a WiFi driver or some such
> > > > > > > > > > > that does exactly that. But all they are dumping is a binary
> > > > > > > > > > > blob.
> > > > > > > > > > In your v5 I see you mentioned
> > > > > > > > > > drivers/net/wireless/ath/ath10k/coredump.c, but that is a
> > > > > > > > > > precedence for
> > > > > > > > > > including it as is from the device rather converting it to ASCII85 or
> > > > > > > > > > something else. It seems odd to do that type of conversion in kernel
> > > > > > > > > > space when it could be perfectly done in userspace.
> > > > > > > > > It really can't. An end user could maybe be expected to zip or
> > > > > > > > > tar a coredump file before attaching it to a bug report but they
> > > > > > > > > are certainly not going to try to ASCII85 encode random bits of
> > > > > > > > > it. Whereas, putting that in the kernel means it is just there.
> > > > > > > > > It is done. And it is pretty trivial - just call a helper
> > > > > > > > > function and it does everything for you. Also, I very much doubt
> > > > > > > > > you can spew raw binary data via dmesg. Even if the kernel would
> > > > > > > > > print it for you (which I doubt), the user tools like syslogd
> > > > > > > > > and dmesg itself are going to filter it to make it ASCII safe.
> > > > > > > > >
> > > > > > > > > The i915 error dumps have been ASCII85 encoded using the
> > > > > > > > > kernel's ASCII85 encoding helper function since forever. This
> > > > > > > > > patch is just a wrapper around the kernel's existing
> > > > > > > > > implementation in order to make it more compatible with printing
> > > > > > > > > to dmesg. This is not creating a new precedent. It already
> > > > > > > > > exists.
No! no big dump in dmesg.
> > > > > > > > >
> > > > > > > > > > $ git grep ascii85.h
> > > > > > > > > > drivers/gpu/drm/i915/i915_gpu_error.c:#include <linux/ascii85.h>
> > > > > > > > > > drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:#include <linux/ascii85.h>
> > > > > > > > > > drivers/gpu/drm/msm/adreno/adreno_gpu.c:#include <linux/ascii85.h>
> > > > > > > > > > drivers/gpu/drm/xe/xe_lrc.c:#include <linux/ascii85.h>
> > > > > > > > > > drivers/gpu/drm/xe/xe_vm.c:#include <linux/ascii85.h>
> > > > > > > > > And the list of drivers which dump raw binary data in a coredump
> > > > > > > > > file is... ath10k. ASCII85 wins 3 to 1.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > > We want the devcoredump file to still be human readable.
> > > > > > > > > > > That won't be the case if you stuff binary data in the
> > > > > > > > > > > middle of it. Most obvious problem - the zeros in the data
> > > > > > > > > > > will terminate your text file at that point. Potentially
> > > > > > > > > > > bigger problem for end users - random fake ANSI codes will
> > > > > > > > > > > destroy your terminal window if you try to cat the file to
> > > > > > > > > > > read it.
> > > > > > > > > > Users don't get a coredump and cat it to the terminal.
> > > > > > > > > > =(lk%A8`T7AKYH#FD,6++EqOABHUhsG%5H2ARoq#E$/V$Bl7Q+@<5pmBe<q;Bk;0mCj@.3DIal2FD5Q-+E_RBART+X@VfTuGA2/4Dfp.E@3BN0DfB9.+E1b0F(KAV+:8
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Lucas De Marchi
> > > > > > > > > They might. Either intentionally or accidentally. I've certainly
> > > > > > > > > done it myself. And people will certainly want to look at it in
> > > > > > > > > any random choice of text editor, pager, etc. 'cos you know, it
> > > > > > > > > is meant to be read by humans. If it is full of binary data then
> > > > > > > > > that becomes even more difficult than simply being full of ASCII
> > > > > > > > > gibberish. No matter what you are doing, the ASCII version is
> > > > > > > > > safer and easier to look at the rest of the file around it.
> > > > > > > > >
> > > > > > > > > I don't understand why you are so desperate to have raw binary
> > > > > > > > > data in the middle of a text file. The disadvantages are
> > > > > > > > > multiple but the only advantage is a slightly smaller file. And
> > > > > > > > > the true route to smaller files is to add compression like we
> > > > > > > > > have in i915.
> > > > > > > > >
> > > > > > > > > John.
> > > > > > > > >
> > > > > > > > PS: Also meant to add that one of the important uses cases for
> > > > > > > > dumping logs to dmesg is for the really hard to repro bugs that
> > > > > > > > show up in CI extremely rarely. We get the driver to dump an error
> > > > > > > > capture to dmesg and pull that out from the CI logs. Even if you
> > > > > > > > could get binary data through dmesg, pretty sure the CI tools
> > > > > > > > would also not be happy with it. Anything non-printable will get
> > > > > > > > munged for sure when turning it into a web page.
> > > > > > > I think that's the main source of confusion on what we are discussing.
> > > > > > > I was not talking about dmesg at all. I'm only complaining about feeding
> > > > > > > ascii85-encoded data into a *devcoredump* when apparently there isn't a
> > > > > > > good reason to do so. I'd rather copy the binary data to the
> > > > > > > devcoredump.
> > > > > > But the intent is to dump a devcoredump to dmesg. It makes much sense
> > > > > It seems like an awful idea to dump hundreds of MB to dmesg. When we
> > > > > talked about printing to dmesg it was about **GuC log** and on very
> > > > > initial states of driver probe where we didn't actually have a good
> > > > > interface for that. And the log wouldn't be so big. If we can already
> > > > > capture the devcoredump, what would be the reason to dump to dmesg
> > > > > (other than the non-valid "our CI captures dmesg, and doesn't
> > > > > capture devcoredump", which should be fixed).
> > > > >
> > > > > If any sysadmin have their serial console flooded by such garbage there
> > > > > are 2 reactions: 1) someone got in control of my machine; 2) something
> > > > > went really bad with this machine. It's not "fear not, wait for it to
> > > > > complete, it's just normal debug data I will attach to an issue in
> > > > > gitlab". And I'm mentioning a serial console here due to that
> > > > > cond_resched() added, which is only needed because you are trying to do
> > > > > in kernel space what should be in userspace.
> > > > >
> > > > > Oh well... looking at this the main reason to use ascii85 I can see is
> > > > > because we already have parts of *our* devcoredump using it, and
> > > > > userspace relying on that. That's new to me. Let's stop bringing dmesg
> > > > > into this discussion.
> > > > >
> > > > > > to have a single implementation that can be used for multiple
> > > > > > purposes. Otherwise you are duplicating a lot of code unnecessarily.
> > > > > >
> > > > > > And I still think it is a *very* bad idea to be including binary data
> > > > > > in a text file. The devcoredump is supposed to be human readable. It
> > > > > no, it's not. devcoredump doesn't dictate the format, it's up to the
> > > > > drivers to do that. See their documentation.
> > > > >
> > > > > > is supposed to be obtained by end users and passed around. Having
> > > > > > binary data in there just makes everything more complex and error
> > > > > > prone. We want this to be as simple, easy and safe as possible.
> > > > > >
> > > > > > > For dmesg, there's a reason to encode it as you pointed out... but
> > > > > > > no users shouldn't actually see it - we should be getting all of those
> > > > > > > cases in CI. For the escape scenarios, yeah... better having it
> > > > > > > ascii85-encoded.
> > > > > > >
> > > > > > > What you are adding to devcoredump also doesn't even seem to be an
> > > > > > > ascii85 representation, but a multiple lines that should be concatenated
> > > > > > > to form the ascii85 representation. For dmesg it makes sense. Not for
> > > > > > > devcoredump. We should also probabaly need a length field (correctly
> > > > > > > accounting for the additional characters for each line) so we don't
> > > > > > > have an implicit dependency on what's the next field to know how much to
> > > > > > > parse.
> > > > > > The decoding is pretty trivial given that line feeds are not part of
> > > > > > the ASCII85 character set and so can just be dropped. Besides The
> > > > > > output is already not 'pure' ASCII85 because the ASCII85 data is
> > > > > > embedded within a devcoredump. There is all sorts of other text about,
> > > > > > including on the start of the line. There are multiple ASCII85 blobs
> > > > > > in there that need to be decoded separately. This is nothing new to my
> > > > > > patch set. All of that is already there. And as per comments on the
> > > > > > previous devcoredump patches from Matthew B, the object data can many
> > > > > > hundreds of MBs in size. Yet no-one batted an eyelid when that was
> > > > > > added. So why the sudden paranoia about adding a couple of MB of GuC
> > > > > > log in the same form?
> > > > > I suppose you are talking about commit 4d5242a003bb ("drm/xe: Implement capture of
> > > > > HWSP and HWCTX"). Probably because I haven't seen that commit doing an
> > > > > ascii85 encoding before, otherwise I'd have similar review feedback.
> > > > >
> > > > > Looking at this just now, so I will also have to balance the previous
> > > > > users and existing userspace consuming it.
> > > > >
> > > > > +José, would it be ok from the userspace POV to start adding the \n?
> > > > > Then we can at least have all fields in our devcoredump to follow the
> > > > > same format. Are these the decoder parts on the mesa side?
> > > > >
> > > > > src/intel/tools/aubinator_error_decode.c
> > > > > src/intel/tools/error2hangdump.c?
> > > > >
> > > > > From a quick look, read_xe_data_file() already continues the previous
> > > > > topic when it reads a newline, but the parsers for HWCTX and HWSP
> > > > > seems to expect to to have the entire topic in a single line. But I may
> > > > > be missing something.
> > > > Sorry I'm not following up this thread.
> > > > Add a '\n' where exactly?
> > > To break very long ASCII85 streams across multiple lines. That will
> > > allow the devcoredump file to output via dmesg for the situations where
> > > reading from sysfs is not possible.
> > >
> > > This patch is adding an ASCII85 encoding helper that is more friendly to
> > > output via dmesg. The patch does not currently change the existing
> > > ASCII85 encodings of VMs and hw contexts. However, the intention would
> > > be to update that code to use this helper eventually.
> > It will break the parser and I don't think we are allowed to break it at this point.
> The intent has always been to add compression as we had in i915. That will
> presumably also break the parser. Although I'm not seeing how a debug log
> parser counts as critical user space that must not ever be broken.
We shouldn't be breaking the current userspace tools. Any change like this would
need to be synchronized between all the current decode tools.
>
> > What I can suggest is add another sysfs with a coredump that skips the binary dumps so it is readable by humans.
> That will just lead to confusion and problems with people sending the wrong
> file. This needs to be kept as simple and error-proof as possible.
Perhaps it is time for us to convince devcoredump folks to accept
multiple files like nvme folks were asking a while ago? [1]
[1] - https://lore.kernel.org/lkml/1557676457-4195-4-git-send-email-akinobu.mita@gmail.com/
>
> John.
>
> >
> > > John.
> > >
> > > > > Lucas De Marchi
> > > > >
> > > > > > And again, arbitrarily long lines (potentially many thousands of
> > > > > > characters wide) in a text file can cause problems. Having it line
> > > > > > wrapped gets rid of those potential problems and so is safer. Anything
> > > > > > that reduces the risk of an error report being broken is a good thing
> > > > > > IMHO. Robustness is worthwhile!
> > > > > >
> > > > > > John.
> > > > > >
> > > > > > > Lucas De Marchi
> > > > > > >
> > > > > > > > John.
> > > > > > > >
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function
2024-09-12 13:57 ` Rodrigo Vivi
@ 2024-09-12 18:06 ` John Harrison
2024-09-16 15:32 ` Rodrigo Vivi
0 siblings, 1 reply; 54+ messages in thread
From: John Harrison @ 2024-09-12 18:06 UTC (permalink / raw)
To: Rodrigo Vivi
Cc: Souza, Jose, De Marchi, Lucas, Intel-Xe@lists.freedesktop.org,
Brost, Matthew
On 9/12/2024 06:57, Rodrigo Vivi wrote:
> On Wed, Sep 11, 2024 at 12:59:54PM -0700, John Harrison wrote:
>> On 9/11/2024 12:54, Souza, Jose wrote:
>>> On Wed, 2024-09-11 at 12:35 -0700, John Harrison wrote:
>>>> On 9/11/2024 12:30, Souza, Jose wrote:
>>>>> On Wed, 2024-09-11 at 14:12 -0500, Lucas De Marchi wrote:
>>>>>> On Tue, Sep 10, 2024 at 01:17:11PM GMT, John Harrison wrote:
>>>>>>> On 9/10/2024 12:43, Lucas De Marchi wrote:
>>>>>>>> On Mon, Sep 09, 2024 at 06:31:41PM GMT, John Harrison wrote:
>>>>>>>>> On 9/6/2024 19:06, John Harrison wrote:
>>>>>>>>>> On 9/5/2024 20:04, Lucas De Marchi wrote:
>>>>>>>>>>> On Thu, Sep 05, 2024 at 07:01:33PM GMT, John Harrison wrote:
>>>>>>>>>>>> On 9/5/2024 18:54, Lucas De Marchi wrote:
>>>>>>>>>>>>> On Thu, Sep 05, 2024 at 01:50:58PM GMT,
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>> why are we not dumping the binary data directly to devcoredump?
>>>>>>>>>>>> As per earlier comments, there is a WiFi driver or some such
>>>>>>>>>>>> that does exactly that. But all they are dumping is a binary
>>>>>>>>>>>> blob.
>>>>>>>>>>> In your v5 I see you mentioned
>>>>>>>>>>> drivers/net/wireless/ath/ath10k/coredump.c, but that is a
>>>>>>>>>>> precedence for
>>>>>>>>>>> including it as is from the device rather converting it to ASCII85 or
>>>>>>>>>>> something else. It seems odd to do that type of conversion in kernel
>>>>>>>>>>> space when it could be perfectly done in userspace.
>>>>>>>>>> It really can't. An end user could maybe be expected to zip or
>>>>>>>>>> tar a coredump file before attaching it to a bug report but they
>>>>>>>>>> are certainly not going to try to ASCII85 encode random bits of
>>>>>>>>>> it. Whereas, putting that in the kernel means it is just there.
>>>>>>>>>> It is done. And it is pretty trivial - just call a helper
>>>>>>>>>> function and it does everything for you. Also, I very much doubt
>>>>>>>>>> you can spew raw binary data via dmesg. Even if the kernel would
>>>>>>>>>> print it for you (which I doubt), the user tools like syslogd
>>>>>>>>>> and dmesg itself are going to filter it to make it ASCII safe.
>>>>>>>>>>
>>>>>>>>>> The i915 error dumps have been ASCII85 encoded using the
>>>>>>>>>> kernel's ASCII85 encoding helper function since forever. This
>>>>>>>>>> patch is just a wrapper around the kernel's existing
>>>>>>>>>> implementation in order to make it more compatible with printing
>>>>>>>>>> to dmesg. This is not creating a new precedent. It already
>>>>>>>>>> exists.
> No! no big dump in dmesg.
Please see other response. Dumping via dmesg is intended for internal
use and impossible to repro fatal scenarios. There is zero expectation
and end user would ever see a dump via dmesg. This entire patch set only
includes one actual trigger for doing such dumps and that is only if
CONFIG_DRM_XE_DEBUG is defined. Which it would not be for an end user.
And if you are saying that internal developers are not allowed to use
dumps via dmesg then we might as well give up and go home because there
are very many bugs for which this is the only viable debug method.
>
>>>>>>>>>>> $ git grep ascii85.h
>>>>>>>>>>> drivers/gpu/drm/i915/i915_gpu_error.c:#include <linux/ascii85.h>
>>>>>>>>>>> drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:#include <linux/ascii85.h>
>>>>>>>>>>> drivers/gpu/drm/msm/adreno/adreno_gpu.c:#include <linux/ascii85.h>
>>>>>>>>>>> drivers/gpu/drm/xe/xe_lrc.c:#include <linux/ascii85.h>
>>>>>>>>>>> drivers/gpu/drm/xe/xe_vm.c:#include <linux/ascii85.h>
>>>>>>>>>> And the list of drivers which dump raw binary data in a coredump
>>>>>>>>>> file is... ath10k. ASCII85 wins 3 to 1.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> We want the devcoredump file to still be human readable.
>>>>>>>>>>>> That won't be the case if you stuff binary data in the
>>>>>>>>>>>> middle of it. Most obvious problem - the zeros in the data
>>>>>>>>>>>> will terminate your text file at that point. Potentially
>>>>>>>>>>>> bigger problem for end users - random fake ANSI codes will
>>>>>>>>>>>> destroy your terminal window if you try to cat the file to
>>>>>>>>>>>> read it.
>>>>>>>>>>> Users don't get a coredump and cat it to the terminal.
>>>>>>>>>>> =(lk%A8`T7AKYH#FD,6++EqOABHUhsG%5H2ARoq#E$/V$Bl7Q+@<5pmBe<q;Bk;0mCj@.3DIal2FD5Q-+E_RBART+X@VfTuGA2/4Dfp.E@3BN0DfB9.+E1b0F(KAV+:8
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Lucas De Marchi
>>>>>>>>>> They might. Either intentionally or accidentally. I've certainly
>>>>>>>>>> done it myself. And people will certainly want to look at it in
>>>>>>>>>> any random choice of text editor, pager, etc. 'cos you know, it
>>>>>>>>>> is meant to be read by humans. If it is full of binary data then
>>>>>>>>>> that becomes even more difficult than simply being full of ASCII
>>>>>>>>>> gibberish. No matter what you are doing, the ASCII version is
>>>>>>>>>> safer and easier to look at the rest of the file around it.
>>>>>>>>>>
>>>>>>>>>> I don't understand why you are so desperate to have raw binary
>>>>>>>>>> data in the middle of a text file. The disadvantages are
>>>>>>>>>> multiple but the only advantage is a slightly smaller file. And
>>>>>>>>>> the true route to smaller files is to add compression like we
>>>>>>>>>> have in i915.
>>>>>>>>>>
>>>>>>>>>> John.
>>>>>>>>>>
>>>>>>>>> PS: Also meant to add that one of the important uses cases for
>>>>>>>>> dumping logs to dmesg is for the really hard to repro bugs that
>>>>>>>>> show up in CI extremely rarely. We get the driver to dump an error
>>>>>>>>> capture to dmesg and pull that out from the CI logs. Even if you
>>>>>>>>> could get binary data through dmesg, pretty sure the CI tools
>>>>>>>>> would also not be happy with it. Anything non-printable will get
>>>>>>>>> munged for sure when turning it into a web page.
>>>>>>>> I think that's the main source of confusion on what we are discussing.
>>>>>>>> I was not talking about dmesg at all. I'm only complaining about feeding
>>>>>>>> ascii85-encoded data into a *devcoredump* when apparently there isn't a
>>>>>>>> good reason to do so. I'd rather copy the binary data to the
>>>>>>>> devcoredump.
>>>>>>> But the intent is to dump a devcoredump to dmesg. It makes much sense
>>>>>> It seems like an awful idea to dump hundreds of MB to dmesg. When we
>>>>>> talked about printing to dmesg it was about **GuC log** and on very
>>>>>> initial states of driver probe where we didn't actually have a good
>>>>>> interface for that. And the log wouldn't be so big. If we can already
>>>>>> capture the devcoredump, what would be the reason to dump to dmesg
>>>>>> (other than the non-valid "our CI captures dmesg, and doesn't
>>>>>> capture devcoredump", which should be fixed).
>>>>>>
>>>>>> If any sysadmin have their serial console flooded by such garbage there
>>>>>> are 2 reactions: 1) someone got in control of my machine; 2) something
>>>>>> went really bad with this machine. It's not "fear not, wait for it to
>>>>>> complete, it's just normal debug data I will attach to an issue in
>>>>>> gitlab". And I'm mentioning a serial console here due to that
>>>>>> cond_resched() added, which is only needed because you are trying to do
>>>>>> in kernel space what should be in userspace.
>>>>>>
>>>>>> Oh well... looking at this the main reason to use ascii85 I can see is
>>>>>> because we already have parts of *our* devcoredump using it, and
>>>>>> userspace relying on that. That's new to me. Let's stop bringing dmesg
>>>>>> into this discussion.
>>>>>>
>>>>>>> to have a single implementation that can be used for multiple
>>>>>>> purposes. Otherwise you are duplicating a lot of code unnecessarily.
>>>>>>>
>>>>>>> And I still think it is a *very* bad idea to be including binary data
>>>>>>> in a text file. The devcoredump is supposed to be human readable. It
>>>>>> no, it's not. devcoredump doesn't dictate the format, it's up to the
>>>>>> drivers to do that. See their documentation.
>>>>>>
>>>>>>> is supposed to be obtained by end users and passed around. Having
>>>>>>> binary data in there just makes everything more complex and error
>>>>>>> prone. We want this to be as simple, easy and safe as possible.
>>>>>>>
>>>>>>>> For dmesg, there's a reason to encode it as you pointed out... but
>>>>>>>> no users shouldn't actually see it - we should be getting all of those
>>>>>>>> cases in CI. For the escape scenarios, yeah... better having it
>>>>>>>> ascii85-encoded.
>>>>>>>>
>>>>>>>> What you are adding to devcoredump also doesn't even seem to be an
>>>>>>>> ascii85 representation, but a multiple lines that should be concatenated
>>>>>>>> to form the ascii85 representation. For dmesg it makes sense. Not for
>>>>>>>> devcoredump. We should also probabaly need a length field (correctly
>>>>>>>> accounting for the additional characters for each line) so we don't
>>>>>>>> have an implicit dependency on what's the next field to know how much to
>>>>>>>> parse.
>>>>>>> The decoding is pretty trivial given that line feeds are not part of
>>>>>>> the ASCII85 character set and so can just be dropped. Besides The
>>>>>>> output is already not 'pure' ASCII85 because the ASCII85 data is
>>>>>>> embedded within a devcoredump. There is all sorts of other text about,
>>>>>>> including on the start of the line. There are multiple ASCII85 blobs
>>>>>>> in there that need to be decoded separately. This is nothing new to my
>>>>>>> patch set. All of that is already there. And as per comments on the
>>>>>>> previous devcoredump patches from Matthew B, the object data can many
>>>>>>> hundreds of MBs in size. Yet no-one batted an eyelid when that was
>>>>>>> added. So why the sudden paranoia about adding a couple of MB of GuC
>>>>>>> log in the same form?
>>>>>> I suppose you are talking about commit 4d5242a003bb ("drm/xe: Implement capture of
>>>>>> HWSP and HWCTX"). Probably because I haven't seen that commit doing an
>>>>>> ascii85 encoding before, otherwise I'd have similar review feedback.
>>>>>>
>>>>>> Looking at this just now, so I will also have to balance the previous
>>>>>> users and existing userspace consuming it.
>>>>>>
>>>>>> +José, would it be ok from the userspace POV to start adding the \n?
>>>>>> Then we can at least have all fields in our devcoredump to follow the
>>>>>> same format. Are these the decoder parts on the mesa side?
>>>>>>
>>>>>> src/intel/tools/aubinator_error_decode.c
>>>>>> src/intel/tools/error2hangdump.c?
>>>>>>
>>>>>> From a quick look, read_xe_data_file() already continues the previous
>>>>>> topic when it reads a newline, but the parsers for HWCTX and HWSP
>>>>>> seems to expect to to have the entire topic in a single line. But I may
>>>>>> be missing something.
>>>>> Sorry I'm not following up this thread.
>>>>> Add a '\n' where exactly?
>>>> To break very long ASCII85 streams across multiple lines. That will
>>>> allow the devcoredump file to output via dmesg for the situations where
>>>> reading from sysfs is not possible.
>>>>
>>>> This patch is adding an ASCII85 encoding helper that is more friendly to
>>>> output via dmesg. The patch does not currently change the existing
>>>> ASCII85 encodings of VMs and hw contexts. However, the intention would
>>>> be to update that code to use this helper eventually.
>>> It will break the parser and I don't think we are allowed to break it at this point.
>> The intent has always been to add compression as we had in i915. That will
>> presumably also break the parser. Although I'm not seeing how a debug log
>> parser counts as critical user space that must not ever be broken.
> We shouldn't be breaking the current userspace tools. Any change like this would
> need to be synchronized between all the current decode tools.
That is why the comment was 'eventually we would like to'. Nothing in
this patch will break a user tool unless that tool cannot cope with new
data being added to the core dump. And if we can't add new stuff to core
dumps then again, we are fundamentally broken.
>
>>> What I can suggest is add another sysfs with a coredump that skips the binary dumps so it is readable by humans.
>> That will just lead to confusion and problems with people sending the wrong
>> file. This needs to be kept as simple and error-proof as possible.
> Perhaps it is time for us to convince devcoredump folks to accept
> multiple files like nvme folks were asking a while ago? [1]
>
> [1] - https://lore.kernel.org/lkml/1557676457-4195-4-git-send-email-akinobu.mita@gmail.com/
Is that likely to happen any time soon? That thread was from May 2019.
We need something now. And it's not clear if that is adding a filing
system within a single core dump file (i.e. read one file from sysfs and
then extract later like a tarball) or creating multiple sysfs files that
all must be read together and passed around together. I would strongly
advise against the latter. As I said already, the whole coredump thing
needs to be as simple and easy to use as possible.
If more official support is added to devcoredump itself in some number
of years time and is actually beneficial, then we can move over to using
that interface (and break the user land tools again...). But until then,
this version works with the least amount of disruption for significant
benefit. I.e., it lets us actually debug problems right now.
John.
>
>> John.
>>
>>>> John.
>>>>
>>>>>> Lucas De Marchi
>>>>>>
>>>>>>> And again, arbitrarily long lines (potentially many thousands of
>>>>>>> characters wide) in a text file can cause problems. Having it line
>>>>>>> wrapped gets rid of those potential problems and so is safer. Anything
>>>>>>> that reduces the risk of an error report being broken is a good thing
>>>>>>> IMHO. Robustness is worthwhile!
>>>>>>>
>>>>>>> John.
>>>>>>>
>>>>>>>> Lucas De Marchi
>>>>>>>>
>>>>>>>>> John.
>>>>>>>>>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump
2024-09-12 9:16 ` [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump Jani Nikula
@ 2024-09-12 18:50 ` John Harrison
2024-09-13 7:26 ` Jani Nikula
0 siblings, 1 reply; 54+ messages in thread
From: John Harrison @ 2024-09-12 18:50 UTC (permalink / raw)
To: Jani Nikula, Intel-Xe
On 9/12/2024 02:16, Jani Nikula wrote:
> On Thu, 05 Sep 2024, John.C.Harrison@Intel.com wrote:
>> Michal Wajdeczko (1):
>> drm/print: Introduce drm_line_printer
> Given the discussion around other parts, it might be prudent to just
> upstream this separately via drm-misc.
For what purpose? Without the rest of this patch set that one patch is
pointless - it has no other users and it has no other purpose.
John.
>
> BR,
> Jani.
>
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump
2024-09-12 18:50 ` John Harrison
@ 2024-09-13 7:26 ` Jani Nikula
0 siblings, 0 replies; 54+ messages in thread
From: Jani Nikula @ 2024-09-13 7:26 UTC (permalink / raw)
To: John Harrison, Intel-Xe
On Thu, 12 Sep 2024, John Harrison <john.c.harrison@intel.com> wrote:
> On 9/12/2024 02:16, Jani Nikula wrote:
>> On Thu, 05 Sep 2024, John.C.Harrison@Intel.com wrote:
>>> Michal Wajdeczko (1):
>>> drm/print: Introduce drm_line_printer
>> Given the discussion around other parts, it might be prudent to just
>> upstream this separately via drm-misc.
> For what purpose? Without the rest of this patch set that one patch is
> pointless - it has no other users and it has no other purpose.
I'm just trying to make it easier to upstream this stuff. You'll need to
Cc: it to dri-devel and get acks from drm-misc maintainers anyway to
merge it via drm-xe-next. Or you could just get it merged via
drm-misc-next, in parallel, and just reference this series.
BR,
Jani.
--
Jani Nikula, Intel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function
2024-09-12 18:06 ` John Harrison
@ 2024-09-16 15:32 ` Rodrigo Vivi
2024-09-16 17:46 ` John Harrison
0 siblings, 1 reply; 54+ messages in thread
From: Rodrigo Vivi @ 2024-09-16 15:32 UTC (permalink / raw)
To: John Harrison
Cc: Souza, Jose, De Marchi, Lucas, Intel-Xe@lists.freedesktop.org,
Brost, Matthew
On Thu, Sep 12, 2024 at 11:06:20AM -0700, John Harrison wrote:
> On 9/12/2024 06:57, Rodrigo Vivi wrote:
> > On Wed, Sep 11, 2024 at 12:59:54PM -0700, John Harrison wrote:
> > > On 9/11/2024 12:54, Souza, Jose wrote:
> > > > On Wed, 2024-09-11 at 12:35 -0700, John Harrison wrote:
> > > > > On 9/11/2024 12:30, Souza, Jose wrote:
> > > > > > On Wed, 2024-09-11 at 14:12 -0500, Lucas De Marchi wrote:
> > > > > > > On Tue, Sep 10, 2024 at 01:17:11PM GMT, John Harrison wrote:
> > > > > > > > On 9/10/2024 12:43, Lucas De Marchi wrote:
> > > > > > > > > On Mon, Sep 09, 2024 at 06:31:41PM GMT, John Harrison wrote:
> > > > > > > > > > On 9/6/2024 19:06, John Harrison wrote:
> > > > > > > > > > > On 9/5/2024 20:04, Lucas De Marchi wrote:
> > > > > > > > > > > > On Thu, Sep 05, 2024 at 07:01:33PM GMT, John Harrison wrote:
> > > > > > > > > > > > > On 9/5/2024 18:54, Lucas De Marchi wrote:
> > > > > > > > > > > > > > On Thu, Sep 05, 2024 at 01:50:58PM GMT,
> > > > > > > > > > > > > > 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.
> > > > > > > > > > > > > > why are we not dumping the binary data directly to devcoredump?
> > > > > > > > > > > > > As per earlier comments, there is a WiFi driver or some such
> > > > > > > > > > > > > that does exactly that. But all they are dumping is a binary
> > > > > > > > > > > > > blob.
> > > > > > > > > > > > In your v5 I see you mentioned
> > > > > > > > > > > > drivers/net/wireless/ath/ath10k/coredump.c, but that is a
> > > > > > > > > > > > precedence for
> > > > > > > > > > > > including it as is from the device rather converting it to ASCII85 or
> > > > > > > > > > > > something else. It seems odd to do that type of conversion in kernel
> > > > > > > > > > > > space when it could be perfectly done in userspace.
> > > > > > > > > > > It really can't. An end user could maybe be expected to zip or
> > > > > > > > > > > tar a coredump file before attaching it to a bug report but they
> > > > > > > > > > > are certainly not going to try to ASCII85 encode random bits of
> > > > > > > > > > > it. Whereas, putting that in the kernel means it is just there.
> > > > > > > > > > > It is done. And it is pretty trivial - just call a helper
> > > > > > > > > > > function and it does everything for you. Also, I very much doubt
> > > > > > > > > > > you can spew raw binary data via dmesg. Even if the kernel would
> > > > > > > > > > > print it for you (which I doubt), the user tools like syslogd
> > > > > > > > > > > and dmesg itself are going to filter it to make it ASCII safe.
> > > > > > > > > > >
> > > > > > > > > > > The i915 error dumps have been ASCII85 encoded using the
> > > > > > > > > > > kernel's ASCII85 encoding helper function since forever. This
> > > > > > > > > > > patch is just a wrapper around the kernel's existing
> > > > > > > > > > > implementation in order to make it more compatible with printing
> > > > > > > > > > > to dmesg. This is not creating a new precedent. It already
> > > > > > > > > > > exists.
> > No! no big dump in dmesg.
> Please see other response. Dumping via dmesg is intended for internal use
> and impossible to repro fatal scenarios. There is zero expectation and end
> user would ever see a dump via dmesg. This entire patch set only includes
> one actual trigger for doing such dumps and that is only if
> CONFIG_DRM_XE_DEBUG is defined. Which it would not be for an end user.
>
> And if you are saying that internal developers are not allowed to use dumps
> via dmesg then we might as well give up and go home because there are very
> many bugs for which this is the only viable debug method.
What I'm saying is, as a user of CONFIG_DRM_XE_DEBUG, I really don't want to see
this big polution in my dmesg everytime.
I understand the case that the machine entirely hang at boot and you have nothing
but the serial log messages that was dumped there. And you want more information
in that view. I understand the case, although I know that we should be really
working to avoid this kind of failure to start with.
A failure on a Firmware communication should never ever caused the platform to hang.
But well, you might tell that in order to solve cases like this you would need
information from why the firmware failed so badly, right?!
This should be a one off case, or a totally separate config, and definitely not
driving decisions of stable api/abi like the devcoredump. Clear now?
>
>
> >
> > > > > > > > > > > > $ git grep ascii85.h
> > > > > > > > > > > > drivers/gpu/drm/i915/i915_gpu_error.c:#include <linux/ascii85.h>
> > > > > > > > > > > > drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:#include <linux/ascii85.h>
> > > > > > > > > > > > drivers/gpu/drm/msm/adreno/adreno_gpu.c:#include <linux/ascii85.h>
> > > > > > > > > > > > drivers/gpu/drm/xe/xe_lrc.c:#include <linux/ascii85.h>
> > > > > > > > > > > > drivers/gpu/drm/xe/xe_vm.c:#include <linux/ascii85.h>
> > > > > > > > > > > And the list of drivers which dump raw binary data in a coredump
> > > > > > > > > > > file is... ath10k. ASCII85 wins 3 to 1.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > > We want the devcoredump file to still be human readable.
> > > > > > > > > > > > > That won't be the case if you stuff binary data in the
> > > > > > > > > > > > > middle of it. Most obvious problem - the zeros in the data
> > > > > > > > > > > > > will terminate your text file at that point. Potentially
> > > > > > > > > > > > > bigger problem for end users - random fake ANSI codes will
> > > > > > > > > > > > > destroy your terminal window if you try to cat the file to
> > > > > > > > > > > > > read it.
> > > > > > > > > > > > Users don't get a coredump and cat it to the terminal.
> > > > > > > > > > > > =(lk%A8`T7AKYH#FD,6++EqOABHUhsG%5H2ARoq#E$/V$Bl7Q+@<5pmBe<q;Bk;0mCj@.3DIal2FD5Q-+E_RBART+X@VfTuGA2/4Dfp.E@3BN0DfB9.+E1b0F(KAV+:8
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Lucas De Marchi
> > > > > > > > > > > They might. Either intentionally or accidentally. I've certainly
> > > > > > > > > > > done it myself. And people will certainly want to look at it in
> > > > > > > > > > > any random choice of text editor, pager, etc. 'cos you know, it
> > > > > > > > > > > is meant to be read by humans. If it is full of binary data then
> > > > > > > > > > > that becomes even more difficult than simply being full of ASCII
> > > > > > > > > > > gibberish. No matter what you are doing, the ASCII version is
> > > > > > > > > > > safer and easier to look at the rest of the file around it.
> > > > > > > > > > >
> > > > > > > > > > > I don't understand why you are so desperate to have raw binary
> > > > > > > > > > > data in the middle of a text file. The disadvantages are
> > > > > > > > > > > multiple but the only advantage is a slightly smaller file. And
> > > > > > > > > > > the true route to smaller files is to add compression like we
> > > > > > > > > > > have in i915.
> > > > > > > > > > >
> > > > > > > > > > > John.
> > > > > > > > > > >
> > > > > > > > > > PS: Also meant to add that one of the important uses cases for
> > > > > > > > > > dumping logs to dmesg is for the really hard to repro bugs that
> > > > > > > > > > show up in CI extremely rarely. We get the driver to dump an error
> > > > > > > > > > capture to dmesg and pull that out from the CI logs. Even if you
> > > > > > > > > > could get binary data through dmesg, pretty sure the CI tools
> > > > > > > > > > would also not be happy with it. Anything non-printable will get
> > > > > > > > > > munged for sure when turning it into a web page.
> > > > > > > > > I think that's the main source of confusion on what we are discussing.
> > > > > > > > > I was not talking about dmesg at all. I'm only complaining about feeding
> > > > > > > > > ascii85-encoded data into a *devcoredump* when apparently there isn't a
> > > > > > > > > good reason to do so. I'd rather copy the binary data to the
> > > > > > > > > devcoredump.
> > > > > > > > But the intent is to dump a devcoredump to dmesg. It makes much sense
> > > > > > > It seems like an awful idea to dump hundreds of MB to dmesg. When we
> > > > > > > talked about printing to dmesg it was about **GuC log** and on very
> > > > > > > initial states of driver probe where we didn't actually have a good
> > > > > > > interface for that. And the log wouldn't be so big. If we can already
> > > > > > > capture the devcoredump, what would be the reason to dump to dmesg
> > > > > > > (other than the non-valid "our CI captures dmesg, and doesn't
> > > > > > > capture devcoredump", which should be fixed).
> > > > > > >
> > > > > > > If any sysadmin have their serial console flooded by such garbage there
> > > > > > > are 2 reactions: 1) someone got in control of my machine; 2) something
> > > > > > > went really bad with this machine. It's not "fear not, wait for it to
> > > > > > > complete, it's just normal debug data I will attach to an issue in
> > > > > > > gitlab". And I'm mentioning a serial console here due to that
> > > > > > > cond_resched() added, which is only needed because you are trying to do
> > > > > > > in kernel space what should be in userspace.
> > > > > > >
> > > > > > > Oh well... looking at this the main reason to use ascii85 I can see is
> > > > > > > because we already have parts of *our* devcoredump using it, and
> > > > > > > userspace relying on that. That's new to me. Let's stop bringing dmesg
> > > > > > > into this discussion.
> > > > > > >
> > > > > > > > to have a single implementation that can be used for multiple
> > > > > > > > purposes. Otherwise you are duplicating a lot of code unnecessarily.
> > > > > > > >
> > > > > > > > And I still think it is a *very* bad idea to be including binary data
> > > > > > > > in a text file. The devcoredump is supposed to be human readable. It
> > > > > > > no, it's not. devcoredump doesn't dictate the format, it's up to the
> > > > > > > drivers to do that. See their documentation.
> > > > > > >
> > > > > > > > is supposed to be obtained by end users and passed around. Having
> > > > > > > > binary data in there just makes everything more complex and error
> > > > > > > > prone. We want this to be as simple, easy and safe as possible.
> > > > > > > >
> > > > > > > > > For dmesg, there's a reason to encode it as you pointed out... but
> > > > > > > > > no users shouldn't actually see it - we should be getting all of those
> > > > > > > > > cases in CI. For the escape scenarios, yeah... better having it
> > > > > > > > > ascii85-encoded.
> > > > > > > > >
> > > > > > > > > What you are adding to devcoredump also doesn't even seem to be an
> > > > > > > > > ascii85 representation, but a multiple lines that should be concatenated
> > > > > > > > > to form the ascii85 representation. For dmesg it makes sense. Not for
> > > > > > > > > devcoredump. We should also probabaly need a length field (correctly
> > > > > > > > > accounting for the additional characters for each line) so we don't
> > > > > > > > > have an implicit dependency on what's the next field to know how much to
> > > > > > > > > parse.
> > > > > > > > The decoding is pretty trivial given that line feeds are not part of
> > > > > > > > the ASCII85 character set and so can just be dropped. Besides The
> > > > > > > > output is already not 'pure' ASCII85 because the ASCII85 data is
> > > > > > > > embedded within a devcoredump. There is all sorts of other text about,
> > > > > > > > including on the start of the line. There are multiple ASCII85 blobs
> > > > > > > > in there that need to be decoded separately. This is nothing new to my
> > > > > > > > patch set. All of that is already there. And as per comments on the
> > > > > > > > previous devcoredump patches from Matthew B, the object data can many
> > > > > > > > hundreds of MBs in size. Yet no-one batted an eyelid when that was
> > > > > > > > added. So why the sudden paranoia about adding a couple of MB of GuC
> > > > > > > > log in the same form?
> > > > > > > I suppose you are talking about commit 4d5242a003bb ("drm/xe: Implement capture of
> > > > > > > HWSP and HWCTX"). Probably because I haven't seen that commit doing an
> > > > > > > ascii85 encoding before, otherwise I'd have similar review feedback.
> > > > > > >
> > > > > > > Looking at this just now, so I will also have to balance the previous
> > > > > > > users and existing userspace consuming it.
> > > > > > >
> > > > > > > +José, would it be ok from the userspace POV to start adding the \n?
> > > > > > > Then we can at least have all fields in our devcoredump to follow the
> > > > > > > same format. Are these the decoder parts on the mesa side?
> > > > > > >
> > > > > > > src/intel/tools/aubinator_error_decode.c
> > > > > > > src/intel/tools/error2hangdump.c?
> > > > > > >
> > > > > > > From a quick look, read_xe_data_file() already continues the previous
> > > > > > > topic when it reads a newline, but the parsers for HWCTX and HWSP
> > > > > > > seems to expect to to have the entire topic in a single line. But I may
> > > > > > > be missing something.
> > > > > > Sorry I'm not following up this thread.
> > > > > > Add a '\n' where exactly?
> > > > > To break very long ASCII85 streams across multiple lines. That will
> > > > > allow the devcoredump file to output via dmesg for the situations where
> > > > > reading from sysfs is not possible.
> > > > >
> > > > > This patch is adding an ASCII85 encoding helper that is more friendly to
> > > > > output via dmesg. The patch does not currently change the existing
> > > > > ASCII85 encodings of VMs and hw contexts. However, the intention would
> > > > > be to update that code to use this helper eventually.
> > > > It will break the parser and I don't think we are allowed to break it at this point.
> > > The intent has always been to add compression as we had in i915. That will
> > > presumably also break the parser. Although I'm not seeing how a debug log
> > > parser counts as critical user space that must not ever be broken.
> > We shouldn't be breaking the current userspace tools. Any change like this would
> > need to be synchronized between all the current decode tools.
> That is why the comment was 'eventually we would like to'. Nothing in this
> patch will break a user tool unless that tool cannot cope with new data
> being added to the core dump. And if we can't add new stuff to core dumps
> then again, we are fundamentally broken.
>
> >
> > > > What I can suggest is add another sysfs with a coredump that skips the binary dumps so it is readable by humans.
> > > That will just lead to confusion and problems with people sending the wrong
> > > file. This needs to be kept as simple and error-proof as possible.
> > Perhaps it is time for us to convince devcoredump folks to accept
> > multiple files like nvme folks were asking a while ago? [1]
> >
> > [1] - https://lore.kernel.org/lkml/1557676457-4195-4-git-send-email-akinobu.mita@gmail.com/
> Is that likely to happen any time soon? That thread was from May 2019. We
> need something now. And it's not clear if that is adding a filing system
> within a single core dump file (i.e. read one file from sysfs and then
> extract later like a tarball) or creating multiple sysfs files that all must
> be read together and passed around together. I would strongly advise against
> the latter. As I said already, the whole coredump thing needs to be as
> simple and easy to use as possible.
>
> If more official support is added to devcoredump itself in some number of
> years time and is actually beneficial, then we can move over to using that
> interface (and break the user land tools again...). But until then, this
> version works with the least amount of disruption for significant benefit.
> I.e., it lets us actually debug problems right now.
>
> John.
>
>
> >
> > > John.
> > >
> > > > > John.
> > > > >
> > > > > > > Lucas De Marchi
> > > > > > >
> > > > > > > > And again, arbitrarily long lines (potentially many thousands of
> > > > > > > > characters wide) in a text file can cause problems. Having it line
> > > > > > > > wrapped gets rid of those potential problems and so is safer. Anything
> > > > > > > > that reduces the risk of an error report being broken is a good thing
> > > > > > > > IMHO. Robustness is worthwhile!
> > > > > > > >
> > > > > > > > John.
> > > > > > > >
> > > > > > > > > Lucas De Marchi
> > > > > > > > >
> > > > > > > > > > John.
> > > > > > > > > >
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function
2024-09-16 15:32 ` Rodrigo Vivi
@ 2024-09-16 17:46 ` John Harrison
0 siblings, 0 replies; 54+ messages in thread
From: John Harrison @ 2024-09-16 17:46 UTC (permalink / raw)
To: Rodrigo Vivi
Cc: Souza, Jose, De Marchi, Lucas, Intel-Xe@lists.freedesktop.org,
Brost, Matthew
On 9/16/2024 08:32, Rodrigo Vivi wrote:
> On Thu, Sep 12, 2024 at 11:06:20AM -0700, John Harrison wrote:
>> On 9/12/2024 06:57, Rodrigo Vivi wrote:
>>> On Wed, Sep 11, 2024 at 12:59:54PM -0700, John Harrison wrote:
>>>> On 9/11/2024 12:54, Souza, Jose wrote:
>>>>> On Wed, 2024-09-11 at 12:35 -0700, John Harrison wrote:
>>>>>> On 9/11/2024 12:30, Souza, Jose wrote:
>>>>>>> On Wed, 2024-09-11 at 14:12 -0500, Lucas De Marchi wrote:
>>>>>>>> On Tue, Sep 10, 2024 at 01:17:11PM GMT, John Harrison wrote:
>>>>>>>>> On 9/10/2024 12:43, Lucas De Marchi wrote:
>>>>>>>>>> On Mon, Sep 09, 2024 at 06:31:41PM GMT, John Harrison wrote:
>>>>>>>>>>> On 9/6/2024 19:06, John Harrison wrote:
>>>>>>>>>>>> On 9/5/2024 20:04, Lucas De Marchi wrote:
>>>>>>>>>>>>> On Thu, Sep 05, 2024 at 07:01:33PM GMT, John Harrison wrote:
>>>>>>>>>>>>>> On 9/5/2024 18:54, Lucas De Marchi wrote:
>>>>>>>>>>>>>>> On Thu, Sep 05, 2024 at 01:50:58PM GMT,
>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>> why are we not dumping the binary data directly to devcoredump?
>>>>>>>>>>>>>> As per earlier comments, there is a WiFi driver or some such
>>>>>>>>>>>>>> that does exactly that. But all they are dumping is a binary
>>>>>>>>>>>>>> blob.
>>>>>>>>>>>>> In your v5 I see you mentioned
>>>>>>>>>>>>> drivers/net/wireless/ath/ath10k/coredump.c, but that is a
>>>>>>>>>>>>> precedence for
>>>>>>>>>>>>> including it as is from the device rather converting it to ASCII85 or
>>>>>>>>>>>>> something else. It seems odd to do that type of conversion in kernel
>>>>>>>>>>>>> space when it could be perfectly done in userspace.
>>>>>>>>>>>> It really can't. An end user could maybe be expected to zip or
>>>>>>>>>>>> tar a coredump file before attaching it to a bug report but they
>>>>>>>>>>>> are certainly not going to try to ASCII85 encode random bits of
>>>>>>>>>>>> it. Whereas, putting that in the kernel means it is just there.
>>>>>>>>>>>> It is done. And it is pretty trivial - just call a helper
>>>>>>>>>>>> function and it does everything for you. Also, I very much doubt
>>>>>>>>>>>> you can spew raw binary data via dmesg. Even if the kernel would
>>>>>>>>>>>> print it for you (which I doubt), the user tools like syslogd
>>>>>>>>>>>> and dmesg itself are going to filter it to make it ASCII safe.
>>>>>>>>>>>>
>>>>>>>>>>>> The i915 error dumps have been ASCII85 encoded using the
>>>>>>>>>>>> kernel's ASCII85 encoding helper function since forever. This
>>>>>>>>>>>> patch is just a wrapper around the kernel's existing
>>>>>>>>>>>> implementation in order to make it more compatible with printing
>>>>>>>>>>>> to dmesg. This is not creating a new precedent. It already
>>>>>>>>>>>> exists.
>>> No! no big dump in dmesg.
>> Please see other response. Dumping via dmesg is intended for internal use
>> and impossible to repro fatal scenarios. There is zero expectation and end
>> user would ever see a dump via dmesg. This entire patch set only includes
>> one actual trigger for doing such dumps and that is only if
>> CONFIG_DRM_XE_DEBUG is defined. Which it would not be for an end user.
>>
>> And if you are saying that internal developers are not allowed to use dumps
>> via dmesg then we might as well give up and go home because there are very
>> many bugs for which this is the only viable debug method.
> What I'm saying is, as a user of CONFIG_DRM_XE_DEBUG, I really don't want to see
> this big polution in my dmesg everytime.
How many times have you seen "big polution in your dmesg" so far?
Right now, checked in, as we are currently shipping the Xe driver to the
public, the spam is far worse than after this patch set. On a CT
failure, it will dump the the CT buffer contents as a hexdump. If the
buffer is very backed up (which it often is in the case of a fatal GuC
failure), that could be something like 2MB of data dumped has a
one-word-per-line hexdump to dmesg. And that has no config option to
turn it off at all. I.e., that is enabled and shipping for end users
with their RedHat default kernel build. This version provides a lot more
useful information in a much more compact and less spewing form, and is
off by default. That is, it is producing less "pollution" not more.
Also, this feature has been part of i915 for over a year (or two, or
three?). How much "big pollution" have you suffered on i915 in all that
time?
>
> I understand the case that the machine entirely hang at boot and you have nothing
> but the serial log messages that was dumped there. And you want more information
> in that view. I understand the case, although I know that we should be really
> working to avoid this kind of failure to start with.
>
> A failure on a Firmware communication should never ever caused the platform to hang.
> But well, you might tell that in order to solve cases like this you would need
> information from why the firmware failed so badly, right?!
This is not about debugging common hangs caused by end users, bad UMDs,
etc. This is about debugging fatal kernel or firmware bugs. Those are
things that should never happen. If you are hitting any of this on a
regular basis then the driver is fundamentally broken and you can't
actually be using it for anything meaningful anyway. This is about
debugging the issues that occur once in a blue moon. And if you ever hit
one locally (on production hardware, with a production driver and
production firmware) then I would be incredibly surprised and absolutely
want to get that log from you to debug what happened.
>
> This should be a one off case, or a totally separate config, and definitely not
> driving decisions of stable api/abi like the devcoredump. Clear now?
I have no idea what you mean by "driving decisions of stable api/abi
like the devcoredump". This is not changing any stable API. It is not
changing the devcoredump infrastructure. It is adding extremely useful
features to our private and internally defined coredump content. And if
you are referring to the dump-via-dmesg (which is config option
controlled or locally added by a developer themselves), that is not part
of devcoredump. The intent is to use devcoredump as the container being
dumped because why duplicate code? Although currently it can't because
of how we have implemented our devcoredump capture code. But either way,
it has absolutely zero bearing on any APIs or on how devcoredumps are
used for regular debugging of end user hangs.
As for config options, sure we can create as many config options as we
like but this feature absolutely needs to be enabled for CI builds.
Plus, last time I tried adding a new config option for debug code, I was
told that we should just use the existing one and not pollute the config
space.
But like I said, the currently shipping Xe driver has the CT dump
permanently enabled. There is no config option at all. So using any
config option is still a significant improvement.
John.
>
>>
>>>>>>>>>>>>> $ git grep ascii85.h
>>>>>>>>>>>>> drivers/gpu/drm/i915/i915_gpu_error.c:#include <linux/ascii85.h>
>>>>>>>>>>>>> drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:#include <linux/ascii85.h>
>>>>>>>>>>>>> drivers/gpu/drm/msm/adreno/adreno_gpu.c:#include <linux/ascii85.h>
>>>>>>>>>>>>> drivers/gpu/drm/xe/xe_lrc.c:#include <linux/ascii85.h>
>>>>>>>>>>>>> drivers/gpu/drm/xe/xe_vm.c:#include <linux/ascii85.h>
>>>>>>>>>>>> And the list of drivers which dump raw binary data in a coredump
>>>>>>>>>>>> file is... ath10k. ASCII85 wins 3 to 1.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> We want the devcoredump file to still be human readable.
>>>>>>>>>>>>>> That won't be the case if you stuff binary data in the
>>>>>>>>>>>>>> middle of it. Most obvious problem - the zeros in the data
>>>>>>>>>>>>>> will terminate your text file at that point. Potentially
>>>>>>>>>>>>>> bigger problem for end users - random fake ANSI codes will
>>>>>>>>>>>>>> destroy your terminal window if you try to cat the file to
>>>>>>>>>>>>>> read it.
>>>>>>>>>>>>> Users don't get a coredump and cat it to the terminal.
>>>>>>>>>>>>> =(lk%A8`T7AKYH#FD,6++EqOABHUhsG%5H2ARoq#E$/V$Bl7Q+@<5pmBe<q;Bk;0mCj@.3DIal2FD5Q-+E_RBART+X@VfTuGA2/4Dfp.E@3BN0DfB9.+E1b0F(KAV+:8
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Lucas De Marchi
>>>>>>>>>>>> They might. Either intentionally or accidentally. I've certainly
>>>>>>>>>>>> done it myself. And people will certainly want to look at it in
>>>>>>>>>>>> any random choice of text editor, pager, etc. 'cos you know, it
>>>>>>>>>>>> is meant to be read by humans. If it is full of binary data then
>>>>>>>>>>>> that becomes even more difficult than simply being full of ASCII
>>>>>>>>>>>> gibberish. No matter what you are doing, the ASCII version is
>>>>>>>>>>>> safer and easier to look at the rest of the file around it.
>>>>>>>>>>>>
>>>>>>>>>>>> I don't understand why you are so desperate to have raw binary
>>>>>>>>>>>> data in the middle of a text file. The disadvantages are
>>>>>>>>>>>> multiple but the only advantage is a slightly smaller file. And
>>>>>>>>>>>> the true route to smaller files is to add compression like we
>>>>>>>>>>>> have in i915.
>>>>>>>>>>>>
>>>>>>>>>>>> John.
>>>>>>>>>>>>
>>>>>>>>>>> PS: Also meant to add that one of the important uses cases for
>>>>>>>>>>> dumping logs to dmesg is for the really hard to repro bugs that
>>>>>>>>>>> show up in CI extremely rarely. We get the driver to dump an error
>>>>>>>>>>> capture to dmesg and pull that out from the CI logs. Even if you
>>>>>>>>>>> could get binary data through dmesg, pretty sure the CI tools
>>>>>>>>>>> would also not be happy with it. Anything non-printable will get
>>>>>>>>>>> munged for sure when turning it into a web page.
>>>>>>>>>> I think that's the main source of confusion on what we are discussing.
>>>>>>>>>> I was not talking about dmesg at all. I'm only complaining about feeding
>>>>>>>>>> ascii85-encoded data into a *devcoredump* when apparently there isn't a
>>>>>>>>>> good reason to do so. I'd rather copy the binary data to the
>>>>>>>>>> devcoredump.
>>>>>>>>> But the intent is to dump a devcoredump to dmesg. It makes much sense
>>>>>>>> It seems like an awful idea to dump hundreds of MB to dmesg. When we
>>>>>>>> talked about printing to dmesg it was about **GuC log** and on very
>>>>>>>> initial states of driver probe where we didn't actually have a good
>>>>>>>> interface for that. And the log wouldn't be so big. If we can already
>>>>>>>> capture the devcoredump, what would be the reason to dump to dmesg
>>>>>>>> (other than the non-valid "our CI captures dmesg, and doesn't
>>>>>>>> capture devcoredump", which should be fixed).
>>>>>>>>
>>>>>>>> If any sysadmin have their serial console flooded by such garbage there
>>>>>>>> are 2 reactions: 1) someone got in control of my machine; 2) something
>>>>>>>> went really bad with this machine. It's not "fear not, wait for it to
>>>>>>>> complete, it's just normal debug data I will attach to an issue in
>>>>>>>> gitlab". And I'm mentioning a serial console here due to that
>>>>>>>> cond_resched() added, which is only needed because you are trying to do
>>>>>>>> in kernel space what should be in userspace.
>>>>>>>>
>>>>>>>> Oh well... looking at this the main reason to use ascii85 I can see is
>>>>>>>> because we already have parts of *our* devcoredump using it, and
>>>>>>>> userspace relying on that. That's new to me. Let's stop bringing dmesg
>>>>>>>> into this discussion.
>>>>>>>>
>>>>>>>>> to have a single implementation that can be used for multiple
>>>>>>>>> purposes. Otherwise you are duplicating a lot of code unnecessarily.
>>>>>>>>>
>>>>>>>>> And I still think it is a *very* bad idea to be including binary data
>>>>>>>>> in a text file. The devcoredump is supposed to be human readable. It
>>>>>>>> no, it's not. devcoredump doesn't dictate the format, it's up to the
>>>>>>>> drivers to do that. See their documentation.
>>>>>>>>
>>>>>>>>> is supposed to be obtained by end users and passed around. Having
>>>>>>>>> binary data in there just makes everything more complex and error
>>>>>>>>> prone. We want this to be as simple, easy and safe as possible.
>>>>>>>>>
>>>>>>>>>> For dmesg, there's a reason to encode it as you pointed out... but
>>>>>>>>>> no users shouldn't actually see it - we should be getting all of those
>>>>>>>>>> cases in CI. For the escape scenarios, yeah... better having it
>>>>>>>>>> ascii85-encoded.
>>>>>>>>>>
>>>>>>>>>> What you are adding to devcoredump also doesn't even seem to be an
>>>>>>>>>> ascii85 representation, but a multiple lines that should be concatenated
>>>>>>>>>> to form the ascii85 representation. For dmesg it makes sense. Not for
>>>>>>>>>> devcoredump. We should also probabaly need a length field (correctly
>>>>>>>>>> accounting for the additional characters for each line) so we don't
>>>>>>>>>> have an implicit dependency on what's the next field to know how much to
>>>>>>>>>> parse.
>>>>>>>>> The decoding is pretty trivial given that line feeds are not part of
>>>>>>>>> the ASCII85 character set and so can just be dropped. Besides The
>>>>>>>>> output is already not 'pure' ASCII85 because the ASCII85 data is
>>>>>>>>> embedded within a devcoredump. There is all sorts of other text about,
>>>>>>>>> including on the start of the line. There are multiple ASCII85 blobs
>>>>>>>>> in there that need to be decoded separately. This is nothing new to my
>>>>>>>>> patch set. All of that is already there. And as per comments on the
>>>>>>>>> previous devcoredump patches from Matthew B, the object data can many
>>>>>>>>> hundreds of MBs in size. Yet no-one batted an eyelid when that was
>>>>>>>>> added. So why the sudden paranoia about adding a couple of MB of GuC
>>>>>>>>> log in the same form?
>>>>>>>> I suppose you are talking about commit 4d5242a003bb ("drm/xe: Implement capture of
>>>>>>>> HWSP and HWCTX"). Probably because I haven't seen that commit doing an
>>>>>>>> ascii85 encoding before, otherwise I'd have similar review feedback.
>>>>>>>>
>>>>>>>> Looking at this just now, so I will also have to balance the previous
>>>>>>>> users and existing userspace consuming it.
>>>>>>>>
>>>>>>>> +José, would it be ok from the userspace POV to start adding the \n?
>>>>>>>> Then we can at least have all fields in our devcoredump to follow the
>>>>>>>> same format. Are these the decoder parts on the mesa side?
>>>>>>>>
>>>>>>>> src/intel/tools/aubinator_error_decode.c
>>>>>>>> src/intel/tools/error2hangdump.c?
>>>>>>>>
>>>>>>>> From a quick look, read_xe_data_file() already continues the previous
>>>>>>>> topic when it reads a newline, but the parsers for HWCTX and HWSP
>>>>>>>> seems to expect to to have the entire topic in a single line. But I may
>>>>>>>> be missing something.
>>>>>>> Sorry I'm not following up this thread.
>>>>>>> Add a '\n' where exactly?
>>>>>> To break very long ASCII85 streams across multiple lines. That will
>>>>>> allow the devcoredump file to output via dmesg for the situations where
>>>>>> reading from sysfs is not possible.
>>>>>>
>>>>>> This patch is adding an ASCII85 encoding helper that is more friendly to
>>>>>> output via dmesg. The patch does not currently change the existing
>>>>>> ASCII85 encodings of VMs and hw contexts. However, the intention would
>>>>>> be to update that code to use this helper eventually.
>>>>> It will break the parser and I don't think we are allowed to break it at this point.
>>>> The intent has always been to add compression as we had in i915. That will
>>>> presumably also break the parser. Although I'm not seeing how a debug log
>>>> parser counts as critical user space that must not ever be broken.
>>> We shouldn't be breaking the current userspace tools. Any change like this would
>>> need to be synchronized between all the current decode tools.
>> That is why the comment was 'eventually we would like to'. Nothing in this
>> patch will break a user tool unless that tool cannot cope with new data
>> being added to the core dump. And if we can't add new stuff to core dumps
>> then again, we are fundamentally broken.
>>
>>>>> What I can suggest is add another sysfs with a coredump that skips the binary dumps so it is readable by humans.
>>>> That will just lead to confusion and problems with people sending the wrong
>>>> file. This needs to be kept as simple and error-proof as possible.
>>> Perhaps it is time for us to convince devcoredump folks to accept
>>> multiple files like nvme folks were asking a while ago? [1]
>>>
>>> [1] - https://lore.kernel.org/lkml/1557676457-4195-4-git-send-email-akinobu.mita@gmail.com/
>> Is that likely to happen any time soon? That thread was from May 2019. We
>> need something now. And it's not clear if that is adding a filing system
>> within a single core dump file (i.e. read one file from sysfs and then
>> extract later like a tarball) or creating multiple sysfs files that all must
>> be read together and passed around together. I would strongly advise against
>> the latter. As I said already, the whole coredump thing needs to be as
>> simple and easy to use as possible.
>>
>> If more official support is added to devcoredump itself in some number of
>> years time and is actually beneficial, then we can move over to using that
>> interface (and break the user land tools again...). But until then, this
>> version works with the least amount of disruption for significant benefit.
>> I.e., it lets us actually debug problems right now.
>>
>> John.
>>
>>
>>>> John.
>>>>
>>>>>> John.
>>>>>>
>>>>>>>> Lucas De Marchi
>>>>>>>>
>>>>>>>>> And again, arbitrarily long lines (potentially many thousands of
>>>>>>>>> characters wide) in a text file can cause problems. Having it line
>>>>>>>>> wrapped gets rid of those potential problems and so is safer. Anything
>>>>>>>>> that reduces the risk of an error report being broken is a good thing
>>>>>>>>> IMHO. Robustness is worthwhile!
>>>>>>>>>
>>>>>>>>> John.
>>>>>>>>>
>>>>>>>>>> Lucas De Marchi
>>>>>>>>>>
>>>>>>>>>>> John.
>>>>>>>>>>>
^ permalink raw reply [flat|nested] 54+ messages in thread
end of thread, other threads:[~2024-09-16 17:47 UTC | newest]
Thread overview: 54+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-09-05 20:50 [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump John.C.Harrison
2024-09-05 20:50 ` [PATCH v7 01/10] drm/xe/guc: Remove spurious line feed in debug print John.C.Harrison
2024-09-10 19:32 ` Julia Filipchuk
2024-09-05 20:50 ` [PATCH v7 02/10] drm/xe/devcoredump: Add a section heading for the submission backend John.C.Harrison
2024-09-10 19:33 ` Julia Filipchuk
2024-09-05 20:50 ` [PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function John.C.Harrison
2024-09-06 1:54 ` Lucas De Marchi
2024-09-06 2:01 ` John Harrison
2024-09-06 3:04 ` Lucas De Marchi
2024-09-07 2:06 ` John Harrison
2024-09-10 1:31 ` John Harrison
2024-09-10 19:43 ` Lucas De Marchi
2024-09-10 20:17 ` John Harrison
2024-09-11 19:12 ` Lucas De Marchi
2024-09-11 19:30 ` Souza, Jose
2024-09-11 19:35 ` John Harrison
2024-09-11 19:54 ` Souza, Jose
2024-09-11 19:59 ` John Harrison
2024-09-12 13:57 ` Rodrigo Vivi
2024-09-12 18:06 ` John Harrison
2024-09-16 15:32 ` Rodrigo Vivi
2024-09-16 17:46 ` John Harrison
2024-09-11 19:31 ` John Harrison
2024-09-10 19:33 ` Julia Filipchuk
2024-09-11 1:27 ` John Harrison
2024-09-05 20:50 ` [PATCH v7 04/10] drm/xe/guc: Copy GuC log prior to dumping John.C.Harrison
2024-09-11 0:48 ` Julia Filipchuk
2024-09-05 20:51 ` [PATCH v7 05/10] drm/xe/guc: Use a two stage dump for GuC logs and add more info John.C.Harrison
2024-09-11 0:48 ` Julia Filipchuk
2024-09-11 1:14 ` John Harrison
2024-09-05 20:51 ` [PATCH v7 06/10] drm/print: Introduce drm_line_printer John.C.Harrison
2024-09-05 20:51 ` [PATCH v7 07/10] drm/xe/guc: Dead CT helper John.C.Harrison
2024-09-11 0:09 ` John Harrison
2024-09-11 19:55 ` Julia Filipchuk
2024-09-11 20:13 ` John Harrison
2024-09-11 20:57 ` Julia Filipchuk
2024-09-05 20:51 ` [PATCH v7 08/10] drm/xe/guc: Dump entire CTB on errors John.C.Harrison
2024-09-11 20:12 ` Julia Filipchuk
2024-09-05 20:51 ` [PATCH v7 09/10] drm/xe/guc: Add GuC log to devcoredump captures John.C.Harrison
2024-09-11 20:25 ` Julia Filipchuk
2024-09-05 20:51 ` [PATCH v7 10/10] drm/xe/guc: Add a helper function for dumping GuC log to dmesg John.C.Harrison
2024-09-11 20:36 ` Julia Filipchuk
2024-09-11 20:41 ` John Harrison
2024-09-05 20:57 ` ✓ CI.Patch_applied: success for drm/xe/guc: Improve GuC log dumping and add to devcoredump (rev2) Patchwork
2024-09-05 20:57 ` ✗ CI.checkpatch: warning " Patchwork
2024-09-05 20:58 ` ✓ CI.KUnit: success " Patchwork
2024-09-05 21:10 ` ✓ CI.Build: " Patchwork
2024-09-05 21:13 ` ✓ CI.Hooks: " Patchwork
2024-09-05 21:14 ` ✗ CI.checksparse: warning " Patchwork
2024-09-05 22:06 ` ✗ CI.BAT: failure " Patchwork
2024-09-08 0:02 ` ✗ CI.FULL: " Patchwork
2024-09-12 9:16 ` [PATCH v7 00/10] drm/xe/guc: Improve GuC log dumping and add to devcoredump Jani Nikula
2024-09-12 18:50 ` John Harrison
2024-09-13 7:26 ` Jani Nikula
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox