On Fri, August 17, 2007 15:24, Jan Kiszka wrote: >>>>> > Ok, since we discussed that in xenomai mailinglist yesterday and >>>>> there >>>>> > seems to be no solution with my bios, >>>>> There is one solution which you refused to try. >>>> Not refused, just postponed. What I suppose is, that my rtnet problem >>>> is >>>> independent from the xenomai problem because of the mentioned reasons, >>>> and >>>> that's what I wanted to find out to save some time in installing >>>> everything new and finding out that it's a completely different >>>> problem. >>> Your slave utterly fails to send its calibration request frame on time. >>> It misses its slot by more than 200 cycles (yeah, 400 ms, I packed my >>> calculator already as well), and this is a fairly unusual behaviour, >>> very likely due to timer latency issues of the underlying hardware (or >>> RTOS, but that's less likely). >>> If you don't believe this, start instrumenting (printk etc.) TDMA and >>> compare the time it wants to sleep for its slot to the time it actually >>> does. I would be surprised if the delay is already wrong (not saying >>> that this is absolutely impossible, but very unlikely given your other >>> reports). >> It wasn't a question of believing. That my xenomai timing is out of any >> acceptible range is not a question. That my slave is not able to send >> the >> requests in time, too. What I was just wondering about is the fact, that >> a >> master on the same machine is able to do cycle times under 2 ms (same > Hmm, I have some theory about this, but it's too speculative ATM. >> behaviour with two identical cloned machines, so no hardware problem). >> If > You mean you cloned the _slave_ setup to two different boxes (different > mainboards at least) and the issue persists? I must have overread this > "minor" hint then. In that case we would face a software issue, and I > would take everything back.
I meant I cloned the harddisk. We ordered two identical HP machines, same hardware, same boards. We installed one and cloned the installation to the other. Both work as a master with an embedded system as slave perfectly. Both fail to work as a slave with the other machine as a master. Of course both have the same Xenomai latencies. If it is a general Bios problem with the SMI, to my opinion it's clear that it fails on both machines then. >> you tell me, it's nevertheless the Xenomai problem, I have no doubt it >> is >> like that. I will report what 2.6.2 will do. > Again: If you slave issue if "portable" across different hardware and > even Xenomai versions, we need to step into RTnet debugging as sketched > earlier. This need not take much time as already the first action of the > slave fails. If you go that way and need more hints where to look, let > me know. It's important for me to find the reason and a solution for that problem, for my diploma or afterwards, since the system should work one day ;) Two machines, yes, different hardware, no. So I'm thankful for every hint I get. Greets, Nadym ------------------------------------------------------------------------- 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
