[PATCH] drm: Funnel drm logs to tracepoints

[Pekka Paalanen]

On Wed, 16 Oct 2019 00:35:39 +0200
Daniel Vetter <daniel.vetter at ffwll.ch> wrote:

> Yeah I don't think tuning the spam level will ever work. What we need
> is some external input (most likely from the user clicking the "my
> external screen doesn't work" button, or maybe the compositor
> realizing something that should work didn't, or some other thing that
> indicates trouble), and then retroactively capture all
> debug/informational message leading up to doom.
> 
> But without that external "houston we have a problem" input all the
> debug spam is really just spam and unwanted. btw even if we don't spam
> dmesg if we enable too much we might have simply trouble with all the
> printk formatting work we do for nothing. So maybe we need something
> like trace_printk which iirc delays the formatting until the stuff
> actually gets read from the log buffer. Plus trace_printk might make
> it clear enough that it's not stable uapi ... so maybe we do want
> trace_printk in the end?
> 
> Just not really looking forward to reimplementing half the tracing
> infrastructure just for this ...

Hi,

a thought about the UAPI:

Debugfs is not good because it's not supposed to be touched or even
present in production, right? But we want something that will
specifically be available in production. So a new file in some fs
somewhere it should be, and userspace in production can read it at will
to attach to a bug report.

Those semantics, "only use this content for attaching into a bug
report" should be made very clear in the UAPI. Not just the kernel
function names, but in the UAPI that an end user might
see. /proc/driver/drm/bug-report-aid or whatever. And that file, while
a ring buffer, could be aggressively big, intended to be compressed
before sent out with a bug report. Or maybe it comes out as readily
compressed.

The file name itself would be stable UAPI, the contents not at all.

I believe it has to be a ring buffer that is being continuously written
also during normal operations, so that we don't have to ask end users
to reproduce the issue again just to get some logs. Maybe the issue
happens once in a fortnight. The information must be extractable after
the fact, without before-hand preparations.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20191016/6c4431ba/attachment.sig>