Re: [rtl] kernel memory limit
On Thu, Apr 19, 2001 at 05:41:27PM -0700, Basham, Richard R wrote: > Hello all, > > I am trying to use mbuff to allocate several named shared memory buffers from a >kernel module. I have 1 G of memory but I can't seem to allocate more than somewhere >just below 64 M of named shared memory from a kernel module. If I use malloc from >user space I can allocate nearly all of the 1 G. It appears that this has something >to do with a kernel limit. Has anyone come across this? Have you found a way around >the limit? > Hmmm... I thought the minimum reserved for vmalloc was 128 MB. The Linux kernel uses addresses above 0xc000 for it's own use. Into this area, it needs to map PCI space, the kernel code and data, vmalloc()'d memory, etc. Some kernels also have a 1-1 mapping of RAM in this area. Naturally, since the area above 0xc000 is 1 GB large, and you have 1 GB of RAM, there's not going to much space for anything else. If you enable CONFIG_HIGHMEM, it will only map physical RAM that it needs, and more of the address range is available for vmalloc, but unfortunately, this option is not available on 2.2. 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/
[rtl] ``Reply-To'' Munging Considered Harmful
http://www.unicom.com/pw/reply-to-harmful.html 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] Linux equivalents to pthread_make_periodic_np and pthread_suspend_np
On Fri, Apr 13, 2001 at 09:22:14PM +0200, Ivan Martinez wrote:
> Hello all:
> I'm trying to make DSLib v2 generate adecuated system calls depending on it being
>Linux, RTLinux, or RTAI. I'm looking in the Linux threads functions and I don't see
>any equivalent to pthread_make_periodic_np and pthread_suspend_np. Is there any?. If
>not, how can I perform such operations?.
> Thank you.
> Ivan Martinez
It can be duplicated using something similar to the attached
file.
dave...
/* Example of a periodic task using straight POSIX calls. */
/* Copyright 2001 David Schleef <[EMAIL PROTECTED]> */
/* Use, distribution, and modification are allowed under the LGPL. */
#include
#include
#include
#include
#include
#define PERIOD 10 /* 100 ms */
void tv_add_usec(struct timeval *tv,unsigned int usec);
int tv_compare(struct timeval *a,struct timeval *b);
void tv_sub(struct timeval *a,struct timeval *b);
int main(int argc,char *argv[])
{
struct timeval now;
struct timeval next_tick;
gettimeofday(&next_tick,NULL);
tv_add_usec(&next_tick,PERIOD);
while(1){
printf("tick\n");
gettimeofday(&now,NULL);
if(tv_compare(&next_tick,&now)<0){
struct timeval timeout;
timeout = next_tick;
tv_sub(&timeout,&now);
select(0,NULL,NULL,NULL,&timeout);
}
tv_add_usec(&next_tick,PERIOD);
}
}
void tv_add_usec(struct timeval *tv,unsigned int usec)
{
tv->tv_usec += usec;
while(tv->tv_usec>=100){
tv->tv_usec -= 100;
tv->tv_sec ++;
}
}
int tv_compare(struct timeval *a,struct timeval *b)
{
if(a->tv_sec==b->tv_sec)return b->tv_usec-a->tv_usec;
return b->tv_sec-a->tv_sec;
}
void tv_sub(struct timeval *a,struct timeval *b)
{
a->tv_sec -= b->tv_sec;
if(a->tv_usec < b->tv_usec){
a->tv_usec += 100;
a->tv_sec --;
}
a->tv_usec -= b->tv_usec;
}
Re: [rtl] Re: [realtime] ESC attendence ... ?
On Fri, Apr 13, 2001 at 01:36:59AM -0400, Peter Cavender wrote: > Because they are not a "real" company, just a couple of people hoping to > reap dot-com profits from a patent based on ancient prior art. Do not > confuse them with any of the for-profit RT Linux outfits with real > products, or any of the GPL patriots that are working on real-time > support. All they want is a royalty check in the mailbox. They couldn't > care less about trade shows or such. > > My advice is to ugnire FSMLabs and use RTAI. It is better anyway. > > :-) Your abilities to write flaimbait have not gone unnoticed. You even got me to respond -- I usually just read flamewars in amusement. Please do not attempt to advocate RTAI at the same time as bashing RTLinux and/or FSMlabs. RTAI discussion holds a relatively amicable position on this RTLinux mailing list, which we would like to keep. Contrary to popular belief, many of the RTAI developers have no specific dislike for RTLinux, and much of the software associated with RTAI also works with RTLinux. dave... (one of the RTAI maintainers) -- [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] Virus emails
On Tue, Apr 03, 2001 at 07:39:23PM +0200, Erwin Rol wrote: > Isn't it slowly getting time that the RTL mailing list admins > take responsibility and disable attachments ? It should suffice to bounce messages containing application/* mime types. 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] driver for computerboards das1200/jr
On Thu, Mar 22, 2001 at 04:19:51PM +, Willem Atsma wrote: > Does anyone know of a driver for this card, or if one of the other DAS > drivers can be used for it? The cb_pcidas driver that is part of Comedi should work with it. http://stm.lbl.gov/comedi 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] comedi from kernel
On Fri, Mar 09, 2001 at 03:52:36PM -0800, Basham, Richard R wrote: > David, > > I had not seen them. Thanks. I did get them and found that they were setup for use >under RTAI. > I made what I thought were the correct changes for RTLinux. When I compiled them I >got: Did you edit the Makefile to tell it where to find the Comedi include files? > /sbin/insmod it.o > it.o: unresolved symbol comedi_cancel > it.o: unresolved symbol comedi_lock > it.o: unresolved symbol comedi_command > it.o: unresolved symbol comedi_register_callback > it.o: unresolved symbol comedi_unlock > it.o: unresolved symbol comedi_command_test modprobe kcomedilib 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] comedi from kernel
On Fri, Mar 09, 2001 at 12:19:06PM -0800, Basham, Richard R wrote: > Hi all, > > Does anyone have a short example of how to use comedi from a kernel module. I was >hoping to get a short comparable example with the correct header files etc. > Have you looked at ftp://stm.lbl.gov/pub/comedi/realtime_comedi_examples.tgz? 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] Real-time drivers for NI 6703 analog output card...
(CC'd to [EMAIL PROTECTED]) On Wed, Feb 28, 2001 at 12:04:56PM +0100, Herman Bruyninckx wrote: > I need a driver for the National Instruments PCI-based analog output > board 6703. Does this exist already somewhere? > > It's not in Comedi. Unless it's just a trivial extension to Comedi... The 66xx series is quite a bit different than the DAQ-STC-based devices (61xx series), and so it is a non-trivial excercise to write a driver. However, there's a developer at NI who is interested in writing one. 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] Discrete integration algorithms
On Fri, Feb 23, 2001 at 12:41:29PM +0100, Ivan Martinez wrote: > Hello all, > I want to add an integrator block to DSLib. Could anybody point me to > documentation about discrete-time integration algorithms?. Has the > simple integration x(t+1)=x(t)+dx*dt an special name or I should call it > something like "SimpleIntegrator"?. Thank you. If you rewrite it in the form y(t) = y(t-1) + x(t), it looks like a trivial IIR filter. 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] IRQ conflicts.
On Tue, Feb 06, 2001 at 07:58:00AM +0100, Bart Thissen wrote: > "Daniel R. Schuette" wrote: > > > > My application is time critical so I would like to be able to use > > RTLinux's hard IRQ capabilities. However, since I have a large number of > > modules (six) on the CPCI bus there seems to always be a conflict between > > one of my modules and an IRQ line used by a Linux (non-RT) device. This > > creates a problem because my driver cannot service the Linux device's > > interrupt and RTLinux won't release the interrupt since my driver has > > registered a hard IRQ. > > > > The optimal sollution would to re-assign the IRQ lines so that there is no > > conflict. Unfortunately though the BIOS my system is using (AWARD) does > > not support this nor do I know of a way to do it in Linux. > > > There are only 4 interrupt lines on the PCI bus, which are shared between > the 6 slots and the AGP bridge. I think it's best if you register your irq's > as hard-irq and check in the handler if the irq is caused by a non-rt linux > device. In that case you can raise a software-interrupt to pass it to linux. > In that case the non-rt handler should be installed on this soft-irq. The number of interrupts on the PCI bus depends on your motherboard design. There are 4 interrupts _per slot_, which on typical older motherboards are physically linked to 4 interrupt lines going into the bus controller. However, this is not true on my alpha, which links the 4 interrupts on 5 slots to 20 separate IRQs, nor on my Tyan Tomcat II SMP motherboard, which links interrupt A on each card to IRQs 16-20. To answer the first question, if you are lucky enough to have an IO-APIC on the motherboard, you can compile the Linux kernel in SMP mode (for 2.2) or 'APIC support on UP' (for 2.4), and then you can reassign IRQs as necessary at boot parameters. Otherwise, you have to deal with a broken BIOS. 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] RTL + Low Latency patch interference?
On Tue, Jan 16, 2001 at 10:26:36AM +0100, Bart Thissen wrote: > > Does any body has experience with the low latency kernel patch and > RTL together? I did try this combination once, and found serious > problems under heavy load, maybe related to bad memory. I do most of my RTAI hacking (and all of my regular activities) with a 2.4.0 kernel patched with a combo of RTAI, LTT, low-latency, timekeeper, and a few random patches. I've seen no difficulties so far, but if you're interested in attempting to crash it for me, you can find the patches at ftp://ftp.zentropix.com/pub/ds/patches. I tend to upload it only when people ask me, though. 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] Problems with RTNET (rtifconfig)
On Wed, Jan 10, 2001 at 05:38:00PM +0100, Janis wrote: > I have problems with RTNET installation and usage. > I use RedHat 6.2, RT Linux 2.3 (as well as RTAI 1.4, RTAI 1.6), > RTNET-0.9.0 > 1. When I install RTNET the file /include/modbuild/config.h is not > found. > Therefore I create directory /include/modbuild/ , rename and > copy file > /home/rtnet-0.9.0/tmpconfig.h > as file /home/rtnet-0.9.0/ /include/modbuild/config.h. > I don't know is it right operation, but compilation process > completed successfully > and ping works with driver 3c59x_rt_old. This is ok. It's a known bug that is fixed in CVS, but there hasn't been a bugfix release. > 2. The next problem is with rtifconfig, because device file " > /dev/rtnet" is not found. > It seems that device file "rtnet" is not registered. So I cannot > configure network and work > with RTNET in hard real time. run 'make dev'. 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] NI_PCI_Driver
On Fri, Jan 05, 2001 at 04:47:37PM -0800, Basham, Richard R wrote: > Hello, > > Does anyone know where I can find the latest > National Instruments PCI device driver (NI_PCI_Driver) ? > > I want to use it with a PCI-6033 card. It's part of the Comedi package, http://stm.lbl.gov/comedi. 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] serial card drivers
On Thu, Dec 21, 2000 at 10:00:56PM +0800, A.Han wrote: > Hi all, >I am developing a CNC(Computer Numerical Control) system basing on rt-linux 2.2, >and I am preparing to use some RS-232 serial card like moxa 104. I know there is >linux device driver for serial card, but does it work in rt-linux?(to be honest,I >know little about drivers) I want to do some output in rt threads,do I need a >rt-driver for the serial card? If I do, how can I get it, and how to use it? I really >hope to get your advise. >Thanks for your help, and merry christmas to all. > There is no real-time driver for the moxa 104 that anyone has announced. You have two choices a) port the moxa 104 driver to real-time or have someone else port it, or b) use one of the multiport boards based on standard PC UARTs (8250, 16450, 16550, etc.). It's been a few years since I've used multi-port serial boards, so I can't recommend one off-hand. 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] SBC 8260
On Wed, Dec 20, 2000 at 08:49:03AM -0800, Rafeeq Ur Rehman wrote: > > Has anybody used SBC 8260 from EST (Now Wind River). I want to try it but need to >know if anyone has tried this board earlier. > I've been porting Linux and RTAI to the Motorola 8260 ADS board, and both run fine. Recent versions of Linux have run on the SBC 8260 board, but few-days-old versions have had a little bit of brokenness. Once this is fixed (I have patches), both Linux and RTAI should run on the EST SBC 8260 board, as well. If you already have Linux running on the board, tell me the version of the kernel that you are using, and I'll send you a patch for RTAI. Then, you can build RTAI out of CVS, and we'll see what happens. 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] rtnet
On Mon, Dec 04, 2000 at 05:05:38PM +0900, Randolph Lee wrote: > Hello, > > Currently I'm working on a project using RT Linux for networking. I'm using > Rtnet V0.9.0. I was wondering if there is an RT function that is similar to > inet_addr or inet_aton (in arpa/inet.h). > You can use the function in_aton(), which is declared in . It is RT-safe. By the way, I'm working on a new home for RTnet, which currently is just a mailing list, but will soon be a CVS repository as well. Information can be found at: http://opensource.lineo.com/mailman/listinfo/rtnet The list address is <[EMAIL PROTECTED]>. 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] Unsolved symbols of COMEDI on minirtl2.3
On Sat, Dec 02, 2000 at 05:55:35PM +0800, Zaimin Zhong wrote: > Hi all, > > One more question about installing COMEDI on minirtl2.3. > > When I "insmod comedi.o", minirtl2.3 complaints about unsolved symbols: > > request_module > waitqueue_lock > > I have no idea which module is missing for comedi. Do you have any idea? It looks like a bug in Comedi. I would understand it better if I could find the .config file for minirtl. Any ideas? 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] rtnet
On Wed, Nov 22, 2000 at 03:19:28PM +0100, [EMAIL PROTECTED] wrote: > hi, > > I have to use an embedded Pc, a MOPSlcd4. I did the whole development > (of a rtp sniffer) on a normal PC as well as the tests. Then, the > precision of paquet arrival time is acccurate within the microseconds > (on normal PC). after that i did the same (with exactly same > application) on the embedded system and i got a time which is accurate > within only 10 milliseconds!!! I resume: > > on a normal PC: 12:45:30.146589 > on MOPSlcd4:12:45:30.14 Linux timestamps packets with get_fast_time() in the kernel. True to its name, get_fast_time() is implemented with a fast method of determining the current time. On a CPU with a TSC, it uses the TSC to get usec resolution, but otherwise it uses xtime, which is the time at the last 100 Hz clock tick, thus causing 10 msec resolution. If the kernel used do_gettimeofday() on a 486 for every packet, network speed would slow down a lot. This patch will cause a 486 to use do_gettimeofday() instead of xtime for timestamping packets: --- linux-2.2.17/kernel/time.c.orig Wed Nov 22 11:04:19 2000 +++ linux-2.2.17/kernel/time.c Wed Nov 22 11:17:53 2000 @@ -43,7 +43,7 @@ *tm=xtime; } -void (*do_get_fast_time)(struct timeval *) = do_normal_gettime; +void (*do_get_fast_time)(struct timeval *) = do_gettimeofday; /* * Generic way to access 'xtime' (the current time of day). 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] Patch available: use 8254 ch.1 instead of ch.2
On Tue, Nov 21, 2000 at 05:05:47PM -0500, jason sodergren wrote: > > Hi, all. > > I've made a small patch to schedulers/i386/rtl_time.c in rtlinux-3.0pre8 > that allows use of the 8254's channel 1 instead of channel 2. > Use of channel 1 is selected by means of a module parameter. > > This is useful to my project because I'm using a 486-class system > that does not need channel 1 for DRAM refresh (it's based on the AMD > Elan SC400). This frees up channel 2 for the usual role of driving > the PC speaker. Note that timer 1 is used for other things, particularly APM. Using timer one on one of my machines works fine -- until I put it to sleep, at which point it blows up. And I haven't found a way to replace the original value. 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] I/O ports beyond 0x3FF
On Mon, Oct 02, 2000 at 09:14:12AM +0100, Alexandre Ap?stolo wrote: > In order to obtain access to the I/O port beyond 0x3FF I belive I have to call the >"iopl" Linux funcion. You believe incorrectly. 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/
[rtl] Re: Problems with RTNET
On Thu, Sep 21, 2000 at 06:18:38PM +0200, Joachim Herb wrote: > Hello, > > using rtnet I encounter the following problem: > > After a certain time I get lots of the errormessage: > kfree_rtskb() skb=NULL This means that some code is trying to free a buffer that doesn't exist. Obviously a bug. > 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) This is a case of "error between hardware spec and programmer". I don't know why this happens, and it doesn't look good, but it also doesn't seem to hurt too much. Send me your code, and I'll see if it causes errors on my machines. I won't be able to get to it for a few days, because I am physically separated from my test machines, which are currently powered off. 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] RTNET / Linux Trace Toolkit
On Wed, Sep 20, 2000 at 12:06:47PM +0200, Joachim Herb wrote: > Hello Karim, > > after reading your mail about the use of the LTT together with the RTNET > module, I would like to ask you some questions: > > - You wrote that the response time is <=65 microseconds. What is the > maximal throughput over the ethernet connection? What is the maximal packet size? > Is this the MTU value and is this value fixed or can it be changed? 65 usec is for small packets, add about 0.1 usec per byte for large packets because of the time it takes on the wire. The MTU value is 1500, and although some hardware supports larger packets, I wouldn't try. The maximum throughput is theoretically 100 Mbit/sec. This can actually be achieved on a full-duplex line. If you intend to use a non-full-duplex line, you need to have some kind of time-division protocol on top of rtnet, which will decrease throughput significantly. > - I asume that the interrupt of the network card is handled as a realtime > interrupt (by RTAI) and not as a normal linux interrupt. (It's shown this > way in your screenshot) Is this correct? Does the response time (or the > throughput) change under load? yes, no. > - When will your network card drivers be released? Do you (or anybody here > on the list) know when the next version of the RTNET module will be > released (and what cards will be supported)? ftp://ftp.lineoisg.com/pub/rtnet Working drivers are tulip and 3c59x, plus what Karim sends me in the near future. 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 and RTLinux
On Tue, Sep 05, 2000 at 05:05:56PM +0200, David Olofson wrote: > Tue, 05 Sep 2000 [EMAIL PROTECTED] wrote: > > > > Let's say I have N message buffers in a pool. What if > > > > there is no more free buffer? > > > > > > Then the design for your hard real > > > time system was wrong :-) > > > > Or system reached its limits. > > Yep, and the only options are a) redesign and b) upgrading the hardware. > > > It depends on your possibilities and intentions. > > What if amount of incoming data is unpredictable but you have > > to process at most as you can with a limited hardware? > > That's a kind of *soft* real time system, which is not really what RTL is > intended for. (Although the input->"some kind of output" latency could have a > hard RT requirement - but the memory allocation would still be soft RT.) You > can't optimize a single API for both hard and soft RT, at least not without > making it a major PITA to use if you want hard RT, so IMHO, it's a very good > idea not to mix these two kinds of systems up when discussing APIs. I don't think that "running out of memory" and "running out of CPU time" are fundamentally different things. It's just that with a memory allocator, you are notified of a lack of resources and can do something graceful instead of locking the machine. 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] Trouble upgrading to RT2.0
On Mon, Aug 28, 2000 at 11:31:41AM -0600, [EMAIL PROTECTED] wrote: > > First: /usr/src/linux/.config > > > > rtlinux-2.3-pre2: CONFIG_RTL=y > > > > rtlinux-2.3-pre3: CONFIG_RTLINUX=y > > Why was this changed? > > Why is this referenced in comedi? So that Comedi can autodetect RTLinux. This is the reason I gave when I convinced you to originally put it in. Not a problem, the autodetect script can be changed as necessary. > > Second: linux/rtl.h: No such file or directory > > Is there any way to detect (#ifdef) the change from to > > It's easy to define > #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,3,0) > > We probably need a RTLINUX_VERSION_CODE too. Wasn't this discussion about source compatibility? Requiring that the user modify the source code to upgrade != source compatibility. 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] tcp-ip commands in rt modules
On Tue, Aug 22, 2000 at 04:13:03PM +0200, Wilken Boie wrote: > > If you _do_ need it from the RT side you could look at this package >ftp://ftp.lineoisg.com/pub/rtnet/rtnet-0.9.0.tgz). > It is restricted though in serveral ways (e.g. support for UDP only and > currently only on type of NIC). ^^ two!?!?! (I worked very hard for the second NIC. =) ) Actually, the reason that there aren't more supported is because tulip devices are a) cheap, b) reliable, c) multi-vendor and d) available in many different configurations, including multiple- channel, PCMCIA, 100baseT, fiber, etc. I also don't have time. If anyone has other good chipset candidates, I'll put it on My List. 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] Real Time in realtime ?
On Tue, Aug 22, 2000 at 03:03:25PM +0200, Klaus Keppler wrote: > Hi, > > How can i get the Real Time ( seconds since 1970, time_t) in an > rt-thread. I need this time as timestamp for my aquired data. > > Because the system-time on my rtlinux-box drifts away many seconds the > day, i would like to get the time from the RealTimeClockChip on the > processor board, converted to time_t. If you are only interested in seconds, you can use xtime.tv_sec, which is generally not going to be off more than 10 ms, is monotonic, and can be read atomically. I have a kernel patch that reimplements the way that Linux keeps time, making it completely dependent on the TSC instead of the TSC/timer-1 hybrid approach that is used now. One of the side effects (i.e., the main reason I wrote it) is that you should be able to call gettimeofday() from a real-time task. The real-time part isn't completely implemented yet, however, because I started working on other stuff. It will be at ftp://stm.lbl.gov/pub/realtime/patch-*-timekeeper whenever I upload it. You should also consider running NTP if your clock drifts badly. 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] FW: sprintf for floating point numbers in rt module
On Fri, Aug 11, 2000 at 02:39:08PM +0200, Pavel Andris wrote: > > Hi Janet and all, > > my quick and dirty packet is nothing but a collection of about 250 > sources + includes from glibc. Only i586 architecture is covered. The > sources were collected to cover sprintf() + sscanf() needs of my RT > threads. I do lot of floating point operations and it is essential for > my application. > > Actually the glibc sources were (almost) not modified and I declare I > don't understand them. I wrote only a simple Makefile to get a lib > that is partially linked (ld -r) with my RT modules. > > The lib contains e.g. unmodified malloc and friends that crash a > computer very reliably when called from a RT thread, as > expected. That's why I gave up publishing the lib. In spite of this > sprintf and sscanf work fine. Anyway I should investigate if they call > any dangereous function. > > I provided the lib to 2 or 3 people who asked me for a tarball but I > received no feedback from them. > > Some time later I realized that the same result could be possibly > reached by linking with standard libc (ld with right options), but I'm > just too lazy to try it. > > If you want the tarball in spite of everything mentioned above, drop > me a line, I'll upgrade README and send it to you. If you send me a copy, I'll put it into CVS so people can work on it. I'll also spend a little bit of time and make sure that it compiles with different distributions/kernels/RTs. This (libc functions for rt modules) is something that needs to happen, and you seem to have the best starting point. 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] About size
On Thu, Aug 10, 2000 at 09:25:06AM -0400, Binu Balakrishnan wrote: > Hi RTLinuxers, > > What is the size of the basic Linux kernel and what is that of RTLinux kernel? On i386, a compiled Linux kernel is about .5 to 2 MB, depending on which options are configured. My laptop, 2.4.0-test4-ds1, with a lot of options enabled, is at the higher end, my 486 running 2.0.37, is at the lower end. (This is the size of _uncompressed_ kernel images.) For 2.2.14-rtl2.3, the RTLinux module sizes on my laptop are: -rw-r--r--1 root root 122196 Jul 6 06:47 rtl_fifo.o -rw-r--r--1 root root 114864 Jul 6 06:47 rtl_posixio.o -rw-r--r--1 root root 329912 Jul 6 06:47 rtl_sched.o -rw-r--r--1 root root 320670 Jul 6 06:47 rtl_time.o 95% of the size is debigging symbols. After being stripped: -rw-r--r--1 root root 7708 Aug 10 11:31 rtl_fifo.o -rw-r--r--1 root root 6048 Aug 10 11:31 rtl_posixio.o -rw-r--r--1 root root 7952 Aug 10 11:31 rtl_sched.o -rw-r--r--1 root root10104 Aug 10 11:31 rtl_time.o 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] generating random numbers
On Wed, Aug 09, 2000 at 12:58:20PM +0700, Adi Sudewa wrote: > > Hi all, > > how to generate random integers from within real-time thread. > I need to generate random numbers so my simulation can be unpredictable. > It is not cool to have a train running with 20.00 m/s speed > all the time so I'd like to have the speed fluctuate round 20.00 m/s. The GNU Scientific Library has one of the finest collections of PRNGs, from the trvially simple to ones capable of real work, and then some capable of Real Work (tm). I'd pick a relatively simple one and port it to RT. 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] Problem with Digital I/O board
On Fri, Aug 04, 2000 at 01:52:16PM -0400, Bin Lin wrote: > Hello, > > I am writing a simple driver for National Instruments PCI-DIO-96 digital > I/O board. You might consider using the PCI-DIO-96 driver in Comedi. 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] Programming sockets in RTL?
On Wed, Aug 02, 2000 at 08:44:30PM -0400, Tony Mouawad wrote: > Is it possible to integrate a TCP/IP based server in an RTL module? I'm > not sure how to do this using the RTL libraries. No. You can use a user-space helper task that acts as your server, which is probably the best solution if you don't need hard-real-time operation from your server. (Not likely.) If you actually need real-time networking, you can use RTnet, although it doesn't work with TCP. Only UDP. (ftp://ftp.lineoisg.com/pub/rtnet) 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] AD-card
On Tue, Aug 01, 2000 at 01:40:09PM +0200, Peter T. Drechsler wrote: > Hi. > > Can anyone recommend me a decent AD-Card that runs under RTLinux. > Kernel is 2.0.33 with appropriate RT-Patch. Runs. > Could be PCI ot At. > Should have at least 8 analog inputs with gains (12 Bit is ok). > Should have 2 or more analog outputs, preferable 0-10V. Look at Comedi. http://stm.lbl.gov/comedi. Lots of boards supported. > I want read out thermoelements type K. Since the voltages are micro-V > I need gains in the order of 10, 100, 1000. Are you sure that you need real-time? Thermocouple leads make great antennas, and because of this are usually heavily filtered, sometimes using a 1 Hz low pass filter. The latency in the filter usually is greater than the latency of Linux. (This may be irrelevant if you have another need for real-time.) Also, it is usually recommended to use external amplification and filtering for thermocouple inputs. (And from personal experience: if possible, find a circuit that can detect disconnected thermocouples...) 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] rt_printk long long output
On Mon, Jul 31, 2000 at 01:32:33PM +0200, [EMAIL PROTECTED] wrote:
> > My question is a silly one : how to do rt_printk() of gethrtime() return
> > value. gethrtime() returns 64-bit signed integer (a long long int).
> > I already tried %q (quad int), %L, and %ll but they won't work.
>
> No more than two months ago we discussed this topic
> on the list. Check archive.
>
> The answer is: no longlong capability of printk() because
> it would require 64 bit division. However your processor has
> 32 bit arithmetic only and no math library linked with the kernel.
>
> Print the time in hex:
> print("%.8x%.8x", (long)((time>>32)&0x), (long)(time&0x));
>
A vsprintf() that handles %f and %lld would be a good candidate
for a kernel module C library. It is pretty clear that a patch
to the main kernel would not be accepted -- there isn't even a
global macro to do long long division because Linus wants to
remind everyone that using long long is crufty and bogus on the
i386.
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] rthal struct define
On Mon, Jul 31, 2000 at 10:36:43AM -0500, daniel sheltraw wrote:
> Hello RTAIers
>
> It looks like rthal is defined in the modified irq.c. When I try to
> install a new SVAGlib I get a error that rthal is undefined which halts the
> install. Why isn't rthal defined in a header file which
> one could then #include in an include file of any new software
> to be installed?
>
> Daniel
You are running into a number of problems:
1. Your distribution uses symlinks from /usr/include/{linux|asm} to
/usr/src/linux/include/{linux|asm}. This is wrong. Keep in mind
that this has been wrong for about 5 years, but everyone *thinks*
it is right because Red Hat does it.
2. SVGAlib assumes that kernel header files are acceptable for
compiling a user-space program and/or library. This is also
wrong. Notably, compiling SVGAlib against an SMP kernel will
cause similar problems with undefined __global_cli and friends.
3. SVGAlib uses cli() in user-space. This is borderline stupid
on SVGAlib's part. Unfortunately, due to the design of SVGAlib,
this is required. (Borderline stupid == can cause lockups.)
Anyway, what is wrong with using the SVGAlib binary that is
packaged with your distribution? It will cause higher latency
for real-time interrupts (because of cli() in user-space), but
it works.
Also, there are options other than SVGAlib, including using GGI,
KGI, kernel framebuffer, or (my personal favorite) a stripped-down
X server.
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] Interrupts
On Tue, Jul 25, 2000 at 05:25:40PM -0600, [EMAIL PROTECTED] wrote: > On Tue, Jul 25, 2000 at 02:07:20PM -0700, David Schleef wrote: > > Why don't you just use a Linux-like void *dev_id? Is it the > > migration difficulties in changing function prototypes, or is there > > some fundamental reason? The lack of a callback handle really makes > > writing correct drivers a pain. > > sigaction provides the irq# -- so if you want that information, use the > sigaction interface. I'd rather make the RTLinux environment > look like Posix threads than like the interior of the Linux kernel. > The interior Linux kernel is much more complex, much less familiar, and > guaranteed to be not stable. I think it is a fundamental error to use > Linux internal operations as an API. I agree about the inherint long-term stability of Linux interfaces (except that the irq prototype hasn't been changed since 1.1.17.) But not having Linux-like interfaces available means that it is much more difficult to port drivers from Linux to RTLinux. > But I don't see the problem even with the rtl_request_irq interface. > After all, it is a one line function to provide the functionality > you want. Am I missing something? Maybe you can give me an example. It takes about 30 lines to get dev_id functionality. The irq number has to be converted to a dev_id using a lookup table, which means that you have to have functions to add/remove entries to/from the lookup table as well as the ISR wrapper. Even with this, you can't share interrupts because the irq is not unique. If you want the full cruft, look at the comedi source. Note that the RTL V1 prototype (void isr(void)) makes it completely impossible to have multiple devices using the same driver. I don't really care whether or not RTLinux supports dev_id, since the code in Comedi works as it is. I just copy the same code to new projects as necessary. 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] Interrupts
On Tue, Jul 25, 2000 at 01:42:42PM -0600, [EMAIL PROTECTED] wrote:
> On Tue, Jul 25, 2000 at 07:15:43PM +0200, Tomasz Motylewski wrote:
> > On Tue, 25 Jul 2000 [EMAIL PROTECTED] wrote:
> >
> > > 1. Can I use one funtion several times as interupt handler ?
> >
> > Yes, you can.
> >
> > > 2. How can I find out which interrupt triggered the handler function ?
> >
> > Very good question ! I was searching once and I was not able to find an
> > answer.
>
> Define a capture function for each irq
>
> catch_irq_10( ...){ common_irq(10); ...}
>
> Or, in V3 RTLinux us the sigaction call to install a handler and the
> first argument is the irq#, or, in earlier versions of RTLinux
> use rtl_request_irq and the first argument is the irq#, or you can
> can extract the signal number from the pt_regs argument -- in x86 it is in
> the eax field.
Why don't you just use a Linux-like void *dev_id? Is it the
migration difficulties in changing function prototypes, or is there
some fundamental reason? The lack of a callback handle really makes
writing correct drivers a pain.
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/
[rtl] RTnet -- real-time networking
After a long period of continued improvements and bug fixing, I'm happy to announce the availability of RTnet, developed by Lineo ISG (formerly Zentropix). RTnet is a modification of the existing Linux networking subsystem to provide real-time performance for sending and receiving packets over standard IP networks. The IP, ICMP, and UDP protocols are supported. TCP is not supported, because it is not possible to make it real-time. The programming interface is identical to the standard sockets interface, making it (almost) source code compatible with user-space applications that use Linux networking. Since it is based on Linux networking, RTnet should be able to communicate with existing network stacks. RTnet can be used with either RTLinux-2.3 and RTAI-1.3, and may be distributed and modified under the Gnu GPL. The code is still beta, but it is stable enough to be used in applications. Let me know if you have questions/find bugs, etc. Patches for new drivers and improvements are welcome. RTnet is available at ftp://ftp.lineoisg.com/pub/rtnet/rtnet-0.9.0.tgz. 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] Comedi and Minirtl...
On Wed, Jul 12, 2000 at 10:06:08AM -0700, Pete Buechler wrote: > On Wed, 12 Jul 2000, Herman Bruyninckx wrote: > > > We are trying to make MiniRtl floppies with Comedi drivers. But Comedi > > seems to need the libc, which is a couple of megabytes big. Is there > > another, much smaller ``embedded'' libc available? Is newlib from Cygnus > > such an alternative? Would it be possible to use it together with Comedi? > > 1) Try statically linking Comedi, it may be using only a small part of the > library. libcomedi hits some rather sensitive areas of glibc, so statically linking anything causes binary sizes of about 300 kB. It shouldn't be too hard to knock this down in some cases, i.e., changing a sscanf() to strtol() dropped the average binary size of the demos to 240 kB. Think I'll keep that change. 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/
[rtl] Re: system frozen with comedi and higher freq
On Mon, Jul 10, 2000 at 09:48:57AM +0200, Olaf Petzold wrote: > Hallo, > > some times ago I started this thread. Now some days later I had the time to > verify some things (with new comedi-0.7.45, mbuff-6.6), e.g. the hint of using > the right gcc: > > # cat /proc/version > Linux version 2.2.14-rtl2.2 (root@rtreg) (gcc driver version 2.95.2 19991024 >(release) executing gcc version 2.7.2.3) #10 Mit Jul 12 09:57:32 CEST 2000 > > So I recompiled the kernel, module, mbuff and comedi with the gcc 2.7.2.3 > (without smp support). I insmoded the module from runlevel 1: > > About 4 kHz the systems slows down. About 4.5 kHz I will get into troubel, > while rmmod the rtreg I got a lot of kernel oops (see attachement). Whats going > on ? The first oops appears to be caused by some code in the kernel attempting to jump to a user-space address. This could either be due to memory corruption or dangling pointers. Could you send me your code, so I can crash my computer? 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] clock questions
On Wed, Jul 05, 2000 at 05:32:35PM -0500, daniel sheltraw wrote: > Hello RTers > > > A couple basic questions for yall, > > I have a PII machine. When I look in /proc/ioports I see "timer" listed once > with associated port addresses 40h-5fh. > > Q: Is all this address space for one PIT only? No. It is a 8253-compatible chip, which has 3 timers. Ports 0x44-0x5f are aliased to 0x40-0x43. Timer 0 is used for the 100 Hz clock interrupt (Linux) , and one-shot or periodic clocking in RTAI and RTLinux. In some cases, the Local APIC timer on the Pentium may be used. Timer 1 was historically used to refresh DRAM. This is no longer the case, typically. Several of my machines work fine when you reprogram timer 1, but my laptop crashes any time the APM BIOS is entered if timer 1 has been modified. The output of timer 2 is connected to the PC internal speaker, and is responsible for the freqency of the console beeping. If you are willing to give up the console beep (who isn't? I find it annoying...) then you can use timer 2 for other purposes. Only timer 0 is connected to an interrupt. (IRQ 0) > Q: Which counter (and PIT if more than one is available) is being >used for RTLinux (or RTAI)? Both use Timer 0 for timing purposes, if a Local APIC is not available or not enabled. RTAI uses timer 2 to emulate a TSC. > Q: By "time-stamp clock" does one mean system clock? No. Time stamp _counter_ refers to the Pentium-internal counter, which increments at the processor core frequency. It can be accessed much faster than the 8253 timers, is more accurate, and overflows less often. > Q: How does any of the above differ for the 486? Most 486's don't have a TSC. (Some clones do.) 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] Is it possible to perform network operations from RTLinux task?
On Thu, Jun 29, 2000 at 03:20:47PM -0400, Ajay Avasthi wrote: > Is it possible to send out UDP packets on a network from an RTLinux > task? If so, how? > > Ajay > If you don't need real-time performance, use a user-space helper task. If you _do_ need real-time performance, Lineo ISG (a.k.a., the artist formerly known as Zentropix) will be releasing a real-time networking package "any day now." I know, we've been saying that for a long time now, but it is now possible to allocate some resources to clean it up and stabilize additional drivers. Since it is derived from Linux networking, it is, of course, GPL. 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] hrtime_t -> int
On Mon, Jun 26, 2000 at 09:22:44AM -0500, Cory Papenfuss wrote:
> I've (sorta) figured it out. The int must first be cast as a long long
> or the multiplication will overflow, but when I tried putting a division in a
> rt-space function to return miliseconds since boot, I get
>
> ./init.o: unresolved symbol __divdi3
>
> when I try to load up my init.o module. Is the access of the longlong division
> forbidden within rt-space?
Long long division requires a function call to a function that is
part of libgcc. Do to 'executive decision' in the kernel, i.e.,
it's been that way forever, libgcc is not linked with the kernel.
(Libgcc _is_ linked with the kernel for most non-i386 architectures,
however.) You have the option of making a difference 'executive
decision', and link your module with libgcc.
dave...
>
> BTW, getlrtime that produced that error is little more than
>
> unsigned long int getlrtime(void){
> return((unsigned long)((long long)gethrtime() / 100LL)
> }
>
> -Cory
> On Mon, 26 Jun 2000, Michael Barabanov wrote:
>
> > Cory Papenfuss ([EMAIL PROTECTED]) wrote:
> > > Hey all... I've got something that's been bugging me for awhile on this
> > > project. I really only need millisecond resolution (since I'm logging data to
> > > disk), but the hrtime_t doesn't like to be divided by 1000 (NS_PER_MS), as
> > > it's a funky type. Any way I can get around that and get a millisecond
> > > timestamp?
> >
> > What do you mean it doesn't like to be divided? hrtime_t is just
> > an alias for long long.
> >
> > > On a related note, I've got a user-space app that can send new
> > > pthread_make_period_np periods (again in [ms]). Problem is that if I try to
> > > send a time greater than 2147 ms, the machine craps out. I suspect it's a
> > > rollover on my
> > >
> > > looptime = * 100;
> > > pthread_make_periodic_np(thread[0], genesis+OFFSET, looptime);
> > >
> > >
> > > What's a good way to do arithmetic on these hrtime_t creatures?
> >
> > looptime = * (long long) 100;
> >
> > Michael.
> >
>
>
> -- [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] 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] unresolved symbols: check_region()
On Sat, Jun 17, 2000 at 11:52:57PM +0800, Zaimin Zhong wrote: > Hi! > > Sorry to waste the bandwidth, but I could not link following functions > > check_region() > request_region() > udelay() > > statically into my RTL module. Which libary must be linked when above > functions are called. > > Thanks very much! These are kernel functions. They are not available statically. 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] installation
On Sun, Jun 11, 2000 at 01:47:55PM +0100, Gordon Morison wrote: > When I do a depmod -a comedi.o I get > depmod: Can't open /lib/modules/comedi.o/modules.dep depmod -e comedi.o ^ The -e option tells you which symbols can't be resolved. 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] installation
On Sat, Jun 10, 2000 at 07:14:31PM +0100, Gordon Morison wrote: > Hello there > > After having installed RTLinux 2.2 I attempted to install comedi-0.7.44, but when I do a make install depmod returns Unresolved symbols for each of the comedi modules. Can anyone give me a hint as to what I have missed or what I have done wrong as I have been wrestling with this all day, I have looked through all the documention I have and I can't find anything. > > Thanks in advance > > Gordon Morison What is the output of 'depmod -e comedi.o'? 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] Many .O files to one loadable .O module with GCC?
On Tue, Jun 06, 2000 at 06:12:01PM -0500, Sheldon Hoffman wrote: > > > We are using Red Hat 6.1 on a pentium 233 Mhz with > Linux version 2.2.14-rtl2.2 (gcc version egcs-2.91.66 > 19990314/Linux (egcs-1.1.2 release)) #4 Sat May 20 08:52:04 CDT 2000 > > We are hoping to build a single loadable (INSMOD module compatible) > object module for RTLinux. The project consists of many (> 50) .C > files and associated .H files. > > We plan to use MAKE to compile each .C + .H file separately to a .O > file then build the final .O loadable module from all the individual > .O files. > > We can't figure out how to get GCC to accept a number of .O files > and create a single .O file that can be loaded into RTLinux with INSMOD. > > Can anyone suggest how we can build a single .O loadable module from > many .O files that were individually compiled using GCC? > ld -r -o big.o small1.o small2.o It is important, however, to make sure that small1.o and small2.o are compiled with the correct flags and that the .c files include the correct header files. Looking at the output of 'make modules' while compiling a kernel and watching the details really helps. The sound drivers are especially useful. 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/
[rtl] Re: PC104 A/D boards
On Mon, Jun 05, 2000 at 03:55:04PM +0200, Vasili Goutas wrote: > I'm looking for a PC104 A/D board supported by comedi with following > properties > 4 analog input, > 4 analog output decoupled, > 4 digital input, > 4 digital output decoupled, > hardware timer. > > It could also be two boards with these properties in sum. > If you know such a board, please send me an email ? > ComputerBoards (www.computerboards.com) makes several PC104 boards that are supposed to be identical to their ISA counterparts. Unfortunately, Comedi support for these boards is a bit sketchy, with a few individual boards in the DAS series being supported, while the others are supported if you can guess the magic to fit it all together. I've only recently been learning of details of all the DAS boards, and I'm strongly considering rewriting the DAS drivers in the near future. The other well-supported manufacturers, DT and NatInst, do not seem to manufacture PC104 boards. 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] APM alert !!!!
On Mon, Jun 05, 2000 at 12:34:45PM +0400, Michael Barabanov wrote: > Linux 2.3.xx kernels allow APM support to be built as a module. > This feature solves the problem for at least RTL 3.0. > > Michael. > How does compiling as a module help? 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] APM alert !!!!
On Thu, Jun 01, 2000 at 04:37:35PM +0100, Stuart Hughes wrote: > Hi Victor, > > Tried it on RTLinux 2.3/Linux 2.2.14. Exactly the same effect. If you > cat /proc/apm, the jitter jumps out to ~ 7 miliseconds. > > Regards, Stuart. > Every so often, a thread comes up in the Linux kernel mailing list about modifying the kernel to run APM inside a virtual machine, since APM also causes problems with SMP. There is already other code doing this, such as (I think) the VESA framebuffer code and BIOS calls on other architectures. Usually, the thread erupts into a flamewar about the stupidities involved with running something inside a virtual machine _inside_ the kernel. Supposedly, ACPI will solve these problems, except that a) ACPI doesn't work on my machine, and b) the user-space ACPI code was developed independently from the APM code, and thus is incompatible. Go figure. 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] driver for sound card
On Thu, May 25, 2000 at 08:16:41PM +0200, Thomas Gross wrote: > Hello, > > does anybody know, are there any driver or applications for a standard > sound card for rt-linux. I want it for data aquisition and noise analysis. > > Thomas Hmmm... bad idea. Sound cards have a few properties that make them good sound cards, but bad data acquisition cards. - input and output signals are currents, not voltages - input is generally heavily filtered, with unknown filters, but generally cut out anything below 20 Hz, around 50 or 60 Hz (depending on your local line frequency), and above 10 kHz. The <20 Hz filter is nasty, since it makes DC measurements impossible. - unknown absolute conversion between input current and sample value - dynamic input gain control - limited range of speeds - output generally has crappy electrical properties that do not cause audible noise, such as high frequency glitches. Having said this, I'm sure there is an application where this would be acceptible for measurement. 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] Driver
On Wed, May 17, 2000 at 11:06:40AM -0700, Matt Cheselka wrote: > > Dave, maybe I'm really missing something here. I'm referring to the > drivers in comedi-0.7.xx/comedi/drivers/*.c. Nothing in this source code > makes any mention of RTL or RTAI. The only things that do are actually in > comedi-0.7.xx/comedi/rtl.c and comedi_fops.c. The problem here is that > stuff like comedi_rtl_init() -- which to me sounds like a pretty important > function -- doesn't DO anything (everything is commented out)!!! Im my opinion, a good driver should simply do what it needs to do, and get out of the way of the operating system. The individual drivers are also somewhat OS independent, in that anything that is different between OSs is moved into the comedi core, and properly #ifdef'd. > What you're saying (and please please please excuse my stupidity if this > is wrong) is that comedi is already 'wired' to run under RTL or RTAI and > nothing has to be done to a particular driver except to modify it so it > becomes incorportated into comedi (attach, detach, subdevices, > etc). Meaning, I don't need to put any rt_task_init(), > rt_task_wait() stuff into my driver. Yes. Drivers work automatically with RTAI and RTL, provided that they don't do anything "RT-stupid", that is, call kernel functions that are not real-time compatible, register interrupt correctly, don't have any unbounded waits, etc. Hardware drivers in comedi are actually _really_ simple -- just a collection of functions that are called by the Comedi core to do specific jobs. Ask yourself why the driver is running a task. Is this really a driver, or an application/driver combination? I prefer to make drivers as simple as possible, so starting a task seems too high level. I can think of reasons why you might want a task, but not in a data acquisition driver. > I guess I have some confusion about what's going on in comedi/drivers and > comedi/realtime. comedi/realtime contains two "virtual drivers" that are actually applications disguised as drivers. They use real-time tasks to emulate features that exist on higher-level data acquisition boards. It's kind of cool to use them every once and a while, but if you are doing serious work that requires such features, it is better to buy a real board. However, they make nice examples if you are writing applications that use Comedi. > If the above paragraph is true, can you point me to where comedi decides > that a driver is to be run in RTL or otherwise? The driver is not "run in RTLinux" as you say. The application calls comedi from RTLinux. Comedi calls the hardware driver. The driver doesn't do anything RT-stupid. Thus, the driver works in real-time. (I will readily admit that comedi drivers do many things RT-stupid, but it is not generally an issue. Writing real-time drivers is a continual learning process.) 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] Driver
On Wed, May 17, 2000 at 02:19:40AM -0700, roux jean-denis wrote: >Hi all, > > Is there any open driver using RTAI (Ethernet driver > for example) that I could have in order to see the > real-time constraints ? > Look at Comedi, (http://stm.lbl.gov/comedi), which is a collection of data acquisition drivers that work (simultaneously) with both regular Linux and RTAI (or RTLinux). The only thing that I can point to as what makes them different as real time drivers is that the Comedi-to- low-level driver interface allows/encourages drivers to be real time. (And that Comedi provides a real-time interface.) 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] Labview
On Fri, May 12, 2000 at 08:27:17AM -0400, Crum, Bill W wrote: > Hi, > > Is Labview RT available for Linux, or just Windows? > > For discussion sake, how would rtlinux/labview benefit over Labview RT? > > thanks, > > Bill > RTLinux and/or RTAI allow you to use devices on the ISA and PCI busses. The NI RT boards are only capable of driving devices that are connected to them, specifically, the 60[34]0E and 6533E. The NI RT boards can probably give better latency and jitter, but only by a factor of 2 or 3. I'm not sure I'd be willing to pay USD 1500 for a 486/100 when I can buy a PIII/500 for significantly less than that. 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: FW: [rtl] Labview
On Thu, May 11, 2000 at 09:19:33AM -0700, Dan Samber wrote: > > I have a naive question: > How does Labview benefit from RTLinux? Alledgedly, the people at National > Instruments > have arranged things (via special drivers or some other mechanism) so > that there > are no ugly things like gaps in data acquisition etc. > > Can someone clear things up for me? > A good data acquisition board these days have hardware fifos that allow them to sample at full speed (>100 kS/s) without dropping samples. That being said, the operating system does have to guarantee _some_ maximum interrupt latency, in this case, at about 10 ms. Windows can handle this until you walk away and get a cup of coffee. I've never seen this failure under Linux (with my limited set of computers.) PCI cards using DMA allow you to increase this latency indefinitely, assuming you have enough RAM, and also assuming you have access to the driver source code... =) However, simple acquisition isn't very useful if your needs are more complicated than streaming input and output. Very quickly, it becomes necessary to record and generate synchronization events, accurate timestamps, etc. These things can be done trivially using an RTOS, but cannot be done accurately using LabView or any other user-space tool. Using RTLinux is essentially like using NI's plug-in real-time 486 boards, except that you can use existing ISA/PCI-based hardware. 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] RTL PCMCIA ADC driver
On Mon, May 01, 2000 at 09:32:32AM -0700, Steve Rosenbluth wrote: > > By the way, if anyone is interested in helping write a driver for the > National Instruments 200kHz 16 bit pcmcia ADC, there is someone starting > a driver in Australia: [EMAIL PROTECTED] NI just recently sent me one of these cards (thanks, NI) and it will soon work with Comedi. 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] RTLinux and RTimage processing
On Wed, Apr 26, 2000 at 12:51:56PM +0200, Cedric Hyppolite wrote: > PCI CNA AT-MIO-16-XE-50 Is supported. See http://stm.lbl.gov/comedi 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] code snippet to access Pentium timer
On Tue, Apr 25, 2000 at 08:43:27AM -0600, Doug Fortune wrote:
> Does anyone have a C code snippet to read the
> high resolution Pentium timer? I am presuming
> it is 64 bits.
>
#include
{
unsigned long low,high;
rdtsc(low,high);
}
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] gcc and g++ mbuff confusion. __attribute__((packed))
On Thu, Apr 20, 2000 at 03:59:51PM +0200, Olaf Petzold wrote:
> At first it's seems the compiler option -malign-double overides the
> attributes, it's important to know. Secondly why is there a difference between
> x1_t and x2_t ?? (it's interesting for me)
Because you made a typo.
typedef struct {
char c;
uint32 ui32;
struct s2 {
uint16 ui16[2];
- };
+ } s2_m;
} x2_t;
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] outw
On Fri, Apr 14, 2000 at 01:44:19PM +0200, Sylvester Drozdik wrote: > David Schleef wrote: > > > How are you slowing down IO? Linux has macros specifically for > > this, that is, outw_p() and inw_p(). This slows down ISA I/O by > > putting a fake bus access after the real one, which is useful if > > the board can't handle back-to-back I/O. > > For slowing down, I tried outw_p ( with and without REALLY_SLOW_IO defined) > - nothing. > Also tried three methods (below) with or without input command (before > or/and after output) - nothing. I adjusted the WAIT STATE jumper on the > board - nothing. You said that you are using a PCL-823. Did you mean PCL-832? Have you tried a really long wait, e.g., 1 ms or more? Then you could methodically decrease the wait to see if there is a limit. Also, a very long wait will show if this is a timing problem, or a problem with the order or way that outw() is called. It's hard to tell with neither a board nor full source. 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] outw
On Wed, Apr 12, 2000 at 04:13:23PM +0200, Sylvester Drozdik wrote:
> Hi,
> I'am working on a PCL823 board driver kernel module using outw and inw
> from . I should write subsequent 16bit ports within an IRQ
> routine -- but I can't. The first outw writes the port well, next ones
> do something else. Here the code:
> void intr_handler(void)
> {
> outw(v1,a1); // a
> outw(v2,a2); // b
> }
> If I comment out 'a' or 'b', it works.
> I've tried to slow down the IO, without being too slow for an IRQ.
> Nothing helped.
> Any Idea?
> Maybe it isn't an RTL specific issue...
It most likely isn't an RTL issue.
How are you slowing down IO? Linux has macros specifically for
this, that is, outw_p() and inw_p(). This slows down ISA I/O by
putting a fake bus access after the real one, which is useful if
the board can't handle back-to-back I/O.
Also, you might try inserting an inw() from the board in between
the outw()s, i.e.,
outw(v1,a1); // a
inw(a1);
outw(v2,a2); // b
Crazy as it may seem, I have seen boards that can't handle two
consecutive write cycles.
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] automating driver conversions
On Fri, Apr 07, 2000 at 02:03:24PM -0700, Willem Atsma wrote: > Hi, > > I wrote a driver and now I want to addapt it for RTLinux. Can anyone think of > reasons why I couldn't write a header file with macros to replace normal linux > calls with the appropriate rtl ones? Has anyone done this? > > Willem Drivers are usually designed in a 2 or 3 layer model, with the bottom layer (closest to hardware) being mostly OS independent, and depending mostly on the middle layer for its functionality. Linux drivers usually follow this model, especially the network drivers. There are 2 approaches to converting such drivers to real-time. One is to make the low-level drivers _completely_ real-time and non-real-time safe, and have the middle layer take care of the details of how RTLinux/RTAI/Linux work differently. This is the approach I've taken with comedi, mainly because I control the middle layer. Another approach is to develop a second, compatible middle layer, especially for real-time. This way, you can easily #define low-level drivers to be real-time, non-real-time, or dual, simply by changing compilation flags. This usually involves changing the names of the important functions from func() to RT_func(), and then using #ifdef DRIVER_RT #define RT_func() rt_func() #endif #ifdef DRIVER_NON_RT #define RT_func() func() #endif #ifdef DRIVER_DUAL #define RT_func() (some_flag?rt_func():func()) #endif That version is readable/understandable, but the following is easier to maintain for many functions: #ifdef DRIVER_RT #define FLAG 1 #endif #ifdef DRIVER_NON_RT #define FLAG 0 #endif #ifdef DRIVER_DUAL #define FLAG some_flag #endif #define RT_func() (FLAG?rt_func():func()) Naturally, this approach requires that you have the same prototypes for both rt_func() and func(), which is not the case for most functions that you may want to use. One such example is request_irq() and its equivalents in RTLinux and RTAI. The main benefit of this approach is that you are able to use the same binary module for both real-time and non-real-time, makeing testing easier. I've had sucess with both approaches, although the latter is simpler for porting existing code. Since you wrote the driver, I'd suggest the first approach, since you are in charge of all the source. If you driver doesn't follow a layered model, now would be a good time to fix it. 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] a shared interrupt service routine
On Thu, Apr 06, 2000 at 06:23:28PM +0200, Tomasz Motylewski wrote: > On Wed, 5 Apr 2000, David Schleef wrote: > > On Thu, Apr 06, 2000 at 01:46:01PM +0900, JunHyeok Heo wrote: > > > > The BIOS of my PC allocates the same irq number to > > > the video capture card and the on-board sound device. > > > Is it possible to share the same interrupt between the RTL driver > > > and the plain linux driver ? > > > Nope. Move the card to a different slot, and hope your motherboard > > manufacturer wasn't stupid. I've seen motherboards where _every_ > > slot was mapped to IRQ 9. > > Well, I would say it should be possible. In the RT ISR check whether the > interrupt was from the frame grabber, if not trigger the soft interrupt > which will be then serviced by ALSA. Take care about cases when both devices > generate interrupts. > Interrupts to the framegrabber will be blocked during the sound card ISR. 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] a shared interrupt service routine
On Thu, Apr 06, 2000 at 01:46:01PM +0900, JunHyeok Heo wrote: > > Hi! > I am writing a device driver of a video capture card. > The kernel is 2.2.13-rtl2.0. > > The BIOS of my PC allocates the same irq number to > the video capture card and the on-board sound device. > > The ALSA(Advanced Linux Sound Architecture)-driver is used for > the on-board sound device. > Activating both devices resulted in hanging down the system. > > Is it possible to share the same interrupt between the RTL driver > and the plain linux driver ? Nope. Move the card to a different slot, and hope your motherboard manufacturer wasn't stupid. I've seen motherboards where _every_ slot was mapped to IRQ 9. 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] using vsnprintf in rtl
On Wed, Apr 05, 2000 at 06:24:45PM +0200, Klaus Keppler wrote: > Has anyone successfully used vsnprintf() and/or snprintf() without any > problems inside rtlinux tasks ? > My rtlinux-box crashes somtimes, so it would be great to know that the > usage of vsnprintf() is NOT the reason for my problem. > thanks in advance > klaus If you are using vsprintf() or sprintf() from the kernel, it is safe. However, since you say that you are using snprintf(), the source for this function must come from somewhere else. Could be any number of problems then. 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] the performance of linux run on MPC860
On Wed, Mar 29, 2000 at 01:57:30PM -0700, Kulwinder Atwal wrote: > Does not a lower time mean it runs faster? > It sounds like linux is running faster than pSOS and VxWorks. > > Maybe I am mistaken by your test, but it sounds like Linux is faster. > > - Kal. > Without knowing full details of the source code, it is impossible to tell what might be happening. There's no description about what happens inside the loop, what compilers are used, etc. It could simply be a matter of one compiler inserting an extra memory operation, in order to be more correct or to make debugging easier. 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: [realtime] Re: [rtl] virtual memory in RTL
On Wed, Mar 22, 2000 at 06:02:24PM +0100, David Olofson wrote: > Wed, 22 Mar 2000 [EMAIL PROTECTED] wrote: > > (BTW: from the Linux man page: > > As SCHED_FIFO and SCHED_RR processes can preempt > >other processes forever, only root processes are allowed to activate these > >policies under Linux. > > ) > > Yep, you have to have *some* kind of adrenaline rush left with protected memory > and all! ;-) If you want to be completely safe, you could always throw in a > watchdog thread or something... I was thinking Magic SysRq key to kill the > current (SCHED_FIFO or SCHED_RR) thread as another alternative, but I might be > missing something that already exists. You can use SysRq-K to kill everything on the current console. Unfortuantely, this does not work in X, and it's been screwing up my console lately. But a SysRq real-time killer is a good idea. I might just code one for the fun of it. A watchdog might be a better idea -- a high priority real-time processes that watches to make sure SCHED_OTHER processes get scheduled. 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] DrDobbs
On Sat, Mar 18, 2000 at 11:43:35PM +0100, Tomasz Motylewski wrote: > On Sat, 18 Mar 2000, Erwin Rol wrote: > > > And nice to see a "windows" magazine to talk about something else. > > Of course they have to mention NT doing Real time in the same way. > > Did they recompile the NT kernel using soft-cli ? ;-) > NT uses a hardware abstraction layer that replaces cli() (or the NT equivalent) with a virtual function call all the time, similar to RTAI. A HAL would be a nice way for Linux to make binary-only drivers work with RTLinux (and SMP, and various other patches that change inline functions and structure layout) -- that is, force binary-only drivers to use a HAL, but allow source drivers to use inline speedups. 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] Date: Sat, 18 Mar 2000 20:32:35 +0800
On Sat, Mar 18, 2000 at 06:30:31AM -0800, Phil Wilshire wrote: > dyd > Good idea. > This should be in the form of a HTML page perhaps.. > Get started and realtimelinux.org will host it for you. > If you maintain any upgrades from the group then we'll post your latest > copy as and when.. > > Just make a stab at it and others will follow. I agree. If there were a well-written/well-maintained document about this, I would add my list of ok/not-ok kernel functions. 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] Writing to Memory in Kernel Space
On Thu, Mar 16, 2000 at 08:19:25AM -0800, Estabridis, Janet P wrote: > Hi, > I have tried to search the archives for two days, but can't. So, I really > need some help now. > > I am using RTL1.1 on kernel 2.0.36. > > I am accessing a video frame grabber at (0xB), but want to try and speed > things up. It is an ISA card. > > I have > > unsigned char *ptr; > > ptr = bus_to_virt(0xB); > > > and then I can assign any value to*(ptr+offset). > > How can I do a block write in kernel space ??? I tried memset_io( ... ) > but it is unresolved memset_io() is the correct function to use. It is defined in . And remember that it takes a _bus address_, not the virtual address you converted 0xb to. (The bus address, in this case, is 0xb.) I would strongly encourage using readb() and writeb() instead of doing straight access to memory. There are many reasons to do this, including portability. Another reason is that since ptr is not declared volatile, you may get strange reordering that is difficult to debug. Back in January, I suggested using the bus_to_virt() method, which is "less than correct". Also, that method avoids the debug checking that is done in newer 2.3.x kernels to see if you are accessing ISA memory without mapping it. I expect that sometime in early 2.5, drivers will have to start explicitly mapping ISA space. 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/
[rtl] [announce] comedi-0.7.40, comedilib-0.7.9
Everyone's favorite collection of open-source data acquisition drivers has been updated again. New, fresh souce code is available for you to crash your machine with, at ftp://stm.lbl.gov/pub/comedi. Also, there is a 1-line bug fix for comedilib-0.7.8, which is triggered occasionally by the new code. Don't bother upgrading comedilib unless you notice problems. (The problem is: every program crashes immediately.) Bug fixes in this release: - elimination of a rather nasty memory leak - general bug chasing in dt2801 driver New drivers: - ii_pci20kc for Intelligent Instruments PCI-20001C carrier board, thanks to Markus Kempf - pcl812 for Advantech PCL-812PG, PCL813B and compatibles, thanks to Michal Dobes - Two virtual drivers that use real-time tasks to emulate features on advance data acquisition hardware (not really new, but...) New features: - new Comedi command structure/ioctl actually works, several drivers have been updated for it. - comedi_data_*() and comedi_dio_*() functions have been ported from comedilib to kcomedilib - range information is now fully modularized, basically a completion of driver modularization in the mid .30s. - all boards now use the same timer specification for sampling rates - new code that, as a side effect, triggers a bug in comedilib - updated and enhanced the INSTALL file - included new INSTALL.RTAI and INSTALL.RTLinux files 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] jiffies and udelay in rtl
On Thu, Mar 02, 2000 at 09:02:27AM +0100, Alain Rolle wrote: > Hi there, > > I'm implementing a RT driver (RTL2.0 ,Kernel 2.2.13) and I'm not sure that > I can use "jiffies" in it (I'm using these for detecting time outs). > Should I not use some rtl specific call to do that? Same question > concerning the linux "udelay" call. Can someone help me on this topic ? > You may use jiffies, but remember that it will never be updated while you are running real-time code. (Because interrupts are disabled.) udelay() is completely real-time compatible. (Possibly untrue for 2.2.15pre10.) 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] timers
On Tue, Feb 29, 2000 at 06:34:50PM +0100, Jens Lauer wrote:
> Hi folks,
>
[...]
> What could be the reason for the misbehaviour of sleep, usleep and
> select in a function?
>
This is slightly off your topic, but the following source code shows
some of the issues involved in using usleep() and select() functions
in Linux. Run the program and graph the results. Oviously, since
the Linux timer granularity is (typ) 10 ms, you see this effect show
up in the graph.
dave...
#include
#include
#include
void test1(void);
void test2(void);
int main(int argc,char *argv[])
{
test1();
return 0;
}
void test1(void)
{
struct timeval tv1;
struct timeval tv2;
int usec;
int actual;
for(usec=0;usec<1;usec+=100){
gettimeofday(&tv1,NULL);
usleep(usec);
gettimeofday(&tv2,NULL);
actual=(tv2.tv_sec-tv1.tv_sec)*100+
(tv2.tv_usec-tv1.tv_usec);
//actual=tv2.tv_sec*100+tv2.tv_usec;
printf("%d %d\n",usec,actual);
}
}
void test2(void)
{
struct timeval now;
struct timeval targ,t;
int usec,sec;
int actual;
int i;
usec=(1.0e6/230.0);
sec=0;
gettimeofday(&targ,NULL);
for(i=0;i<1000;i++){
targ.tv_usec+=usec;
if(targ.tv_usec>=100){
targ.tv_usec-=100;
targ.tv_sec++;
}
t=targ;
gettimeofday(&now,NULL);
t.tv_sec-=now.tv_sec;
if(t.tv_usec" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
[rtl] [Daniel.Egger@suse.de: Re: string-486.h?]
This just appeared on the Linux kernel mailing list. It seems to be an interesting coincidence, or none at all. dave... - Forwarded message from [EMAIL PROTECTED] - Date: Wed, 23 Feb 2000 18:55:57 +0100 (CET) From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Subject: Re: string-486.h? To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] In-Reply-To: <[EMAIL PROTECTED]> Precedence: bulk X-Loop: [EMAIL PROTECTED] X-Orcpt: rfc822;linux-kernel-outgoing-dig On 23 Feb, Brian Gerst wrote: > The code in include/asm-i386/string-486.h has been disabled for quite > long time now. Is it truly dead and can be removed? What is broken > with it? I'd like to append another question. The current gcc seems to have problems with memcpy calls in the kernel source. When compiling a kernel I get unresolved memcpy symbols for example in hisax. Although memcpy is used all over the source I get these unresolved symbols just in a few places. -- Servus, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - End forwarded message - -- [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] Problem loading modules
On Wed, Feb 23, 2000 at 11:04:35AM +0100, Erwin Authried wrote: > David Schleef[SMTP:[EMAIL PROTECTED]] wrote: > > > > Nope. gcc-2.7.2.3 outputs assembly instructions that perform > > the memcpy, even with very long strings. > > > > > > > > dave... > > > Be careful. With *exactly* the statement above, compiled with -O2, memset is called. > With some shorter or longer strings, memset is not used. > > -erwin > You are correct. I somehow managed to completely ignore "memset" and focused instead on my incorrect interpretation of "memset" as "memcpy". I'm happy you corrected me, because this brings up gcc bugs/features (depending on perspective) on multiple levels. On one level, gcc optimization is _definiately_ wrong calling memset(ptr,0,3) instead of the trivial two or three instructions required to zero by hand. This appears to be the behavior in both gcc-2.7.2.3 and egcs-2.91.66. This deserves a bug report. Then, of course, it is not clear that gcc should be calling library functions instead of __builtin_memset or just inlining memset code, especially when the -fno-builtins flag is set. It is true that memset can have no other legitimate meaning. But clearly, for the purposes here, generating "call memset" is not useful, and in other circumstances, "call memset" is definately bad. Grepping the gcc source indicates that there are a number of function calls that gcc will emit in certain circumstances. 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] Problem loading modules
On Tue, Feb 22, 2000 at 12:51:11PM +, Stuart Hughes wrote: > > Note also the following compiler feature: > > If have in your RT code: > > char buf[12] = "mystring"; > > You get an error, due to an implicit call to memset. Nope. gcc-2.7.2.3 outputs assembly instructions that perform the memcpy, even with very long strings. 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] Problem loading modules
On Fri, Feb 18, 2000 at 04:12:22AM -0700, Kulwinder Atwal wrote: > Paul Koning wrote: > > > > > "Dresner," == Dresner, Norman A <[EMAIL PROTECTED]> writes: > > > > Dresner,> It has to be possible to "re-create" functions like strcat > > Dresner,> et al that are usable in the kernel, and I have difficulty > > Dresner,> believing that someone hasn't already done just that. > > > > You don't need to re-create anything. All you need is to link the > > relevant object library with your module. > > > > That assumes, of course, that the library doesn't need to do system > > calls (like malloc). For example, the strings stuff should be fine > > except for "strstr". Math should be fine unless there's some > > exception related stuff in it. > > Use the functions in include/asm-i386/string-486.h > Although the call 'strstr' does not appear in string.h it is in this > file. You may wish to use instead, since it will do the right thing on different processors. 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] "frank" and rtl_printf()
On Fri, Feb 18, 2000 at 05:29:30AM -0500, Kenneth Jacker wrote: > > A related question: how to "watch" the output of 'dmesg' grow (the > command, not the file at /var/log/dmesg)? I tried "dmesg|tail -f", > but that doesn't work. I usually use 'tail -f /var/log/messages|grep kernel'. 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] RTL performance
On Thu, Feb 10, 2000 at 01:07:09PM -0700, [EMAIL PROTECTED] wrote: > On Thu, Feb 10, 2000 at 10:45:35AM -0800, David Schleef wrote: > > And I hope you never do. What would I ever do with a VESA data > > acquisition board? Hang it up in my obsolete-hardware sculpture I > > have in my office, I guess. AGP has no future. > > > > I don't see a real need for 400 MB/sec from a card, when computers > > can't even currently handle 100 MB/sec from a PCI card. This comment was in reference to "why manufacturers don't make AGP boards", not why "AGP boards are bad". The "AGP has no future" comment should indicate that I'd be happy to go into a diatribe about why I dislike AGP, but I digress... 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] Memory Mapped ISA Video Frame Grabber Help
On Mon, Jan 10, 2000 at 01:52:11PM -0800, Estabridis, Janet P wrote: > Dave, > I am doing this from user space right now. I am using fd "/dev/mem" which > is what Mr. Rubini's book example and he's advice via e-mail was. > > What is the difference between "/dev/mem" and "/dev/kmem" ? > > I'll try "/dev/kmem" and I'll try and look at the SVGAlib source. > > I truely did not think accessing a memory mapped card would be trouble from > user space and I thought it would be easier until things are working (if you > can map it). I'll also try it from kernel space if all else fails. Sorry, /dev/mem was correct. But mmap_kmem() is just defined to be mmap_mem(), which makes me suspicious. Have you tried plain, old read/write/fseek() on /dev/mem? Are you using a 2.2.x or 2.0.x kernel? 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] Memory Mapped ISA Video Frame Grabber Help
On Mon, Jan 10, 2000 at 06:39:25AM -0800, Estabridis, Janet P wrote: > Hi, > This is not really a real-time question, but if someone could help I'd > appreciate it. Eventually a real-time task will update my video monitor at > 30 Hz. > > I have kernel 2.0.36 with RTLv1.1. I am currently trying to get a > Imagenation ISA video frame grabber (model CX100-30) with overlay memory up > and running. Alessandro Rubini has created a very limited device driver for > it which does not support video overlay memory. My task is quite simple, I > simply need to update some text fields of the video overlay memory. So, I > figured that I would do it in user space first to create all the static text > and see how I need to update the dynamic text in non-real time, then worry > about real-time and a device driver. > > The card has I/O register that I can control. The overlay memory (or ram > memory - they share the same addresses and you select which you want to > write to via an i/o register) take up 64K (0x) of address space from > 0x8 to 0xF. I have set the card up to be at address 0xA because > when I used Rubini's device driver there was a routine to check to see where > there was free space and 0xA and 0xB came up as free. (I did notice > in the companies DOS routines that this was also shared with the vga card > and they turn the vga card off to write to the frame grabber. But, I have > e-mailed Rubini and he never mentioned that I needed to do anything like > that and there was nothing that I could see in his device driver source) > > In order to get to that address I'm using the mmap routine. > > My mmap is as follows: > > unsigned char * address; > int fd; > > address = (unsigned char *) mmap( (void *)0xA, 0x, PROT_READ | > PROT_WRITE, MAP_FILE | MAP_PRIVATE | MAP_FIXED, fd, 0 ); > > This returns successfully and address = 0xA. > > But, if I assign values to this address space 0xA - 0xA it is as if > I am not accessing the cards memory at all. I simply use *address = > (unsigned char)0xff which should make the overlay pixel a white dot. > > So, am I using mmap wrong ? Is there something else I need to do to utilize > this card via Linux ? Am I doing something stupid and someone out there can > set me straight ? Is there a better way to do this ? HELP ! > What fd are you using? Are you doing this from user space? I can't possibly see how this would work. In a driver, you can get the mapped address of ISA himem by using ptr = bus_to_virt( 0xa ); If you really want to access the device from user space, you could probably map /dev/kmem at the appropriate pointer. To do this, I'd start by looking at the source for SVGAlib, which does (used to do) a similar mapping for video cards. As for kernel drivers, look in drivers/net for examples. Grep for 0xa. Some older SCSI cards used to use high memory, also. 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/
