Jan Kiszka wrote:
Hi all,
we (an RTnet user and I) just learned that switching on CONFIG_REGPARM
in 2.6 kernel can cause troubles with RTAI 3.1 (maybe earlier versions
as well) and with RTnet (likely all releases) with respect to LXRT
functions on x86. While the LXRT dispatcher pushes all arguments on the
stack, handler functions expect them in registers if CONFIG_REGPARM is
on and the number of arguments does not exceed 3. The user reported that
/user/latency failed to work in this case, and also no RTnet (i.e. RTDM)
call succeeded due to messed-up arguments.
I read some RTAI changelog about fixing the task trampolines, but all
LXRT entries, i.e. the API functions, do yet deal with it - also
verified by disassembling the user's rtai_lxrt.ko...
For RTnet, it would not be much work to add regparm or asmlinkage
(what's the difference BTW?) to our rather small API, but I guess it's a
bit more work for RTAI. So, better catch and deny this kernel setup? I'm
asking before patching RTnet in case RTAI 3 (fusion doesn't suffer from
this - no LXRT) goes the latter way...
As I told to RTAI users already (see RTAI archives):
do not use CONFIG_REGPARM if you want to use RTAI.
For your convinience here is it:
----------------------------------------------------------------------
Dipl. Ing. (FH) Malte Witt wrote:
> Hi Harald,
>
> this is what I stated on this list yesterday There are some issues on
SuSE gcc compilers. As I stated before, try plain 2.95.3 compiler from
gnu.org for kernel code. You will most probably succeed. If you have
further questions, just mail me.
>
RTAI has been tested up to gcc-3.4.3 here at DIAPM . My idea is that all
those seeing kernel space examples run but not those in user space have
the REGPARM option in the kernel enabled. I've recently withnessed such
a problem with a friend here at DIAPM.
Such an option breaks the argument passing scheme of LXRT from user space.
------------------------------------------------------------------------
Paolo
