headers
Philippe Gerum | 1 Oct 2011 11:53
Favicon

Re: xenomai-forge: cast to pointer from integer of different size

On Fri, 2011-09-30 at 21:53 +0200, Thomas De Schampheleire wrote:
> Hi,
> 
> I'm trying to compile xenomai-forge on powerpc, but am facing
> compilation problems:
> 
> libtool: compile:
> /repo/tdescham/reborn/buildroot-08-eglibc-test-toolchain/output/host/usr/bin/powerpc-linux-gcc
> -DHAVE_CONFIG_H -I. -I../../lib/include -O2 -D_GNU_SOURCE -D_REENTRANT
> -Wall -pipe -Wstrict-prototypes -Wmissing-prototypes -Wno-long-long
> -Wno-unused-parameter -Werror -D__XENO__ -D__IN_XENO__
> -Wstrict-prototypes -I../../include -pipe -Os -D_LARGEFILE_SOURCE
> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -MT
> libcopperplate_la-cluster.lo -MD -MP -MF
> .deps/libcopperplate_la-cluster.Tpo -c cluster.c  -fPIC -DPIC -o
> .libs/libcopperplate_la-cluster.o
> cc1: warnings being treated as errors
> In file included from cluster.c:89:
> ../../include/copperplate/heapobj.h: In function 'mainheap_ptr':
> ../../include/copperplate/heapobj.h:82: error: cast to pointer from
> integer of different size
> ../../include/copperplate/heapobj.h: In function 'mainheap_off':
> ../../include/copperplate/heapobj.h:87: error: cast from pointer to
> integer of different size
> cc1: warnings being treated as errors
> 
> The C library we are using for this build is eglibc.
> 
> The offending code is:
> static inline void *mainheap_ptr(off_t off)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Bernhard | 3 Oct 2011 09:37
Picon
Favicon

Xenomai configure option --enable-arm-tsc in Xenomai-2.6

Hi

Currently I'm using Xenomai-2.5.6. Now I need to do some tests on the 
most recent repository version.

Previously I was using the option --enable-arm-tsc in the configuration 
step. In Xenomai-2.6 this options seems still to be present, however it 
behaves like the old option --enable-arm-arch. I think this behavior is 
wrong.

In addition I'd like to know if --enable-arm-tsc is selected 
automatically of if it is still necessary to use this option.

Best regards,
Michael
Permalink | Reply | 4 comments |
headers
Gilles Chanteperdrix | 3 Oct 2011 10:16
Favicon

Re: Xenomai configure option --enable-arm-tsc in Xenomai-2.6

On 10/03/2011 09:37 AM, Michael Bernhard wrote:
> Hi
> 
> Currently I'm using Xenomai-2.5.6. Now I need to do some tests on the 
> most recent repository version.
> 
> Previously I was using the option --enable-arm-tsc in the configuration 
> step. In Xenomai-2.6 this options seems still to be present, however it 
> behaves like the old option --enable-arm-arch. I think this behavior is 
> wrong.
> 
> In addition I'd like to know if --enable-arm-tsc is selected 
> automatically of if it is still necessary to use this option.

You probably do not need --enable-arm-tsc. For more details, see
README.INSTALL.

--

-- 
					    Gilles.
Permalink | Reply | 0 comments |
headers
Gilles Chanteperdrix | 3 Oct 2011 10:20
Favicon

Re: Xenomai configure option --enable-arm-tsc in Xenomai-2.6

On 10/03/2011 09:37 AM, Michael Bernhard wrote:
> Hi
> 
> Currently I'm using Xenomai-2.5.6. Now I need to do some tests on the 
> most recent repository version.
> 
> Previously I was using the option --enable-arm-tsc in the configuration 
> step. In Xenomai-2.6 this options seems still to be present, however it 
> behaves like the old option --enable-arm-arch. I think this behavior is 
> wrong.

--enable-arm-tsc DOES NOT behave like the old option --enable-arm-arch.
Hence the rename.

--

-- 
					    Gilles.
Permalink | Reply | 2 comments |
headers
Michael Bernhard | 3 Oct 2011 10:34
Picon
Favicon

Re: Xenomai configure option --enable-arm-tsc in Xenomai-2.6

On 10/03/2011 10:20 AM, Gilles Chanteperdrix wrote:
> --enable-arm-tsc DOES NOT behave like the old option --enable-arm-arch.
> Hence the rename.
For me, doing the transition form Xenomai-2.5 to 2.6, it was just 
confusing that --enable-arm-tsc has exactly the same help text as the 
old --enable-arm-arch. It would be probably good to add an additional 
sentence to explain why one has to select the architecture for this 
option. Something like this:

"To enable the correct TSC user-space implementation, select for which ..."

--
Michael
Permalink | Reply | 1 comment |
headers
Petr Cervenka | 3 Oct 2011 10:39
Picon
Favicon

Re: Frequency downscaling of new intel CPU


Hello again.
I know, that my problem is not so close related with the xenomai. But I think many of xenomai users with new
intel CPUs have similar problem.
I tried it it with two different main boards and none of the BIOS settings helped. (C-states: disabled,
Speedstep: disabled, CPU idle: high performance, TurboBoost: disabled, ...). My theory is that the
linux kernel overrides BIOS settings, but I don't know how to prove it.
Any ideas that could help me?

Petr Cervenka

______________________________________________________________.
> Od: "Petr Cervenka" <grugh <at> centrum.cz>
> Komu: "xenomai-help" <xenomai-help <at> gna.org>
> Datum: 26.09.2011 09:02
> Předmět: Frequency downscaling of new intel CPU
>
>Hello.
>
>I recently tried newer computer and I suprusingly realized that it has bigger load than the old one with our
xenomai application.
>The problem is in the frequency downscaling of the processor when the load in under 100%.
>Of course I have disabled CPU_FREQ, ACPI_PROCESSOR and INTEL_IDLE as suggested.
>Later I tried also to disable CPU_IDLE, 7300_IDLE (intel chipset idle memory) and all power efficiency
settings in the BIOS, but without success.
>The experienced behaviour is following:
>when the process is waiting for an event, the processor lowers its frequency and when the event happens it
tries to restore (slowly) its nominal frequency.
>
>Do you have any advice or tip what to try, because I'm really desperate?
(Continue reading)

Permalink | Reply | 5 comments |
headers
Julien Delange | 3 Oct 2011 10:46
Picon

Using -rc3 or -rc4 with the 2.6.38 kernel

Dear all,

I currently try to use the latest Xenomai -rc version with the
2.6.38.8. I am able to both compile and build my kernel. However, when
trying to use it with QEMU, it seems it does not work.
If I look at the errors, it seems that udev reports a timeout. After
investigating a little bit, it seems this is related to a regression
in the 2.6.38 kernel on the IDE ATA layer[1] and that the ide layer
generates a lot of IRQ. As a result, the system (a stable debian)
takes at least 5 minutes to boot, waiting for udev to timeout.

Does anyone already experienced that kind of issue when testing the
latest version of xenomai with this kernel version ? If so, how did
you get rid of this error ?

Thanks for any comment or suggestion regarding that problem.

[1] : https://lkml.org/lkml/2011/4/12/538
Permalink | Reply | 0 comments |
headers
Eric Noulard | 3 Oct 2011 10:47
Picon

Re: Frequency downscaling of new intel CPU

2011/10/3 Petr Cervenka <grugh <at> centrum.cz>:
>
> Hello again.
> I know, that my problem is not so close related with the xenomai. But I think many of xenomai users with new
intel CPUs have similar problem.
> I tried it it with two different main boards and none of the BIOS settings helped. (C-states: disabled,
Speedstep: disabled, CPU idle: high performance, TurboBoost: disabled, ...). My theory is that the
linux kernel overrides BIOS settings, but I don't know how to prove it.
> Any ideas that could help me?

Did you verify that you don't have any cpufred related module loaded?

What does

$ lsmod | grep cpu

indicate?

You can try that one too:

$ find /sys/devices/system -name "cpufreq"

--

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
Permalink | Reply | 3 comments |
headers
Julien Delange | 3 Oct 2011 10:48
Picon

Re: Frequency downscaling of new intel CPU

On Mon, Oct 3, 2011 at 4:39 AM, Petr Cervenka <grugh <at> centrum.cz> wrote:
> Any ideas that could help me?

What about looking at /proc/cpuinfo while running your system ? If you
see that the speed is not the maximal, indeed, the frequency scaling
system changes the speed of the processor.
Permalink | Reply | 0 comments |
headers
Gilles Chanteperdrix | 3 Oct 2011 11:15
Favicon

Re: Xenomai configure option --enable-arm-tsc in Xenomai-2.6

On 10/03/2011 10:34 AM, Michael Bernhard wrote:
> On 10/03/2011 10:20 AM, Gilles Chanteperdrix wrote:
>> --enable-arm-tsc DOES NOT behave like the old option --enable-arm-arch.
>> Hence the rename.
> For me, doing the transition form Xenomai-2.5 to 2.6, it was just 
> confusing that --enable-arm-tsc has exactly the same help text as the 
> old --enable-arm-arch. It would be probably good to add an additional 
> sentence to explain why one has to select the architecture for this 
> option. Something like this:
> 
> "To enable the correct TSC user-space implementation, select for which ..."

Right. But --enable-arm-tsc does not enable the correct TSC user-space
implementation. It is an option only useful for old I-pipe patches that
did not support the "kuser" tsc implementation. So, using this option
with Xenomai 2.6.0 is probably not what you want to do.

--

-- 
					    Gilles.
Permalink | Reply | 0 comments |

Gmane