From: Johannes Berg <johannes@sipsolutions.net>
To: Daniel Vetter <daniel@ffwll.ch>, "Goel, Akash" <akash.goel@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"Gupta, Sourab" <sourab.gupta@intel.com>
Subject: Re: [RFC 00/12] Support for sustained capturing of GuC firmware logs
Date: Thu, 02 Jun 2016 12:21:49 +0200 [thread overview]
Message-ID: <1464862909.2169.9.camel@sipsolutions.net> (raw)
In-Reply-To: <20160602101618.GE7231@phenom.ffwll.local>
On Thu, 2016-06-02 at 10:16 +0000, Daniel Vetter wrote:
> I still kinda like relayfs, except that it's not available in non-
> debug builds. But so are plenty of other really interesting files we
> have hidden in there.
>
> sysfs isn't the solution, I already have a black eye from the sysfs
> maintainer for our error state.
Heh. I tend to agree though.
> No idea really where to put stuff. One option might be to have an
> official debug directory (like we have power already) in sysfs as the
> canonical place where drivers can dump stuff. We're not the only ones
> with too much data to get to userspace for debugging driver/hw
> issues, e.g. wireless firmware has pretty similar solutions.
We have two things in wireless:
1) the devcoredump stuff, but that's a one-time event when something
bad happens and dumps a big blob into userspace, doesn't seem
relevant here
2) continuous logging, which uses a debugfs file (though it could be
relayfs as well, doesn't really make a difference)
There could be something said for using tracing, but that's only
independent of debugfs since the tracefs introduction in kernel 4.1.
johannes
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-06-02 10:58 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-27 19:42 [RFC 00/12] Support for sustained capturing of GuC firmware logs akash.goel
2016-05-27 19:42 ` [RFC 01/12] drm/i915: Decouple GuC log setup from verbosity parameter akash.goel
2016-05-27 19:42 ` [RFC 02/12] drm/i915: Add GuC ukernel logging related fields to fw interface file akash.goel
2016-05-27 19:42 ` [RFC 03/12] drm/i915: Support for GuC interrupts akash.goel
2016-05-27 19:43 ` Chris Wilson
2016-05-28 8:46 ` Goel, Akash
2016-05-27 19:56 ` Chris Wilson
2016-05-28 9:22 ` Goel, Akash
2016-05-28 12:13 ` Chris Wilson
2016-05-28 13:45 ` Goel, Akash
2016-05-28 14:35 ` Chris Wilson
2016-05-28 17:33 ` Goel, Akash
2016-05-27 19:42 ` [RFC 04/12] drm/i915: Handle log buffer flush interrupt event from GuC akash.goel
2016-05-27 19:42 ` [RFC 05/12] drm/i915: Add a relay backed debugfs interface for capturing GuC logs akash.goel
2016-05-27 19:42 ` [RFC 06/12] drm/i915: Store GuC ukernel logs in the relay buffer akash.goel
2016-05-27 19:42 ` [RFC 07/12] drm/i915: Allocate local buffer to store GuC ukernel logs akash.goel
2016-05-27 19:42 ` [RFC 08/12] drm/i915: Store GuC ukernel logs in the local buffer akash.goel
2016-05-27 19:43 ` [RFC 09/12] drm/i915: Add a char device file interface to capture GuC ukernel logs akash.goel
2016-05-27 19:48 ` Chris Wilson
2016-05-28 8:51 ` Goel, Akash
2016-05-27 19:43 ` [RFC 10/12] drm/i915: Support to capture GuC logs by multiple clients via device file iface akash.goel
2016-05-27 19:43 ` [RFC 11/12] drm/i915: Add sysfs interface to capture the GuC ukernel logs akash.goel
2016-05-27 19:43 ` [RFC 12/12] drm/i915: Forcefully flush GuC log buffer on reset akash.goel
2016-05-28 6:09 ` ✗ Ro.CI.BAT: failure for Support for sustained capturing of GuC firmware logs Patchwork
2016-06-02 10:16 ` [RFC 00/12] " Daniel Vetter
2016-06-02 10:21 ` Johannes Berg [this message]
2016-06-03 7:15 ` Daniel Vetter
2016-06-03 10:14 ` Goel, Akash
2016-06-03 10:20 ` Chris Wilson
2016-06-08 8:30 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1464862909.2169.9.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=akash.goel@intel.com \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=sourab.gupta@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox