All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.