[Xenomai-core] [PATCH] I see negative faults

[Xenomai-core] [PATCH] I see negative faults

[Fillod Stephane]

[-- Attachment #1: Type: text/plain, Size: 175 bytes --]

Dear Xeonmai/I-Pipe maintainers,

Attached is an obvious patch (to me). Part of it is across I-Pipe.
Is there a reason why the counter was declared signed?
-- 
Stephane

[-- Attachment #2: int-faults.patch --]
[-- Type: application/octet-stream, Size: 1095 bytes --]

diff -u -r1.1.1.4 hal.h
--- include/asm-generic/xenomai/hal.h	23 Nov 2007 22:39:43 -0000	1.1.1.4
+++ include/asm-generic/xenomai/hal.h	17 Dec 2007 13:39:14 -0000
@@ -343,7 +343,7 @@
 
 extern rthal_trap_handler_t rthal_trap_handler;
 
-extern int rthal_realtime_faults[RTHAL_NR_CPUS][RTHAL_NR_FAULTS];
+extern unsigned rthal_realtime_faults[RTHAL_NR_CPUS][RTHAL_NR_FAULTS];
 
 extern int rthal_arch_init(void);
 
--- kernel/xenomai/arch/generic/hal.c	21 Nov 2007 10:26:33 -0000	1.1.1.4
+++ kernel/xenomai/arch/generic/hal.c	17 Dec 2007 13:39:16 -0000
@@ -85,7 +85,7 @@
 
 rthal_trap_handler_t rthal_trap_handler;
 
-int rthal_realtime_faults[RTHAL_NR_CPUS][RTHAL_NR_FAULTS];
+unsigned rthal_realtime_faults[RTHAL_NR_CPUS][RTHAL_NR_FAULTS];
 
 volatile int rthal_sync_op;
 
@@ -662,7 +662,7 @@
         p += sprintf(p, "\n%3d: ", trap);
 
         for_each_online_cpu(cpu) {
-            p += sprintf(p, "%12d", rthal_realtime_faults[cpu][trap]);
+            p += sprintf(p, "%12u", rthal_realtime_faults[cpu][trap]);
         }
 
         p += sprintf(p, "    (%s)", rthal_fault_labels[trap]);

Re: [Xenomai-core] [PATCH] I see negative faults

[Philippe Gerum]

Fillod Stephane wrote:
> Dear Xeonmai/I-Pipe maintainers,
> 
> 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?

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


-- 
Philippe.

Re: [Xenomai-core] [PATCH] I see negative faults

[Fillod Stephane]

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?

-- 
Stephane

PS: Happy new year to whoever read this message :-) 

Re: [Xenomai-core] [PATCH] I see negative faults

[Philippe Gerum]

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.