still verification problems

Hi

I still have problems with 2 tests of the testsuite:
irqloop doesn't seem to work:
-------------------------------------
bash-3.00# irqbench/irqloop
Test mode:    user-space task
Port type:    serial
Port address: 0x3f8
Port IRQ:     4

Received IRQs:     0
Acknowledged IRQs: 0
bash-3.00# 
------------------------------------

latency in kernel mode fails
-----------------------------------
bash-3.00# latency/latency -t1
== Sampling period: 100 us
== Test mode: in-kernel periodic task
== All results in microseconds
latency: failed to start in-kernel timer benchmark, code -25
---|------------|------------|------------|--------|-------------------------
RTS|  267928.028|  805352.732|      32.768|       0|    00:00:40/00:00:40
bash-3.00# 
-----------------------------------------------------------------------------------

if nobody can give me hints (modules are loaded) where to look for the errors, maybe somebody can
send me the manpages. I heard they are availible for debian unstable users, but

Re: Problem with time-out ends

Hello,

I tried your new patch and, now there is no longer issue of priority
inheritance with a mutex. Thanks a lot for that.

However, there are still problems with my big application. It still crashes.

From the test program that you corrected (with check functions), I
succeeded to reproduce them.

Write function returns "Interrrupt system call" error (EINTR). this is
normal.

but I ve got the same error message with pthread_mutex_unlock. In the
specification of this function, there is a note about that : "These
functions shall not return an error code of [EINTR]." (these functions are
pthread_mutex_lock, pthread_mutex_unlock, pthread_mutex_trylock)

So I ve got 3 error types :
pthread_mutex_unlock returns "Interrrupt system call" and "Unknown error
512". When there is "Unknown error 512" message, there are "Bug :
scheduling while atomic" kernel traces.
In the last error type, My test program is stopped without display of a
function error return code and there are also "Bug : scheduling while
atomic" kernel traces.

In the test program, there are three Xenomai thread :
threadTimeOutEnd (prio : 85): This thread waits the timeout end thanks to
a Semaphore (In the timeout end handler, the Semaphore is posted), and
warns threadTimeOut with a condvar broadcast. This thread calls display

Re: Problem with time-out ends

On Tue, Jun 3, 2008 at 11:02 AM, Fabien MAHOT
<fabien.mahot <at> etu.univ-nantes.fr> wrote:
> Hello,
>
> I tried your new patch and, now there is no longer issue of priority
> inheritance with a mutex. Thanks a lot for that.
>
> However, there are still problems with my big application. It still crashes.
>
> From the test program that you corrected (with check functions), I
> succeeded to reproduce them.
>
> Write function returns "Interrrupt system call" error (EINTR). this is
> normal.
>
> but I ve got the same error message with pthread_mutex_unlock. In the
> specification of this function, there is a note about that : "These
> functions shall not return an error code of [EINTR]." (these functions are
> pthread_mutex_lock, pthread_mutex_unlock, pthread_mutex_trylock)

Actually I do not know how this can happen, since the EINTR error is
trapped inside pthread_mutex_lock. Will try your example.

> void EndTimeOut (int signo,siginfo_t *info,void*context)
> {
>    volatile int i, result = 0;
>
>    DeleteTimer(((struct stTimeOut*)(info->si_value.sival_ptr))->timer_h);

This is incorrect, timer_delete is not async signal safe.

Re: still verification problems

On Tue, Jun 3, 2008 at 9:53 AM, Joachim Meyer <Jogi95 <at> web.de> wrote:
> Hi
>
> I still have problems with 2 tests of the testsuite:
> irqloop doesn't seem to work:
> -------------------------------------
> bash-3.00# irqbench/irqloop
> Test mode:    user-space task
> Port type:    serial
> Port address: 0x3f8
> Port IRQ:     4
>
> Received IRQs:     0
> Acknowledged IRQs: 0
> bash-3.00#
> ------------------------------------
>
> latency in kernel mode fails
> -----------------------------------
> bash-3.00# latency/latency -t1
> == Sampling period: 100 us
> == Test mode: in-kernel periodic task
> == All results in microseconds
> latency: failed to start in-kernel timer benchmark, code -25
> ---|------------|------------|------------|--------|-------------------------
> RTS|  267928.028|  805352.732|      32.768|       0|    00:00:40/00:00:40
> bash-3.00#
> -----------------------------------------------------------------------------------
>
> if nobody can give me hints (modules are loaded)

VxWorks problems

Hi,

I still have problems with the use of vxworks emulation. Indeed I need to
lock interrupt ( intLock() and intUnLock() ) in order to manipulate a tas=
ks
control blocks table. But I'm in user space ... what can I do ?

Is there something like a package which can allow me to place user events
to construct a perfmeter, something like windview ?

Thank you in advance

Matthieu

Re: still verification problems

Joachim Meyer wrote:
> Hi
> 
> I still have problems with 2 tests of the testsuite:
> irqloop doesn't seem to work:
> -------------------------------------
> bash-3.00# irqbench/irqloop
> Test mode:    user-space task
> Port type:    serial
> Port address: 0x3f8
> Port IRQ:     4
> 
> Received IRQs:     0
> Acknowledged IRQs: 0
> bash-3.00# 
> ------------------------------------

Hm, irqloop is from the irqbench test suite requiring a special setup
and does not make sense on non X86 systems: See

http://www.rts.uni-hannover.de/xenomai/lxr/source/doc/txt/irqbench.txt

> latency in kernel mode fails
> -----------------------------------
> bash-3.00# latency/latency -t1
> == Sampling period: 100 us
> == Test mode: in-kernel periodic task
> == All results in microseconds
> latency: failed to start in-kernel timer benchmark, code -25
> ---|------------|------------|------------|--------|-------------------------

xeno-test on AT91SAM9263 irqloop and switchtest problem?

Hi all,

I have here a AT91SAM9263 with a 2.6.24 kernel, Xenomai 2.4.3 and Adeos
Patch 1.9-01 and run the xeno-test. It seems there are a Problem with 
the irqloop and the switchtest applications.
In the attachment you can find the log files.

Thomas

xeno-test: started -p 250 -T 120
withBusybox is 1
xeno-test: running tests
/usr/xenomai/bin/xeno-test: eval: line 1: -p: not found

Thu Jan  1 00:29:11 UTC 1970
running: /usr/xenomai/bin/xeno-config --verbose
xeno-config --verbose
        --version="2.4.3"
        --cc="arm-at91-linux-gnu-gcc"
        --arch="arm"
        --prefix="/usr/xenomai"
        --xeno-cflags="-I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -D__XENO__"
        --xeno-ldflags="-L/usr/xenomai/lib -lpthread "
        --posix-cflags="-I/usr/xenomai/include -I/usr/xenomai/include/posix -D_GNU_SOURCE
-D_REENTRANT -D__XENO__"
        --posix-ldflags="-Wl, <at> /usr/xenomai/lib/posix.wrappers -L/usr/xenomai/lib -lpthread_rt
-lpthread -lrt "
        --library-dir="/usr/xenomai/lib"

Re: VxWorks problems

On Tue, Jun 3, 2008 at 11:20 AM, Matthieu
<matthieu.connaulte_xenomai <at> gadz.org> wrote:
> Hi,
>
> I still have problems with the use of vxworks emulation. Indeed I need to
> lock interrupt ( intLock() and intUnLock() ) in order to manipulate a tas=
> ks
> control blocks table. But I'm in user space ... what can I do ?

Use a mutex.

--

-- 
 Gilles

Re: xeno-test on AT91SAM9263 irqloop and switchtest problem?

On Tue, Jun 3, 2008 at 12:01 PM, Paradoxxa <paradoxxa2001 <at> web.de> wrote:
> Hi all,
>
> I have here a AT91SAM9263 with a 2.6.24 kernel, Xenomai 2.4.3 and Adeos
> Patch 1.9-01 and run the xeno-test. It seems there are a Problem with the
> irqloop and the switchtest applications.
> In the attachment you can find the log files.

To run the latency test with -t 1 or -t 2, you need to enable the
"timerbench" driver in the kernel configuration menu.
In the same bench, the switchtest test needs the "switchtest" driver.

I do not see any error message about irqloop in the logs you sent us.

--

-- 
 Gilles

Re: Problem with time-out ends

On Tue, Jun 3, 2008 at 11:12 AM, Gilles Chanteperdrix
<gilles.chanteperdrix <at> gmail.com> wrote:
> On Tue, Jun 3, 2008 at 11:02 AM, Fabien MAHOT
> <fabien.mahot <at> etu.univ-nantes.fr> wrote:
>> Hello,
>>
>> I tried your new patch and, now there is no longer issue of priority
>> inheritance with a mutex. Thanks a lot for that.
>>
>> However, there are still problems with my big application. It still crashes.
>>
>> From the test program that you corrected (with check functions), I
>> succeeded to reproduce them.
>>
>> Write function returns "Interrrupt system call" error (EINTR). this is
>> normal.
>>
>> but I ve got the same error message with pthread_mutex_unlock. In the
>> specification of this function, there is a note about that : "These
>> functions shall not return an error code of [EINTR]." (these functions are
>> pthread_mutex_lock, pthread_mutex_unlock, pthread_mutex_trylock)
>
> Actually I do not know how this can happen, since the EINTR error is
> trapped inside pthread_mutex_lock. Will try your example.

Ah, I see, it is pthread_mutex_unlock which returns EINTR, not
pthread_mutex_lock. I will change this. In the meantime, you can
simply ignore the EINTR error: the mutex unlock succeeeded even if it
returns EINTR.