Krzysztof Błaszkowski wrote:
> On Wed, 2010-08-18 at 14:37 +0200, Gilles Chanteperdrix wrote:
>> Krzysztof Błaszkowski wrote:
>>>>> rather i use native clean x86 environment (on e.g. x86_64)
>>>> I do this all the time, and never had any problem.
>>> i had lots with header files mainly.
>> Well, the glibc and Xenomai header files are the same on 64 bits and 32
>> bits machines... of course, if you are talking about other libs...
> ;) i don't mean Xenomai and degree of crosscompilation complexity
> depends on what you try to compile.
> i remember a few years ago it was not so funny.
>>> and i am happy with my way.
>>>> Also, why not running 64 bits code on your atom? There are some x86_32
>>>> only atoms? What about SMP?
>>> for some other constraints i will not mention i use 32 bits now.
>>> this is single core cpu so no point to use smp for e.g. 8 cpus (nor
>>> bigsmp)
>> Well, my atom has hyper-threading, so, SMP can be used, Linux sees two
>> threads. I suspect yours has hyper-threading too, since Linux mentions
>> that it sees an ACPI SMP table, but usually, hyper-threading needs to be
>> enabled at BIOS level.
> yes, it has "ht". disabled now. i thought that i don't want to try to
> solve superposition of various corner cases and stuck on solving this.
> otoh, i could create such case. did i ?
> (btw, rtai 3.7 works)

This does not give us any clue, since neither the I-pipe patch nor the
heap code are shared. But as I said, I suspect the bug is rather in the
kernel configuration than anywhere else.

We are going to try something else. The .config I use on my atom is here:;a=blob_plain;f=boards/generic/atom-32/config-2.6.31;hb=HEAD

Could you start from this configuration, adding only what is needed to
boot your box (root filesystem device controller, or network controller
if booting over nfs, root filesystem), then test this kernel?


Xenomai-core mailing list

Reply via email to