[Adeos-main] Re: Adeos-cvs Digest, Vol 10, Issue 11

[Philippe Gerum <rpm@xenomai.org>]

Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>Jan Kiszka wrote:
>>
>>>adeos-cvs-request@domain.hid 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.
>>
> 
> 
> Then better make IPIPE_TRACE_POINTS configurable. Also the whole
> ipipe_trace_begin/end interface could be made optional so that the
> number of paths could be reduced by _1_ (not more...).
> 

Ok, I'll do that. Hopefully, this will help the boot issue too.

-- 

Philippe.