Johan Borkhuis | 2 Jul 13:25 2007
Picon

Switch to secondary mode

Hello,

I am having some problems with an application switching to secondary 
mode. One of my applications is switching to secondary mode when a 
function is called in a library. This function itself is empty (only 
returning 0).
When I move this function out of the library into the main C-file the 
program stays in primary mode. What could be happening here?

This is the output of a backtrace:
./dsAuxEvQueTest1[0x10001858]
/lib/ld.so.1[0x3001eaf8]
[0x0]
./dsAuxEvQueTest1[0x100018f0]
./dsAuxEvQueTest1[0x10005c9c]
/lib/libpthread.so.0[0xffd32fc]
/lib/libc.so.6(__clone+0x84)[0xfe751e8]

Do I need to use some specific compile or link commandline arguments?

My architecture is ppc, Xenomai version 2.3.1 and kernel 2.6.14.

Kind regards,
    Johan Borkhuis
Philippe Gerum | 2 Jul 13:54 2007

Re: Switch to secondary mode

On Mon, 2007-07-02 at 13:25 +0200, Johan Borkhuis wrote:
> Hello,
> 
> I am having some problems with an application switching to secondary 
> mode. One of my applications is switching to secondary mode when a 
> function is called in a library. This function itself is empty (only 
> returning 0).
> When I move this function out of the library into the main C-file the 
> program stays in primary mode. What could be happening here?
> 

Late binding to functions performed on behalf of the dynamic loader
against shared libraries shall need the kernel during symbol resolution
(internal syscalls) or execution (e.g. demand loading, COW), hence the
switch. Unfortunately, the I-pipe patch for PPC does not support
disabling all on-demand memory mappings for selected Linux tasks (only
the x86 and ARM patches support this feature so far).

> This is the output of a backtrace:
> ./dsAuxEvQueTest1[0x10001858]
> /lib/ld.so.1[0x3001eaf8]
> [0x0]
> ./dsAuxEvQueTest1[0x100018f0]
> ./dsAuxEvQueTest1[0x10005c9c]
> /lib/libpthread.so.0[0xffd32fc]
> /lib/libc.so.6(__clone+0x84)[0xfe751e8]
> 
> Do I need to use some specific compile or link commandline arguments?
> 
> My architecture is ppc, Xenomai version 2.3.1 and kernel 2.6.14.
(Continue reading)

Johan Borkhuis | 2 Jul 16:18 2007
Picon

Re: Switch to secondary mode

Philippe,

Philippe Gerum wrote:
> Late binding to functions performed on behalf of the dynamic loader
> against shared libraries shall need the kernel during symbol resolution
> (internal syscalls) or execution (e.g. demand loading, COW), hence the
> switch. Unfortunately, the I-pipe patch for PPC does not support
> disabling all on-demand memory mappings for selected Linux tasks (only
> the x86 and ARM patches support this feature so far).
>   

Thank you for you answer.

Just for me to make sure I understand this correctly:
We are not using shared libraries for our application, our applications 
are linked against .a files, which are included in the final application 
(all symbols are resolved and available in the executable, so I expected 
that all symbols would have been resolved. This does apply to that as 
well to this type of applications?
(I tried linking using -static,  but that does still give the same problem.)

How can I avoid this problem? Is there a way to make sure all symbols 
are available in memory, or is there a way to instruct the 
compiler/linker/loader to perform the symbol-resolving during 
compile-time or on load?
One thing I am thinking of (but this may be completely wrong) is to have 
a Init function in all modules that are part of the library. When a 
library module is used, this Init function needs to be called before 
switching to RT-mode, so the symbols are made available to the 
application. Would this work (and solve the problem), or would this 
(Continue reading)

Johan Borkhuis | 2 Jul 16:27 2007
Picon

Re: Switch to secondary mode

One more question.

I tried finding the cause of the switch using the backtrace commands, 
but this does not give a very clear picture of what is causing the 
switch. Are there other commands that give a better view, or is there 
some instruction (or just a direction) on how to interpret the backtrace?

Kind regards,
    Johan Borkhuis
Philippe Gerum | 2 Jul 16:48 2007

Re: Switch to secondary mode

On Mon, 2007-07-02 at 16:18 +0200, Johan Borkhuis wrote:
> Philippe,
> 
> Philippe Gerum wrote:
> > Late binding to functions performed on behalf of the dynamic loader
> > against shared libraries shall need the kernel during symbol resolution
> > (internal syscalls) or execution (e.g. demand loading, COW), hence the
> > switch. Unfortunately, the I-pipe patch for PPC does not support
> > disabling all on-demand memory mappings for selected Linux tasks (only
> > the x86 and ARM patches support this feature so far).
> >   
> 
> Thank you for you answer.
> 
> Just for me to make sure I understand this correctly:
> We are not using shared libraries for our application, our applications 
> are linked against .a files, which are included in the final application

In such a case, you have likely hit an illustration of the latter issue
which the I-pipe/ppc implementation still suffers from: some page table
entries are missed during real-time operations. As a consequence of
this, the nucleus catches page faults on behalf of RT threads in primary
mode, then switches these threads back to secondary in order to process
the faults, and eventually wire the missing PTEs in. This is something
calling mlockall() does not prevent the application from (like COW).

The shared lib problem would be another issue, even if it relates to the
same general topic (i.e. lazy/on-demand mapping of memory resources the
kernel performs).

(Continue reading)

Stephan Guenther | 2 Jul 23:16 2007
Picon

Xenomai & Gumstix cross compiling

Hello,
I have to install Xenomai on a gumstix (ARM architecture). So I did the
following:

1) I looked for a compatible Gumstix Build root (one with a kernel version
matching a Xenomai Patch). That was Gumstix SVN revision 936 (2.6.15
kernel).

2) I startet the Gumstix Buildroot and interrupted it as soon as the kernel
was downloaded. At this point, it is a vanilla kernel to which gumstix
specific patches will be applied later in the build root process.
I extractet the kernel, applied the correct Adeos patch and the Xenomai
patches by running "scripts/prepare-kernel.sh <path_to_adeos_patched_kernel>
-- arch=arm"

3) I bzipped the resulting kernel and copied it in the Gumstix build root
(so it will not be downloaded or overwritten again). Then I startet the
Gumstix build root process again and configured everything without errors.
The Xeonmai options where available.
After the process had finished I copied the image on my gumstix. The gumstix
is booting up correctly and loading the Xenomai domain - everything seems to
be alright.

4) Now I had to cross compile Xenomai on my i386 host. I used ELDT (Embedded
Linux Development Tools) and run the following commands in the xenomai root
directory:

xenomai_root/configure --build=i686-linux --host=arm-linux CC=arm-linux-gcc
LD=arm-linux-ld
make DESTDIR=/home/.../xenobin install
(Continue reading)

Johan Borkhuis | 3 Jul 11:09 2007
Picon

Re: Switch to secondary mode

Philippe,

Again, thank you for very extensive answer. It is starting to get 
clearer what is happening here but I still have some questions.

The first one is probably an easy one: what do you mean by COW? I did 
try to find what this means, but I was only able to find references to 
farm animals..... (and some references to lazy linking etc. but there 
COW was also not explained).

Philippe Gerum wrote:
> On Mon, 2007-07-02 at 16:18 +0200, Johan Borkhuis wrote:
>   
>> Philippe,
>>
>> Philippe Gerum wrote:
>>     
>>> Late binding to functions performed on behalf of the dynamic loader
>>> against shared libraries shall need the kernel during symbol resolution
>>> (internal syscalls) or execution (e.g. demand loading, COW), hence the
>>> switch. Unfortunately, the I-pipe patch for PPC does not support
>>> disabling all on-demand memory mappings for selected Linux tasks (only
>>> the x86 and ARM patches support this feature so far).
>>>   
>>>       
>> Thank you for you answer.
>>
>> Just for me to make sure I understand this correctly:
>> We are not using shared libraries for our application, our applications 
>> are linked against .a files, which are included in the final application
(Continue reading)

Philippe Gerum | 3 Jul 19:21 2007

Re: Switch to secondary mode

On Tue, 2007-07-03 at 11:09 +0200, Johan Borkhuis wrote:
> Philippe,
> 
> Again, thank you for very extensive answer. It is starting to get 
> clearer what is happening here but I still have some questions.
> 
> The first one is probably an easy one: what do you mean by COW? I did 
> try to find what this means, but I was only able to find references to 
> farm animals.....

Ok, that's a good start.

>  (and some references to lazy linking etc. but there 
> COW was also not explained).

Search for "copy-on-write".

> 
> Philippe Gerum wrote:
> > On Mon, 2007-07-02 at 16:18 +0200, Johan Borkhuis wrote:
> >   
> >> Philippe,
> >>
> >> Philippe Gerum wrote:
> >>     
> >>> Late binding to functions performed on behalf of the dynamic loader
> >>> against shared libraries shall need the kernel during symbol resolution
> >>> (internal syscalls) or execution (e.g. demand loading, COW), hence the
> >>> switch. Unfortunately, the I-pipe patch for PPC does not support
> >>> disabling all on-demand memory mappings for selected Linux tasks (only
(Continue reading)

Jeff Koftinoff | 3 Jul 21:53 2007

Re: Switch to secondary mode

Philippe Gerum wrote:
> In such a case, you have likely hit an illustration of the latter issue
> which the I-pipe/ppc implementation still suffers from: some page table
> entries are missed during real-time operations. As a consequence of
> this, the nucleus catches page faults on behalf of RT threads in primary
> mode, then switches these threads back to secondary in order to process
> the faults, and eventually wire the missing PTEs in. This is something
> calling mlockall() does not prevent the application from (like COW).
>
> The shared lib problem would be another issue, even if it relates to the
> same general topic (i.e. lazy/on-demand mapping of memory resources the
> kernel performs).
>
>   
Hi Philippe.

Very soon I am going to be using Xenomai on PPC with SMP...

Under what situations are 'page table entries missed'? what exactly does 
that mean?

Regards,
Jeff Koftinoff

www.jdkoftinoff.com
Philippe Gerum | 3 Jul 23:40 2007

Re: Switch to secondary mode

On Tue, 2007-07-03 at 12:53 -0700, Jeff Koftinoff wrote:
> Philippe Gerum wrote:
> > In such a case, you have likely hit an illustration of the latter issue
> > which the I-pipe/ppc implementation still suffers from: some page table
> > entries are missed during real-time operations. As a consequence of
> > this, the nucleus catches page faults on behalf of RT threads in primary
> > mode, then switches these threads back to secondary in order to process
> > the faults, and eventually wire the missing PTEs in. This is something
> > calling mlockall() does not prevent the application from (like COW).
> >
> > The shared lib problem would be another issue, even if it relates to the
> > same general topic (i.e. lazy/on-demand mapping of memory resources the
> > kernel performs).
> >
> >   
> Hi Philippe.
> 
> Very soon I am going to be using Xenomai on PPC with SMP...

You mean ppc64?

> 
> Under what situations are 'page table entries missed'? what exactly does 
> that mean?
> 

For instance, the MMU service code constantly needs to populate an
internal cache holding the most recently used PTEs, but also to evict
some page table entries, when it is under pressure to get space into the
cache to hold other - hotter - entries. In that case, any subsequent
(Continue reading)


Gmane