[PATCH i-g-t v1 0/4] RFC: Create smaller dmesg reports for a test

[PATCH i-g-t v1 0/4] RFC: Create smaller dmesg reports for a test

[Kamil Konieczny]

  Inform igt_runner about some lines in dmesg which could be
safely skipped during creating a results.json.

  With this, runner will also lift dmesg size limit for current
test and will postpone size fitting to last phase of a run when
it will generate json report.

TODO: This is draft which implements only lines skipping, without
any reporting what was done. Also, implementation for a fail path
when applied regex will not lower resulting demsg is left for
future.

Cc: Sobin Thomas <sobin.thomas@intel.com>
Cc: Ryszard Knop <ryszard.knop@intel.com>
Cc: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>

Kamil Konieczny (4):
  runner/executor: Create temporary unlimited dmesg save
  lib/igt_core: Create message for runner with unlimiting dmesg size
  tests/intel/xe_exec_system_allocator: Lower dmesg size collected
  runner/resultgen: Create smaller dmesg report by dropping lines
    matched with skip regex

 lib/igt_core.c                         | 31 +++++++++++++++++++
 lib/igt_core.h                         |  1 +
 runner/executor.c                      | 43 ++++++++++++++++----------
 runner/output_strings.h                |  8 +++++
 runner/resultgen.c                     | 17 ++++++++--
 tests/intel/xe_exec_system_allocator.c |  1 +
 6 files changed, 83 insertions(+), 18 deletions(-)

-- 
2.54.0

[PATCH i-g-t v1 1/4] runner/executor: Create temporary unlimited dmesg save

[Kamil Konieczny]

Scan incoming dmesg message for '[IGT] ulimit' and if seen lift
disk limit for this particular test. Later on results will take
following params and create a report within limits, either by
dropping lines matched by regex or by taking only a few
important parts from it.

Signed-off-by: Kamil Konieczny <kamil.konieczny@linux.intel.com>
---
 runner/executor.c | 43 +++++++++++++++++++++++++++----------------
 1 file changed, 27 insertions(+), 16 deletions(-)

diff --git a/runner/executor.c b/runner/executor.c
index 847abe481..a95d278bd 100644
--- a/runner/executor.c
+++ b/runner/executor.c
@@ -638,7 +638,7 @@ const char *get_out_filename(int fid)
 }
 
 /* Returns the number of bytes written to disk, or a negative number on error */
-static long dump_dmesg(int kmsgfd, int outfd, ssize_t size)
+static long dump_dmesg(int kmsgfd, int outfd, ssize_t size, bool *ulimit)
 {
 	/*
 	 * Write kernel messages to the log file until we reach
@@ -653,7 +653,7 @@ static long dump_dmesg(int kmsgfd, int outfd, ssize_t size)
 	unsigned long long seq, cmpseq, usec;
 	bool underflow_once = false;
 	char cont;
-	char buf[2048];
+	char buf[4096];
 	ssize_t r;
 	long written = 0;
 
@@ -690,7 +690,7 @@ static long dump_dmesg(int kmsgfd, int outfd, ssize_t size)
 			}
 		}
 
-		r = read(kmsgfd, buf, sizeof(buf));
+		r = read(kmsgfd, buf, sizeof(buf) - 1);
 		if (r < 0) {
 			if (errno == EPIPE) {
 				if (!underflow_once) {
@@ -714,6 +714,10 @@ static long dump_dmesg(int kmsgfd, int outfd, ssize_t size)
 		write(outfd, buf, r);
 		written += r;
 
+		buf[r] = '\0';
+		if (strstr(buf, "[IGT] ulimit"))
+			*ulimit = true;
+
 		if (comparefd < 0 && sscanf(buf, "%u,%llu,%llu,%c;",
 					    &flags, &seq, &usec, &cont) == 4) {
 			/*
@@ -820,11 +824,11 @@ static const char *show_kernel_task_state(const char *msg)
 	return msg;
 }
 
-static bool disk_usage_limit_exceeded(struct settings *settings,
+static bool disk_usage_limit_exceeded(size_t disk_limit,
 				      size_t disk_usage)
 {
-	return settings->disk_usage_limit != 0 &&
-		disk_usage > settings->disk_usage_limit;
+	return disk_limit != 0 &&
+		disk_usage > disk_limit;
 }
 
 static const char *need_to_timeout(struct settings *settings,
@@ -833,7 +837,8 @@ static const char *need_to_timeout(struct settings *settings,
 				   double time_since_activity,
 				   double time_since_subtest,
 				   double time_since_kill,
-				   size_t disk_usage)
+				   size_t disk_usage,
+				   size_t disk_limit)
 {
 	int decrease = 1;
 
@@ -896,7 +901,7 @@ static const char *need_to_timeout(struct settings *settings,
 		return show_kernel_task_state("Inactivity timeout exceeded. Killing the current test with SIGQUIT.\n");
 	}
 
-	if (disk_usage_limit_exceeded(settings, disk_usage))
+	if (disk_usage_limit_exceeded(disk_limit, disk_usage))
 		return "Disk usage limit exceeded.\n";
 
 	return NULL;
@@ -984,6 +989,8 @@ static int monitor_output(pid_t child,
 	long dmesgwritten;
 	bool socket_comms_used = false; /* whether the test actually uses comms */
 	bool results_received = false; /* whether we already have test results that might need overriding if we detect an abort condition */
+	bool disk_limit = settings->disk_usage_limit;
+	bool unlimit;
 
 	runner_gettime(&time_beg);
 	time_last_activity = time_last_subtest = time_killed = time_beg;
@@ -1307,9 +1314,13 @@ static int monitor_output(pid_t child,
 	socket_end:
 
 		if (kmsgfd >= 0 && FD_ISSET(kmsgfd, &set)) {
+			unlimit = false;
 			time_last_activity = time_now;
 
-			dmesgwritten = dump_dmesg(kmsgfd, outputs[_F_DMESG], dmsg_chunk_size);
+			dmesgwritten = dump_dmesg(kmsgfd, outputs[_F_DMESG], dmsg_chunk_size, &unlimit);
+			if (unlimit)
+				disk_limit = 0;
+
 			if (settings->sync)
 				fdatasync(outputs[_F_DMESG]);
 
@@ -1462,7 +1473,7 @@ static int monitor_output(pid_t child,
 				 * Same goes for stopping because we
 				 * exceeded the disk usage limit.
 				 */
-				if (killed && disk_usage_limit_exceeded(settings, disk_usage)) {
+				if (killed && disk_usage_limit_exceeded(disk_limit, disk_usage)) {
 					timeoutresult = false;
 
 					if (socket_comms_used) {
@@ -1537,7 +1548,7 @@ static int monitor_output(pid_t child,
 						 igt_time_elapsed(&time_last_activity, &time_now),
 						 igt_time_elapsed(&time_last_subtest, &time_now),
 						 igt_time_elapsed(&time_killed, &time_now),
-						 disk_usage);
+						 disk_usage, disk_limit);
 
 		if (timeout_reason) {
 			if (killed == SIGKILL) {
@@ -1552,8 +1563,8 @@ static int monitor_output(pid_t child,
 					asprintf(abortreason, "Child refuses to die, tainted 0x%lx.", taints);
 				}
 
-				dmsg_chunk_size = calc_last_dmesg_chunk(settings->disk_usage_limit, disk_usage);
-				dump_dmesg(kmsgfd, outputs[_F_DMESG], dmsg_chunk_size);
+				dmsg_chunk_size = calc_last_dmesg_chunk(disk_limit, disk_usage);
+				dump_dmesg(kmsgfd, outputs[_F_DMESG], dmsg_chunk_size, &unlimit);
 				if (settings->sync)
 					fdatasync(outputs[_F_DMESG]);
 
@@ -1583,13 +1594,13 @@ static int monitor_output(pid_t child,
 		}
 	}
 
-	dmsg_chunk_size = calc_last_dmesg_chunk(settings->disk_usage_limit, disk_usage);
-	dmesgwritten = dump_dmesg(kmsgfd, outputs[_F_DMESG], dmsg_chunk_size);
+	dmsg_chunk_size = calc_last_dmesg_chunk(disk_limit, disk_usage);
+	dmesgwritten = dump_dmesg(kmsgfd, outputs[_F_DMESG], dmsg_chunk_size, &unlimit);
 	if (settings->sync)
 		fdatasync(outputs[_F_DMESG]);
 	if (dmesgwritten > 0) {
 		disk_usage += dmesgwritten;
-		if (settings->disk_usage_limit && disk_usage > settings->disk_usage_limit) {
+		if (disk_limit && disk_usage > disk_limit) {
 			char disk[1024];
 
 			snprintf(disk, sizeof(disk), "igt_runner: disk limit exceeded at dmesg dump, %zu > %zu\n", disk_usage, settings->disk_usage_limit);
-- 
2.54.0

[PATCH i-g-t v1 2/4] lib/igt_core: Create message for runner with unlimiting dmesg size

[Kamil Konieczny]

Create a way to communicate to runner that test or subtest want
to lift disk limit size collected in a run and delays size limit
fitting to results processing.

Signed-off-by: Kamil Konieczny <kamil.konieczny@linux.intel.com>
---
 lib/igt_core.c | 31 +++++++++++++++++++++++++++++++
 lib/igt_core.h |  1 +
 2 files changed, 32 insertions(+)

diff --git a/lib/igt_core.c b/lib/igt_core.c
index 72b7d3449..e0f6eb969 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -3606,6 +3606,37 @@ void igt_emit_ignore_dmesg_regex(const char *ignore_dmesg_regex)
 	igt_kmsg(KMSG_INFO "%s%s\n", mark_ignore_dmesg, ignore_dmesg_regex);
 }
 
+/**
+ * igt_emit_ulimit_dmesg:
+ * @begin_size: size of a beginning part
+ * @end_size: size of an ending part
+ * @ignore_dmesg_regex: string regex
+ *
+ * Emits a string '[IGT] ulimit' in demsg for igt_runner to ignore dmesg disk
+ * size limit for one test. Later on results will filter out matched regex to
+ * reduce its size in report.json. If that will not be enough, results will
+ * further reduce it under a desired disk limit. Regex parameter should be a
+ * last one emited. User could use begin and end sizes to reduce it more for
+ * this particular test (zero means no reduction).
+ */
+void igt_emit_ulimit_dmesg(const size_t begin_size, const size_t end_size, const char *ignore_dmesg_regex)
+{
+	static const char ulimit[] = "ulimit"; /* [IGT] ulimit ... params */
+	GError *err = NULL;
+	GRegex *re;
+
+	re = g_regex_new(ignore_dmesg_regex, G_REGEX_OPTIMIZE, 0, &err);
+	if (err) {
+		igt_debug("regexp: '%s'\n", err->message);
+		g_error_free(err);
+		igt_assert_f(re, "Error in regexp\n");
+	}
+
+	g_regex_unref(re);
+	igt_kmsg(KMSG_INFO "%s size_start=%ld size_end=%ld regex: %s\n", ulimit,
+		 begin_size, end_size, ignore_dmesg_regex);
+}
+
 /**
  * @igt_measured_usleep: Helper to model accurate sleep time for tests
  * @usec: usec to sleep
diff --git a/lib/igt_core.h b/lib/igt_core.h
index 9fe3997e7..d8e0249ee 100644
--- a/lib/igt_core.h
+++ b/lib/igt_core.h
@@ -1643,6 +1643,7 @@ int igt_pci_system_reinit(void);
 void igt_pci_system_cleanup(void);
 
 void igt_emit_ignore_dmesg_regex(const char *ignore_dmesg_regex);
+void igt_emit_ulimit_dmesg(const size_t begin_size, const size_t end_size, const char *ignore_dmesg_regex);
 
 unsigned int igt_measured_usleep(unsigned int usec);
 
-- 
2.54.0

[PATCH i-g-t v1 3/4] tests/intel/xe_exec_system_allocator: Lower dmesg size collected

[Kamil Konieczny]

Allow igt_runner to lower dmesg size collected during a run.
This will drop lines matched with regex, also in success runs
only small 4KB portion of beginning and end will be collected.

Signed-off-by: Kamil Konieczny <kamil.konieczny@linux.intel.com>
---
 tests/intel/xe_exec_system_allocator.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/intel/xe_exec_system_allocator.c b/tests/intel/xe_exec_system_allocator.c
index 0f1d6ee9c..1f1482a97 100644
--- a/tests/intel/xe_exec_system_allocator.c
+++ b/tests/intel/xe_exec_system_allocator.c
@@ -2565,6 +2565,7 @@ int igt_main()
 		va_bits = xe->va_bits;
 		open_sync_file();
 		dev_id = intel_get_drm_devid(fd);
+		igt_emit_ulimit_dmesg(4096, 4096, "drm:drm_pagemap_migrate_to_devmem|Skipping madvise reset for vma");
 	}
 
 	for (const struct section *s = sections; s->name; s++) {
-- 
2.54.0

[PATCH i-g-t v1 4/4] runner/resultgen: Create smaller dmesg report by dropping lines matched with skip regex

[Kamil Konieczny]

Tests can skip some messages to keep generated dmesg report
under disk limit size.

Signed-off-by: Kamil Konieczny <kamil.konieczny@linux.intel.com>
---
 runner/output_strings.h |  8 ++++++++
 runner/resultgen.c      | 17 +++++++++++++++--
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/runner/output_strings.h b/runner/output_strings.h
index 91ef5f2c3..943fb67a6 100644
--- a/runner/output_strings.h
+++ b/runner/output_strings.h
@@ -62,6 +62,14 @@ static const char STARTING_DYNAMIC_SUBTEST_DMESG[] = ": starting dynamic subtest
  */
 static const char IGT_ADD_IGNORED_REGEX_DMESG[] = "add ignored dmesg regex: ";
 
+/*
+ * Output in dmesg when a test wants runner to dynamically ignore disklimit.
+ *
+ * Example:
+ * [IGT] ulimit ...params... regex: Skipping madvise reset for vma
+ */
+static const char IGT_ADD_IGNORE_LIMIT_REGEX_DMESG[] = "ulimit";
+
 /*
  * Output when a test process is executed.
  *
diff --git a/runner/resultgen.c b/runner/resultgen.c
index 29fc5cbb1..f4c16ee75 100644
--- a/runner/resultgen.c
+++ b/runner/resultgen.c
@@ -1008,6 +1008,7 @@ static bool fill_from_dmesg(int fd,
 	size_t i;
 	GRegex *re;
 	GRegex *re_ignore; /* regex for dynamically ignored dmesg line */
+	GRegex *re_skip; /* regex for dynamically skipping dmesg line */
 
 	if (!f) {
 		return false;
@@ -1019,6 +1020,7 @@ static bool fill_from_dmesg(int fd,
 	}
 
 	re_ignore = NULL;
+	re_skip = NULL;
 	while (getline(&line, &linelen, f) > 0) {
 		char *formatted;
 		unsigned flags;
@@ -1078,6 +1080,12 @@ static bool fill_from_dmesg(int fd,
 		if ((ignore = strstr(message, IGT_ADD_IGNORED_REGEX_DMESG)) != NULL)
 			add_ignored_regex(&re_ignore, ignore + strlen(IGT_ADD_IGNORED_REGEX_DMESG));
 
+		if ((ignore = strstr(message, IGT_ADD_IGNORE_LIMIT_REGEX_DMESG)) != NULL) {
+			ignore = strstr(message, "regex: ");
+			add_ignored_regex(&re_skip, ignore + strlen("regex: "));
+			/* TODO: implement rest of params */
+		}
+
 		if (settings->piglit_style_dmesg) {
 			if ((flags & 0x07) <= settings->dmesg_warn_level && continuation != 'c' &&
 			    g_regex_match(re, message, 0, NULL) &&
@@ -1095,8 +1103,12 @@ static bool fill_from_dmesg(int fd,
 					append_line(&dynamic_warnings, &dynamic_warnings_len, formatted);
 			}
 		}
-		append_line(&dmesg, &dmesglen, formatted);
-		append_line(&dynamic_dmesg, &dynamic_dmesg_len, formatted);
+
+		if (not_ignored(re_skip, message)) {
+			append_line(&dmesg, &dmesglen, formatted);
+			append_line(&dynamic_dmesg, &dynamic_dmesg_len, formatted);
+		}
+
 		free(formatted);
 	}
 	free(line);
@@ -1137,6 +1149,7 @@ static bool fill_from_dmesg(int fd,
 	free(warnings);
 	free(dynamic_warnings);
 	clean_regex(&re_ignore);
+	clean_regex(&re_skip);
 	g_regex_unref(re);
 	fclose(f);
 	return true;
-- 
2.54.0

Re: [PATCH i-g-t v1 0/4] RFC: Create smaller dmesg reports for a test

[Knop, Ryszard]

IMO this is going to end up either unused, and people will keep
complaining they want a higher limit anyways, or overused, and people
will complain why some of their logs are randomly missing from CI logs.

In general it seems like this does not break the CI infra directly, so
I won't say no to anything here, but it's one of those things that dial
up the magic and we seem to have lots of that in disk limits recently.

Ryszard

On Wed, 2026-05-20 at 17:49 +0200, Kamil Konieczny wrote:
>   Inform igt_runner about some lines in dmesg which could be
> safely skipped during creating a results.json.
> 
>   With this, runner will also lift dmesg size limit for current
> test and will postpone size fitting to last phase of a run when
> it will generate json report.
> 
> TODO: This is draft which implements only lines skipping, without
> any reporting what was done. Also, implementation for a fail path
> when applied regex will not lower resulting demsg is left for
> future.
> 
> Cc: Sobin Thomas <sobin.thomas@intel.com>
> Cc: Ryszard Knop <ryszard.knop@intel.com>
> Cc: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
> 
> Kamil Konieczny (4):
>   runner/executor: Create temporary unlimited dmesg save
>   lib/igt_core: Create message for runner with unlimiting dmesg size
>   tests/intel/xe_exec_system_allocator: Lower dmesg size collected
>   runner/resultgen: Create smaller dmesg report by dropping lines
>     matched with skip regex
> 
>  lib/igt_core.c                         | 31 +++++++++++++++++++
>  lib/igt_core.h                         |  1 +
>  runner/executor.c                      | 43 ++++++++++++++++----------
>  runner/output_strings.h                |  8 +++++
>  runner/resultgen.c                     | 17 ++++++++--
>  tests/intel/xe_exec_system_allocator.c |  1 +
>  6 files changed, 83 insertions(+), 18 deletions(-)

Re: [PATCH i-g-t v1 0/4] RFC: Create smaller dmesg reports for a test

[Jani Nikula]

On Fri, 29 May 2026, "Knop, Ryszard" <ryszard.knop@intel.com> wrote:
> IMO this is going to end up either unused, and people will keep
> complaining they want a higher limit anyways, or overused, and people
> will complain why some of their logs are randomly missing from CI logs.
>
> In general it seems like this does not break the CI infra directly, so
> I won't say no to anything here, but it's one of those things that dial
> up the magic and we seem to have lots of that in disk limits recently.

Overall seems like there are a number of hacky approaches being added,
e.g. tweaking of the drm.debug parameter value, and filtering parts of
the dmesg.

Debugging issues is often seriously difficult even with the full
dmesg. Having an imcomplete dmesg makes everything more difficult. And
it's the worst if you don't even know that when looking at the dmesg.

We could *maybe* discuss reducing the stored dmesgs for tests that
passed. Or reduce the time the dmesgs are stored for passed dmesgs. But
even then it's often useful to see the passed results when debugging
failed results.

But no matter what, full dmesgs should be the standard for failed tests,
and nothing less is acceptable.


BR,
Jani.


>
> Ryszard
>
> On Wed, 2026-05-20 at 17:49 +0200, Kamil Konieczny wrote:
>>   Inform igt_runner about some lines in dmesg which could be
>> safely skipped during creating a results.json.
>> 
>>   With this, runner will also lift dmesg size limit for current
>> test and will postpone size fitting to last phase of a run when
>> it will generate json report.
>> 
>> TODO: This is draft which implements only lines skipping, without
>> any reporting what was done. Also, implementation for a fail path
>> when applied regex will not lower resulting demsg is left for
>> future.
>> 
>> Cc: Sobin Thomas <sobin.thomas@intel.com>
>> Cc: Ryszard Knop <ryszard.knop@intel.com>
>> Cc: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
>> 
>> Kamil Konieczny (4):
>>   runner/executor: Create temporary unlimited dmesg save
>>   lib/igt_core: Create message for runner with unlimiting dmesg size
>>   tests/intel/xe_exec_system_allocator: Lower dmesg size collected
>>   runner/resultgen: Create smaller dmesg report by dropping lines
>>     matched with skip regex
>> 
>>  lib/igt_core.c                         | 31 +++++++++++++++++++
>>  lib/igt_core.h                         |  1 +
>>  runner/executor.c                      | 43 ++++++++++++++++----------
>>  runner/output_strings.h                |  8 +++++
>>  runner/resultgen.c                     | 17 ++++++++--
>>  tests/intel/xe_exec_system_allocator.c |  1 +
>>  6 files changed, 83 insertions(+), 18 deletions(-)

-- 
Jani Nikula, Intel

Re: [PATCH i-g-t v1 0/4] RFC: Create smaller dmesg reports for a test

[Ville Syrjälä]

On Fri, May 29, 2026 at 03:52:13PM +0300, Jani Nikula wrote:
> On Fri, 29 May 2026, "Knop, Ryszard" <ryszard.knop@intel.com> wrote:
> > IMO this is going to end up either unused, and people will keep
> > complaining they want a higher limit anyways, or overused, and people
> > will complain why some of their logs are randomly missing from CI logs.
> >
> > In general it seems like this does not break the CI infra directly, so
> > I won't say no to anything here, but it's one of those things that dial
> > up the magic and we seem to have lots of that in disk limits recently.
> 
> Overall seems like there are a number of hacky approaches being added,
> e.g. tweaking of the drm.debug parameter value, and filtering parts of
> the dmesg.
> 
> Debugging issues is often seriously difficult even with the full
> dmesg. Having an imcomplete dmesg makes everything more difficult. And
> it's the worst if you don't even know that when looking at the dmesg.
> 
> We could *maybe* discuss reducing the stored dmesgs for tests that
> passed. Or reduce the time the dmesgs are stored for passed dmesgs. But
> even then it's often useful to see the passed results when debugging
> failed results.
> 
> But no matter what, full dmesgs should be the standard for failed tests,
> and nothing less is acceptable.

If disk space is the issue then just compress the damn logs.

-- 
Ville Syrjälä
Intel

Re: [PATCH i-g-t v1 0/4] RFC: Create smaller dmesg reports for a test

[Knop, Ryszard]

On Fri, 2026-05-29 at 18:09 +0300, Ville Syrjälä wrote:
> On Fri, May 29, 2026 at 03:52:13PM +0300, Jani Nikula wrote:
> > On Fri, 29 May 2026, "Knop, Ryszard" <ryszard.knop@intel.com> wrote:
> > > IMO this is going to end up either unused, and people will keep
> > > complaining they want a higher limit anyways, or overused, and people
> > > will complain why some of their logs are randomly missing from CI logs.
> > > 
> > > In general it seems like this does not break the CI infra directly, so
> > > I won't say no to anything here, but it's one of those things that dial
> > > up the magic and we seem to have lots of that in disk limits recently.
> > 
> > Overall seems like there are a number of hacky approaches being added,
> > e.g. tweaking of the drm.debug parameter value, and filtering parts of
> > the dmesg.
> > 
> > Debugging issues is often seriously difficult even with the full
> > dmesg. Having an imcomplete dmesg makes everything more difficult. And
> > it's the worst if you don't even know that when looking at the dmesg.
> > 
> > We could *maybe* discuss reducing the stored dmesgs for tests that
> > passed. Or reduce the time the dmesgs are stored for passed dmesgs. But
> > even then it's often useful to see the passed results when debugging
> > failed results.
> > 
> > But no matter what, full dmesgs should be the standard for failed tests,
> > and nothing less is acceptable.
> 
> If disk space is the issue then just compress the damn logs.

The problem is not disk space, the problem is everything that happens
between raw logs being produced and them landing for consumption -
processing, visualization, etc. Right now, if you overdo it, the whole
pipeline blows up, so we *really* don't want to bump the test limit.

This is being reworked so that it's no longer a problem, so once that's
done, we will be able to increase the limit instead of going through
all of this stuff.

Re: [PATCH i-g-t v1 0/4] RFC: Create smaller dmesg reports for a test

[Kamil Konieczny]

Hi Jani,
On 2026-05-29 at 15:52:13 +0300, Jani Nikula wrote:
> On Fri, 29 May 2026, "Knop, Ryszard" <ryszard.knop@intel.com> wrote:
> > IMO this is going to end up either unused, and people will keep
> > complaining they want a higher limit anyways, or overused, and people
> > will complain why some of their logs are randomly missing from CI logs.
> >
> > In general it seems like this does not break the CI infra directly, so
> > I won't say no to anything here, but it's one of those things that dial
> > up the magic and we seem to have lots of that in disk limits recently.

I also do not like this as this could depend on kernel
and debug flags/env vars.

> 
> Overall seems like there are a number of hacky approaches being added,
> e.g. tweaking of the drm.debug parameter value, and filtering parts of
> the dmesg.
> 
> Debugging issues is often seriously difficult even with the full
> dmesg. Having an imcomplete dmesg makes everything more difficult. And
> it's the worst if you don't even know that when looking at the dmesg.

Full logs are still there, at least for Intel CI, in full dmesg.

The idea was to have a begin and end of dmesg for each test, so
if needed a dmesg for particular test could be found from full
one, where by full I mean one for whole run for all tests (link
on results page to dmesgNN.txt) But that recently also have had
its problems, when one from igt_runner was more complete than a
full one. +cc J-P

The problem is that igt_runner do not know about how much logs
could appear in dmesg, so given a disk limit for all runs it
kills a single test when it exceeds it. For some tests it should
kill it sooner, for others it could allow bigger and see a
success instead of incomplete.

For the cases when it fails, it should be enough to have ten
first bugs in dmesg then hundreds? Here also comes non-decidable
dillema when to stop collecting a dmesg, when kernel could
print it indefinitly.

Regards,
Kamil

> 
> We could *maybe* discuss reducing the stored dmesgs for tests that
> passed. Or reduce the time the dmesgs are stored for passed dmesgs. But
> even then it's often useful to see the passed results when debugging
> failed results.
> 
> But no matter what, full dmesgs should be the standard for failed tests,
> and nothing less is acceptable.
> 
> 
> BR,
> Jani.
> 
> 
> >
> > Ryszard
> >
> > On Wed, 2026-05-20 at 17:49 +0200, Kamil Konieczny wrote:
> >>   Inform igt_runner about some lines in dmesg which could be
> >> safely skipped during creating a results.json.
> >> 
> >>   With this, runner will also lift dmesg size limit for current
> >> test and will postpone size fitting to last phase of a run when
> >> it will generate json report.
> >> 
> >> TODO: This is draft which implements only lines skipping, without
> >> any reporting what was done. Also, implementation for a fail path
> >> when applied regex will not lower resulting demsg is left for
> >> future.
> >> 
> >> Cc: Sobin Thomas <sobin.thomas@intel.com>
> >> Cc: Ryszard Knop <ryszard.knop@intel.com>
> >> Cc: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
> >> 
> >> Kamil Konieczny (4):
> >>   runner/executor: Create temporary unlimited dmesg save
> >>   lib/igt_core: Create message for runner with unlimiting dmesg size
> >>   tests/intel/xe_exec_system_allocator: Lower dmesg size collected
> >>   runner/resultgen: Create smaller dmesg report by dropping lines
> >>     matched with skip regex
> >> 
> >>  lib/igt_core.c                         | 31 +++++++++++++++++++
> >>  lib/igt_core.h                         |  1 +
> >>  runner/executor.c                      | 43 ++++++++++++++++----------
> >>  runner/output_strings.h                |  8 +++++
> >>  runner/resultgen.c                     | 17 ++++++++--
> >>  tests/intel/xe_exec_system_allocator.c |  1 +
> >>  6 files changed, 83 insertions(+), 18 deletions(-)
> 
> -- 
> Jani Nikula, Intel

Re: [PATCH i-g-t v1 0/4] RFC: Create smaller dmesg reports for a test

[Kamil Konieczny]

Hi Ville,
On 2026-05-29 at 18:09:30 +0300, Ville Syrjälä wrote:
> On Fri, May 29, 2026 at 03:52:13PM +0300, Jani Nikula wrote:
> > On Fri, 29 May 2026, "Knop, Ryszard" <ryszard.knop@intel.com> wrote:
> > > IMO this is going to end up either unused, and people will keep
> > > complaining they want a higher limit anyways, or overused, and people
> > > will complain why some of their logs are randomly missing from CI logs.
> > >
> > > In general it seems like this does not break the CI infra directly, so
> > > I won't say no to anything here, but it's one of those things that dial
> > > up the magic and we seem to have lots of that in disk limits recently.
> > 
> > Overall seems like there are a number of hacky approaches being added,
> > e.g. tweaking of the drm.debug parameter value, and filtering parts of
> > the dmesg.
> > 
> > Debugging issues is often seriously difficult even with the full
> > dmesg. Having an imcomplete dmesg makes everything more difficult. And
> > it's the worst if you don't even know that when looking at the dmesg.
> > 
> > We could *maybe* discuss reducing the stored dmesgs for tests that
> > passed. Or reduce the time the dmesgs are stored for passed dmesgs. But
> > even then it's often useful to see the passed results when debugging
> > failed results.
> > 
> > But no matter what, full dmesgs should be the standard for failed tests,
> > and nothing less is acceptable.
> 
> If disk space is the issue then just compress the damn logs.
> 

It was tried but failed in CI pipe, where plain text is
expected. +J-P

Regards,
Kamil

> -- 
> Ville Syrjälä
> Intel