From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <44427E26.6040608@domain.hid> Date: Sun, 16 Apr 2006 19:25:58 +0200 From: Philippe Gerum MIME-Version: 1.0 Subject: Re: [Xenomai-help] Problems running testsuite References: <200604131149.40706.tmarscha@domain.hid> <443E9FD2.6070807@domain.hid> <200604141342.40129.tmarscha@domain.hid> <17471.38482.617361.14216@domain.hid> <443FB0BA.5060404@domain.hid> In-Reply-To: <443FB0BA.5060404@domain.hid> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jim Cromie Cc: xenomai@xenomai.org Jim Cromie wrote: > Gilles Chanteperdrix wrote: > >> Tobias Marschall wrote: >> > Hello, >> > > On Thursday 13 April 2006 21:00, you wrote: >> > > I saw a similar error when using --enable-x86-sep and not having >> NPTL >> > > enabled in glibc. >> > > Try configuring without --enable-x86-sep (used in the README.INSTALL >> > > Pentium x86 example, the default is disabled). >> > that did the trick, thank you for the hint! I did check that the >> cpu supported > the sep instruction, but I wasn't aware that NPTL is >> required in this case. >> > > Mentioning this in README.INSTALL would be helpful. I wonder if >> that mistake > could be caught by configure. >> It could be caught by configure, at least if not cross-compiling, by >> running getconf GNU_LIBPTHREAD_VERSION. >> >> > > ie: > [jimc@domain.hid xenomai]$ getconf GNU_LIBPTHREAD_VERSION > NPTL 2.3.6 > > doesnt /proc/cpuinfo, flags entry, indicate whether the cpu supports SEP ? > It should, yes. > flags : fpu vme de pse tsc msr mce cx8 apic mtrr pge mca cmov > pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe est tm2 > Strange indeed, if that's a recent genuine Intel CPU. > > what x86 processors support --enable-x86-sep ? Pentium-4 ? Xeon ? > Athlon ? > my Pentium-M apparently doesnt. AFAIK, Intel supports sysenter/sysexit since the PII, and AMD introduced them with the K7. The genuine Pentium M does support them, no doubt. > > > > WRT inferring more stuff from the build/host machine, I have some concerns; > I build on my 686 laptop for a smaller/different 586 target. This is > not 'cross-compilation', > and could be compromised by too many automatic optimizations. > So, ideally, Id like the potentially troublesome optimizations to be > identified and gated by a prompt. > > Maybe we need a script thats run on the target box, that collects > the needed configuration factors; presumably including: > CPUFLAGS=`grep flags /proc/cpuinfo` > NPTL_AVAIL=`getconf GNU_LIBPTHREAD_VERSION` > The problem is that we might not always have the target at hand when building the user-space support (e.g. LiveCD, deployment distro stuff). Therefore it could only be some optional helper, but not part of the regular build process. > > Somewhat related: prepare-kernel asks me for target architecture, I > started by entering i586 explicitly, > but after a while, just took the i686 default. Ive not noticed anything > different/wrong, > but would appreciate confirmation/explanation. > Which information did you look at to determine that it was using the 686 profile? > thanks > jimc > > > PS. attached is an attempt to improve README.INSTALL along these and > other lines. > Please feel free to cut out the false parts ;-) > > > ------------------------------------------------------------------------ > > Index: README.INSTALL > =================================================================== > --- README.INSTALL (revision 927) > +++ README.INSTALL (working copy) > @@ -74,6 +74,19 @@ > Once the target kernel has been prepared, all Xenomai configuration > options are available from the "Real-time subsystem" toplevel menu. > > +When configuring, you should *disable* PM (power management), ACPI, > +and CPU_FREQ. The 1st 2 invoke uninterruptible BIOS routines, which > +destroy the rt-determinism guarantees that you're presumably seeking. > +If you're curious, build it, install it, and run xeno-test, you'll > +likely see very large latencies. If you see otherwise, please email > +the evidence. > + > +CPU_FREQ is bad because it breaks some timing guarantees on some > +chips, and these problems are too varied/unpredictable to accomodate. > +For example, (my) Pentium-M laptop shows "cpu MHz : 600.000" at idle, > +but 1700 when compiling. Some TSCs also change frequency with the > +processor, making them useless if the clock is changing. > + > Once configured, the kernel should be built as usual. > > It might be a good idea to put all the output into a different build > @@ -143,9 +156,11 @@ > NAME DESCRIPTION [BINDING,]DEFAULT(*) > > --enable-x86-sep Enable x86 SEP instructions strong,disabled > - for issuing syscalls > + for issuing syscalls. > + You will also need NPTL > > --enable-x86-tsc Enable x86 TSC for timings strong,enabled > + falls back to PIT if needed > > --enable-arm-arch Define version of the target strong,"4" > ARM core architecture > > > ------------------------------------------------------------------------ > > _______________________________________________ > Xenomai-help mailing list > Xenomai-help@domain.hid > https://mail.gna.org/listinfo/xenomai-help -- Philippe.