First of all thanks Jan for the quick response! On 1/19/06, Jan Kiszka <[EMAIL PROTECTED]> wrote: > George Doukas wrote: > > Hello everybody... > > > > I've been working with RTnet over RTAI/LXRT for sometime and now I'm in a > > process to integrate ORTE to my work... > >> > Although I've studied the provided ORTE documentation and some portions > >> > of > > the source code there are some issues that are not 100% clear to me and > > would appreciate if you could help clear them out. > > > > First of all I assume that ORTE (liborte) supports real-time operation over > > RTnet in userspace through LXRT. Is this true? > > If this is actually true then in order to use ORTE from real-time LXRT > > threads is it required to insmod orte_rt and ortemanager_rt modules kernel > > or not? > > > > Nope. ORTE only includes support to run it the kernel environments of > RTAI or RTLinux/GPL. The makefiles need to be adapted and some > initialisation calls need to be re-organised in order to run over a > RT-userspace libraries. >
OK that's clear to me now... NO LXRT (for now)... > > > I' asking this because I've allready used orte from within LXRT real-time > > threads (after calling rt_make_hard_real_time) without having the 2 modules > > loaded (ortemanager runs as normal process) and this scheme seems to work... > > Did you wrap the POSIX calls of liborte onto LXRT? Did you replaced the > socket API calls? A bit more hacking is required in case LXRT should be > used. > No, no hacks were made! I just call normal liborte functions inside hard real-time LXRT threads... I suppose there's a context switch (to soft RT) every time I make a liborte call... so bye-bye HRT! > > Instead, I once (Aug. '05) gave this a try for the POSIX skin of Xenomai > (i.e. RTAI/fusion at that time). I had to change only some parts of the > manager and the examples (init/cleanup stuff...). And I had to fix the > realtime attribute of ORTE thread (well, I had to introduce them). Don't > know if this is fixed now, but Petr (CC'ed) proposed some extension of > ORTE at that time. > > This all was possible with few changes to ORTE because the POSIX skin > gets attached to a conforming program just by relinking. The trick: > > make CFLAGS="`<xeno-inst-dir>/bin/xeno-config --posix-cflags`" \ > LDFLAGS="`<xeno-inst-dir>/bin/xeno-config --posix-ldflags`" > > when compiling ORTE for normal Linux. Even RTnet is then automatically > selected as it overloads the UDP sockets in that case. What was and > unfortunately is still missing in Xenomai is rw-lock support or, better, > wrapping. Actually, rw-locks should better be mapped on mutexes in the > RT-case (to optimise the worst case contention, not the average). And > this is what I did by some further hack I don't have at hand. It > extended Xenomai to provide rwlocks as mutexes. But I think today this > should better be done in ORTE directly because the wrapping applies to > other POSIX conforming RTOSes as well. > > > > > > > The reason why I followed this scheme is because I could not load > > ortemanager_rt module... each time I try to insmod ortemanager_rt the system > > freezes! > > No need for the kernel module in the userspace scenario, all ORTE work > will be done in userspace. > > > I've found an older post about a similar problem and the solution proposed > > was to pass the parameter rtskb_cache_size=64 when loading rtnet.o. That did > > not work for me! > > This tweaking of RTnet is required for kernel and userspace scenarios as > ORTE initialises a lot of stuff in RT context (and for this case you > need preallocted buffers in the rtskb_cache). That is partly due to the > RTPS design (which includes some dynamics), but I think it should be > avoidable to some degree. At least one could explicitly leave RT-context > during that allocation (as long as the related routine doesn't hold a > lock at the same time...). I'm not so deep into this anymore, but I see > in my attached hack that the "printf" was introduced to implicitly > switch the mode. Well, it was a hack... > So lets forget LXRT... I'm trying to use ORTE from kernel space, thus orte_rt.o and ortemanager_rt.o modules must be loaded. Even though I use the parameter rtskb_cache_size=64 when loading rtnet.o, the system freezes when I try to load ortemanager_rt.o. Why? I'm using... RTAI 3.1 over linux 2.4.26 kernel (adeos patched) RTnet 0.8.3 ORTE 0.3.1 (I've also tried RTAI 3.1 with RTnet 0.8.2 and ORTE 0.3.0) My test system consists of two P4 machines with the above configuration on a dedicated ethernet network. On both nodes I issue the following commands: insmod /usr/realtime/modules/rtai_hal.o insmod /usr/realtime/modules/rtai_ksched.o insmod /usr/realtime/modules/rtai_lxrt.o insmod /usr/realtime/modules/rtai_sem.o insmod /usr/realtime/modules/rtai_mbx.o rmmod 8139too (or eepro100 for the other node) insmod /usr/local/rtnet/modules/rtai_rtdm.o /usr/local/rtnet/sbin/rtnet start I've edited rtnet script so that rtnet.o is loaded with the appropriate parameter like this: insmod $RTNET_MOD/rtnet$MODULE_EXT rtskb_cache_size=64 >/dev/null || exit 1 (At this point rtping works just fine) And finally... insmod /usr/local/orte/lib/modules/2.4.26-adeos/orte/orte_rt.o insmod /usr/local/orte/lib/modules/2.4.26-adeos/orte/ortemanager_rt.o THE SYSTEM FREEZES (on any node) !!! > > Hope I could provide some useful information, and maybe Petr can add > further comments on plans to improve hard-RT userspace support of ORTE. > Anything happened in this regard in the meantime? > > Jan > You've been very helpful, thanks again. I only hope you can help me once more. George ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
