[linux-2.6.26.8-rt14] RT Page Fault.

[linux-2.6.26.8-rt14] RT Page Fault.

[Lukasz Majewski]

Hello

I hope that this post won't be regarded as "dummy" one.

I'm struggling with 2.6.26.8-rt14 linux kernel for ARM architecture.

I'm using toolchain with uClibc 0.9.30, binutils 2.18 and gcc 4.2.4. I'm 
also using -msoft-float flag when I'm compiling my rt application. I'm 
performing heavy mathematical computations (mostly multiplication of 
double matrices).


The application is build around a simple static cyclic schedule with 
period of 20ms. During this time I'm performing my calculations for 
around 13 ms and sleep (with nanosleep)  for 7ms. I'm using gettimeofday 
instead of clock_gettime. I've set it's rtprio as 71 (only posixtimer 
has 99 rtprio). I'm also using NFS to mount root file system from my 
host x86 ubuntu PC.

My application consist of several .c and .h files, which build several 
object files (.o). I'm also using some global variables defined at 
common_def.h header file. I'm linking this application statically 
(LDFLAG=-static), so executable binary has 113kB .My embedded system has 
48MB of RAM to be used by Linux.

When I start my application it runs for some time and ends as expected. 
It seems that everything is OK. Static schedule is not violated. 
Unfortunately, after running this application for couple of times (6 to 
10) I can see that static schedule is violated(delayed in execution) for 
about 2-4 seconds. Application is running for 1-2 seconds as expected 
and then crashes(I mean exits with static schedule delay of 2-4 
seconds). It looks like page fault, but in my main() I've add mlockall() 
as writen in the examples from rt.wiki. Moreover I've prevent stack as 
written  in "square_wave example". Before my application exits I'm 
calling munlockall(). When I log via ssh to my embedded system and start 
top,I cannot see that I've got some memory leaks or zombi processes 
during run of my RT application.

May it be possible that by some chance some global variable is not 
locked in the memory? What is the "scope" of mlockall? Is it only valid 
in one .o module or it lock all pages as they were loaded?

What is the order of loading binary executable to the memory? May it 
happen that in some case there is one page which was not locked and it 
causes page fault?

In my application I'm using some /dev/ files (like ttyS0). I'm opening 
it during startup of my program (with non block flag) and call 
read/write during my RT loop. I've checked that with of without call to 
this read/write functions bug described above shows up.

I have also try to replace NFS rootfs with the same rootfs from SD card. 
There was no difference and the bug was in both cases.

I'd appreciate any hints/comments what can cause this bug. I was trying 
to use strace and gdb to fix this problem, but this tools are to slow 
and they cause violation of my cyclic static schedule.


Thank's in advance,
Lukasz

Re: [linux-2.6.26.8-rt14] RT Page Fault.

[Remy Bohmer]

Hello Lukasz,

> I'm also using NFS to mount root file system from my host x86 ubuntu PC.

Have you tried already running from a ram-disk?

> When I start my application it runs for some time and ends as expected. It
> seems that everything is OK. Static schedule is not violated. Unfortunately,
> after running this application for couple of times (6 to 10) I can see that
> static schedule is violated(delayed in execution) for about 2-4 seconds.
> Application is running for 1-2 seconds as expected and then crashes(I mean
> exits with static schedule delay of 2-4 seconds). It looks like page fault,

You can trace the number of page-faults during run, by means of
getrusage(), see rt-wiki.
2-4 seconds sounds quite long for page fault handling to me (unless
you are using page/swap files)

> but in my main() I've add mlockall() as writen in the examples from rt.wiki.
> Moreover I've prevent stack as written  in "square_wave example". Before my
> application exits I'm calling munlockall(). When I log via ssh to my
> embedded system and start top,I cannot see that I've got some memory leaks
> or zombi processes during run of my RT application.
>
> May it be possible that by some chance some global variable is not locked in
> the memory? What is the "scope" of mlockall? Is it only valid in one .o

mlockall() is somewhat tricky. It locks all allocated data pages (and
future pages, if specified) in to RAM, but IIRC code segments are not
forced to be loaded into RAM, but only code segments that are loaded
once, will be locked. So, in theory, there could be pages still on the
NFS share that are not loaded when the problem arises. So, this could
be the problem you see, but it would not be the first suspect I would
look for.

> I'd appreciate any hints/comments what can cause this bug.

I read you use uClibc, the last time I looked at it (quite some time
ago), it lacked support for priority inheritance mutexes... Aren't you
running in a mutex priority inversion?

Or priority inversion related to other interrupt threads? You run at
prio 71, if you leave the network, or block device
softirqs/irq-threads on 50, you could have a priority inversion on
this level as well. This would be my prime suspect...

> I was trying to
> use strace and gdb to fix this problem, but this tools are to slow and they
> cause violation of my cyclic static schedule.

No ETM trace available? Really nice to have in such cases...


Kind Regards,

Remy

Re: [linux-2.6.26.8-rt14] RT Page Fault.

[Lukasz Majewski]

Hello,

Thank you for this extremely fast response. :-)

I haven't try to run my application from RAM disk (as suppose you 
suggest building initramrd or initramfs). It's inconvenient, for 
development, since size of such init ram disk is limited. I will try it 
anyway.

Now some explanation about uClibc. I know that this C library lacks of 
many features (for instance NTPL support for ARM). Unfortunately, for 
ARM architecture, there is nice utility -> buildroot  for building 
toolchain and  root filesystems. I'm not using x86 as target 
architecture, so cross compiling toolchain without errors is success as 
it is :-).

I've tried pxtdist tool from pengutronix.de , but I cannot build proper 
toolchain without errors for my Atmel's ARM9 device (ARMv5tej arch to be 
precise). Or saying it in another way -> I gave up after spending some 
time and moved back toward working uClibc. I've build some toolchains, 
but during build I've encountered some errors and despite of that it, 
built arm-linux-gcc which worked, I wasn't sure if glibc is not cracked 
in some way.

On my first post I haven't mention that I was checking rusage struct for 
minor and major page faults.
In my program I checked it twice: first before calling mlockall() - on 
the beginning of the program and after munlockall() when program ends 
either when delay occurs or in normal termination. In both cases I've 
got the same number of minor and major page faults. So it looks that no 
page fault appears.


I've checked, and it turns out that uClibc 0.9.30 is not supporting PI 
(priority inversion) and futexes. This may cause my bug ,since I'm 
heavily using read/write on /dev/ files (read/write to 4 differen 
files). There's a lot of space for priority inversion in my code :-/. I 
was writing this code with holly faith that "in some way" priority 
inversion is avoided. I assumed, that access to some device (resource in 
this case) has some mechanism to inheritance the priority.

Is looks,that the only solution for me is to build toolchain with glibc 
at least 2.6 and gcc 4.+ with full support of Priority Inheritance, 
futexses and "clock_" set of functions.  As I mentioned it's a bit 
tricky for ARM (especialy with proper ABI and software floating point 
support (msoft-float)). But it looks as the only feasible solution.

Thanks for advice.

Regards,
Lukasz



Remy Bohmer wrote:
> Hello Lukasz,
>
>   
>> I'm also using NFS to mount root file system from my host x86 ubuntu PC.
>>     
>
> Have you tried already running from a ram-disk?
>
>   
>> When I start my application it runs for some time and ends as expected. It
>> seems that everything is OK. Static schedule is not violated. Unfortunately,
>> after running this application for couple of times (6 to 10) I can see that
>> static schedule is violated(delayed in execution) for about 2-4 seconds.
>> Application is running for 1-2 seconds as expected and then crashes(I mean
>> exits with static schedule delay of 2-4 seconds). It looks like page fault,
>>     
>
> You can trace the number of page-faults during run, by means of
> getrusage(), see rt-wiki.
> 2-4 seconds sounds quite long for page fault handling to me (unless
> you are using page/swap files)
>
>   
>> but in my main() I've add mlockall() as writen in the examples from rt.wiki.
>> Moreover I've prevent stack as written  in "square_wave example". Before my
>> application exits I'm calling munlockall(). When I log via ssh to my
>> embedded system and start top,I cannot see that I've got some memory leaks
>> or zombi processes during run of my RT application.
>>
>> May it be possible that by some chance some global variable is not locked in
>> the memory? What is the "scope" of mlockall? Is it only valid in one .o
>>     
>
> mlockall() is somewhat tricky. It locks all allocated data pages (and
> future pages, if specified) in to RAM, but IIRC code segments are not
> forced to be loaded into RAM, but only code segments that are loaded
> once, will be locked. So, in theory, there could be pages still on the
> NFS share that are not loaded when the problem arises. So, this could
> be the problem you see, but it would not be the first suspect I would
> look for.
>
>   
>> I'd appreciate any hints/comments what can cause this bug.
>>     
>
> I read you use uClibc, the last time I looked at it (quite some time
> ago), it lacked support for priority inheritance mutexes... Aren't you
> running in a mutex priority inversion?
>
> Or priority inversion related to other interrupt threads? You run at
> prio 71, if you leave the network, or block device
> softirqs/irq-threads on 50, you could have a priority inversion on
> this level as well. This would be my prime suspect...
>
>   
>> I was trying to
>> use strace and gdb to fix this problem, but this tools are to slow and they
>> cause violation of my cyclic static schedule.
>>     
>
> No ETM trace available? Really nice to have in such cases...
>
>
> Kind Regards,
>
> Remy
>
>   

Re: [linux-2.6.26.8-rt14] RT Page Fault.

[Remy Bohmer]

Hello Lukasz,

2009/2/23 Lukasz Majewski <majess1982@gmail.com>:
> Hello,
>
> Thank you for this extremely fast response. :-)

No thanks :-)

> Now some explanation about uClibc. I know that this C library lacks of many
> features (for instance NTPL support for ARM). Unfortunately, for ARM
> architecture, there is nice utility -> buildroot  for building toolchain and
>  root filesystems. I'm not using x86 as target architecture, so cross
> compiling toolchain without errors is success as it is :-).
> I've tried pxtdist tool from pengutronix.de , but I cannot build proper
> toolchain without errors for my Atmel's ARM9 device (ARMv5tej arch to be
> precise). Or saying it in another way -> I gave up after spending some time
> and moved back toward working uClibc. I've build some toolchains, but during
> build I've encountered some errors and despite of that it, built

If you have problems building compiler toolchains, there are other
ways to do it.
You can use a precompiled (and tested) toolchain, for example:
* http://www.codesourcery.com/sgpp/lite/arm.
* http://www.denx.de/wiki/DULG/ELDK
* ....
The advantage of such a precompiled toolchain, is that it saves you a
lot of build time, and you can focus on the things that matter for
your application.

> arm-linux-gcc which worked, I wasn't sure if glibc is not cracked in some
> way.
>
> On my first post I haven't mention that I was checking rusage struct for
> minor and major page faults.
> In my program I checked it twice: first before calling mlockall() - on the
> beginning of the program and after munlockall() when program ends either
> when delay occurs or in normal termination. In both cases I've got the same
> number of minor and major page faults. So it looks that no page fault
> appears.

Strange, normally mlockall generates a lot of pagefaults by just
calling it, so there should be a difference before and directly after
calling mlockall.

> I've checked, and it turns out that uClibc 0.9.30 is not supporting PI
> (priority inversion) and futexes. This may cause my bug ,since I'm heavily
> using read/write on /dev/ files (read/write to 4 differen files). There's a
> lot of space for priority inversion in my code :-/. I was writing this code
> with holly faith that "in some way" priority inversion is avoided. I
> assumed, that access to some device (resource in this case) has some
> mechanism to inheritance the priority.

That depends on the driver behind it. In kernel there is always PI
support on mutexes.
PI mutexes should be enabled for mutexes in your own code.

Do not forget to look at the priority of softirq-s/irq-threads related
to your RT-threads.
if, for example, you have a thread running at prio 60, softirqs and
irq-threads running at 50, and your RT thread is running at 70, and it
has some dependency to the prio 50 irqs, then you could have an
inversion problem here as well. The prio 60 task could prevent the
softirqs and irq-threads from running, leaving the prio 70 task
waiting for a very long time.

> Is looks,that the only solution for me is to build toolchain with glibc at
> least 2.6 and gcc 4.+ with full support of Priority Inheritance, futexses
> and "clock_" set of functions.  As I mentioned it's a bit tricky for ARM
> (especialy with proper ABI and software floating point support
> (msoft-float)). But it looks as the only feasible solution.

As mentioned above, you could use a precompiled toolchain.
It would at least safe you time to get it working, and if you still
want to compile one yourself, you can always do it later...

Kind Regards,

Remy

Re: [linux-2.6.26.8-rt14] RT Page Fault.

[Robert Schwebel]

On Mon, Feb 23, 2009 at 12:01:04AM +0100, Lukasz Majewski wrote:
> Now some explanation about uClibc. I know that this C library lacks of
> many features (for instance NTPL support for ARM). Unfortunately, for
> ARM architecture, there is nice utility -> buildroot  for building
> toolchain and  root filesystems.

You can use ptxdist do do almost the same.

> I've tried pxtdist tool from pengutronix.de, but I cannot build proper
> toolchain without errors for my Atmel's ARM9 device (ARMv5tej arch to be
> precise). Or saying it in another way -> I gave up after spending some
> time and moved back toward working uClibc.

Well, you could have reported that to the OSELAS.Toolchain maintainers :)

What kind of problem do you see? We are using the the v5te toolchain
quite intensively on AT91SAM9260 and AT91SAM9263 without problems.

So send us your error output and let's see what we can do. The ptxdist
mailing list is probably the right list for that kind of discussion.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [linux-2.6.26.8-rt14] RT Page Fault.

[Lukasz Majewski]

Hello Robert.

I'm building toolchain for AT572D940HF Atmel chip. It's ARM9 combined 
with DSP. I'd like to build toolchain for ARM9 (ARMv5tej) with 
-msoft-float support, EABI and full glibc ,to support all stuff 
connected with PREEMPT_RT patch - especially librt.

Now I've downloaded:
ptxdist-1.99.11 and ptxdist-1.99.11-patches.

and
OSELAS.Toolchain-1.99.3

I've selected 
./ptxconfigs/arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized

I need toolchain with -msoft-float support and EABI.

Unfortunately there is an error about mismatch in the linux-kernel 
headers. My Host PC has linux-kernel of 2.6.24 and not 2.6.27. My target 
is working under 2.6.26.8-rt14 kernel.
The error is in building of NTPL library, after successfully compilation 
of gcc compiler.

How can I provide proper kernel headers?

Now I'm trying with 
arm-v5te-linux-gnueabi-gcc-4.1.2-glibc-2.5-binutils-2.17-kernel-2.6.18 
ptxconfig. I hope that this will be sufficiently new to provide priority 
inheritance, futexes , librt with all features.

I'm building it now and hope that I won't encounter any problems.


Regards,
Lukasz

Robert Schwebel wrote:
> On Mon, Feb 23, 2009 at 12:01:04AM +0100, Lukasz Majewski wrote:
>   
>> Now some explanation about uClibc. I know that this C library lacks of
>> many features (for instance NTPL support for ARM). Unfortunately, for
>> ARM architecture, there is nice utility -> buildroot  for building
>> toolchain and  root filesystems.
>>     
>
> You can use ptxdist do do almost the same.
>
>   
>> I've tried pxtdist tool from pengutronix.de, but I cannot build proper
>> toolchain without errors for my Atmel's ARM9 device (ARMv5tej arch to be
>> precise). Or saying it in another way -> I gave up after spending some
>> time and moved back toward working uClibc.
>>     
>
> Well, you could have reported that to the OSELAS.Toolchain maintainers :)
>
> What kind of problem do you see? We are using the the v5te toolchain
> quite intensively on AT91SAM9260 and AT91SAM9263 without problems.
>
> So send us your error output and let's see what we can do. The ptxdist
> mailing list is probably the right list for that kind of discussion.
>
> rsc
>   

Re: [linux-2.6.26.8-rt14] RT Page Fault.

[Robert Schwebel]

Hi Lukasz,

On Mon, Feb 23, 2009 at 05:21:36PM +0100, Lukasz Majewski wrote:
> I'm building toolchain for AT572D940HF Atmel chip. It's ARM9 combined
> with DSP. I'd like to build toolchain for ARM9 (ARMv5tej) with
> -msoft-float support, EABI and full glibc ,to support all stuff
> connected with PREEMPT_RT patch - especially librt.

Ok.

> Now I've downloaded:
> ptxdist-1.99.11 and ptxdist-1.99.11-patches.

yup

> and
> OSELAS.Toolchain-1.99.3

exactly

> I've selected
> ./ptxconfigs/arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized
>
> I need toolchain with -msoft-float support and EABI.

The toolchain you've selected above actually is softfloat and EABI. You
don't have to change anything, just do the steps you've mentioned above
and 'ptxdist go'.

> Unfortunately there is an error about mismatch in the linux-kernel
> headers.

Please send the exact error message (if too long, please off-list, to me
and "Marc Kleine-Budde <m.kleine-budde@pengutronix.de>").

> My Host PC has linux-kernel of 2.6.24 and not 2.6.27.

That's no problem; the toolchain you are trying to build is based on the
2.6.27 sanitized kernel headers. It's usually no problem at all using
such a toolchain on a variety of other kernel versions.

> My target is working under 2.6.26.8-rt14 kernel.

Should work.

> The error is in building of NTPL library, after successfully compilation
> of gcc compiler.
>
> How can I provide proper kernel headers?

See above, error messages, please.

> Now I'm trying with
> arm-v5te-linux-gnueabi-gcc-4.1.2-glibc-2.5-binutils-2.17-kernel-2.6.18
> ptxconfig. I hope that this will be sufficiently new to provide priority
> inheritance, futexes , librt with all features.

Yes, it is.

> I'm building it now and hope that I won't encounter any problems.

You may want to check that we have an update for 1.99.3 here:
http://www.pengutronix.de/oselas/toolchain/download/OSELAS.Toolchain-1.99.3.1.tar.bz2

There has been a build error on some distros and it might happen that
you are seeing exactly this issue.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [linux-2.6.26.8-rt14] RT Page Fault.

[Lukasz Majewski]

Hello Robert,

I've tried to build toolchain using the following ptxconfig file:

./ptxconfigs/arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized


I've also (as You advice) downloaded and used

OSELAS.Toolchain-1.99.3.1.tar.bz2

Then I've started building of my toolchain with

lukma@xxx:~/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1$ ../bin/ptxdist go

I've encountered following error (I hope that it's long enough to track 
it down.):

gawk -f ../scripts/gen-as-const.awk ../ports/sysdeps/arm/nptl/tcb-offsets.sym \

    | /usr/bin/gcc -S -o /home/lukma/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1/platform-arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/build-target/glibc-2.8-crt-build/tcb-offsets.hT3 -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -g -Wstrict-prototypes      -I../include -I/home/lukma/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1/platform-arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/build-target/glibc-2.8-crt-build/csu -I/home/lukma/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1/platform-arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/build-target/glibc-2.8-crt-build -I../ports/sysdeps/arm/elf -I../ports/sysdeps/unix/sysv/linux/arm/eabi/nptl
  -I../ports/sysdeps/unix/sysv/linux/arm/eabi -I../ports/sysdeps/unix/sysv/linux/arm/nptl -I../ports/sysdeps/unix/sysv/linux/arm -I../ports/sysdeps/unix/sysv/linux -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../ports/sysdeps/unix/sysv -I../nptl/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../ports/sysdeps/unix/arm -I../ports/sysdeps/unix -I../nptl/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../ports/sysdeps/arm/eabi -I../ports/sysdeps/arm/nptl -I../ports/sysdeps/arm -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../ports -I../np
 tl  -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/i486-linux-gnu/4.2.4/include -isystem /home/lukma/sbox_lukma/tools/arm-d940/arm-v5te-linux-gnueabi/gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/sysroot-arm-v5te-linux-gnueabi/usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h        -DHAVE_INITFINI -x c - \

        -MD -MP -MF /home/lukma/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1/platform-arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/build-target/glibc-2.8-crt-build/tcb-offsets.h.dT -MT '/home/lukma/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1/platform-arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/build-target/glibc-2.8-crt-build/tcb-offsets.h.d /home/lukma/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1/platform-arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/build-target/glibc-2.8-crt-build/tcb-offsets.h'

In file included from ../include/tls.h:6,

                 from ../ports/sysdeps/unix/sysv/linux/arm/eabi/sysdep.h:28,

                 from <stdin>:1:

../ports/sysdeps/arm/nptl/tls.h:48:3: error: #error "TLS support is required."

In file included from ../include/tls.h:6,

                 from ../include/link.h:45,

                 from ../include/dlfcn.h:3,

                 from ../sysdeps/generic/ldsodefs.h:32,

                 from ../ports/sysdeps/arm/ldsodefs.h:39,

                 from ../sysdeps/unix/sysv/linux/ldsodefs.h:25,

                 from <stdin>:2:

../ports/sysdeps/arm/nptl/tls.h:48:3: error: #error "TLS support is required."

In file included from ../ports/sysdeps/arm/nptl/tls.h:57,

                 from ../include/tls.h:6,

                 from ../include/link.h:45,

                 from ../include/dlfcn.h:3,

                 from ../sysdeps/generic/ldsodefs.h:32,

                 from ../ports/sysdeps/arm/ldsodefs.h:39,

                 from ../sysdeps/unix/sysv/linux/ldsodefs.h:25,

                 from <stdin>:2:

../ports/sysdeps/unix/sysv/linux/arm/eabi/sysdep.h:31:3: error: #error Kernel headers are too old

In file included from <stdin>:1:

../ports/sysdeps/unix/sysv/linux/arm/eabi/sysdep.h:31:3: error: #error Kernel headers are too old

make[3]: *** [/home/lukma/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1/platform-arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/build-target/glibc-2.8-crt-build/rtld-global-offsets.h] Error 1

make[3]: *** Waiting for unfinished jobs....

make[3]: *** [/home/lukma/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1/platform-arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/build-target/glibc-2.8-crt-build/tcb-offsets.h] Error 1

make[3]: Leaving directory `/home/lukma/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1/platform-arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/build-target/glibc-2.8/csu'

make[2]: *** [csu/subdir_lib] Error 2

make[2]: Leaving directory `/home/lukma/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1/platform-arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/build-target/glibc-2.8'

make[1]: Leaving directory `/home/lukma/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1/platform-arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/build-target/glibc-2.8-crt-build'

make[1]: *** [csu/subdir_lib] Error 2

make: *** [/home/lukma/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1/platform-arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/state/glibc-crt.compile] Error 2

I don't know what kind of error it is.

My host PC is running at Ubuntu 2.6.24-22-generic with gcc 4.2.4. I've 
only changed target directory from '/opt' to 
'/home/lukma/sbox_lukma/tools' with "ptxdist menuconfig". Above error is 
the same for

OSELAS.Toolchain-1.99.3 and OSELAS.Toolchain-1.99.3.1


Regards,
Lukasz.


Robert Schwebel wrote:
> Hi Lukasz,
>
> On Mon, Feb 23, 2009 at 05:21:36PM +0100, Lukasz Majewski wrote:
>   
>> I'm building toolchain for AT572D940HF Atmel chip. It's ARM9 combined
>> with DSP. I'd like to build toolchain for ARM9 (ARMv5tej) with
>> -msoft-float support, EABI and full glibc ,to support all stuff
>> connected with PREEMPT_RT patch - especially librt.
>>     
>
> Ok.
>
>   
>> Now I've downloaded:
>> ptxdist-1.99.11 and ptxdist-1.99.11-patches.
>>     
>
> yup
>
>   
>> and
>> OSELAS.Toolchain-1.99.3
>>     
>
> exactly
>
>   
>> I've selected
>> ./ptxconfigs/arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized
>>
>> I need toolchain with -msoft-float support and EABI.
>>     
>
> The toolchain you've selected above actually is softfloat and EABI. You
> don't have to change anything, just do the steps you've mentioned above
> and 'ptxdist go'.
>
>   
>> Unfortunately there is an error about mismatch in the linux-kernel
>> headers.
>>     
>
> Please send the exact error message (if too long, please off-list, to me
> and "Marc Kleine-Budde <m.kleine-budde@pengutronix.de>").
>
>   
>> My Host PC has linux-kernel of 2.6.24 and not 2.6.27.
>>     
>
> That's no problem; the toolchain you are trying to build is based on the
> 2.6.27 sanitized kernel headers. It's usually no problem at all using
> such a toolchain on a variety of other kernel versions.
>
>   
>> My target is working under 2.6.26.8-rt14 kernel.
>>     
>
> Should work.
>
>   
>> The error is in building of NTPL library, after successfully compilation
>> of gcc compiler.
>>
>> How can I provide proper kernel headers?
>>     
>
> See above, error messages, please.
>
>   
>> Now I'm trying with
>> arm-v5te-linux-gnueabi-gcc-4.1.2-glibc-2.5-binutils-2.17-kernel-2.6.18
>> ptxconfig. I hope that this will be sufficiently new to provide priority
>> inheritance, futexes , librt with all features.
>>     
>
> Yes, it is.
>
>   
>> I'm building it now and hope that I won't encounter any problems.
>>     
>
> You may want to check that we have an update for 1.99.3 here:
> http://www.pengutronix.de/oselas/toolchain/download/OSELAS.Toolchain-1.99.3.1.tar.bz2
>
> There has been a build error on some distros and it might happen that
> you are seeing exactly this issue.
>
> rsc
>