Re: [rtl] Sparc hardware?
} Hey, } Are there any plans to port RTLinux to the sparc } architecture? } What would be involved in doing this? No plans as of yet. There wouldn't be a lot of work involved. RTLinux 3.0 has a pretty good template for ports to other chips. I'm assuming you mean the newer PCI based sparcs. The older SBUS based sparc are a nightmare for RTLinux. We looked at them some time ago. -- [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/
AW: [rtl] Execution time of Realtime-Task
Hello David, [...] Are you using FP or some more "advanced" math functions? [...] Nope. At the moment its just bit shifting and int calculations :). But I will get some FP to do when I have AD/DA cards in my system, which will be in the next project. [...] A third possibility: It seems to me that it isn't X, but rather the applications that affect you RT task. (Otherwise running X on NT - or any other alternative to a local X server - probably wouldn't have the same effect as running a local server. It *could* be the library and not the server, but...) That is, it might be *any* form of system stress that affects the RT task. [...] If you run graphical X apps on an X Client, you get some network traffic which depends on window size/ color depth/some other stuff I don't know. If I have a basic xterm, almost nothing happens. When running KDevelop fullscreen (without doing anything, no scrolling, compiling, etc ... ), I get an additional 70-80 us. Its MUCH worse when I'm scrolling through source code :) [...] My guess would be that the fluctuations in execution time are the result of cache misses caused by the applications flushing RT data out of the cache. The Celeron has 128 kB of full core speed cache, and a 66 MHz system bus, so there can be quite some difference between accessing hot and cold data. Are you using lots of data, look-up tables or anything like that? [...] Cache misses could also be part of the problem ... my module is now 800k in memory, depeding on how large I set my data structures. But only a small part of it is accessed with my current configuration, so I think the biggest part is the network traffic. Marco -- [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/
Re: [rtl] nano2count
Thanks for the answer,
I now can't get the process to runn periodic.
I try folloing calls inside the process wich is started whith
rt_task_resume after initialisation.
start_time = msec2start * 1000 * 1000; //start in X nanosec
rt_sleep( nano2count( start_time ) );
rt_set_periodic_mode();
rtl_printf ( KERN_DEBUG
"RTAI dmm16: going to make reading thread periodic.\n" );
if ( rt_task_make_periodic_relative_ns( rt_whoami(),
100,
period ) != 0 ){
rtl_printf( KERN_ERR "RTAI dmm16: error making reading thread
periodic\n");
return;
}
do {
rt_task_wait_period( );
...
}while(1)
I set the period to 50 ns maybe this is to less. I greped my mail
folder, and found a message where someone wrote that the period has to
be between 1ms and 10ms. Values greater 10ms are set to 10ms but what
about values less 1ms?
After the above call .._periodic_.. the task seems never to be waked up.
Paolo Mantegazza wrote:
Vasili Goutas wrote:
Hi
I'm using rtai-1.4 with linux-2.2.16.
I have a problem using the function nano2count.
rt_printk ( KERN_DEBUG
"RTAI dmm16: going to make reading thread periodic. period = %lu,
nano2count(period) = %lu\n", period, nano2count(period) );
gives me the following output:
7RTAI dmm16: going to make reading thread periodic. period =
5, nano2count(period) = 0
Above you try to write an %llu with just %lu. What you get is
unpredictable.
Note that you cannot use %llu within the kernel. You should be enough
with:
rt_printk ( KERN_DEBUG "RTAI dmm16: going to make reading thread
periodic. period = %lu, nano2count(period) = %lu\n", (usigned
long)period, (unsigned long) nano2count(period) );
After the call of
rt_task_make_periodic_relative_ns( thread[DMM16_THREAD_READING],
nano2count( start_time ),
nano2count( period ) ) != 0 )
the system freezes because of the task code wich will than runn
permanent.
The above is used incorrectly, see the new PDF manual at:
http://www.aero.polimi.it/projects/rtai/.
Someone should add the newest documentation to the rtai-1.4 package.
Assuming delay_from_now and period are in nanoseconds it goes as:
rt_task_make_periodic_relative_ns(thread[DMM16_THREAD_READING],
delay_from_now, period);
Even if you have no manual, rgrep the wealth of available examples and
you'll immediately get how it is used.
-- [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/
Re: [rtl] nano2count
Vasili Goutas wrote:
Thanks for the answer,
I now can't get the process to runn periodic.
I try folloing calls inside the process wich is started whith
rt_task_resume after initialisation.
start_time = msec2start * 1000 * 1000; //start in X nanosec
rt_sleep( nano2count( start_time ) );
rt_set_periodic_mode();
rtl_printf ( KERN_DEBUG
"RTAI dmm16: going to make reading thread periodic.\n" );
if ( rt_task_make_periodic_relative_ns( rt_whoami(),
100,
period ) != 0 ){
rtl_printf( KERN_ERR "RTAI dmm16: error making reading thread
periodic\n");
return;
}
do {
rt_task_wait_period( );
...
}while(1)
When you do rt_set_periodic you stop any running timer. The sequence is:
rt_set_periodic_mode();
start_rt_timer();
Beside the fact that it does not make sense to set the timer mode after
having starting the timer, you must not do that in tasks but at the
initting of your module. Note also that the periodic mode is the the
default one and need not to be set, if you never used oneshot before.
Moreover what's the type msec2start? Hope long long, or you get into
trouble if it is sligtly more that 4000.
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/
Re: [rtl] nano2count
Paolo Mantegazza wrote: I'm not sure if I understand who the periodic mode runs. First I have to declare that the specified task will run periodicaly with a period of ns or units, depending which function is called. Then the task runs until a call of rt_task_wait_period(). This period is the one defined in the m,ake_period call. If start_rt_timer() has never been called, the task will never resumed ? Does start_rt_timer( period ) defines the same period as in the make_periodic call ? When you do rt_set_periodic you stop any running timer. The sequence is: rt_set_periodic_mode(); start_rt_timer(); In the examples directory in the stress module I found following #define ONE_SHOT ... #ifdef ONE_SHOT rt_set_oneshot_mode(); #endif period = start_rt_timer(nano2count(TICK_TIME)); expected = start = rt_get_time() + 10*period; rt_task_make_periodic(thread, start, period); ... Why is here first set the oneshot mode? Also the manual for rt_set_oneshot_mode says that before each start_rt_timer call rt_set_oneshot_mode should be called. Beside the fact that it does not make sense to set the timer mode after having starting the timer, you must not do that in tasks but at the initting of your module. Note also that the periodic mode is the the default one and need not to be set, if you never used oneshot before. Moreover what's the type msec2start? Hope long long, or you get into trouble if it is sligtly more that 4000. Its of type RTIME 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/
Re: [rtl] RTNET / Linux Trace Toolkit
Joachim Herb wrote: Joachim Herb wrote: - In your package TracePackage-0.9.3.tgz you included patches named: patch-ltt-rtai-22.2.4-000822 and patch-ltt-linux-2.2.16-with-rtai-22.2.4-000822 As there is no RTAI-22.2.4 on the RTAI website, and the version of RTAI for the linux kernel version 2.2.16 is RTAI-1.4, I think your patches are for this version? Sorry, now I have seen that it is for RTAI-1.3a. But its not too hard to get it working with 1.4. Does someone get it working with RTAI-1.4? Vasili -- [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/
Re: [rtl] nano2count
Vasili Goutas wrote: Paolo Mantegazza wrote: Please be careful, what's below are not my words but yours. I'm not sure if I understand who the periodic mode runs. First I have to declare that the specified task will run periodicaly with a period of ns or units, depending which function is called. Then the task runs until a call of rt_task_wait_period(). This period is the one defined in the m,ake_period call. If start_rt_timer() has never been called, the task will never resumed ? Does start_rt_timer( period ) defines the same period as in the make_periodic call ? 1) - set the timer mode 2) - start the real time timer 3) do all the rest The period you use for a task has nothing to do with the timer period. Clearly if the timer is in periodic mode you cannot run a task with a period that is less than that of the timer. in periodic mode the period of the timer gives you the smaller time resolution you can use. When you do rt_set_periodic you stop any running timer. The sequence is: rt_set_whatever_mode(); start_rt_timer(); In the examples directory in the stress module I found following #define ONE_SHOT ... #ifdef ONE_SHOT rt_set_oneshot_mode(); #endif period = start_rt_timer(nano2count(TICK_TIME)); expected = start = rt_get_time() + 10*period; rt_task_make_periodic(thread, start, period); ... Why is here first set the oneshot mode? Also the manual for rt_set_oneshot_mode says that before each start_rt_timer call rt_set_oneshot_mode should be called. So what's wrong above? Have I read it correctly or do I need a pair of glasses? The answer is also below where it is said the periodic mode is the default. So clearly if you want it oneshot you must specifically ask for it. Beside the fact that it does not make sense to set the timer mode after having starting the timer, you must not do that in tasks but at the initting of your module. Note also that the periodic mode is the the default one and need not to be set, if you never used oneshot before. 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/
Re: [rtl] RTNET / Linux Trace Toolkit
Karim Yaghmour wrote: Hello Vasili, I've used the 22.2.4 stuff to patch over RTAI 1.4. The patch utility complains a little, but it successfully applies the patch. I haven't compiled the result, but it should work without a problem. Also, I haven't tried patching the related kernel source, but that shouldn't be a problem either. Give it a try and tell me if it works ... The RTAI-1.4 sources are no problem, but I tried to patch the kernel sources which was prepatched with the RTAI patch and get some error messages. Don't think that it will run without creating a new release of your toolkit containing a patch for linux-2.2.16 and RTAI-1.4. The result of my try to patch the kernel was: "patch -p1 patch-ltt-linux-2.2.16-with-rtai-22.2.4-000822" patching file Documentation/Configure.help patching file Makefile patching file arch/i386/config.in patching file arch/i386/defconfig patching file arch/i386/kernel/entry.S patching file arch/i386/kernel/i386_ksyms.c Hunk #1 succeeded at 33 (offset 1 line). patching file arch/i386/kernel/irq.c patching file arch/i386/kernel/process.c patching file arch/i386/kernel/sys_i386.c patching file arch/i386/kernel/time.c Hunk #2 FAILED at 79. Hunk #3 FAILED at 112. Hunk #4 FAILED at 248. Hunk #5 FAILED at 261. Hunk #6 FAILED at 306. Hunk #7 FAILED at 334. Hunk #8 succeeded at 241 with fuzz 2 (offset -233 lines). Hunk #9 FAILED at 254. Hunk #10 FAILED at 330. 8 out of 10 hunks FAILED -- saving rejects to file arch/i386/kernel/time.c.rej patching file arch/i386/kernel/traps.c patching file arch/i386/mm/fault.c patching file drivers/Makefile patching file drivers/trace/Makefile patching file drivers/trace/tracer.c patching file drivers/trace/tracer.h patching file fs/buffer.c patching file fs/exec.c patching file fs/ioctl.c patching file fs/open.c patching file fs/read_write.c patching file fs/select.c patching file include/linux/time.h Hunk #1 FAILED at 60. 1 out of 1 hunk FAILED -- saving rejects to file include/linux/time.h.rej patching file include/linux/trace.h patching file init/main.c patching file ipc/msg.c patching file ipc/sem.c patching file ipc/shm.c patching file kernel/Makefile patching file kernel/exit.c patching file kernel/fork.c patching file kernel/itimer.c patching file kernel/sched.c Hunk #2 succeeded at 76 with fuzz 2 (offset 34 lines). Hunk #4 succeeded at 508 (offset 34 lines). Hunk #6 succeeded at 881 (offset 34 lines). Hunk #7 FAILED at 1562. Hunk #8 FAILED at 1577. Hunk #9 FAILED at 1593. 3 out of 9 hunks FAILED -- saving rejects to file kernel/sched.c.rej patching file kernel/signal.c patching file kernel/softirq.c patching file kernel/time.c Hunk #1 succeeded at 66 with fuzz 2 (offset 34 lines). Hunk #2 FAILED at 100. Hunk #3 FAILED at 138. Hunk #4 FAILED at 200. Hunk #5 succeeded at 284 with fuzz 2 (offset 25 lines). Hunk #6 FAILED at 304. Hunk #7 FAILED at 463. 5 out of 7 hunks FAILED -- saving rejects to file kernel/time.c.rej patching file kernel/trace.c patching file mm/filemap.c patching file mm/page_alloc.c patching file mm/vmscan.c patching file net/core/dev.c patching file net/socket.c Vasili -- [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/
[rtl] Problems with RTNET
Hello, using rtnet I encounter the following problem: After a certain time I get lots of the errormessage: kfree_rtskb() skb=NULL When reload the card driver and the rtnet module the error message disappears but shows up later again. I have changed the example rt_echo_client to send an packet every 10 ms to an echo server. I use a semaphore for flow control (so the next packet is sent only if the previous was sent back by the server). The packet size is 1472 (the largest possible on my system). In the echo_recv handler I have added an rt_recvmsg() to receive the sent back message. In spite of the error message the connent of the message sent back by the echo server is correct. The rt_echo_client runs on RTAI-1.4 on top of linux-2.2.16, the network card is an 3Com 3c900 Boomerang 10Mbps Combo PCI and the used driver is 3c59x_rt_old. The server runs on a normal linux-2.2.16 (so "half-RT network"). If the server is also realtime (same card, same driver), then the same errormessages might also appear on ther server side. Once the following message appeared there, too: Too much work in interrupt state e081. Temporaily disabling functions (7f7e) What do these error messages mean and is there a problem? Thank you for your help. Bye Joachim -- Sent through GMX FreeMail - http://www.gmx.net -- [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/
Re: [rtl] RTNET / Linux Trace Toolkit
Vasili Goutas wrote: Karim Yaghmour wrote: Hello Vasili, I've used the 22.2.4 stuff to patch over RTAI 1.4. The patch utility complains a little, but it successfully applies the patch. I haven't compiled the result, but it should work without a problem. Also, I haven't tried patching the related kernel source, but that shouldn't be a problem either. Give it a try and tell me if it works ... The RTAI-1.4 sources are no problem, but I tried to patch the kernel sources which was prepatched with the RTAI patch and get some error messages. Don't think that it will run without creating a new release of your toolkit containing a patch for linux-2.2.16 and RTAI-1.4. The result of my try to patch the kernel was: "patch -p1 patch-ltt-linux-2.2.16-with-rtai-22.2.4-000822" patching file Documentation/Configure.help ... Hello, I patched rtai-1.4 the following way: First apply the patch and then resolve the conflicts manually. Most of the reject files can be ignored: Often you find constructions like: In rtai-22.2.4-ltt: #if 0 linux code #else RTAI code #endif in the official rtai-1.4 these have changed to #ifdef CONFIG_RTHAL RTAI code #else linux code #endif The rest are only a few changes. Then if you compile you get a few errors because definitions of functions have moved from kernel files to rtai.h. I works for me. Joachim -- Joachim Herb mailto:[EMAIL PROTECTED] -- [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/
Re: [rtl] unresolved symbols
Andrew Xiang wrote: I wrote a driver for linux. When I do depmod -ade, I get unresolved symbols on kmalloc, printk, register_chrdev? Although it does not affect the driver, the driver still works. But it is annoying to see it when redhat starts up since it does depmod -a everytime it starts up. why is that? thanks -- [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/ I had the same problem. It went away when I used added the rtl.mk file to my makefiles. Theo -- Theo ten Brummelaar The CHARA Array-Georgia State University-Mount Wilson Observatory http://www.chara.gsu.edu/~theo Ph: 626-796-5405 Fax: 626-796-6717 -- [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/
Re: AW: [rtl] Execution time of Realtime-Task
On Thu, 21 Sep 2000 [EMAIL PROTECTED] wrote: How much memory does it access in a single run? Right now it can be up to about 800k, depeding on the runtime configuration of the module. But it should be much less with the configuration I am running now. Anyway, if the system is not loaded, the memory accessed in RT task is likely to remain in the cache until next run, which runs then faster. It you run other things, caches are flushed more frequently. Could you compare the execution time ot the first run of the task to subsequent ones? Or suspend it for a minute, run some program accessing lots or memory, kill it, wake up your RT task, and again compare the first run to the subsequent ones? -- Tomek -- [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/
