Mmiotrace regression in 2.6.28-rc6

[Pekka Paalanen <pq@iki.fi>]

Hi Steve,

now that the NULL deref bug in ring buffer resize is gone, I found
another regression.

It seems I am not getting any "buffer overflow" messages anymore.

Oh bummer, looks like I completely missed this one:
(hope it's not in any .27 kernel)


commit 3928a8a2d98081d1bc3c0a84a2d70e29b90ecf1c
Author: Steven Rostedt <rostedt@goodmis.org>
Date:   Mon Sep 29 23:02:41 2008 -0400

    ftrace: make work with new ring buffer
    
    This patch ports ftrace over to the new ring buffer.
    
    Signed-off-by: Steven Rostedt <srostedt@redhat.com>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

<...>
diff --git a/kernel/trace/trace_mmiotrace.c b/kernel/trace/trace_mmiotrace.c
index a108c32..bdbf09d 100644
--- a/kernel/trace/trace_mmiotrace.c
+++ b/kernel/trace/trace_mmiotrace.c
<...>
@@ -130,10 +130,14 @@ static unsigned long count_overruns(struct trace_iterator *iter)
 {
        int cpu;
        unsigned long cnt = 0;
+/* FIXME: */
+#if 0
        for_each_online_cpu(cpu) {
                cnt += iter->overrun[cpu];
                iter->overrun[cpu] = 0;
        }
+#endif
+       (void)cpu;
        return cnt;
 }

Steve, how am I going to fix this?
I think it's quite crucial to know when the dump is incomplete.


There's also another issue, but I am not sure how to reproduce it.
The symptom is, that
echo whatever > /debug/tracing/trace_marker
gets stuck in a loop, bash eats 100% CPU: 10% user, 90% system.
I got that twice today, like this: after a fresh boot echoing 64, 200,
70 to trace_entries, switching between nop and mmiotrace tracers,
echoing 0 or 1 to tracing_enabled, and running the testmmiotrace
module. At some point the user marker got stuck.

But then I tried to do that a third time by repeating some usage
patterns I thought might trigger it, but it didn't happen.

On the positive side, the basic test using testmmiotrace.ko
with the basic setup produces the correct output.


Thanks.

-- 
Pekka Paalanen
http://www.iki.fi/pq/