Fillod Stephane wrote:
> Philippe Gerum wrote:
>> Fillod Stephane wrote:
>>> Attached is an obvious patch (to me). Part of it is across I-Pipe.
>>> Is there a reason why the counter was declared signed?
>>>
>> Well, because the number of faults was not expected to increase
>> indefinitely... Is it the PF count we are talking about, on a mpc85xx?
> 
> Indeed. It's a MPC8541E. 
> 
> $ cat /proc/xenomai/faults
> TRAP         CPU0
>   0:            4    (Data or instruction access)
>   1:            0    (Alignment)
>   2:            0    (Altivec unavailable)
>   3:            0    (Program check exception)
>   4:            0    (Machine check exception)
>   5:            0    (Unknown)
>   6:            0    (Instruction breakpoint)
>   7:            0    (Run mode exception)
>   8:            0    (Single-step exception)
>   9:            0    (Non-recoverable exception)
>  10:            0    (Software emulation)
>  11:            0    (Debug)
>  12:            0    (SPE)
>  13:            0    (Altivec assist)
>  14:   3221526824    (Cache-locking exception)
>  15:            0    (Kernel FP unavailable)
> 
> Any clue?
> 

Book-E cache locking instructions are still considered as privileged ops
by the kernel, so userland gets a SIGILL as a result of issuing them,
therefore Xenomai has to switch back the context to secondary mode for
this reason. There seems to be something going on at application level.

-- 
Philippe.

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to