David J. Christini wrote:
>
> Below is a pared down version of my rt_process.c. I've cut out all COMEDI
> data acquisition and FIFO stuff. I'm running rtlinux-2.3 on a single
> processor computer without SMP support. I use mbuff-0.7.0 for shared
> memory.
>
> If I compile it with:
> gcc -D INT_G -I/usr/src/rtl/linux/include -I/usr/src/rtlinux-2.3
>-I/usr/src/rtlinux-2.3/include -I/usr/src/rtlinux-2.3/include/posix -Wall
>-Wstrict-prototypes -O2 -D__RTL__ -D__KERNEL__ -DMODULE -pipe -fno-strength-reduce
>-m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -g -c -o
>rt_process_tmp.o rt_process.c; ld -r -static rt_process_tmp.o -o rt_process.o
>-L/usr/lib -lm; rm -f rt_process_tmp.o
> my shared memory variable g is int, and the process runs fine.
>
> If I compile it with:
> gcc -D FLOAT_G -I/usr/src/rtl/linux/include -I/usr/src/rtlinux-2.3
>-I/usr/src/rtlinux-2.3/include -I/usr/src/rtlinux-2.3/include/posix -Wall
>-Wstrict-prototypes -O2 -D__RTL__ -D__KERNEL__ -DMODULE -pipe -fno-strength-reduce
>-m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -g -c -o
>rt_process_tmp.o rt_process.c; ld -r -static rt_process_tmp.o -o rt_process.o
>-L/usr/lib -lm; rm -f rt_process_tmp.o
> my shared memory variable g is float, and my computer occasionally, but
> not always, crashes at the first occurence of: sh_mem->g/=2;
>
> Note that I think (although it's difficult to know for sure with this sort
> of "random" phenomenon) that if it runs fine once, it seems that it will
> always run fine unless I reboot the computer. After rebooting, it may run
> fine again. After rebooting again, it may run fine again, etc. But, sooner
> or later, I'll reboot, insmod rt_process, and my system crashes.
>
> The code is at the end of this message, preceded by some possibly useful
> module and dmesg stuff.
>
> Any ideas?
Since this posting goes on without any fix, without interferring with
your use of RTL, I suggest a simple and neutral try that aims at
isolating your problem, to see if it is due to RTL or to something else.
For that you have just to tell not RTL that you are using its FPU
support but implement it yourself by putting in your module:
#define save_cr0_and_clts(x) __asm__ __volatile__ ("movl %%cr0,%0; clts"
:"=r"
(x))
#define restore_cr0(x) __asm__ __volatile__ ("movl %0,%%cr0": :"r"
(x));
#define save_fpenv(x) __asm__ __volatile__ ("fnsave %0" : "=m"
(x))
#define restore_fpenv(x) __asm__ __volatile__ ("frstor %0" : "=m"
(x));
Then a typical programming sequence to be used is the following:
unsigned long cr0;
unsigned long linux_fpe[27];
unsigned long task_fpe[27];
Put the followings just after while(1):
save_cr0_and_clts(cr0);
save_fpenv(linux_fpe);
restore_fpenv(task_fpe);
PUT HERE ALL YOUR THREAD SERVICE FLOATING POINT CALCULATIONS.
then put the following just before waiting for the next period:
save_fpenv(task_fpe);
restore_fpenv(linux_fpe);
restore_cr0(cr0);
If you want to know more go to http://www.aero.polimi.it/projects/rtai/
and read all the suggestions in "Hardware Floating Point Unit (FPU)
support in interrupt handlers".
If it works there is something to be fixed in RTL, if it does not we are
all immersed in the same ignarance ocean(shared fault, half joy). In my
experience, and in that of all those that have followed the suggestion
of using the FPU directly in interrupt handler, the aboves have not
failed yet.
Ciao, Paolo.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
