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

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

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