From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <44E45645.10106@domain.hid> Date: Thu, 17 Aug 2006 13:43:01 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Xenomai-help] problem with installation 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> <1155814285.4366.22.camel@domain.hid> In-Reply-To: <1155814285.4366.22.camel@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5E976401C98A2FF33C942128" Sender: jan.kiszka@domain.hid List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: rpm@xenomai.org Cc: xenomai@xenomai.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5E976401C98A2FF33C942128 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Philippe Gerum wrote: > 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 look= ed 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 st= arted. >>>> 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 n= ative >>>> API services. >>>> Aug 16 16:08:49 dewback kernel: [4294670.232000] Xenomai: starting P= OSIX >>>> services. >>>> Aug 16 16:08:49 dewback kernel: [4294670.232000] Xenomai: starting R= TDM >>>> services. >>>> Aug 16 16:08:49 dewback kernel: [4294670.232000] Xenomai: incompatib= le >>>> timer mode (aperiodic found, need periodic). >>>> Aug 16 16:08:49 dewback kernel: [4294670.232000] Xenomai: VxWorks sk= in >>>> 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 the= m). >>> >> Mmh, not on my test setup: once you set a reasonable period, all skins= >> boot into periodic mode. >=20 > That is the point: all skins are going to use the periodic mode, but no= t > 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 confi= g > 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)= =2E >=20 > 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 ski= n > 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. >=20 > Of course, if only VxWorks is needed, then one just needs to disable th= e > other skins, which would also solve the issue the eager way. >=20 That all sounds a bit fragile configuration-wise, also given that native and posix skins are on by default and that you can enable vxworks without having to switch on periodic timer support (BTW, are the other legacy RTOS skins with this dependency?). I would suggest to enforce the later and maybe enhance the timer initialisation interface in a way that a user/skin can request to lock the mode if it only supports one. Than the latency test should fail to start, thus indicating a wrong usage. Or we "hack" periodic support over aperiodic mode, but that's a different topic. Jan --------------enig5E976401C98A2FF33C942128 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE5FZFniDOoMHTA+kRAiZsAJ0bM+4AoE8lm9P4710wBYHgEJEF2QCeJXp2 e8eYWl2vl37w/Hj0SQE8iqU= =4SHi -----END PGP SIGNATURE----- --------------enig5E976401C98A2FF33C942128--