From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <444F9DA7.2060402@domain.hid> Date: Wed, 26 Apr 2006 18:19:51 +0200 From: Philippe Gerum MIME-Version: 1.0 References: <444F9BDB.200@domain.hid> In-Reply-To: <444F9BDB.200@domain.hid> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [Adeos-main] Re: Adeos-cvs Digest, Vol 10, Issue 11 List-Id: General discussion about Adeos List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: adeos-main@gna.org 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. -- Philippe.