Re: [RFC 00/12] Support for sustained capturing of GuC firmware logs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 6/3/2016 12:45 PM, Daniel Vetter wrote:
On Thu, Jun 02, 2016 at 12:21:49PM +0200, Johannes Berg wrote:
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)

relayfs apparently moved in with debugfs. And a requirement (or at least
strong wishlist item) is that we can get at the data on production systems
(which really shouldn't mount debugfs). Seems like there's no place to
dump debug information outside of debugfs :(

There could be something said for using tracing, but that's only
independent of debugfs since the tracefs introduction in kernel 4.1.

We tried looking into tracing stuff for our performance counters, and at
least there the mismatch for dumping large-scale stuff was too much. But
tracefs looks like just the tracing debugfs directory cut out into a
separate filesystem, exactly to avoid that dreaded debugfs-is-insecure
issues.

I'd say we should smash it into debugfs, and if these troubles persist
then maybe we need to clean up the mess in there a bit and expose it as
drm_debugfs or whatever. Probably a topic for kernel summit even. At least
I feel like there's not enough consensus to add ABI at this point.
Hi Daniel,

Thanks much for your inputs.

So, on interim basis, can we have a relay backed debugfs interface only
i.e. /sys/kernel/debug/dri/guc_log.

And once the support for drm_debugfs is added, its just a matter of changing the file location, i.e. move it inside the drm_debugfs.

Best regards
Akash

-Daniel

_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux