take care of syscall auditing

Ciao,

if you have problems running the very first RTAI installation test, you 
should care also of the kernel syscall auditing option.
If that is the problem, disabling it in the kernel config should solve 
the problem.
However, according to the kernel-parameters doc the default kernel 
option should be an undefined behavior, and the activation/disactivation 
of such an audit will depend on the configuration of the auditing daemon 
of your distribution, if any is installed. Therefore configuring the 
daemon to disable it should be another possibility.
I've never stepped on such a problem on my Linux installations. I just 
discovered it when a collegue of mine had troubles in using RTAI on a, 
not so new but still powerful, quad CPUs server under a recent SUSE 
distribution.
To spot it, have a look at the short dump on the screen. In our case the 
out of range RTAI syscall number was signaled as a kernel bug at some 
line of auditsc.c, displayed at insmoding rtai_sched.ko, when its 
initing tries to get calibration infos from user space, through the user 
space helper, wheter RTAI has been already calibrated or not.

Paolo



_______________________________________________
Rtai mailing list
[email protected]
https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai