Bug 5215

Tom had already been looking into this, I can't remember if he found the root cause yet.
If he hasn't I can likely have a look into it later today.

Yeah, I had mentioned this in our kernel meeting a couple weeks ago, and did look a bit into it but got sidetracked again..

Refreshing my memory, basically what I discovered was that CONFIG_TRACEPOINTS wasn't on because CONFIG_TRACING wasn't on, and CONFIG_TRACING normally gets turned on by the ftrace feature, but in the mips machines ftrace is disabled:

bsp/mti-malta32/mti-malta32.scc:include features/ftrace/ftrace-disable.scc

I'm not sure why the mips machines disable ftrace, but probably the mips machines need to explicitly enable CONFIG_TRACING.  Probably in general nothing should be counting on CONFIG_TRACING being turned on as a side effect of one feature or another..

Oh, here's the explanation for ftrace-disable in mti-malta32.scc:

# v3.8+ kernels have broken mips dynamic ftrace, disable it completely for now

Ah yes, on the qemu machines, in particular 64 bit mips. ftrace is completely broken and 
causes boot failures due to the dynamic trace point calculations. 

We can try re-enabling it again, but an upstream search for a full fix needs to be done first.

Anyone can try a quick boot test, but during my uprev, I carried the config forward as-is, 
since that was the known good baseline.

We should be able to turn on tracepoints explicitly and forget about ftrace, I think.

I assume it's not just DYNAMIC_FTRACE that breaks mips?  It's not turned on explicitly by anything, turning on the function tracer seems to turn it on automatically, but under the assumption that it's any function tracing that causes problems for mips, adding CONFIG_ENABLE_DEFAULT_TRACERS to mips might do the trick for now..

Adding and testing a new tracing/enable-default-tracers.scc to be added after every use of ftrace-disable.scc...

Assigning to Tom as he's clearly already moving with this.

Actually ONFIG_ENABLE_DEFAULT_TRACERS, CONFIG_TRACEPOINTS, etc can't be turned on unless CONFIG_FTRACE is turned on.  CONFIG_FTRACE 'Tracers' is to 'Enable the kernel tracing infrastructure.', the function tracers and dynamic function tracing apparently causing problems are FUNCTION_TRACER

(In reply to comment #9)
> Actually ONFIG_ENABLE_DEFAULT_TRACERS, CONFIG_TRACEPOINTS, etc can't be
> turned on unless CONFIG_FTRACE is turned on.  CONFIG_FTRACE 'Tracers' is to
> 'Enable the kernel tracing infrastructure.', the function tracers and
> dynamic function tracing apparently causing problems are FUNCTION_TRACER

oops hit send before done...

FUNCTION_TRACER Enable the kernel to trace every kernel function. This is done
by using a compiler feature to insert a small, 5-byte No-Operation
instruction at the beginning of every kernel function

and DYNAMIC_FTRACE This option will modify all the calls to function tracing
dynamically (will patch them out of the binary image and
replace them with a No-Op instruction) on boot up.

So we should be able to turn FTRACE on but make sure the above are off.

If that's ok, I'll submit a patch for that, otherwise, need more info on if it really is just FTRACE alone that causes the problem.

(In reply to comment #10)
> (In reply to comment #9)
> > Actually ONFIG_ENABLE_DEFAULT_TRACERS, CONFIG_TRACEPOINTS, etc can't be
> > turned on unless CONFIG_FTRACE is turned on.  CONFIG_FTRACE 'Tracers' is to
> > 'Enable the kernel tracing infrastructure.', the function tracers and
> > dynamic function tracing apparently causing problems are FUNCTION_TRACER
> 
> oops hit send before done...
> 
> FUNCTION_TRACER Enable the kernel to trace every kernel function. This is
> done
> by using a compiler feature to insert a small, 5-byte No-Operation
> instruction at the beginning of every kernel function
> 
> and DYNAMIC_FTRACE This option will modify all the calls to function tracing
> dynamically (will patch them out of the binary image and
> replace them with a No-Op instruction) on boot up.
> 
> So we should be able to turn FTRACE on but make sure the above are off.
> 
> If that's ok, I'll submit a patch for that, otherwise, need more info on if
> it really is just FTRACE alone that causes the problem.

That should be fine. A quick boot test will show if it works or not, so if you can 
enable ftrace, and disable dynamic ftrace and still boot, we are good.

Patches sent to linux-yocto ML:

https://lists.yoctoproject.org/pipermail/linux-yocto/2013-September/001005.html

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.10/commit/?h=meta&id=3058d8141b8c40dddae3801f852dd85866f50e6d