From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4519553A.3040109@domain.hid> Date: Tue, 26 Sep 2006 18:28:42 +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> In-Reply-To: <1159287029.5084.149.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 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. This is a tool chain issue. Niklaus, what tool chain are you using? Wolfgang.