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 [email protected] https://mail.gna.org/listinfo/xenomai-core
