From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [Xenomai-help] problem with installation From: Philippe Gerum In-Reply-To: <44E42BE3.1060709@domain.hid> References: <20060816190510.20935.qmail@domain.hid> <44E36F6A.7060004@domain.hid> <200608162137.09103.nicola17@domain.hid> <44E37823.8080407@domain.hid> <33646.155.98.4.150.1155767832.squirrel@domain.hid> <1155803145.4356.33.camel@domain.hid> <44E42BE3.1060709@domain.hid> Content-Type: text/plain Date: Thu, 17 Aug 2006 13:31:25 +0200 Message-Id: <1155814285.4366.22.camel@domain.hid> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: rpm@xenomai.org List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: xenomai@xenomai.org On Thu, 2006-08-17 at 10:42 +0200, Jan Kiszka wrote: > Philippe Gerum wrote: > > On Wed, 2006-08-16 at 16:37 -0600, Brandt Erickson wrote: > >> So, perhaps I spoke too soon. The system does boot, but I just looked in > >> the syslog and found this: > >> > >> 16 16:08:49 dewback kernel: [4294670.201000] I-pipe: Domain Xenomai > >> registered. > >> Aug 16 16:08:49 dewback kernel: [4294670.201000] Xenomai: hal/x86 started. > >> Aug 16 16:08:49 dewback kernel: [4294670.231000] Xenomai: real-time > >> nucleus v2.2 (Engines Of Creation) loaded. > >> Aug 16 16:08:49 dewback kernel: [4294670.232000] Xenomai: starting native > >> API services. > >> Aug 16 16:08:49 dewback kernel: [4294670.232000] Xenomai: starting POSIX > >> services. > >> Aug 16 16:08:49 dewback kernel: [4294670.232000] Xenomai: starting RTDM > >> services. > >> Aug 16 16:08:49 dewback kernel: [4294670.232000] Xenomai: incompatible > >> timer mode (aperiodic found, need periodic). > >> Aug 16 16:08:49 dewback kernel: [4294670.232000] Xenomai: VxWorks skin > >> init failed, code -16. > >> > >> my .config is attached. As far as I can tell, my timer is periodic and > >> not aperiodic. My kernel is 2.6.16 patched with xenomai-2.2.0 from the > >> download page and not the trunk. > > > > You need to build the native and POSIX skins as modules, so that they do > > not override the timing mode (they both request aperiodic mode to the > > nucleus, which conflicts with the VxWorks skin initializing after them). > > > > Mmh, not on my test setup: once you set a reasonable period, all skins > boot into periodic mode. That is the point: all skins are going to use the periodic mode, but not all applications are able to handle this. E.g. the latency test will force the timing to oneshot using rt_timer_setmode(), but the cyclic test won't, so you end up with funky results such as multi-ms latencies with the latter, albeit the real figure - would the timing mode be aperiodic as assumed - should be a handful of us. In the same vein, running the latency test first, then VxWorks's satch demo on your config would break the box, since the latter does not force the timing mode back to periodic (actually, there is even no interface to do so, except linking the VxWorks app against the native lib to get rt_timer_setmode). Having all skins as modules (RTDM included) is the way to go whenever using oneshot and periodic modes alternately depending on the loaded application is required. This way, the timer is shut off upon skin unloading, which prevents any conflict and makes sure that the next skin will obtain the required mode. I'm not saying that such approach is intuitive though, but only that it voids a fair number of potential issues. Of course, if only VxWorks is needed, then one just needs to disable the other skins, which would also solve the issue the eager way. -- Philippe.