Jan Kiszka wrote: > Karl Reichert wrote: > > Very good news: I found the reason for this behavoir/bug now! > > Very good, but not yet perfect: the bug is still unknown and unfixed. :)
Right, but as long as it is not fixed, maybe a wiki entry should be made to point to this workaround. What do you think? I could make this entry in the next days. > > > > > I'm using the attaced rtnet_start script to start the slave (can't use > the provided one because I don't want RTcfg). > > > > The last command is 'tdmacfg rteth0 slot 0 2300 -s 100 -l rtnet.log' > > > > If I use this script as attached, I get this weird behavoir that the > slave request and calibration reply in a cycle from the past. > > > > If I comment this last command and enter it manually on console (after > sucessfull run of rtnet_start), everything works fine. Also a 'sleep 3' > between the last command and the precending works fine. > > Hmm, ok, that means more input for the static analysis... Is there some > SMP system involved in this? I'm running RTnet on two completly different systems. One has an Intel Core 2 Duo (x86-32, SMP enabled, xenomai configured via './configure --enable-smp')! But the other one is a simple Intel Celeron 2 GHz with only one core. I don't know if it supports Hyperthreading but I don't think so (if this matters, xenomai was configured on this machine _without_ --enable-smp). Both machines show the same behavoir. I don't think SMP is involved. > > > > > So the reason seems to be, that 'tdmacfg rteth0 slave -c 100 -i 1' > returns but in background still sth is going on. Now running the last command > to > fast (without sleep), it can only send the calibration request after this > background stuff is done. And this is why the cycle lies in the past ... > > > > So far my understanding. Maybe just a hint which should be added in the > TDMA.spec or sth that is worth to change on tdmacfg-tool sourcecode. > > Nope, this issue needs to be fixed at kernel level. I will try to look > into this the next days, trying to understand what races here first. Well, if you need any help like trace files, testing of patches or sth like that, please feel free to ask! > > > > Thanks anyway for all your help and support, Jan! > > Thanks for you patience despite this fairly long search! At least we > have a workaround now. Of course! I understand people having jobs and private life and they support RTnet in their free time. So nobody can blame anybody if things take some time ... Karl -- von Karl Reichert NEU! +++ GMX empfiehlt DSL-Komplettpaket von 1&1 +++ Jetzt mit Best-Price-Garantie: http://www.gmx.net/de/go/dsl ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
