[rtl] Forcing rtl_schedule() to be run
How do I do this so that it happens at exact times? I don't really want to write a one-shot task to do this... Seems a bit daft, given the situation. The exact times I'll want it to run will vary wildly. I know in advance when it will be needed, but not until run-time. Thanks, Gary -- [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/
Re: [rtl] Time Stamped Counter (TSC) jitter
On Tue, Dec 11, 2001 at 06:55:37AM -0600, Sheldon Hoffman wrote: To RTLinux [EMAIL PROTECTED] Hello all, I would like to use the pentium processor's Time Stamped Counter (TSC) to measure elapsed time with an accuracy of = 1 uSec. The TSC ticks at the frequency of the processor speed. So on a 333 Mhz computer, the TSC ticks at (approximately) 333,000,000 hz. In order to use the TSC as an elapsed clock, I need to determine the frequency (eg in Hz) of the TSC (ie many ticks the TSC makes per second). I was hoping someone might have some insights on how I can accurately determine the frequency of the TSC. As another note, I'm doing this testing under DOS (16-bit virtual 8086 mode) with interrupts disabled. I believe the same method should apply to RT Linux. I am seeing a TSC count of 331,113,713 +/- 35,000 TSC ticks per second on a 333 Mhz pentium II processor. This variance seems excessively large. Here are some other facts. 1. As recommended by Intel's IA-32 Intel Architecture Software Developer's Manual, I execute the CPUID instruction before executing RDTSC to serialize the TSC. The deal with this is that CPUID actually flushes the pipeline. With modern processors doing out-of-order processing and the like, the CPUID forces your RDTSC instruction to get executed _exactly_ in place instead of at some other random point in your program. [give or take...] Here's the algorithm I use to calibrate (determine the frequency of) the TSC: 1. synchronize the CPU with with the 8254 by reading it until it wraps (from x7FFF to 0). 2. execute CPUID and RDTSC. This is the starting TSC count. 3. Loop 36 times (36 =appx 1,193,180/32,768 = appx 1 seconds worth of 8254 ticks): A. wait for 8254 to wrap B. execute CPUID and RDTSC (and store in the final TSC count) 4. tscHz = (final TSC count - starting TSC count) * (36.0 * 32768.0 / 1193180.0); I know I'm pretty close to the right answer because when I run the program on various pentiums, I see approximately the correct TSC based on the Mhz of the processor. It is the magnitude of the variance (jitter?) that I don't understand. Any insights would be much appreciated! I'm happy to share code with anyone interested in this. What I have to question is... why? Why are you noncing about doing all this stuff? TSC is a simple register. It ticks once every clock cycle, by definition. It's actually on the chip and hard-wired to do this. If you want to know how many times a second it's going to tick, why not ask the CPU how many time a second that _it_ ticks? The main linux kernel has already worked this out once [you may like to have away with some of that code...], but why not use something like CPUID? It should tell you exactly what you want to know. And for reference, you may like to try adding bits of this to the RT Linux scheduler [easy; I've done it] instead of running it in just normal RT task-space. RTLinux is pre-emptive and stuff; you're just asking to be put in a world of hurt if you're trying to work things out this accurately, but doing it from the RT equivalent of user-space. Gary (-; PS Can I have a shufty at your source? I'm interested... -- [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/
Re: [rtl] make devices ?
On Tue, Dec 11, 2001 at 03:13:49PM +0100, Lilja, Michael wrote: Hi All, I have started using the RTlinux 3.1 package on Redhat 7.1 but have a problem when performing 'make devices'. It only works if I log in as root (which I can). I have several other developers who might need to perform the 'make devices' command also, and they do not have root privileges and will not gain root privileges, so how can I get the 'make devices' run. The problem is that non-root users cannot use the 'mknod' command. Hope someone has an answer (and I'm not interested in fakeroot) Well... technically, I guess you could do one of a few things: 1) Make mknod setuid root 2) give everyone write access to /dev... Why do multiple people need to do this? It only needs to be run once per filesystem with /dev on it. If you're using devfs, then you can just write a script to set up the devices at boot-time. Remember: mortal punters should never, ever, ever be allowed to do what you're asking to let the mortal punters do. And last point: In order for your developers to then run a RT task, they need to be able to run insmod. Which is just a downright daft thing to allow mortals to do. And running it setuid is hardly a good idea... If you're going to allow that in any way, the root account on your box can be breahched instantly. In fact, slightly worse than root is that you're allowing 100% kernel access to anything. Gary (-; -- [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/
Re: [rtl] Figuring out the state of a thread
On Tue, Dec 11, 2001 at 02:27:25PM -0500, Pablo Alvarez wrote: Hi all, For my implementation, I need to create new threads, let them run for a little while and die, and then keep creating new ones. Given that I cannot dynamically allocate memory within the RT context, I was thinking about having an array of pthread_ts, and cycling through it picking the first inactive thread when I needed a new one to create. But I cannot figure out how to find out, knowing only the thread handle, whether a thread is still alive (in which case I would want to leave it alone). Any suggestions? How about some shared memory, where each thread has a status byte it can us; writes some sort of I'm free to do some work to it... You wouldn't need to worry about locking or anything... Gary (-; -- [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/
Re: [rtl] Installation of RTLinux .... Please help me.
On Thu, Nov 22, 2001 at 03:18:30PM +0530, Gopalkrishna M R wrote: Hi, Trying to install the RTLinux. Downloaded the prepatched kernel from the web site www.rtlinux.org (rtlinux-2.2-prepatched.tar.gz). Then tried the following steps (as given in Sys Admin - 91, January 2001 issue). 1. Moved the above mentioned file to /usr/src directory then untarred it. 2. Removed the existing /usr/src/linux and created it using ln -s /usr/src/rtlinux-2.2/linux /usr/src/linux 3. Changed the directory to cd /usr/src/linux 4. Entered these commands make menuconfig -- selected the needed things and saved it. make dep make clean make bzImage While running this command it gave the following errors: -- checksum.S:231:badly punctuated parameter list in #define checksum.S:237:badly punctuated parameter list in #define make[2]: ***[checksum.o] Error 1 make[2]: Levaing directory /usr/src/rtlinux-2.2/linux/arch/i386/lib make[1]: ***[first-rule] Error2 make[1]: Leaving directory /usr/src/rtlinux-2.2/linux/arch/i386/lib make:***[_dir_arch/i386/lib] Error2 -- It has not created bzImage I have tried it on linux kernel 2.2 and 2.4. At both the places it gives the similar error messages. Processor used is K6-500 MHz and also Pentium 233 MHz (old motherboard). Can YOU please help me to overcome this problem? IIRC [it's been a while], you need to build stuff from within /usr/src/rtlinux/linux instead of /usr/src/linux because, even though they're symlinked to the same thing, it travels up from it's own dir to pull in some headers, etc. ie, building stuff in /usr/src/rtlinux/linux might access some stuff in ../include, ie /usr/src/rtlinux/include, which is subtly different from /usr/src/include Hope this helps, Gary (-; -- [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/
Re: [rtl] Still... how can I include unistd.h in C++ realtime modules?
On Thu, Nov 08, 2001 at 04:56:31PM +0100, Ivan Martinez wrote: Anybody help me with this, or you won't have a brand new DSLib v1.3.0 supporting C++ ;-) unistd snippage What do you need from unistd.h? The problem is that if you're in suitable kernel space for a real-time module, you won't be allowed most of the functions in unistd. poll() is right out. fork() doesn't makes sense... Gary (-; -- [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/
Re: [rtl] Patent / License issues
On Fri, Nov 09, 2001 at 01:25:11PM +0200, Abraham vd Merwe wrote: Hi! One thing that bothers me a bit about RTLinux which I thought you might help me with: To what extent is software covered under the RTLinux patent/GPL, i.e. it is obvious that if I were to extend the RTLinux scheduler or something that forms an integral part of RTLinux in some way, I'd have to release that changes under GPL/RTLinux patent, but what happens if I write an application that makes use of RTLinux real-time threads or a kernel module that uses real-time interrupts? May that software still be proprietary or are any derived works covered by the license/patent as well? 1) IANAL 2) The GPL sort of implies that if you're running at arm's length from a piece of GPL software, then it's not a problem. Specifically, if you modify, for eg, the scheduler, then those changes must be under the GPL. OTOH, if you write a random application [which happens to be real-time], it shouldn't be a problem. Gary (-; -- [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/
[rtl] Random question
What exactly does this achieve:
int pthread_wakeup_np (pthread_t thread)
{
#ifdef CONFIG_SMP
if (thread-cpu != rtl_getcpuid()) {
pthread_kill(thread,RTL_SIGNAL_WAKEUP);
rtl_reschedule_thread(thread);
} else
#endif
{
pthread_kill(thread,RTL_SIGNAL_WAKEUP);
rtl_reschedule_thread(thread);
}
return 0;
}
?
It's in rtl_sched.c, and, as I see it, if I'm running on an SMP box,
then your scheduler is doing an uneccessary comparison all the time,
and an unnecessary jump [branch? I can't ever remember which one's
which...] half the time...
Gary (-;
-- [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/
Re: [rtl] Problems with RDTSC examples posted here recently
On Sat, Nov 03, 2001 at 02:03:12AM +, [EMAIL PROTECTED] wrote:
Method2 is broken because it gives erroneous results.
In my original post I presented a small program that
called three different versions of a RDTSC functions
(1,2,2A) and only method 1 gave results that were in any
posssible way correct. Since these are three different
functions, there can't be any optimization issues
between the source code in the three functions and it's
not at all obvious -- at least to me -- where
a volatile declaration could be put. If someone could
post a modified version of my program in method 2 or
method 2a worked, I'd be very grateful.
---method1---
__inline__ unsigned long long int rdtsc(void)
{
unsigned long long int x;
__asm__ volatile (.byte 0x0f, 0x31 : =A (x));
return x;
}
---method2A---
__inline__ unsigned long long int hwtime(void)
{
unsigned long long int x;
__asm__(rdtsc\n\t
mov %%edx, %%ecx\n\t
:=A (x));
return x;
}
Things, severally:
1) Use __volatile__, not volatile. Just an ANISism for clarity.
2) The mov is, in practice, as much use as a chocolate teapot. You're
achieving absolutely nada.
3) In the case you're using 2A, [It's been a long time since I did any
serious assembly], don't you need to give some clobber registers?
Specifically, something like:
---method2A-clobber---
__inline__ unsigned long long int hwtime(void)
{
unsigned long long int x;
__asm__(rdtsc\n\t
mov %%edx, %%ecx\n\t
:=A (x)
:
: ecx);
return x;
}
Or %ecx, or whatever it is. Can't remember, as I'm not using it.
In the end, here's some actual code I'm now using:
/* Ripped straight out of vanilla kernel */
#define rdtscll(x) \
__asm__ __volatile__ (rdtsc : =A (x))
snip
long long int time_blocked,counter0,counter1;
do_some_funky_init_stuff();
while (1) {
rdtscll(counter0);
pthread_wait_np ();
rdtscll(counter1);
time_blocked = counter1-counter0;
rtf_put(fifo_out, (char *) time_blocked,sizeof(time_blocked));
}
/snip
Obviously, that achieves very little except to tell you what _other_
processes in your system are doing to aid in the jitter of your piece
of code.
But still, it gets the point across, yes?
Gary (-;
PS Norm, you've been instrumental in getting me this far, and 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/
Re: [rtl] Problems with RDTSC examples posted here recently
On Thu, Nov 01, 2001 at 02:54:37PM -0700, John Regehr wrote: Don't forget to make sure it's __volatile__, elsewise this is the very epitome of what would produce dodgy results... Right. So method2 and method2A seem to be broken in multiple ways - forget you ever saw them. Rather, look at this page: http://www-106.ibm.com/developerworks/linux/library/l-ia.html?dwzone=linux which has a nice explanation of inline assembly syntax for gcc, and even explains why method1 is the right way to code rdtsc. Yep. All of the above are conclusions I came to [and actually used] having read http://sag-www.ssl.berkeley.edu/~korpela/djgpp_asm.html Thanks, Gary (-; -- [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/
Re: [rtl] Problems with RDTSC examples posted here recently
On Wed, Oct 31, 2001 at 05:37:18PM -0700, John Regehr wrote: method1 : 23573589435592- 23573353927542 = 235508050 method2 : 23573353927556- 23573353927556 = 0 method2A : 23573353927607- 23573353927607 = 0 -- also m2_1 - m1_1 = 14 -- and m2A_1- m2_1 = 51 finally m2A_1- m1_1 = 65 Take a look at the code that gcc generates when compiling your program with optimizations. The rdtsc instruction is executed three times, the program sleeps, and then rdtsc is executed only once more - hence the strange results. method2 and method2A are broken. I don't understand what the mov edx, ecx instruction in these functions is supposed to accomplish. Assuming that it is useful, you'll still need to inform gcc that you're clobbering ecx. method1 or something like it is what I've always used. Don't forget to make sure it's __volatile__, elsewise this is the very epitome of what would produce dodgy results... Gary (-; -- [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/
Re: [rtl] getting problem in make bzImage
On Tue, Oct 30, 2001 at 09:55:32AM +0530, Megha jindal , Gurgaon wrote: Hello Sir, We are installing rtlinux-3.0, on redhat- linux7.0 having kernel_patch2.2 . All the steps we have done 1. Installed redhat linux7.0 on Pentium. 2. Followed all the steps given in the installation guide available on the site (rtlinux.org). while creating an image (make bzImage), there is an error init/main.o: In function `check_cx686_cpuid': init/main.o(.text.init+0x2dc): undefined reference to `irq_control' init/main.o(.text.init+0x32d): undefined reference to `irq_control' init/main.o: In function `check_cx686_slop': init/main.o(.text.init+0x393): undefined reference to `irq_control' init/main.o(.text.init+0x3d5): undefined reference to `irq_control' init/main.o: In function `start_kernel': init/main.o(.text.init+0xc63): undefined reference to `irq_control' arch/i386/kernel/kernel.o(.text+0x6): more undefined references to `irq_control' follow Kindly suggest us how to proceed . _which_ 2.2 are you trying? And several things: RH7.0 is known to be crap at compiling kernels, anyways. Dump it [or at least use kgcc instead of gcc as your compiler] Also, 3.1 is available on the FTP site. Try using that instead, and and if you _must_ use 2.2, that one should patch against 2.2.18. As with any kernel patches, YMMV if you use patches from the wrong version... Hope this helps, Gary (-; -- [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/
Re: [rtl] Intel Hardware Performance Counters
On Mon, Oct 22, 2001 at 04:01:12PM +0200, Der Herr Hofrat wrote:
Hi !
same code just a bit more human redable...to check the jitter of a system -
note that the jitter reported is a theorectical one as it is the delay that
can be introced between any two calls on a non-rt system. compile it and run
it on a idle box - if you let it run long enough you will see 1s maximum !
if you load the box heavaly (pingflood , multiple ls -lR / , compile kernel
with make -j 60 ...) you will find half second jumps happening quite soon.
(just ran it on a PIII/800). You also might want to look at the gethrtime
function in rtlinux (rtlinux-3.X/schedulers/i386/rtl_time.h)
Hi.
Thank-you VERY much for this, it's really helpful. Except...
Currently, it works fine for user-space stuff. It quite happily sits
there teling me how long it took between calls.
Except that as soon as I migrate it to kernel-space [rt or not], I get
nada. Below is a butchered variant on hello.c. Am I missing anything
horrible obvious?
Gary (-;
PS I've also discovered that calling the macro rdtsc is bad, because
someone else already got that name, and it was causing many compile
issues
snip
#include rtl.h
#include asm/io.h
#include time.h
#include pthread.h
pthread_t thread;
__inline__ unsigned long long int rdtsc_counter(void)
{
unsigned long long int x;
/* the CPUID instruction is mostly irrelevant; it just
flushes the pipeline for good measure */
__asm__(cpuid\n\t
rdtsc\n\t
mov %%edx, %%ecx\n\t
:=A (x));
return x;
}
void * start_routine(void *arg)
{
struct sched_param p;
int f = 0;
unsigned long long int cpu_ticks_before,cpu_ticks_after;
p . sched_priority = 1;
pthread_setschedparam (pthread_self(), SCHED_FIFO, p);
/* Mental note: 5 nanoseconds is 1/2s */
pthread_make_periodic_np (pthread_self(), gethrtime(), 5);
while (1) {
cpu_ticks_before = rdtsc_counter();
pthread_wait_np ();
rtl_printf(I'm here; I've got to %i, , (int) f);
f++;
cpu_ticks_after = rdtsc_counter();
rtl_printf(And it took %i clock cycles\n, (int) (cpu_ticks_after -
cpu_ticks_before));
}
return 0;
}
int init_module(void) {
return pthread_create (thread, NULL, start_routine, 0);
}
void cleanup_module(void) {
pthread_delete_np (thread);
}
-- [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/
Re: [rtl] depmod: Unresolved symbols in ....
On Fri, Oct 26, 2001 at 08:49:31AM +0900, Shoji KASAI wrote: Hi. I try to install rtlinux-v3.1 to RedHat7.1J(kernel 2.4.4). I make the kernel 2.4.4-rtl bzImage without modify the CC = kgcc of Makefile, and I can boot the kernel 2.4.4-rtl ( see the mail-header of this). But, I had error of depmod -a, as follows. And, I can't use rtlinux system. [root@poco skasai]# /sbin/depmod -a depmod: *** Unresolved symbols in /usr/rtlinux-3.1/modules/psc.o depmod: *** Unresolved symbols in /usr/rtlinux-3.1/modules/rtl_fifo.o depmod: *** Unresolved symbols in /usr/rtlinux-3.1/modules/rtl_posixio.o depmod: *** Unresolved symbols in /usr/rtlinux-3.1/modules/rtl_sched.o depmod: *** Unresolved symbols in /usr/rtlinux-3.1/modules/rtl_time.o [root@poco skasai]# I have psc.o, for example, as follows. [root@poco skasai]# locate psc.o /usr/src/rtlinux/rtlinux-3.1/psc/psc.o /usr/src/rtlinux/rtlinux-3.1/modules/psc.o /usr/rtlinux-3.1/modules/psc.o /lib/modules/2.4.4-rtl/misc/psc.o [root@poco skasai]# What should I do in my system, Please advice me. Try a depmod -ae and see what it says Gary (-; -- [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/
[rtl] Intel Hardware Performance Counters
I'm reading up about Pentium processors and their hardware counters, for eg, counting the exact number of cycles a CPU ticks while doing a particular task. Has anyone tried playing with this? I'm not afraid of intel assembly, but I'm having trouble finding a simple example; something like set regXXX to zero, set regYYY to 3, then read back regXXX when you're bored. Has anyone tried things like this? I'm trying to get some more accurate [down to the nearest clock cycle] information out of schedulers... Thanks, Gary (-; -- [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/
Re: [rtl] create thread from thread?
On Fri, Oct 12, 2001 at 04:17:39PM +0100, David Hamilton wrote: Is it allowed to create a thread from within a thread in the real-time kernel? I can create two threads from the init_module function, but if I try to create the second from within the first thread, my system crashes big time!!! Well, you could probably pull it off with some scary voodoo, but I wouldn't recommend it. Doing real-time htings, then copying a vast block of memory and invoking stuff in it, with all that entails? You're better off creating a variety of thread pool in init_module as a one-off instead of trying to create threads by others that're doing RT things. Gary (-; -- [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/
Re: [rtl] Help on real time scheduling
On Fri, Oct 12, 2001 at 12:24:00PM -0400, Dresner, Norman A. wrote: You're probably using a computer with an x86 architecture. AFAIK, every Linux implementation except the Alpha CPU uses a clock rate (jiffies) of 100 Hz or 10 ms; the Alpha uses 1 Khz. Your choices then are: 1. Use an Alpha with normal Linux and hope for the best 2. Use Real-Time Linux (RTLinux) on any platform it's been ported to. Hang on. Aren't jiffies worked out at boot-time, or is that only because I've only read the source for the x86? I'm sure I remember linux doing some timing loops to discover BogoMips, then working out how big a jiffy is from there? [Note: I _would_ read the source, except my machine went out of contention and now I'm on a friend's box that's only windows] Gary (-; -- [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/
Re: [rtl] virtual memory
On Mon, Oct 01, 2001 at 10:53:44AM -0400, Calin A. Culianu wrote: On Sat, 29 Sep 2001, Chunky Kibbles wrote: On Fri, Sep 28, 2001 at 01:14:46PM -0700, A V wrote: Hi, Does RTLinux uses virtual memory ? I hope not. Becaz real-time kernel should not use virtual memory. But in our RTLinux the module loading is taken care of by Linux kernel. Am i right ? Linux kernel uses virtual memory. How can Linux kernel know that it should not use virtual memory for RT-processes ? Please clear my doubt. Yes, the kernel support full virtual memory; there's no point in it not doing so. The memory, though comes in two varieties for this situation: kernel-space, and user-space. Kernel-space memory will never get swapped out, but user-space memory can be. RT Linux code actually runs as a kernel module [at least, the bit you code to be actual hard real-time]. This module runs in kernel-space, so will never get swapped out. Here's a bit of linux not-so-trivial trivia that I want clarified: Kernel memory doesn't get swapped out in linux, period.. right? I know some other OS kernels (especially microkernels) sometimes like to page out outter parts of the kernel If it's part of the kernel, it's not swapped. Full stop. Modules are considered part of the kernel Gary (-; -- [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/
Re: [rtl] virtual memory
On Fri, Sep 28, 2001 at 01:14:46PM -0700, A V wrote: Hi, Does RTLinux uses virtual memory ? I hope not. Becaz real-time kernel should not use virtual memory. But in our RTLinux the module loading is taken care of by Linux kernel. Am i right ? Linux kernel uses virtual memory. How can Linux kernel know that it should not use virtual memory for RT-processes ? Please clear my doubt. Yes, the kernel support full virtual memory; there's no point in it not doing so. The memory, though comes in two varieties for this situation: kernel-space, and user-space. Kernel-space memory will never get swapped out, but user-space memory can be. RT Linux code actually runs as a kernel module [at least, the bit you code to be actual hard real-time]. This module runs in kernel-space, so will never get swapped out. Gary (-; -- [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/
Re: [rtl] RTL and SMP
On Tue, Sep 25, 2001 at 12:16:26AM -0400, Calin A. Culianu wrote: Does RT-Linux work with multiple processors? If so, what is the idea behind how it can work? Can a real-time thread co-exist with the linux kernel on two different cpu's? If so--how is that magic accomplished? Yes, but the degree of functionality is relevant to which kernel you're using; there's no affinity at all in the 2.2 variant, for example... How is it accomplished? Well, you _do_ have the source... If it can't co-exist with the linux kernel on another cpu, then can multiple real-time threads co-exist on multiple CPUs? Black voodoo. Gary (-; -- [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/
Re: [rtl] Posix threads book
On Tue, Aug 28, 2001 at 06:52:35PM -0500, Jennings, Richard R wrote: Can anyone suggest a good book on practical use of Posix threads (pthreads) with example code, etc. All the books I have found seem to be out of date or have not so good reviews. The O'reilly one is excellent, IMHO http://www.oreilly.com/catalog/pthread/ Gary (-; -- [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/
RE: [rtl] DOUBT ABOUT PROGRAMMING RS232 USING C-lang
On Mon, 20 Aug 2001, Minich, Raymond C wrote:
2. It's embarassing to be obvously clueless.
I just get annoyed at people who won't help themselves and expect to
have others do their work for them...
Just my $0.02
Just mine.
Another question: I was playing with rtlinux, and getting compilation
errors, or, after that, unresolved dependencies. Eventually I traced
them back to the fact that rtlinux-3.1/include/reserve_cpu.h has the
definitions of rtlinux_suspend_linux_{init,cleanup} in it, but on my
machine, they were never getting picked up. The file was getting
included, but none of the defines were ever actually evaluated. I fixed
it with [DIRTY] just adding the noop ones at the end as a fail-safe.
But that's a fugly hack...
Can anyone tell me why that was happening? I'm using an SMP kernel
2.2.19, and it just wasn't getting to the logical point where it
defines either of those two functions; because it's SMP and 2.2, I
didn't have CONFIG_RTL_SUSPEND_LINUX defined.
Out of curiosity, why, also, do you use a piece of code there at all
for the noop? I sorry if I'm being truly dumb, but why get it to even
bother evaluating code such as
do {;} while(0)
?
And by the way; I solved the issues I was having with Andre's patches
to 2.2.19; pass the kernel the noapic option. Found that on a random
mailing list.
Sorry I was so stupid on that one and had to ask here...
Gary (-;
PS Is it worth my using 2.4.4 instead? IIRC, 2.4.4 had some pretty
horrific bugs, but I can't actually remember what they were,
specifically, so they may not be relevant to me...
-- [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/
Re: [rtl] I'm new to this, but
On Mon, 20 Aug 2001, Stephane List wrote: What is a sporadic scheduler ?? A sporadic task : OK, but a sporadic scheduler ?? Do you mean the One Shot mode ? Quote from the project definition: Implementing aperiodic servers in RT-Linux The aim of the project is to implement the Deferrable Server and Sporadic Server, two aperiodic server mechanisms, as additional scheduling policies in RT-Linux. The project involves setting up a RT-linux configuration and updating it with the two mechanisms. An evaluation of their implementation complexity and run-time overhead will also be performed. The project will also investigate the low-level implementation complexity of capacity sharing protocols. Thanks, Gary (-; -- [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/
[rtl] I'm new to this, but
Hi, I'm doing a final-year university project next year implementing two new aperiodic schedulers; a deferred one, and a sporadic one. Then some mathematical analysis on them... Anyway, I've been playing with rtlinux-3.0 [on kernel 2.2.18], and that was fine. I've now tried to upgrade to 3.1, with kernel 2.2.19, and I can't get Andre Hedrick's ide patches to work. Has anyone any experience of this? The drives on the first controller are detected, but then the system stops when it comes to try and detect drives on the second controller. Do I actually gain very much from using the newer kernel? And finally, has anyone actually done anything like those two schedulers before? Thank-you very much, Gary (-; -- [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/
