[rtl] Re: [ANNOUNCE] Adaptive Domain Environment for Operating Systems
I have read your whitepapers very carefully and I believe that the approach is feasable. This looks like a great project, I would definitely be interested in joining the effort. This approach appears to handle some of the weaknesses of the RTLinux method; namely that a binary module can still contain the cli/sti instructions and destroy the determinism. In fact, even a user mode program with root permissions can do the same. The best example is some of the X servers. One comment on implementation; you may have to filter some of the in/out instructions to virtualize the timers. Most operating systems will want to control those to some extent. Wm
RE: [rtl] Linux BootPrompt Question
Based on your original posting, it may be a problem with your lilo.conf file. I'm not sure you can have two append statements, try commenting out the other one and see if this cures the problem. I think you can pass multiple arguments in a single append statement. Regards, Wm -- [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 latency (Athlon 800 - XFree 4.0.1)
Hi Erwin, I have seen similar latencies with XFree servers when acceleration is turned on. The problem was traced to PCI bus activity and is not really interrupt related. Some X server acceleration uses a mode of the PCI bridge which basically enables an infinite retry sequence. A command is given to the video chip and then the status is read, the chip does not respond right away and the PCI bus essentially hangs while the PCI hardware retries the read until the video chip responds. This is a particularly nasty featue of the PCI bus and can destroy determinism in a system which requires real time response. In some X servers this PCI retry can be turned off while retaining other acceleration features. Regards, Wm On Tue, 21 Nov 2000, Erwin Rol wrote: > Hey Paolo, > > I don't see it "every" key press , i see it every enter/return key > press. Which maybe has nothing to do with the keypress , but with the > scrolling in the terminal window ? > > As mentioned in my other mail it works normaly when i disable > acceleration of the video card. > > tonight i will do a serious stress test, to see if it is really stable > and stays under 50 usec. When that is successful, i will try with a > other videocard and see if thats causes problems too under XFree 4.0.1 > or if it is just my video card that sucks (which it does :-) > > > > an other question, is there anyway to figure out if it is caused by > "lockingup" the PCI-bus , without a logic-analizer or scoop ? > > BTW who is eDwin ? :-) > > - Erwin > > > Paolo Mantegazza wrote: > > > > [EMAIL PROTECTED] wrote: > > > > > > > > > This is possible, however, I suspect that Edwin's problem is not with X. > > > Before speculating too much, he should see if a big I/O load without X > > > gets the same behavior. > > > > > > > As I told Edwin, I am not able to reproduce his problem on a PIII 350, > > UP/MP, > > by doing the same actions under X, with a looping cp/sync and a ping -f. > > > > I tested just for 10 minutes or so with X 3.3.6. Since Edwin's problem > > is deterministic, he sees it at every keypress, I think it should not be > > a matter of waiting more time. > > > > Ciao, Paolo. > > -- [rtl] --- > > To unsubscribe: > > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR > > echo "unsubscribe rtl " | mail [EMAIL PROTECTED] > > --- > > For more information on Real-Time Linux see: > > http://www.rtlinux.org/rtlinux/ > -- [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/
[rtl] SMP irq affinity
An SMP system with lots of PCI bus activity, can have serious and sometimes unacceptable RT task jitter for high rate (3000 - 4000Hz) tasks doing data acquisition. Since the CPUs share the PCI bus, the Linux kernel (running on one CPU) can interfere with RT deadlines on the other CPU. One way to minimize this is to force designated irqs to be handled on a specified CPU. I realize that the 2.3.x and 2.4pre kernels have this capability, however I am stuck with 2.2.x. Is there a way to enforce this behavior in RTLinux? Wm -- [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] Debugging RTL-Tasks
Download RTLv2.3 from the rtlinux site - it has the debugging stuff in it. On 17 Aug 2000 [EMAIL PROTECTED] wrote: > > > Hi, > > I'm working at the moment with RTL 2.2. Is there a chance to debug a > RTL-task. I've read of a rtl_debug modul, but don't know where to find. > > Thanks for any help. > > Oliver > > > -- [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] debugging a Page Fault
Thanks for the reply. I agree with the analysis below. I just wanted confirmation on the definition of "Page Fault (exception 14)". I believe this means a pointer has referenced an address which in _not_ in physical memory. Is this correct? Is there a way to look at the stack in gdb? When I do a "backtrace" command the results look reasonable. How can I examine the actual (raw) stack contents? Also, I would like to see where the stack pointer is and how deep I have gone into the stack. On Wed, 16 Aug 2000, Norm Dresner wrote: > If you're causing a page fault when you're returning from a function call, > one possibility is that the function has overwritten the stack and that the > place to which you "return" is not the place from which it was called but > something way off in outer space -- hence a page fault. > > Norm > > At 06:42 PM 8/16/2000 -0400, William Montgomery wrote: > > > >I have a large module which causes my machine to lockup > >from which there is no escape but power off/on. Thanks to the > >great work by the RTLinux folks I am using the new rtl_debug > >module and gdb to find this. The dmesg produces: > > > >rtl_debug: exception 14 in rt_process (EIP=0xc80c63d0), thread id > >0xc6e00600; > >(re)start GDB to debug > > > >I am able to see the line this occurs at using gdb but this is just > >pointing to a function return brace. I see that this is a Page Fault > >exception but I'm not sure what this means or what might be the cause. > > > >Any hints? > > > >Wm > > > >-- [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/
[rtl] debugging a Page Fault
I have a large module which causes my machine to lockup from which there is no escape but power off/on. Thanks to the great work by the RTLinux folks I am using the new rtl_debug module and gdb to find this. The dmesg produces: rtl_debug: exception 14 in rt_process (EIP=0xc80c63d0), thread id 0xc6e00600; (re)start GDB to debug I am able to see the line this occurs at using gdb but this is just pointing to a function return brace. I see that this is a Page Fault exception but I'm not sure what this means or what might be the cause. Any hints? Wm -- [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] Soft Real Time
Hi Bernhard, Interesting comments on PCI bus latencies. Do you (or anyone on this list) have any sample code or other data on programming the PCI bridge chips in the way you describe? Wm On Sun, 25 Jun 2000, Bernhard Kuhn wrote: > Herman Bruyninckx wrote: > > > I have a dual Pentium III 700Mhz, and I wanted to investigate how it > > compares to DSP performance, when everything can be kept in cache. > > Keeping things in cache is only half of the way ... the bigger > problem is to bother around with latencies caused by > the pci-architecture ... with modern chip-sets, it´s hard to > tell what exactly is going on ... several things have to > be taken into account: > > 1. CPU to Host-Bridge latency: you will have to disable caching and >write combinig in case your I/O card is memory mapped. >Even then, you have latencies when sharing the CPU-bus >with another processor. > > 2. Host-Bridge to PCI-Bus latency: you might disable the >read/write fifo (usual depth: 64) of the Host-Bridge. > > 3. you realy should disable PCI-Burst operations, which >can by up to 64 cycles. Otherwise having, for example, >five PCI-device, the arbitration could go up to 10 µs in >this stage. > > 4. Latencys caused be the I/O-Card itself > > > If a worst case latency of about 20 µs are just fine for > your application, then stay with RTL and standard settings. > > Otherwise it´s going deep into details: > > One solution could be the mentioned idea with the second > OS on the second CPU. > > Another method would be to disallow any kind of linux-kernel > activities on the second processor. Some times ago, > i took a look into the code of the kernel scheduler ... > it should be feasabel to keep away user-space processes > and kernel threads from the second processor by modifiying > the code a little bit. > Linux-Interrupts can be directed the the first CPU > by simply reprograming the I/O-APIC, as far as i got it. > So the second CPU should completly belongs to your > RTL-application, that even could fit into the L1-Cache > of the CPU. > > If this didn´t scared you then go reading on: > > Getting rid of the PCI-latencies is a little bit more > difficult: You could use the three-wire APIC protocoll to > attach a special I/O-Card directly onto the CPU. > The maximum latency/jitter is less then one microsecond in > this case, but then you have to bother around with > a 100 MHz serial line, simulation a local APIC ... > > Just a dream ... > > Bernhard > -- [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/
[rtl] RTAI-v1.3 tulip conflict
I am having a problem with rtai-1.3 conflicting with the tulip network driver. The CPU is a dual PIII 700MHz with 128M RAM, the kernel is 2.2.15. The network is fine after boot up - I can ping, rlogin, nfs and others. As soon as I do ldmod (loading basic rtai modules) the network stops responding. This seems to be related to SMP only, I have a CPU from the same manufacturer with same chipsets but single processor which works fine with rtai-1.3. I am including dmesg output below: [..] PPP line discipline registered. PPP BSD Compression module registered tulip.c:v0.91g-ppc 7/16/99 [EMAIL PROTECTED] eth0: Digital DS21143 Tulip rev 65 at 0xec00, 00:10:6F:02:1F:4E, IRQ 19. eth0: EEPROM default media type Autosense. eth0: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. eth0: Index #1 - Media 10baseT-FD (#4) described by a 21142 Serial PHY (2) block. eth0: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block. eth0: Index #3 - Media 100baseTx-FD (#5) described by a 21143 SYM PHY (4) block. eth0: Using user-specified media 10baseT(forced). = Network is working fine... ./ldmod = RT memory manager v0.2 Loaded. * STARTING THE REAL TIME SCHEDULER WITH NO LINUX * * FP SUPPORT AND READY FOR A PERIODIC TIMER * ***<> LINUX TICK AT 120 (HZ) <>*** ***<> CALIBRATED CPU FREQUENCY 698803742 (HZ) <>*** ***<> CALIBRATED APIC_INTERRUPT-TO-SCHEDULER LATENCY 3001 (ns) <>*** ***<> CALIBRATED ONE SHOT APIC SETUP TIME 499 (ns) <>*** * RTAI NEWLY MOUNTED (MOUNT COUNT 1) ** eth0: 21140 transmit timed out, status f06980c5, SIA 52ca 0001 fff8 8ffd0008, resetting... eth0: 21140 transmit timed out, status f06980c7, SIA 52ca 0001 fff8 8ffd0008, resetting... eth0: 21140 transmit timed out, status f06980c7, SIA 52ca 0001 fff8 8ffd0008, resetting... = Network is now broken. Anybody have ideas? I have also tried Donald Becker's latest tulip driver v0.92 with same results. The tulip driver is compiled as a kernel module. I can recover the network by doing: ifconfig eth0 down rmmod tulip remod insmod tulip /etc/rc.d/rc.inet1 Suggestions welcome. William Montgomery -- [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] mbuff_attach for non-root user? (mbuff-0.6.5 relesed).
On Wed, 23 Feb 2000, Tomasz Motylewski wrote: > Are there any wishes for 0.6 and 0.7 series? Some documentation I have > missed to include? > Could you provide a mechanism for allocating memory suitable for DMA (i.e. physically consecutive addresses)? Regards, William Montgomery -- [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/
