[igt-dev] [PATCH i-g-t] lib/kmod: reimplement kmsg_dump()

Chris Wilson chris at chris-wilson.co.uk
Fri Sep 27 22:23:27 UTC 2019


Quoting Lucas De Marchi (2019-09-27 23:20:38)
> On Fri, Sep 27, 2019 at 09:54:00PM +0100, Chris Wilson wrote:
> >Quoting Lucas De Marchi (2019-09-27 21:32:03)
> >> On Fri, Sep 27, 2019 at 01:24:20PM -0700, Lucas De Marchi wrote:
> >> >On Fri, Sep 27, 2019 at 09:09:50PM +0100, Chris Wilson wrote:
> >> >>Quoting Lucas De Marchi (2019-09-20 02:07:23)
> >> >>>Now the line in (1) print as:
> >> >>>        (i915_selftest:5070) igt_kmod-WARNING: [drm:intel_pch_type [i915]] Found Tiger Lake LP PCH
> >> >
> >> >...
> >> >
> >> >>>
> >> >>>This also fixes a double close on fclose() already closes the file
> >> >>>descriptor.
> >> >>>
> >> >>>Signed-off-by: Lucas De Marchi <lucas.demarchi at intel.com>
> >> >>
> >> >>Too bad it doesn't actually work and bails on the first read with EPIPE.
> >> >
> >> >humn... I copy-pasted the line above.
> >> >
> >> >Checking printk.c it will happen if we explode the ringbuffer with log messages
> >> >before actually reading them. You may want to increase the buffer size
> >> >to get them all, but it may make sense to continue on EPIPE since the
> >> >behavior is to reset to the first available message?
> >>
> >> btw AFAICS the previous impl would equally bail out due to getline()
> >> returning -1. Or did I miss anything? (also the default buffer size used
> >> by glibc is the same as the one I'm using here)
> >
> >It's bailing in CI (we've had no output since) and that's the first time
> >I've seen it fail to provide any of the kmsg. Maybe fdopen() is
> >stripping off the O_NONBLOCK?
> 
> O_NONBLOCK shouldn't make a difference. Let me send the patch below
> to see if we paper it over.
> 
> I just tested this by reverting e5de91e68c5c ("Revert "drm/i915/tgl: Implement Wa_1406941453"")
> and running `./build/tests/i915_selftest --run-subtest live_workarounds` on TGL and I do
> get the kmsg (but I have the same behavior without this patch, do).
> 
> I see a failure in CI:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6971/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
> 
> My theory about a huge log seems correct.

But no bigger than they have been.
-Chris


More information about the igt-dev mailing list