Re: [PATCH] drm: Funnel drm logs to tracepoints

From: Sean Paul <sean@poorly.run>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@linux.ie>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Sean Paul <seanpaul@chromium.org>, Sean Paul <sean@poorly.run>
Subject: Re: [PATCH] drm: Funnel drm logs to tracepoints
Date: Wed, 16 Oct 2019 11:55:35 -0400	[thread overview]
Message-ID: <20191016155535.GX85762@art_vandelay> (raw)
In-Reply-To: <d6b47400-c254-4f6b-5fac-59693571dee0@suse.de>

On Wed, Oct 16, 2019 at 03:23:45PM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 16.10.19 um 15:05 schrieb Pekka Paalanen:
> > On Wed, 16 Oct 2019 00:35:39 +0200
> > Daniel Vetter <daniel.vetter@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?
> 
> I'm running Tumbleweed where debugfs is mounted by default for root. I
> could live having the user to mount debugfs to get the file's content.
> 
> > 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.
> 
> Has this ever worked? As soon as a userspace program starts depending on
> the content of this file, it becomes kabi. From the incidents I know,
> Linus has always been quite strict about this. Even for broken interfaces.
> 

I think at this point I've convinced myself to spend the time to add proper
stable event traces to the atomic core + helpers (dp/self refresh/hdcp/etc).
It's going to be a pain (I really hate how much boilerplate is involved in
adding just one event), but I think there's enough interest that it'll be
worth it.

If it turns out to be useful, we can dig into some of the drivers as well.

Sean

> > 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.
> 
> Agreed.
> 
> Best regards
> Thomas
> 
> > 
> > 
> > Thanks,
> > pq
> > 
> 
> -- 
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel