[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJWu+oq3HD3VhYzvRJA-8HQksdrX5zYr4kz7EUpDYvCNQRUGXw@mail.gmail.com>
Date: Sun, 5 Aug 2018 09:46:56 -0700
From: Joel Fernandes <joelaf@...gle.com>
To: Masami Hiramatsu <mhiramat@...nel.org>
Cc: Joel Fernandes <joel@...lfernandes.org>,
LKML <linux-kernel@...r.kernel.org>,
"Cc: Android Kernel" <kernel-team@...roid.com>,
Boqun Feng <boqun.feng@...il.com>,
Byungchul Park <byungchul.park@....com>,
Ingo Molnar <mingo@...hat.com>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Namhyung Kim <namhyung@...nel.org>,
Paul McKenney <paulmck@...ux.vnet.ibm.com>,
Peter Zijlstra <peterz@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>,
Thomas Glexiner <tglx@...utronix.de>,
Tom Zanussi <tom.zanussi@...ux.intel.com>
Subject: Re: [PATCH v12 0/3] tracing: Centralize preemptirq tracepoints and
unify their usage
Hi Masami,
On Fri, Aug 3, 2018 at 9:51 PM, Joel Fernandes <joelaf@...gle.com> wrote:
[...]
>> On Thu, 2 Aug 2018 19:57:09 -0700
>> Joel Fernandes <joelaf@...gle.com> wrote:
>>
>>> Hi Masami,
>>>
>>> On Thu, Aug 2, 2018 at 7:55 AM, Masami Hiramatsu <mhiramat@...nel.org> wrote:
>>> > Hi Joel,
>>> >
>>> > I found this caused several issues when testing ftrace.
>>> >
>>> > #1) ftrace boottest (FTRACE_STARTUP_TEST) fails
>>>
>>> This sadly appears to be a real issue. The startup test for
>>> "preemptirqsoff" tracer fails, however it passes for only preemptoff
>>> or only irqsoff. I tested only the last 2 tracers, not the first one,
>>> that's why I didn't catch it. I need to debug this more.
I figured out this one too. Its because I need to account for
preempt_count() in tracer_hardirqs_off since the tracer probe is now
called with an additional level of preempt disabled from the
tracepoint code. Without that accounting, stop_critical_timings may
not be called causing an empty trace buffer. That should be easy to
fix, I'm on vacation though and back on 13th so can most likely look
at it only then (the week after the next).
>>> > #2) mmiotrace reports "IRQs not enabled as expected" error
>>> > #3) lock subsystem event boottest causes "IRQs not disabled as expected" error (sometimes)
The only thing left to figure out is #3 ("lock subsystem event
boottest"). Could you let me know how to run this test?
Thanks for the reporting these,
- Joel
Powered by blists - more mailing lists