On Wed, 16 Oct 2019 00:35:39 +0200 Daniel Vetter <daniel.vetter@xxxxxxxx> 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
Attachment:
pgpwMCdJ8zzVS.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
