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. Excuse me for asking, but *why* would you want to do this? If you have RTLinux you get hard real-time guarantees, which can be used in the same way low latency can. As I remember, the low latency patch just sprinkled schedule() randomly on the kernel source like magic faery dust. Shouldn't make a damn bit of difference to RTLinux, since it preempts the regular Linux kernel anytime it wants. Don't know if there are any adverse effects the other way around, since I haven't tried this, since I don't see the point. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Double Serial
On Tue, Jan 16, 2001 at 08:56:15AM +0100, Carsten Fischer wrote: I'm looking for a driver for a Dual RS-232 serial ports -card (using PCMCIA) (SILICOM). Can you give any more details on this piece of hardware? Also, have you tried looking in the 2.4 kernel section that has PCMCIA serial drivers to see if this card is supported? I have got a Toshiba Notebook with just one serial port, but I need two I/O ports. There are no problems by using rt_com-driver and ttyS0 . -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] minirtl on ide
Hi, I'm also trying to put miniRTL on IDE. I'm stuck at the very first step! My hard-disk (hda) has an ext2 filesystem. I would like to know if I can make an msdos fs on hda1 without affecting the present system. I had checked cfdisk, fdisk and sfdisk utilities, but I'm missing something. Can you please help? Thanks in advance. Regards Ramesh I'm trying to put minirtl on an ide disk. boot it from the floppy, then 1) create a 2MB msdos fs on /dev/hda1 2) create a 4MB++ minix fs on /dev/hda2 put the image file from the floppy on /dev/hda1 this system can now boot from ide into a RAMDISK to now put it on the IDE disk so that it will actually run from the IDE. 1) boot the system into ramdisk 2) upload a default version of cp (the one from busybox laks the -R flag) 3) mount the minix partition under /mnt 4) cd / 5) cp -pRd * /mnt (excluding /mnt naturally...) *** * RAMESH K, Receiver Engineer * Millimeterwave Observatory Ph: +91-80-3340128 ext 447 * Raman Research InstituteFax: +91-80-3340492 Attn Ramesh K * Sir C V Raman Avenue * Sadashivanagar* Bangalore - 560 080 * India * http://www.rri.res.in * * *** -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
On Tue, Jan 16, 2001 at 08:17:00AM -0700, John Regehr wrote: The point is that real-time applications have widely varying requirements and, as people have been discussing recently, not everybody wants to stuff their app into the more restricted and difficult enviroment. I want to point out that (A) RTLinux programming environment is not so difficult and (B) the low latency patches are not so unrestricted. Andrew Morton (who seems to have been the second Linux developer to turn into an entire programming team) has a list of "don't do that"'s to accompany his patch. One drawback of running soft real-time apps in user space while running hard real-time apps in RTLinux is that RTLinux will become a source of latency for regular Linux. In other words, if a RTLinux task has a WCET of 1ms, then the worst-cast dispatch latency of regular Linux will be increased by 1ms. Just as the worst-case dispatch latency of SCHED_OTHER processes in Linux gets worse by the worst case compute time of and SCHED_FIFO process. John -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/ -- - Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] 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 Your_email" | 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:10:53AM -0700, John Regehr wrote: On Tue, Jan 16, 2001 at 08:17:00AM -0700, John Regehr wrote: The point is that real-time applications have widely varying requirements and, as people have been discussing recently, not everybody wants to stuff their app into the more restricted and difficult enviroment. I want to point out that (A) RTLinux programming environment is not so difficult and I agree that it's not that hard, but it does raise the bar somewhat. The user/kernel boundary is there for a reason, after all: to prevent buggy applications from corrupting each other or the system, and to make it possible to reclaim all resources when an app terminates abnormally. That said, the real-time signals in RTLinux 3 look really cool, and they are a nice step towards providing a friendlier programming model. Thanks. We have a funny message to put out: on the one hand RTL programming requires some skill level but on the other hand, I don't want people to automatically assume you need to be a kernel hacker to write RTL code. John -- - Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
On Tue, Jan 16, 2001 at 08:38:30AM -0700, [EMAIL PROTECTED] wrote: You could have asked me: aside from getting wierd OS failures (which is always fun) there is a really interesting area in which "soft" realtime applications interact with hard realtime applications: e.g. hard RT collects frames, feeds them to a soft RT which does some mixing, and hard RT outputs. I think that the area in which hard and soft RT cooperate is one of the most important researchdevelopment areas in OS. I stand humbled. My apologies if I seemed overly negative towards the question of using the low latency patch. It's just that it seems like applications that require low latency could be deftly handled by using hard real time, and the low latency patch has a lot of provisos for its use. There was much discussion on the Linux kernel list about the issues that the low latency patch raised. While many people said that it Worked For Them(tm), it looked like the patch would not be compatible with many drivers and perhaps even platforms (did anyone ever test the patch on anything besides ia32?). However, if you get the low latency patch and our RTLinux patch to apply cleanly and work, all the more power to you. I'd be interested to hear how it works out. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
[rtl] co-existence of RTAI and RTLinux ?
Hi, I am following Phil Wilshire's instruction at http://www.realtimelinux.org/articles/linux-expo/montreal/paper/indexc.html step by step to BUILD the necessary concepts of RTLInux.Now I reach to the step that I have to install RTAI (for those examples in Phil's paper), though I already have rtlinux-2.0 and my device driver is based on rtlinux-2.0 too. Can a process have functions from both RTAI and RTLinux? They have some common functions, such as rt_task_make_periodic, rt_task_init. Maybe it does not make sense at all to have both of them, either one shall be fine. Then why have developed both for such lots of effort? Thanks. Dingrong Yi -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
[rtl] #define MODULE (KDevelop RTLinux)
Hi. I read the discussion btw David Olofson and the french Gentlemen about developping for RTLinux. Consider me a beginner in about everything.., anyway: First question. A collegue of mine was about to dispair today when he tried to understand the way, RT-applications are built. We use KDevelop and added the path to the RT-modules (RTLinux 2.2.3) to the linker- and the includes to the compiler-options (project|options). As this would not make him happy, let alone produce a working program, I wonder if it is of any importance that the right modules are already loaded at _compile-time_. You can also point my nose at any programming guide or document which might be useful in the context of programming under RTLinux (we have the man-pages, thanks). Second. Is Ivan Martinez' Dynamic Systems Library available for download? The last time I tried, the server would not let me in but it could rid us of some problems... I guess. But maybe I am wrong. Does it simplify the rtl-api e.g. in conjunction with Qt and the like? Thanks for reading, Michael -- Michael Uplawski [EMAIL PROTECTED] / [EMAIL PROTECTED] PGP: RSA/IDEA 2048Bits 0x19847a51 Fingerprint: AC C1 2F 8F 59 9C FF 3C 6D A8 67 4A 45 3E 4C F2 (GPG d/e on request) Es lebe H[a,e]cker! -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
Tue, 16 Jan 2001 Nathan Paul Simons wrote: 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. Excuse me for asking, but *why* would you want to do this? If you have RTLinux you get hard real-time guarantees, which can be used in the same way low latency can. No. You can't use Linux drivers from within RTL or RTAI without getting the same latency problems as standard Linux user space threads. This renders RTL and RTAI virtually useless for multimedia programming, unless you want to port all drivers you need no actual RTL. (I was headed in that direction until the lowlatency patch arrived, BTW.) As I remember, the low latency patch just sprinkled schedule() randomly on the kernel source like magic faery dust. Not exactly randomly; especially not in the latest versions. They're inserted in places where the kernel stays for "ages" occasionally, so that SCHED_FIFO threads can be scheduled within at most 1 ms, rather than up to 100 ms later, or worse. Not magic and not beautiful, but it upgrades Linux from "entirely worthless" to "totally superior" WRT serious real time multimedia. Shouldn't make a damn bit of difference to RTLinux, since it preempts the regular Linux kernel anytime it wants. Don't know if there are any adverse effects the other way around, since I haven't tried this, since I don't see the point. Right, it shouldn't make any difference to RTL, but it makes all the difference to code running in Linux threads - including any Linux code that RTL threads use to interface with Linux. An excellent example of why one might want to use both RTL and lowlatency would be a Linux based arcade machine, game console or other serious gaming machine. To get anything like the animation quality you see on consoles and arcade machines, you need video refresh rate synchronization, full frame rate and double buffering. To guarantee full frame rate, you need to make sure that the graphics engine gets the CPU time it needs *when* it needs it. It also needs to use various multimedio drivers, which also need their CPU time at the right times. Linux/lowlatency is an excellent solution for that. Further, due to stupid design of the majority of video cards, retrace synchronization isn't as simple as it should be. You need to poll certain ports or registers for the "retrace bit", or similar, depending on what video chipset you're using. The problem is that the retrace occurs for significantly less than one ms in most resolutions, so it's easy to miss it entirely, even with Linux/lowlatency. Besides, it's a huge waste of CPU power, spending lots of time polling. However, RTL allows a periodic thread to do the polling, starting just before the retrace is expected, reducing the wasted CPU time to almost nothing. This thread can then provide the grapics engine with a reliable retrace sync info. In the case of graphics drivers that don't support true pageflipping, but use blits instead, this retrace sync driver can be used to allow the back-VRAM blit to start at the right time, which is required to avoid tearing. //David ..- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `-- http://www.linuxaudiodev.com/maia -' ..- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-- [EMAIL PROTECTED] -' -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
} Actually, our practical experiences with the lowlatency patch is that you can } use it for hard real time as well, as long as a worst case latency of 1 ms is } acceptable. For multimedia (which is nearly always using buffered streaming of } various kinds, all the way down to the hardware level), this is excellent. All } we need is to make sure that buffers are processed in time. Sub 30 s worst } case latency doesn't result in a significant performance improvement, not even } for audio. Note that this is x86. If your system requires FBCon (PPC and sparc) you need to learn to live with 810ms (yes, 810 milliseconds) worst-case with the rage128 card (similar performance for other video cards) with the linux low-latency patches. Andrew does have FBCon listed on the "don't do this" list but that does rule out several systems. That being said, the low-latency patches are a nice complement to RTLinux. RTLinux provides hard real-time and _guarantees_ while the low-latency patches give good response for Linux processes. Most RTLinux based systems are built from a combination of RTLinux tasks and traditional Linux tasks, after all. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
[rtl] NMI handling under RTL?
Sorry if this is a silly question - I'm not remarkably familiar with RTLinux. I'm trying to decide if using RTL is a good way to approach a problem. Is it possible to intercept an NMI (specifically an interrupt generated by an ISA bus IO CHANNEL CHECK condition)? I have a device (a hw watchdog) which will generate an IOCHCHK upon timeout. I want to do some logging on this condition before the board is reset ... I see an rtl_request_irq() interface to register a handler, but I'm not sure what the irq passed here actually indicates - a vector number? If anyone could clarify this for me, I'd appreciate it! I'm not really an expert on x86 interrupt controller architecture ... Thanks! Matt Hughes [EMAIL PROTECTED] -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
[rtl] RTAI/RTLinux compatibility
Hi, Sorry to post this again, as I did not get answer from the previous related question. Is RTAI compatible with RTLinux? As I want to use the features of LXRT of RTAI, but my device driver was based on RTLinux. I wish a user space process of LXRT could access (read or write) the FIFO created by a RTLinux thread or process. Any comments are welcome. Thanks. Dingrong Yi -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
RE: [rtl] RT FIFO used by Qt ploting
Tue, 16 Jan 2001 Stephen D. Cohen wrote: [...] The hard solution is to do some sort of handshaking between the RT world and the non-RT world. The easy solution is generally to make the FIFOs much bigger. :-) Besides, unless you're allowed to drop data, you'll need to buffer it up somewhere anyway - why not in the FIFO, rather than adding the overhead and complexity of another buffering system? //David ..- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `-- http://www.linuxaudiodev.com/maia -' ..- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-- [EMAIL PROTECTED] -' -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RT FIFO used by Qt ploting
Tue, 16 Jan 2001 Ren Yuhong wrote: Hi, Dear All, I am using Qt RT Linux to develop a package. I need to fetch data via RTFIFO to be plotted within GUI designed by Qt. My three questions are as follows : /** Question 1**/ When I create RT FIFO using "rtf_create(fifo, size)", how can I decide the "size" of the RT FIFO? I even don't know the unit of the size, is it Byte? The size of the FIFO should be at least MAX_WRITE_SIZE + READER_WORST_CASE_LATENCY + some margin, so you don't occasionally lose data. The unit is bytes, AFAIK. /** Question 2**/ Also, say, I tried to create a FIFO by using "rtf_create(3, 300)", however, I found that the data to be passed to the Qt plotter seemed to be displayed contineously, sometimes the data shown is wrong. Could you please kindly give me a clear idea about the RT FIFO's working mechanism? If I take the data out of the FIFO, will it still stay in the FIFO, or be deleted at once? Well, that's implementation dependent, but although the data normally isn't deleted or overwritten by the read() call (it's either a pointer or an offset that is changed after the memory copy operation), you should consider it gone once read() returns. /** Question 3**/ In my kernel module, I set the "pthread" periodical time as 5ms, and output one double data to RTF3, then I will fetch the data from RTF3 to be plotted in GUI. I also set a 5ms QTimer event (plus a QSocketNotifier) to plot the data, but sometimes the data shown is not correct. My question is: Will the user space's 5ms match the kernel module's 5ms well? Normally, you'd sleep on the FIFO read(), and therefore wouldn't need another timer. Your thread would just wake up as soon as there is data in the FIFO. However, you'd need to use non-blocking reads not to freeze the application if the driver stops writing data. (Shouldn't matter much in this case, but you should be aware of it, especially if your application is talking to other drivers as well.) The problem with non-blocking reads is that they will read as much data as is available in tho FIFO, and then return. That is, you *have to* check the read size! The only exception is when you know that the writes are atomic, and you're reading only one "block" at a time. Not knowing much about Qt programming, my questions are; * Does you thread reading code run in a separate thread, and if it does, * Is the interaction between that code and your Qt timer code thread safe? From what you describe, this seems to be some kind of synchronization problem, so nonblocking reads and inter-thread communication are among the first things I'd check. //David ..- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `-- http://www.linuxaudiodev.com/maia -' ..- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-- [EMAIL PROTECTED] -' -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
Tue, 16 Jan 2001 [EMAIL PROTECTED] wrote: On Tue, Jan 16, 2001 at 08:17:00AM -0700, John Regehr wrote: The point is that real-time applications have widely varying requirements and, as people have been discussing recently, not everybody wants to stuff their app into the more restricted and difficult enviroment. I want to point out that (A) RTLinux programming environment is not so difficult and (B) the low latency patches are not so unrestricted. Andrew Morton (who seems to have been the second Linux developer to turn into an entire programming team) has a list of "don't do that"'s to accompany his patch. Indeed, some versions of the patch are not even practically usable for real applications. However, the DDT lists were mainly a "lowlatency on 2.3.4" storry, and were the result of cutting the patch down to a level of ugliness that Linus would accept in the mainstream kernel. Also, that was before some plain bad code was fixed. This code had impact on performance and SMP in particular, as well as on worst case latencies, and these fixed, the DDT list will be more or less eliminated, while still alowing a minimal number of "ugly" conditional reschedule points to guarantee excellent performance under all kinds of system stress. BTW, looking at the latest lowlatency versions for the latest 2.4 kernels, it seems that Linux 2.4 is approaching a level where the lowlatency patch won't even be needed. (Thanks to the work related to SMP performance, mostly.) According to another post I read somewhere, Mingo's *real* lowlatency patch ported to 2.4 keeps the worst case latency on some of the test systems below 0.35 ms, IIRC. Almost 3 times better than the original lowlatency patch on 2.2.10, that is. :-) One drawback of running soft real-time apps in user space while running hard real-time apps in RTLinux is that RTLinux will become a source of latency for regular Linux. In other words, if a RTLinux task has a WCET of 1ms, then the worst-cast dispatch latency of regular Linux will be increased by 1ms. Just as the worst-case dispatch latency of SCHED_OTHER processes in Linux gets worse by the worst case compute time of and SCHED_FIFO process. The same goes for RT threads running under the same scheduler in any environment, unless some kind of high frequency time sharing is used. Lower priority threads always depend on the higher prio threads not to increase their worst case scheduling latency too much. (See why multiuser systems generally don't provide real time scheduling for all users?) //David ..- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `-- http://www.linuxaudiodev.com/maia -' ..- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-- [EMAIL PROTECTED] -' -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] co-existence of RTAI and RTLinux ?
Sat, 13 Jan 2001 Dingrong Yi wrote: Hi, I am following Phil Wilshire's instruction at http://www.realtimelinux.org/articles/linux-expo/montreal/paper/indexc.html step by step to BUILD the necessary concepts of RTLInux.Now I reach to the step that I have to install RTAI (for those examples in Phil's paper), though I already have rtlinux-2.0 and my device driver is based on rtlinux-2.0 too. Can a process have functions from both RTAI and RTLinux? They have some common functions, such as rt_task_make_periodic, rt_task_init. Maybe it does not make sense at all to have both of them, either one shall be fine. Then why have developed both for such lots of effort? This is about the same issue as when developing drivers that must work with Linux 2.0 as well as 2.2, 2.2/2.4 etc; either put the system dependent code in separate modules and have different versions of them, or use compile time checks to decide which lines actually get compiled. //David ..- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `-- http://www.linuxaudiodev.com/maia -' ..- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-- [EMAIL PROTECTED] -' -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] #define MODULE (KDevelop RTLinux)
Tue, 16 Jan 2001 Michael Uplawski wrote: Hi. I read the discussion btw David Olofson and the french Gentlemen about developping for RTLinux. Consider me a beginner in about everything.., anyway: First question. A collegue of mine was about to dispair today when he tried to understand the way, RT-applications are built. We use KDevelop and added the path to the RT-modules (RTLinux 2.2.3) to the linker- and This shouldn't be needed, as "linking" is done by the module loader when inserting the modules. the includes to the compiler-options (project|options). As this would not make him happy, let alone produce a working program, I wonder if it is of any importance that the right modules are already loaded at _compile-time_. No. The headers are all you need. Just make sure that KDevelop tries to build an .o file - *not* an executable file, like it normally does. (That is, about the same settings as used when building shared libraries should work for modules.) //David ..- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `-- http://www.linuxaudiodev.com/maia -' ..- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-- [EMAIL PROTECTED] -' -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
Tue, 16 Jan 2001 Nathan Paul Simons wrote: On Tue, Jan 16, 2001 at 08:38:30AM -0700, [EMAIL PROTECTED] wrote: You could have asked me: aside from getting wierd OS failures (which is always fun) there is a really interesting area in which "soft" realtime applications interact with hard realtime applications: e.g. hard RT collects frames, feeds them to a soft RT which does some mixing, and hard RT outputs. I think that the area in which hard and soft RT cooperate is one of the most important researchdevelopment areas in OS. I stand humbled. My apologies if I seemed overly negative towards the question of using the low latency patch. It's just that it seems like applications that require low latency could be deftly handled by using hard real time, and the low latency patch has a lot of provisos for its use. There was much discussion on the Linux kernel list about the issues that the low latency patch raised. While many people said that it Worked For Them(tm), it looked like the patch would not be compatible with many drivers and perhaps even platforms (did anyone ever test the patch on anything besides ia32?). Actually, apart from some versions of the lowlatency patch not really working (ie not covering all kernel calls), and some user space drivers (like XFree86) and applications having built-in deadlocks that are exposed only if they're running SCHED_FIFO, there's nothing much to worry about. Use kernel drivers, libraries and other stuff as much as you like, but keep in mind that (just as with RTL, RTAI, QNX or whatever) if you access something that's inherently nondeterministic, that will impact the performance of your code. //David ..- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `-- http://www.linuxaudiodev.com/maia -' ..- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-- [EMAIL PROTECTED] -' -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] rtlinux3.0 and HightPoint HPT370 Raid controller
Hi Roman, Did you compile the HPT driver in your kernel? Is there a kernel message about /dev/hde, i.e., is the kernel able to find the HPT controller? Michael. Roman Grigoriev ([EMAIL PROTECTED]) wrote: Hi Guys! I've downloaded rtlinux3.0-test10 from your site I have PIII-800 RAM128Mb 20Gb IBM UATA100 disk HightPoint HPT370 controller Linux ManDrake 7.2 with 2.4 kernel I compiled and make it all I Tried to load from new kernel but got message VFS panic: unable to mount /dev/hde6 I downloaded driver from HightPoint site http://www.highpoint-tech.com/ Linux driver But how can I install it? If anyone make this please give me a hand Thanx Bye -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
