[Intel-gfx] [PATCH] drm/i915: Add aub debug support for kernel

[Liu Aleaxander]

On Thu, Nov 4, 2010 at 5:30 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Thu, 4 Nov 2010 11:44:39 +0800, "Liu, Yuanhan" <yuanhan.liu at intel.com> wrote:
>>
>> On Tue, 2010-11-02 at 22:55 +0800, Liu Aleaxander wrote:
>> >
>> > > Being able to trace the register writes using ftrace is good... In fact we
>> > > can remove our own printks and just use mmiotrace. So is it possible to
>> > > post-process mmiotrace into .aub?
>> >
>> > As I found mmiotrace can handle the operation(read or write), the
>> > register address
>> > and the value's size, yes, it is(I guess).  I will do more
>> > investigation tomorrow.
>> >
>> > Hi,
>>
>> One should do this 'echo mmiotrace > /sys/kernel/debug/tracing' to enable
>> mmio trace. And this should be done before calling ioremap function, AKA,
>> before loading a module. So, first, user should have to stop i915 modules
>> from loading at the boot time. Then enable mmiotrace like said above, then
>> modprobe i915 by hand.
>
> Ok, that is tricky for userland debugging.
>
>> And yes, all the register data are recorded. But just
>> a while, I get a data file about 1G(Since it recorded everything, and some
>> register write and read too often).
>
> Painful, but we could pipe the output from ftrace through a filter to
> eliminate those.
>
>> So, I'm not sure this good for debug. One great advantage of aub file is that
>> user can gave an aub file to us, then we may know what was going wrong,
>> just like we often ask user for something like dmesg log. As it's a bit hard for
>> user to generate an aub file, then it's not good for us to debug.
>>
>> So, ideas and comments? (And feel free to correct me if I'm wrong)
>
> I'm not going to give up on tracepoints just yet since they solve the
> complex issue of exporting the data to userspace.

Yes, indeed.

> The alternative is to
> instrument I915_READ/I915_WRITE with a pair of our own tracepoints (so we
> can selectively choose to record reads or writes) and introduce
> I915_WRITE_UNTRACED/I915_READ_UNTRACED for the raw variants to be used in
> GPIO.

Sorry, I'm not sure I understand you. Our own tracepoints? what's the
difference with mmio
trace?

Assume we will use mmio trace to generate an aub file, I think the
steps would be something
like this:

1. make sure i915.ko module isn't loaded at boot time.
2. mount -t debugfs nodev /sys/kernel/debug
3. echo mmiotrace >/sys/kernel/debug/tracing/current_tracer   # enable
mmio trace
4. cat /sys/kernel/debug/tracing/trace_pipe >/tmp/out&            #
dump the data to a file
5. modprobe i915

After these step, all register data read and write is recorded in
/tmp/out file, it's a bit big, but yes,
just like Chris said, we can filter out something not useful for us,
so this would not be a problem.
Then use a script to convert these data to an aub file, and that's how
the aub file is generated
by using mmio trace.

Well, what are the steps you excepted to get an aub file? Please tell
me, then I may know your
points better.


>
> Still requires post-processing to add the aub headers, but this will allow
> runtime enabling of the capture. How does this sound?

Yes, runtime enabling of the capture is great. And post-processing
isn't that bad at all.
What I concerned is how much hard or easy for user to generate an aub
file. As Nanhai said,
if user met some problem, we can ask him for an aub file, then we
might know what was going
wrong. This is the biggest advantage of aub file. So, I'm not trying
to ask you give up the
tracepoints(it really nice for tracing something down), I just want an
easy way to get an aub file
for us, and especially for user.

Thanks!


-- 
regards
Yuanhan Liu