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