[rtl] Memory needs
Hello rtl users. I am beginning a project where I would like to use a rtl process as both a rt process and a driver for 4 ea. bt848 devices. I need 12 buffers of 172,800 bytes ea. and each buffer needs to be DMA capable (consecutive physical addresses). I could live with the buffers being fragmented - meaning that each buffer might in turn be composed of smaller buffers - but it would make more sense (to me) if each buffer was the size that was really needed. I mention this because it is also my understanding that the maximum memory that can be allocated at any one time using get_free_page () is 128KB. I wish to do all processing in a Linux process. So it would be real nice if I could also access the buffers from my Linux process rather than having rtl (or a driver) set up the bt848 DMA controllers and then have to copy the buffers to another set of 12 buffers in user-land. Sounds like a candidate for shared memory, except that it is my understanding that memory allocated for shared memory is not physically consecutive and therefore not DMA capable. One way that I hear of to do this might be to use the mem = at boot time , reserving the upper 2 MB of ram for my buffers and then hard code carve it up into the buffers that I need. I don't have any idea if these buffers could somehow be accessed from user-land or whether they would have to be copy_to_user()'d or similar. Any suggestions? Good places to look and learn? Also, any corrections of my (mis)understandings would be greatly appreciated. Thanks Wayne E. Van Loon Sr.
[rtl] running the rt_com.o module.
Hi, I am trying to get the rt_com running in rt-linux-2.3. I tried to inert the module but this is what i got: [root@linuxclient rt_com]# insmod rt_com.o rt_com.o: unresolved symbol rtl_register_rtldev rt_com.o: unresolved symbol rtl_unregister_rtldev I then looked for the "rtl_register_rtldev" string in all the files in the rt_com directory to trace the problem but looks like that the only file having this is the rt_com.o module itself. I did un-rem the NMT RT_Linux CFLAG in the Makefile as per what Jochen says next, but that didn't work either. It looks like Michael has already taken care of that in this distribution of the Makefile. i am nearly running out of educated guesses and am approaching the realm of un-educated ones now which has been, on occasions, quite disasterous in the past. Please let me know what i am doing wrong. Yours , Emeel. Sydney, Australia. P.S. A printout of the results that i am getting is attached. [root@linuxclient rt_com]# rm *.o rm: remove `rt_com.o'? y [root@linuxclient rt_com]# make gcc -I/usr/src/rtlinux-2.3/linux/include -I/usr/src/rtlinux-2.3/include -I/usr/src/rtlinux-2.3 -I/usr/src/rtlinux-2.3/include/posix -Wall -Wstrict-prototypes -O2 -D__SMP__ -D__RTL__ -D__KERNEL__ -DMODULE -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=586 -g -c rt_com.c [root@linuxclient rt_com]# ls *.o -rw-r--r-- 1 root root 128036 Jun 22 11:47 rt_com.o [root@linuxclient rt_com]# make install install -c rt_com.o /lib/modules/`uname -r`/misc/rt_com.o [root@linuxclient rt_com]# ls total 300 drwxr-xr-x 2 root root 4096 Jun 22 11:47 . drwxr-xr-x 4 root root 4096 Mar 29 18:50 .. -rw-r--r-- 1 root root15131 Mar 29 18:50 COPYING -rw-r--r-- 1 root root 3224 Mar 29 18:50 ChangeLog -rw-r--r-- 1 root root0 Jun 21 16:46 ComPresults.txt -rw-r--r-- 1 root root 354 Mar 29 18:50 License -rw-r--r-- 1 root root 398 Jun 22 11:47 Makefile -rw-r--r-- 1 root root 397 Jun 22 11:39 Makefile~ -rw-r--r-- 1 root root 528 Mar 29 18:50 README -rw-r--r-- 1 root root 798 Mar 29 18:50 README.RTL -rw-r--r-- 1 root root 330 Mar 29 18:50 TODO -rw-r--r-- 1 root root 1371 Mar 29 18:50 com_posix.c -rw-r--r-- 1 root root 5848 Mar 29 18:50 rt_com-1.html -rw-r--r-- 1 root root11305 Mar 29 18:50 rt_com.c -rw-r--r-- 1 root root 749 Mar 29 18:50 rt_com.h -rw-r--r-- 1 root root 574 Mar 29 18:50 rt_com.html -rw-r--r-- 1 root root 7709 Mar 29 18:50 rt_com.lyx -rw-r--r-- 1 root root 128036 Jun 22 11:47 rt_com.o -rw-r--r-- 1 root root61150 Mar 29 18:50 rt_com.ps -rw-r--r-- 1 root root 2464 Mar 29 18:50 rt_comP.h -rw-r--r-- 1 root root 585 May 31 17:05 rtl.mk -rw-r--r-- 1 root root 1221 Mar 29 18:50 testcom.c [root@linuxclient rt_com]# ls *.o -rw-r--r-- 1 root root 128036 Jun 22 11:47 rt_com.o [root@linuxclient rt_com]# make tests gcc -I/usr/src/rtlinux-2.3/linux/include -I/usr/src/rtlinux-2.3/include -I/usr/src/rtlinux-2.3 -I/usr/src/rtlinux-2.3/include/posix -Wall -Wstrict-prototypes -O2 -D__SMP__ -D__RTL__ -D__KERNEL__ -DMODULE -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=586 -g -c testcom.c -o testcom.o gcc -I/usr/src/rtlinux-2.3/linux/include -I/usr/src/rtlinux-2.3/include -I/usr/src/rtlinux-2.3 -I/usr/src/rtlinux-2.3/include/posix -Wall -Wstrict-prototypes -O2 -D__SMP__ -D__RTL__ -D__KERNEL__ -DMODULE -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=586 -g -c com_posix.c -o com_posix.o [root@linuxclient rt_com]# ls *.o -rw-r--r-- 1 root root 123716 Jun 22 11:48 com_posix.o -rw-r--r-- 1 root root 128036 Jun 22 11:47 rt_com.o -rw-r--r-- 1 root root 122252 Jun 22 11:48 testcom.o [root@linuxclient rt_com]# lsmod Module Size Used by [root@linuxclient rt_com]# insmod rt_com.o rt_com.o: unresolved symbol rtl_register_rtldev rt_com.o: unresolved symbol rtl_unregister_rtldev [root@linuxclient rt_com]# insmod testcom.o testcom.o: unresolved symbol rtl_printf testcom.o: unresolved symbol gethrtime testcom.o: unresolved symbol rt_com_read testcom.o: unresolved symbol rt_com_write testcom.o: unresolved symbol pthread_delete_np testcom.o: unresolved symbol pthread_make_periodic_np testcom.o: unresolved symbol pthread_wait_np testcom.o: unresolved symbol rt_com_setup testcom.o: unresolved symbol __pthread_create [root@linuxclient rt_com]#
Re: [rtl] Floating point in "restricted" code
On Tue, Jun 20, 2000 at 11:30:39AM -0400, Stephen D. Cohen wrote: > Victor Et. Al., > > You recently wrote: > > > 1. Saving fp state is _slow_ so you don't need it in an ISR > > -- there is no performance loss > >in having the ISR hand over work to a thread. > > I have been trying to figure out how to do this for some time. > Would you please provide a code fragment or clear explanation of how to have > an ISR cause a thread to become computable? There are several methods. The simplest is to have a thread suspend itself and then have the ISR send a signal thread: isr_ran = 0; do something thread_to_wakeup = pthread_self(); rtl_no_interrupts(flag); /* make sure I don't miss the wakeup */ if(!wakeup_sent)rtl_suspend_np(pthread_self()); /* hey the ISR woke me up */ do something else ISR_catch_interrupt: if(thread_to_wakeup)pthread_kill(thread_to_wakeup,RTL_SIG_WAKEUP); isr_ran = 1; > > I thought it would be correct to simply have the thread sleep until > it gets woken up by the ISR, but I am told that this will cause the thread > to run in the ISR context. That is, obviously, not what we want. I want to Only if you do a pthread_wakeup_np(thread) of a higher priority thread. > get in and out of ISR context just as quickly as possible, but cause another > thread to become computable (a high priority hardware handler responding to > the interrupt, for example). > > Any suggestions? > > Confusedly Yours, > > Steve > > P.S. -> > > 3. Rare workarounds are better than rarely used features. > > Keeping the API simple is > >critical. > > I could not agree more. You are, I see, a man of taste and perception. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Floating point in "restricted" code
On Tue, Jun 20, 2000 at 03:35:59PM +0200, Paolo Mantegazza wrote: > [EMAIL PROTECTED] wrote: > > > Here's the line of thought: > > 1. Saving fp state is _slow_ so you don't need it in an ISR -- there is no >performance loss > >in having the ISR hand over work to a thread. > > 2. Linux kernel code should follow Linux coding conventions so since use of FP is >fobidden in > >Linux kernel code, RTL assumes that parts of applications that run under Linux >kernel > >are going to not use FP. > >These components can ask RT threads or Linux user processes to do FP >computations. > > 3. Rare workarounds are better than rarely used features. Keeping the API simple >is > >critical. > > The above is totally wrong as when you get to the thread managing the > interrupt you need the FPUsave/restore anyhow, and so end up in loosing > efficiency as you pay for the thread switch overhead. I said there was no performance loss, I did not claim any gain. The point is that there is no real gain from using FP in the ISR. In the absence of a gain, we have, so far, chosen to keep the API simpler. > > Furthermore: I'm very concerned about FP in alternative architectures. I would >like RTL applications > > to run transparently in PPC, MIPS, Alpha, ia32,ia64 and some other upcoming >architectures. > > What's going to happen on a ia64 to code that does > > save fp // which means wait many cycles until the last of God >knows how many > > fp instructions complete and the fp pipeline clears > > do a couple of ops > > restore fp // which means wait until our ops all complete so that >we > >// don't get failure interrupts after we have switched >to > > // another thread. > > > > FP is dangerous, scary, frightening, stuff. It is only barely compatible with RT, >and > > is really dubious outside of an RT thread. > > > > What do you think? > > I do not know anything about ia64 and Alpha, but on PPC and MIPS it is > not much different than with i386. > > Once more if you need to use the FPU sooner or later you have to save > restore it and adding a task switch to keep it "elegant" is just adding > overhead. There is negligable additional overhead. In fact, there may actually be a performance gain due to improved cache locality. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Floating point in "restricted" code
On Wed, Jun 21, 2000 at 09:20:04AM +0100, Stuart Hughes wrote: > "Stephen D. Cohen" wrote: > > > I may be mistaken, but I think in RTAI/RTL, you can set a > > > semaphore from > > > within the ISR, exit and on exit the real-time task/thread > > > will run its > > > code. If it doesn't work this way, it would be nice to have this > > > facility available as this is typical of the sort of thing I > > > used to do > > > with pSOS. pthread_mutex_unlock Alternatively: pthread_kill(thread,RTL_SIG_WAKEUP); Both can be called from an ISR. > > As far as semaphores go, I demand a stable base for RTL, so I am > > still using RTL 2.2 on Linux 2.2-14. This version does not contain > > semaphores as near as I can tell. I am also not certain that semaphores > > work as expected in V3. Anybody want to fill us in (after answering my > > original question)? Jerry has cleaned up semaphores for V3. > > It seems to me that the semaphore handling routines should simply > > check to see if anyone is waiting for a semaphore (when it is given) and, if > > so, call the scheduler. The scheduler should also be called on return from > > every interrupt. Is this the case? > > > > I think you're correct (RTL & RTAI). IMHO it should be changed so there > is a way to pend a task to run only when an ISR has exited. That is exactly what pthread_kill WAKEUP is for. We have designed pthread_kill to be extremely fast and lightweight and to not call the scheduler. But pthread_mutex_unlock also does not call the scheduler and for exactly this reason. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] rtl_printf and periodics_tasks
On Tue, Jun 20, 2000 at 11:13:58PM +0200, Mario Teijeiro Otero wrote: > I have a long pthread periodic of 10ms, ?is it posible that, > when I debugging with rtl_printf, the period of this is large > that 10ms and freeze the kernel? Yes. Try setting RTL_DEFINE_SLOW_CONSOLE in include/rtl_config.h in RTL 2.x or using the config script in RTL 3.x. > -- > El c?digo fuente, como el esti?rcol, si lo diseminas ayuda al crecimiento si > lo acaparas solamente apesta.(Zachary Kessing SLASHDOT) > > > Mario Teijeiro Otero mailto:asimovi at teleline dot es > Powered by Hispafuentes 6.1clave: correo con Asunto: "[PGPKEY]" > Usr. Reg. 122438 o en http://www.terra.es/personal2/asimovi > > -- [rtl] --- > To unsubscribe: > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR > echo "unsubscribe rtl " | mail [EMAIL PROTECTED] > --- > For more information on Real-Time Linux see: > http://www.rtlinux.org/rtlinux/ -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] rt-linux:strange random system hang using FP
On Tue, Jun 20, 2000 at 03:35:53PM +0200, Paolo Mantegazza wrote: > [EMAIL PROTECTED] wrote: > > > And so you do not have machine independent code anymore. And for no advantage. > > Good programming requires a commitment to clarity and simplicity. > > I know, I'm always waiting for Yodaiken' Programming Gospel and the way > to the programmer eternal salvation :-). > > > > Wizards need superstitious people. > > > > ignored. > > Maybe wizards was wrong, likely Gods would have been more appropriate. That's quite pleasant. You can walk in front and throw rose petals in my path, if you'd like. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Floating point in "restricted" code
On Tue, Jun 20, 2000 at 03:41:08PM +0200, Paolo Mantegazza wrote: > Pavel Andris wrote: > > > You may consider a problem, FP is not allowed in interrupt service routine > > (ISR). > > Who said that? > > > The remedy is, write only a short ISR, that wakes up a RT-thread > > (pthread_wakeup_np()) and returns. Having finished the job, the RT-thread > > suspends itself (pthread_suspend_np). > > That's your idea for paying more than needed, the task switch cost. A couple of instructions. Dwarfed by the cost of saving and restoring the FPU. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Floating point in "restricted" code
On Tue, Jun 20, 2000 at 06:37:04PM +0200, Paolo Mantegazza wrote:
> Pavel Andris wrote:
>
> > So, Victor, Paolo could you please make things clear for us? By the
> > way, in my application would ISR last several milliseconds (robot's
> > sample period computations, heavy use of FPU) that's why I tend to
> > "pay more than needed".
>
> My opinion is not a must, is just an opinion. Take into account that all
> techinical solution are a tradeoff between conflicting needs.
My opinion is, of course, authoritative, absolute, and not to be
questioned. -)
My opinion is that a multi-millisecond ISR is generally not a good idea.
I would write things as
isr_catch_interrupt:
count++;
do something fast
put some data somewhere
pthread_kill(compute_thread,RTL_SIG_WAKEUP);
return
compute_thread:
pthread_setfp_np(pthread_self());
while(not_done){
mycount = count;
do the computation;
rtl_no_interrupts(state);
if(mycount == count)
pthread_suspend_np(pthread_self());
rtl_restore_interrupts(state);
}
This needs some work for SMP if you allow the interrupt and
thread to run on different processors, but the changes are not
complex. It is architecture independent and fast and, to me, it
is a clean design. It can be made even simpler by using a mutex, but
I have an irrational dislike of mutexes, so I didn't use them.
> You can do it as you want, my attitude is that Linux constraints are not
> mine. When I'm working in real time Linux must be my stupid servant and
> hardware is just mine.
My attitude is that ignoring Linux constraints is asking for trouble.
Of course, Paolo you know this already, but for the benefit of those
less expert:
Consider, for example:
/* this is Linux kernel code */
save floating point
do a fp computation
kmalloc();
restore fp
And think of what happens when this runs on a SMP machine. What happens
is that the probability of a failure in test is low, but the
probability of an eventual kernel crash is quite high.
The crash comes because the process may suspend during the kmalloc
and then Linux may decide to send it to a different processor!
Of course, you can fix this by making the save fp routine notify
the reassign code that the fp must be restored, but you would
be better off not getting involved here in the first place.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts
On Tue, Jun 20, 2000 at 09:54:18AM -0700, Pascal Charest wrote: > Hi, > > So, if I can't call Linux interrupt handler within an RTAI handler, can > I use two independant handlers ; one from RTAI and the other from Linux? It is trivial to call a Linux interrupt handler from RTLinux. But in RTLinux you do: pthread_kill(rtl_get_linux_thread(cpunumber), RTL_LINUX_MIN_SIGNAL+irq) in pre 2.3 you need the simpler seeming, but nonstandard: rtl_global_pend_irq(irq); Hopefully, you have a Linux handler installed for that interrupt and then it will be invoked. > I've a driver that uses Linux interrupt handler. Then, I want a > realtime process that is calling by the same interrupt. When I'm using > rt_request_global_irq() and doing nothing in my handler, the system > restart or all is ok ; it depends of the Linux driver I use. This is exactly the problem faced by x86 RTLinux for use of the clock which we must share with Linux. > How can I activate, if I can, Linux handler using the same irq? I've > used rt_pend_linux_irq() in my handler but it may crash too. If this happens in RTLinux, please tell me. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Floating point in "restricted" code
On Tue, Jun 20, 2000 at 01:14:41PM -0400, eric keller wrote: > I would like to point out that an interrupt based approach, where the most > important > stuff happens in the ISR is a perfectly viable approach. If a task _must_ get > done > before the next interrupt, then you may as well do it in the ISR. I cannot see > any > advantage in scheduling a thread to clean up after an ISR each time the ISR > runs, > unless that cleanup is not as critical as the interrupt. The advantage is that it encourages keeping the ISR absolutely simple. And, in my experience, complex ISRs are trouble. Well, complex code is trouble -- ok, any code is trouble. > > In my case i want my controller to run in an ISR, which means that I'm going to > use > fp in my ISR. I really don't see anything wrong with that on the processors i > am > using. If it becomes a problem with future processors, maybe i'll have to > switch > to a DSP or other processor where the fpu is not cobbled on like it is on the > i386. > > I think the idea that you shouldn't use fp in kernal mode makes a lot of sense > for > linux and no sense at all for a RTOS. I agree. But we currently only make it easy to use in threads on the following line of reasoning: 1. it is simple to make a thread run from an ISR Therefore a ISR can easily pass FP requests to threads 2. ISRs seem to work better over the long run if they are kept really simple. 3. Anyone who hates this idea can take code out of the arch specific scheduling code and make the ISR use FP directly. It follows that we keep the API simpler, encourage what we consider to be good programming practice, and save ourselves work all at the same time. victor -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Floating point in "restricted" code
On Wed, Jun 21, 2000 at 11:53:27AM +0100, Stuart Hughes wrote: > Arnaud Westenberg wrote: > The real question is if I have an ISR whos only task is to wake up a > thead, what happens: You have a choice. > > a) enter ISR, wakeup thread, thread code runs, return to ISR, exit ISR > pthread_wakeup_np(thread) if "thread" is higher priority than the current thread, whatever it may be, then we switch and run the thread, and return to this thread later and then exit the ISR. > or: > > b) enter ISR, wakeup thread, exit ISR, thead code runs. pthread_kill(thread,RTL_SIG_WAKEUP) or pthread_mutex_unlock(m); executes pthread_kill on all waiting threads. > I'm saying that b) is more conventional, and I would like to have this > facility available. You are a lucky man. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTAI upgrade question and more
On Wed, Jun 21, 2000 at 06:42:56PM +0100, Stuart Hughes wrote: > > You need to get a fresh 2.2.14, run the copyto and then build rtai. > Move the modules to /lib/modules/2.2.14/misc and then run depmod -a. > If you would prefer to use 2.2.16 (strongly recommended if you are connected to a network), you can use the rthal patch that I have made, which is functionally identical to the copyto script. It's at ftp://stm.lbl.gov/pub/realtime/patch-2.2.16-rthal3 dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTAI upgrade question and more
Hi Daniel, daniel sheltraw wrote: > > Hello RTAI world > > I am ready to upgrade from RTAI 0.7 to the latest stable version of RTAI. > Would someone please tell me which version that would be. Also rtai-1.3 from http://www.rtai.org/ > would you tell me how to best do an upgrade or point out any difficulties > they may have had upgrading. Does RTAI have a CD for a more recent version > yet? > You need to get a fresh 2.2.14, run the copyto and then build rtai. Move the modules to /lib/modules/2.2.14/misc and then run depmod -a. No CD just yet... > This has got to be the best linux related mailing list in existence. > I have dealt with a few others very recently and the smugness and > cockyness of the participants of those sites drove me away from > their product. Despite the heated exchanges sometimes, to me it resembles a health marriage :-) > > I have volunteered my services for any manual editing/writing that might be > needed for the RT effort. Please let me know if there is more I can do. > Thanks... Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL, Does a list of functions exist which can be called from RT-threads?
I am very interrested in your set of c-functions, could you email it to me? regards, Bert - Original Message - From: "Pavel Andris" <[EMAIL PROTECTED]> To: "Bert Eding" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, June 20, 2000 9:32 AM Subject: Re: [rtl] RTL, Does a list of functions exist which can be called from RT-threads? > Hi Bert, > > No, it does not (AFAIK, please correct me). Basicaly, you can call > some (NOT all) functions exported by kernel. See man ksyms how to get > a list. > > You can call functions provided by other modules you have insmod-ed. > And finally you can link (ld -r) your module with some libraries. > > If your question is about calling standard C functions, the answer is > no. I've put together a restricted set of standard C functions (mostly > string & format) that I link with my RT modules. > > Regards, > > pa > > -- > .. > Pavel Andris | tel: +421 7 5941 2167 > Institute of Control Theory and Robotics | fax: +421 7 5477 6045 > Slovak Academy of Sciences | > Dubravska cesta 9 | e-mail: [EMAIL PROTECTED] > SK - 842 37 Bratislava | > Slovakia | > . -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
[rtl] RTAI upgrade question and more
Hello RTAI world I am ready to upgrade from RTAI 0.7 to the latest stable version of RTAI. Would someone please tell me which version that would be. Also would you tell me how to best do an upgrade or point out any difficulties they may have had upgrading. Does RTAI have a CD for a more recent version yet? This has got to be the best linux related mailing list in existence. I have dealt with a few others very recently and the smugness and cockyness of the participants of those sites drove me away from their product. I have volunteered my services for any manual editing/writing that might be needed for the RT effort. Please let me know if there is more I can do. Thanks everyone, Daniel Sheltraw Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Floating point in "restricted" code
Stuart Hughes wrote: > > Arnaud Westenberg wrote: > > > > Stuart Hughes wrote: > > > > > One point I want to make is that there is a good reason why often people > > > would choose to have an ISR wake up a real-time task to carry out the > > > bulk of a set of processing. On most other real-time operating systems, > > > the task that gets woken from the ISR runs at a lower privilege level > > > than an ISR (in terms of machine state), also interrupts are normally > > > enabled. This means that the task can be pre-empted by other real-time > > > tasks and also interrupted. In the Linux (hard) real-time > > > implementations (RTL/RTAI) this is not currently true, as I believe that > > > the task/thread runs at the same machine privilege level as the ISR. > > > > This is not correct, I asked this question recently. Here's the question > > and victor's reply: > > > > Q: Does a "hard" handler stop a RT thread? (I would say yes) How are the > > Q: "priorities" between hard handlers and RT threads determined by > > RTLinux? > > > > A: Hard handlers preempt anything that is not running with hard > > interrupts > > A: disabled. There is no other priority mechanism. > > > > So RT threads will be interrupted by the handler. > > > > Hi Arnaud, > > The real question is if I have an ISR whos only task is to wake up a > thead, what happens: > > a) enter ISR, wakeup thread, thread code runs, return to ISR, exit ISR > > or: > > b) enter ISR, wakeup thread, exit ISR, thead code runs. > > I'm saying that b) is more conventional, and I would like to have this > facility available. > > Regards, Stuart. b) is the same as a) if one cares to wakeup the thread after having done every thing that must be done in the ISR, acknowledge the PIC and set enabled the CPU to take interrupts. Making it as in a) is not too complex, but useless as the constraints enatailed by b) are very mild, after all preemption is nothing but scheduling from within interrupts. You can check Comer's book on XINU for an explanation of why it is safe to reschedule from within interrupts. Ciao, Paolo. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Page fault from RT task.
Hi all,
To slove the infinite loop caused by a page fault in a RT task, I added a
test in the
do_page_fault function:
asmlinkage void do_page_fault(struct pt_regs *regs, unsigned long
error_code)
{
struct task_struct *tsk;
struct mm_struct *mm;
struct vm_area_struct * vma;
unsigned long address;
unsigned long page;
unsigned long fixup;
int write;
/* get the address */
__asm__("movl %%cr2,%0":"=r" (address));
tsk = current;
mm = tsk->mm;
/* NEW LINES ***/
if (((unsigned int)mm & 0xF000) != 0xC000) {
printk("Page fault: mm=0x%x pid=0x%x\n", (unsigned int)mm, (unsigned
int)tsk->pid);
tsk->pid = 0;/* To cause a panic */
goto no_context;
}
/* END OF NEW LINES /
/*
* If we're in an interrupt or have no user
* context, we must not take the fault..
*/
if (in_interrupt() || mm == &init_mm)
goto no_context;
With these lines all the information about the bad access are displayed,
and it finishes by a panic "Attempted to kill the idle task !".
Have you another idea ??
Thanks.
Denis RICHARD wrote:
> Hi all,
>
> We work on LINUX 2.2.13 and RTL 2.0.
>
> When a RT task produces a page fault (bad pointer, : see the
> following code),
> the exception function (do_page_fault: arch/i386/mm/fault.c)
> also produces a page fault -> infinite loop.
>
> >From a RT task, it seems that the current task structure is not valide
> (tsk variable in do_page_fault function: tsk = current;).
>
> Is it normal
>
> How to solve the problem and display information about the page fault ?
>
> If this page fault is produced in a simple module (not from a RT task),
> the panic displays all the informations about the access (address, IP,
> stack, ...).
> For debugging it is very useful.
>
> Many thanks.
>
> Denis
>
> #include
> #include
> #include
>
> RT_TASK k_test_task;
> int nb;
>
> void k_test(int data) {
> char *ptr = 0;
>
> for (;;) {
> rtl_printf("k_test: %d\n", nb);
> rtl_printf("ptr=0x%x\n", ptr);
> rtl_printf("Before access in zero\n");
> *ptr = 0; /* Access in zero to produce a page fault */
> rtl_printf("After access in zero\n");
> nb++;
> rt_task_wait();
> }
> }
>
> int init_module(void) {
>
> nb = 0;
> /* Create task*/
> if (rt_task_init(&k_test_task, k_test, 0, 8192, 1) < 0) {
> printk("init_module: Error rt_task_init\n");
> return(-1);
> }
> if (rt_task_make_periodic(&k_test_task, rt_get_time() +
> (RTIME)(RT_TICKS_PER_SEC * 2),
> (RTIME)(RT_TICKS_PER_SEC * 5)) < 0) {
> printk("init_module: Error rt_task_make_periodic\n");
> return(-1);
> }
> return(0);
> }
>
> void cleanup_module(void) {
> rt_task_delete(&k_test_task);
> rtl_printf("Cleanup module\n");
> }
>
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
> ---
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/rtlinux/
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
Re: [rtl] rtl_time and HZ
Hi, > I was told to change the value HZ in the file param.h > and afterwards recompile the kernel. However, having > done this the performance seemed not to improve at > all. I also wonder whether I missed something. I did the same, I can very easily test when the timer is changed simply with "echo ^G" on the console and if the timer changed, the beep is ten times as long as before. This actually happens if I install an own timer like this: timer = rtl_getbestclock( 0 ); rtl_setclockhandler( timer, handler ); timer->init( timer ); spec = 800; timer->settimermode( timer, RTL_CLOCK_MODE_PERIODIC ); timer->settimer( timer, spec ); After that the linux system timer is changed as well. bye, Roman -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Floating point in "restricted" code
Arnaud Westenberg wrote: > > Stuart Hughes wrote: > > > One point I want to make is that there is a good reason why often people > > would choose to have an ISR wake up a real-time task to carry out the > > bulk of a set of processing. On most other real-time operating systems, > > the task that gets woken from the ISR runs at a lower privilege level > > than an ISR (in terms of machine state), also interrupts are normally > > enabled. This means that the task can be pre-empted by other real-time > > tasks and also interrupted. In the Linux (hard) real-time > > implementations (RTL/RTAI) this is not currently true, as I believe that > > the task/thread runs at the same machine privilege level as the ISR. > > This is not correct, I asked this question recently. Here's the question > and victor's reply: > > Q: Does a "hard" handler stop a RT thread? (I would say yes) How are the > Q: "priorities" between hard handlers and RT threads determined by > RTLinux? > > A: Hard handlers preempt anything that is not running with hard > interrupts > A: disabled. There is no other priority mechanism. > > So RT threads will be interrupted by the handler. > Hi Arnaud, The real question is if I have an ISR whos only task is to wake up a thead, what happens: a) enter ISR, wakeup thread, thread code runs, return to ISR, exit ISR or: b) enter ISR, wakeup thread, exit ISR, thead code runs. I'm saying that b) is more conventional, and I would like to have this facility available. Regards, Stuart. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Floating point in "restricted" code
Stuart Hughes wrote: > One point I want to make is that there is a good reason why often people > would choose to have an ISR wake up a real-time task to carry out the > bulk of a set of processing. On most other real-time operating systems, > the task that gets woken from the ISR runs at a lower privilege level > than an ISR (in terms of machine state), also interrupts are normally > enabled. This means that the task can be pre-empted by other real-time > tasks and also interrupted. In the Linux (hard) real-time > implementations (RTL/RTAI) this is not currently true, as I believe that > the task/thread runs at the same machine privilege level as the ISR. This is not correct, I asked this question recently. Here's the question and victor's reply: Q: Does a "hard" handler stop a RT thread? (I would say yes) How are the Q: "priorities" between hard handlers and RT threads determined by RTLinux? A: Hard handlers preempt anything that is not running with hard interrupts A: disabled. There is no other priority mechanism. So RT threads will be interrupted by the handler. > So > for real-time Linux it is currently less important than on other RTOS's > to make the ISR/task distinction, but things may change in the future, > so keeping this in mind may help to produce a design that will be more > conventional: > > a) if real-time Linux changes > b) if you port to other real-time operating systems > > Regards, Stuart > -- [rtl] --- > To unsubscribe: > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR > echo "unsubscribe rtl " | mail [EMAIL PROTECTED] > --- > For more information on Real-Time Linux see: > http://www.rtlinux.org/rtlinux/ -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts
JunHyeok Heo wrote:
>
> Hi! pascal.
>
> First of all, I am sorry for missing your first letter and i had no experience of
>RTAI.
> I am going to explain what i am thinking as a solution in case of RTL.
> I hope you can use RTL instead of RTAI.
You can do this in either system in almost the same way
> But the following method is not verified.
>
> 1. Install your linux interrupt handler as a soft interrupt handler using
>'rtl_get_soft_irq()'
> 2. In real-time interrupt handler, use 'rtl_global_pend_irq()' to call your linux
>interrupt handler.
For RTAI (as Karim said)
rt_request_linux_irq()
rt_pend_linux_irq()
Regards, Stuart
>
> - Original Message -
> From: "Pascal Charest" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, June 21, 2000 1:54 AM
> Subject: Re: [rtl] Interrupts
>
> > Hi,
> >
> > So, if I can't call Linux interrupt handler within an RTAI handler, can
> > I use two independant handlers ; one from RTAI and the other from Linux?
> >
> > I've a driver that uses Linux interrupt handler. Then, I want a
> > realtime process that is calling by the same interrupt. When I'm using
> > rt_request_global_irq() and doing nothing in my handler, the system
> > restart or all is ok ; it depends of the Linux driver I use.
> >
> > How can I activate, if I can, Linux handler using the same irq? I've
> > used rt_pend_linux_irq() in my handler but it may crash too.
> >
> > Pascal
> > Charest
> >
> > Karim Yaghmour wrote:
> > >
> > > Hello Pascal,
> > >
> > > I beleive the problem comes from the fact that you are calling the
> > > Linux interrupt handler from within an RTAI handler. Since Linux
> > > interrupt handlers might call on lock mechanisms redirected by
> > > RTAI, this is where things get messy.
> > >
> > > Rather than using rt_request_global_irq(), try using rt_request_linux_irq().
> > > What this will do is add your handler to the list of handlers linux
> > > will call when the IRQ happens. Therefore, the normal handler gets
> > > called and so does yours. Your handler can then use RTAI locking
> > > mechanisms to do it's work.
> > >
> > > This is actually currently used from within the RTAI schedulers to
> > > try recovering lost jiffies (this is from start_rt_timer in the upscheduler):
> > > rt_request_linux_irq(TIMER_8254_IRQ, recover_jiffies, "rtai_sched",
>recover_jiffies);
> > >
> > > The recover_jiffies function now gets called every time a timer
> > > interrupt gets to Linux.
> > >
> > > J'espere que ca pourra vous aider ...
> > >
> > > Karim
> > >
> > > Pascal Charest wrote:
> > > >
> > > > Hi,
> > > >
> > > > I'm trying to catch interruptions with rtai and forcing the linux
> > > > interrupt handler, but I don't know how to do it correctly. In fact, I
> > > > want to use different drivers with my rt_process and to make them
> > > > realtime without changing their code. There is a example of what I want
> > > > to do :
> > > >
> > > > void handler(int irq)
> > > > {
> > > > ... forcing linux interrupt handler
> > > > ... doing my own work
> > > > }
> > > >
> > > > int init_module()
> > > > {
> > > > ...
> > > > rt_request_global_irq(IRQ, (void*)handler);
> > > > rt_startup_irq(IRQ);
> > > > ...
> > > > }
> > > >
> > > > When I try something, linux stops or the computer restarts when the
> > > > interrupt occurs ; it depends of the rt fonctions I use in my handler.
> > > > Do someone know how to do it?
> > > >
> > > > Thanks in advance,
> > > >
> > > > Pascal Charest
> > > > -- [rtl] ---
> > > > To unsubscribe:
> > > > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> > > > echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
> > > > ---
> > > > For more information on Real-Time Linux see:
> > > > http://www.rtlinux.org/rtlinux/
> > >
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
Re: [rtl] Floating point in "restricted" code
"Stephen D. Cohen" wrote: > > Stuart Et. Al., > > > I may be mistaken, but I think in RTAI/RTL, you can set a > > semaphore from > > within the ISR, exit and on exit the real-time task/thread > > will run its > > code. If it doesn't work this way, it would be nice to have this > > facility available as this is typical of the sort of thing I > > used to do > > with pSOS. > > That is exactly the same structure I used in VxWorks. I was under > the impression, from messages on the list, that this did not work in RTL. > > As far as semaphores go, I demand a stable base for RTL, so I am > still using RTL 2.2 on Linux 2.2-14. This version does not contain > semaphores as near as I can tell. I am also not certain that semaphores > work as expected in V3. Anybody want to fill us in (after answering my > original question)? > Have you looked at RTAI, this has semaphores, mailboxes etc ?? > It seems to me that the semaphore handling routines should simply > check to see if anyone is waiting for a semaphore (when it is given) and, if > so, call the scheduler. The scheduler should also be called on return from > every interrupt. Is this the case? > I think you're correct (RTL & RTAI). IMHO it should be changed so there is a way to pend a task to run only when an ISR has exited. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Floating point in "restricted" code
eric keller wrote: > > I would like to point out that an interrupt based approach, where the most > important > stuff happens in the ISR is a perfectly viable approach. If a task _must_ get > done > before the next interrupt, then you may as well do it in the ISR. I cannot see > any > advantage in scheduling a thread to clean up after an ISR each time the ISR > runs, > unless that cleanup is not as critical as the interrupt. > > In my case i want my controller to run in an ISR, which means that I'm going to > use > fp in my ISR. I really don't see anything wrong with that on the processors i > am > using. If it becomes a problem with future processors, maybe i'll have to > switch > to a DSP or other processor where the fpu is not cobbled on like it is on the > i386. > > I think the idea that you shouldn't use fp in kernal mode makes a lot of sense > for > linux and no sense at all for a RTOS. > eric > Hi Erik, I agree with your points. Each design may have different constraints and so sometimes you may wish to do FP in an ISR. Nothing should be forbidden if one has sound reasons for making a particular design choice. One point I want to make is that there is a good reason why often people would choose to have an ISR wake up a real-time task to carry out the bulk of a set of processing. On most other real-time operating systems, the task that gets woken from the ISR runs at a lower privilege level than an ISR (in terms of machine state), also interrupts are normally enabled. This means that the task can be pre-empted by other real-time tasks and also interrupted. In the Linux (hard) real-time implementations (RTL/RTAI) this is not currently true, as I believe that the task/thread runs at the same machine privilege level as the ISR. So for real-time Linux it is currently less important than on other RTOS's to make the ISR/task distinction, but things may change in the future, so keeping this in mind may help to produce a design that will be more conventional: a) if real-time Linux changes b) if you port to other real-time operating systems Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
