On Wed, Nov 08, 2017 at 12:36:32PM +0000, Chris Wilson wrote:
> Quoting Petri Latvala (2017-11-08 12:32:09)
> > On Wed, Nov 08, 2017 at 12:18:40PM +0000, Chris Wilson wrote:
> > > Some debugging information is too voluminous to enable by default, yet
> > > may be invaluable when it comes to post-mortem debugging. trace_printk()
> > > provides the facility for the trace ringbuffer to be dumped on oops,
> > > this way we can cheaply spam the debug log and only present it in case
> > > of emergency.
> > >
> > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > > ---
> > > lib/igt_core.c | 23 +++++++++++++++++++++++
> > > 1 file changed, 23 insertions(+)
> > >
> > > diff --git a/lib/igt_core.c b/lib/igt_core.c
> > > index 538a4472..ba4622d6 100644
> > > --- a/lib/igt_core.c
> > > +++ b/lib/igt_core.c
> > > @@ -561,6 +561,28 @@ static void low_mem_killer_disable(bool disable)
> > > chmod(adj_fname, buf.st_mode);
> > > }
> > >
> > > +/*
> > > + * If the test takes out the machine, in addition to the usual dmesg
> > > + * spam, the kernel may also emit a "death rattle" -- extra debug
> > > + * information that is overkill for normal successful tests, but
> > > + * vital for post-mortem analysis.
> > > + */
> > > +static void ftrace_dump_on_oops(bool enable)
> > > +{
> > > + int fd;
> > > +
> > > + fd = open("/proc/sys/kernel/ftrace_dump_on_oops", O_WRONLY);
> > > + if (fd < 0)
> > > + return;
> > > +
> > > + /*
> > > + * If we fail, we do not get the death rattle we wish, but we
> > > + * still want to run the tests anyway.
> > > + */
> > > + igt_ignore_warn(write(fd, enable ? "1\n" : "0\n", 2));
> > > + close(fd);
> > > +}
> > > +
> > > bool igt_exit_called;
> > > static void common_exit_handler(int sig)
> > > {
> > > @@ -858,6 +880,7 @@ out:
> > > sync();
> > > oom_adjust_for_doom();
> > > low_mem_killer_disable(true);
> > > + ftrace_dump_on_oops(true);
> >
> >
> > Is there a call to disable it too? Or rather, restore the value that
> > was there before executing a test.
>
> No, because I didn't care. If the machine dies after the process
> excited, that death rattle may still be important.
Fair enough, there's indeed no good place where disabling again makes
sense.
Reviewed-by: Petri Latvala <petri.latvala@xxxxxxxxx>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
