Philippe Gerum wrote:
Jan Kiszka wrote:
[EMAIL PROTECTED] wrote:
...
Commit from rpm (2006-04-26 17:41 CEST)
---------------
Make IPIPE_TRACE_PATHS configurable
ipipe v2.6/common/kernel/ipipe/tracer.c 1.10
ipipe v2.6/common/kernel/ipipe/Kconfig.trace 1.4
From a quick glance it appears to me you provided a nice interface to
break some stuff :). At least the explanation is not correct.
Those four paths are required to 1) always have an active path at hand
for recording, 2+3) keep the latest max or frozen path, and 4) escape
with to an alternative slot during max/frozen updates in case the
previous one is currently locked for output or whatever and cannot
become the new active path.
So, the absolute minimum is 3 when there is definitely no concurrent
usage of ipipe_trace_begin/end vs. ipipe_trace_freeze (remember that
users may want to define their own begin/end points if
IPIPE_TRACE_IRQSOFF is not set). Raising it above 4 is of no practical
use so far.
What is your idea behind it?
My idea is that 4 paths consume way too much memory and causes my
embedded ppc setup to choke at boot. The usual culprits like a bad
download address passed to u-boot and friends are not involved this
time, so until I figure out what on earth is causing this havoc, I'd
like to be able to lower this value to 2 by configuration.
Since the above is not an option, maybe we could try reducing the number
of trace points instead? but I'm not sure if this is going to be enough.
This said, unless there is some hard limit on this too, this would be
useful to export a configuration switch for that.
--
Philippe.
_______________________________________________
Adeos-main mailing list
[email protected]
https://mail.gna.org/listinfo/adeos-main
