From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <45195BF8.6060707@domain.hid> Date: Tue, 26 Sep 2006 18:57:28 +0200 From: Wolfgang Grandegger MIME-Version: 1.0 Subject: Re: [Xenomai-core] Problem with periodic timer on PPC40x solved References: <1159287029.5084.149.camel@domain.hid> <4519553A.3040109@domain.hid> <1159288734.5084.159.camel@domain.hid> In-Reply-To: <1159288734.5084.159.camel@domain.hid> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: rpm@xenomai.org Cc: xenomai-core Philippe Gerum wrote: > On Tue, 2006-09-26 at 18:28 +0200, Wolfgang Grandegger wrote: >> Philippe Gerum wrote: >>> On Tue, 2006-09-26 at 16:56 +0200, gilles.chanteperdrix wrote: >>>> ---------- Debut du message initial ----------- >>>> >>>> De : xenomai-core-bounces@domain.hid >>>> A : niklaus.giger@domain.hid >>>> Copies : xenomai@xenomai.org >>>> Date : Tue, 26 Sep 2006 16:21:18 +0200 >>>> Objet : Re: [Xenomai-core] Problem with periodic timer on >>>> PPC40x solved >>>> >>>>>> On Mon, 2006-09-25 at 22:29 +0200, Niklaus Giger wrote: >>>>>>>> Am Montag, 25. September 2006 17:57 schrieb Philippe >>>> Gerum: >>>>>>>>> On Sun, 2006-09-24 at 23:07 +0200, Wolfgang >>>> Grandegger wrote: >>>>>>>>>> Niklaus Giger wrote: >>>>>> <..> >>>>>>>> Is the output of lines like "Xenomai: Switching >>>> display-3238 to secondary >>>>>>>> mode after exception #1025 from user-space at >>>> 0x100033c4 (pid 3240)" >>>>>>>> harmless or the result of a activated >>>> CONFIG_XENO_OPT_DEBUG<..> option? >>>>> A known hw issue seems to exist with the 405GP (revD), which >>>> causes the >>>>> ESR to be incorrectly set upon FPU emulation trap, which >>>> would in turn >>>>> cause the spurious exception to be relayed to the nucleus by >>>> Adeos. The >>>>> patch below is _not_ the final fix, but rather a way to >>>> check if this >>>>> message is indeed related to the FPU emulation on your >>>> board. Does it >>>>> silence the exception without breaking the box? >>>> The FPU fault may be the result of the latency display thread >>>> using the >>>> FPU: on systems with emulated FPU, this looks normal. >>>> >>> This said, we should not switch the task to secondary mode, but rather >>> emulate the FPU ops in primary mode. To this end, we need to make sure >>> that do_mathemu() is not going to choke over this context (e.g. >>> preemption count check issues over CONFIG_PREEMPT when running >>> unmodified uaccess routines). We additionally need to fix the program >>> check exception handler to give the math emulation code a chance to >>> handle the fault before we complain loudly at the nucleus. >> OK, but in general, soft-float emulation should be used on systems >> without FPU and this is even more important for real-time. > > Makes sense. So maybe we should make this a more explicit and formal > warning, to catch missing soft float emulation, actually. We could already print a compiler warning when the kernel is built with MATH_EMULATION=y. There are a few corner-case where it might make sense to have math emulation enabled e.g. you need to run a binary with hard FP instructions because you are unable to rebuild it from the sources. > >> This is a >> tool chain issue. Niklaus, what tool chain are you using? >> >> Wolfgang. >> >> >>