From: Philippe Gerum <rpm@xenomai.org>
To: Jim Cromie <jim.cromie@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] Problems running testsuite
Date: Mon, 17 Apr 2006 10:43:16 +0200 [thread overview]
Message-ID: <44435524.4040209@domain.hid> (raw)
In-Reply-To: <4442B118.4070300@domain.hid>
Jim Cromie wrote:
> Philippe Gerum wrote:
>
>> 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.
>>
>
> Well, Im not *stoned*, but it clearly looks like I am..
> heres the whole thing:
>
> [jimc@domain.hid linux-2.6.16]$ cat /proc/cpuinfo
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 6
> model : 13
> model name : Intel(R) Pentium(R) M processor 1.70GHz
> stepping : 6
> cpu MHz : 600.000
> cache size : 2048 KB
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 2
> wp : 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
> bogomips : 1198.01
>
>
> very strange. Ive seen someone elses P-4 cpuinfo, flag is there,
> spelled 'sep'
>
Same here.
>
>>>
>>> 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.
>>
> Perhaps I need to email LKML.
> What would you expect if I built with --enable-sep (for my laptop) ?
> success / illegal-instruction exception / undefined-wierd behavior ?
>
Success or illegal instruction, I guess.
<snip>
>>> 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.
>>
> Ack. I was thinking in terms of a script run on target, which produces
> an .rc file,
> which defines the factor=value pairs needed.
> that file, if supplied to prepare-kernel as --target-info=<foo>
> would supply the customizations.
> Yes, somewhat cumbersome..
>
Yep; Gilles's approach looking for potential configuration mismatch
dynamically when running the target code seems easier to implement, and
would provide a better coverage (e.g. building Xenomai for a 'generic'
target).
> Perhaps Ive just been lucky, 'cross-compiling' for 586 on 686.
> Ill try hacking prepare-kernel and re-building.
>
>>>
>>> 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?
>
> The script output told me. In response to my post, Gilles sent me the
> snippet
> from scripts/prepare-kernel where all x86) select i386.
>
> Im not sure what youre asking, so I'll answer something (hopefully) close:
> config/config.guess is providing the basis for the answer
>
> if test x$linux_arch = x; then
> build_arch=`$xenomai_root/config/config.guess`
> default_linux_arch=`echo $build_arch|cut -f1 -d-`
> fi
>
> which 'returns' this:
> test x"${LIBC}" != x && echo "${UNAME_MACHINE}-pc-linux-${LIBC}"
> && exit 0
>
> ie
> sh -vx config/config.guess
> ...
> + eval LIBC=gnu
> LIBC=gnu
> ++ LIBC=gnu
> + test xgnu '!=' x
> + echo i686-pc-linux-gnu
> i686-pc-linux-gnu
>
Ok, that is intended, but only if --arch is unspecified on the command
line. Passing --arch=i586 should select i386 as the kernel architecture,
which in turn causes the exact CPU profile to be obtained from Kconfig's
current 'processor type and features' selection. The latter is what
actually defines the arch-dependent compiler flags for the kernel (i.e.
arch/i386/Makefile.cpu).
>
>>
>>> thanks
>>> jimc
>>>
>>>
>>> PS. attached is an attempt to improve README.INSTALL along these and
>>> other lines.
>
> will redo per your comments
>
--
Philippe.
next prev parent reply other threads:[~2006-04-17 8:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-13 9:49 [Xenomai-help] Problems running testsuite Tobias Marschall
2006-04-13 13:17 ` Jim Cromie
2006-04-13 18:41 ` Philippe Gerum
2006-04-13 18:44 ` Philippe Gerum
2006-04-13 19:00 ` Scott Biddlestone
2006-04-14 11:42 ` Tobias Marschall
2006-04-14 12:32 ` Gilles Chanteperdrix
2006-04-14 14:24 ` Jim Cromie
2006-04-16 17:25 ` Philippe Gerum
2006-04-16 17:58 ` Gilles Chanteperdrix
2006-04-16 18:15 ` Philippe Gerum
2006-04-17 17:12 ` Gilles Chanteperdrix
2006-04-16 21:03 ` Jim Cromie
2006-04-17 8:43 ` Philippe Gerum [this message]
2006-04-16 17:38 ` Philippe Gerum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44435524.4040209@domain.hid \
--to=rpm@xenomai.org \
--cc=jim.cromie@domain.hid \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.