Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

[Wolfgang Grandegger <wg@domain.hid>]

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.
>>
>>
>>