[Xenomai-core] [pull request] Fixes and workarounds for the cond issues

[Xenomai-core] [pull request] Fixes and workarounds for the cond issues

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1714 bytes --]

The following changes since commit af93ec87f975b387243127090b578d57922b38dc:
  Gilles Chanteperdrix (1):
        posix: fix recursive condvar implementation

are available in the git repository at:

  git://git.xenomai.org/xenomai-jki.git for-upstream

These patches pass basic testings, specifically our extended testsuite,
but I'm still unhappy with the workaround. Specifically the fact that we
lose -EINTR as valid return code for the Native side is fairly annoying.

For that reason, I will continue to work out fixed prologue/epilogue
syscalls for both skins that up-to-date user space will be able to
benefit from (native kernel space part is already done). The majority of
users will continue to update kernel and user space synchronously
anyway, for the rest we will provide these workarounds here.


Jan Kiszka (8):
      testsuite: Fix posix mutex test for non-auto-shadow setups
      testsuite: Add timed mutex and cond tests
      Native: Fix error signedness in rt_cont_wait_until
      Native: Fix return code of in-kernel rt_cond_wait[_until]
      Native: Ensure to re-acquire the mutex on cond_wait return
      Native: Work around for error code corruption in rt_cond_wait[_until]
      POSIX: Fix signess issue in EFAULT path of cond_wait_prologue
      POSIX: Work around for error code corruption in pthread_cond_[timed]wait

 ksrc/skins/native/cond.c           |   19 +++--
 ksrc/skins/native/syscall.c        |   30 +++++-
 ksrc/skins/posix/syscall.c         |   29 ++++--
 src/skins/native/cond.c            |    6 +-
 src/testsuite/unit/mutex-torture.c |  185 ++++++++++++++++++++++++++++++------
 5 files changed, 213 insertions(+), 56 deletions(-)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-core] [pull request] Fixes and workarounds for the cond issues

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> The following changes since commit af93ec87f975b387243127090b578d57922b38dc:
>   Gilles Chanteperdrix (1):
>         posix: fix recursive condvar implementation
> 
> are available in the git repository at:
> 
>   git://git.xenomai.org/xenomai-jki.git for-upstream
> 
> These patches pass basic testings, specifically our extended testsuite,
> but I'm still unhappy with the workaround. Specifically the fact that we
> lose -EINTR as valid return code for the Native side is fairly annoying.
> 
> For that reason, I will continue to work out fixed prologue/epilogue
> syscalls for both skins that up-to-date user space will be able to
> benefit from (native kernel space part is already done). The majority of
> users will continue to update kernel and user space synchronously
> anyway, for the rest we will provide these workarounds here.

Let us calm down, and avoid pushing changes which are worse than the
issue they try and correct. I will not publish anything on these issues
before this week-end. Instead of modifying the mutex-torture unt test, I
will try and write a condvar-torture unit test, which exhaustively test
all the return values of pthread_cond_wait/rt_cond_wait, including
interruption by signals during the cond_wait, and the epilogue.

-- 
					    Gilles.

[Xenomai-core] ADEOS patch for LPC3250

[Pierre Ficheux]

Hi all,

Do you know if there is any work on porting ADEOS to NXP LPC3250
(ARM926EJ-S) ?

http://ics.nxp.com/products/lpc3000/lpc32x0

Thx

-- 
Pierre FICHEUX -/- CTO OW/OS4I, France -\- pierre.ficheux@domain.hid
                                         http://www.os4i.com
                                         http://www.ficheux.org
I would love to change the world, but they won't give me the source code

Re: [Xenomai-core] ADEOS patch for LPC3250

[Gilles Chanteperdrix]

Pierre Ficheux wrote:
> Hi all,
> 
> Do you know if there is any work on porting ADEOS to NXP LPC3250
> (ARM926EJ-S) ?
> 
> http://ics.nxp.com/products/lpc3000/lpc32x0

It would be nice if you could avoid replying a random mail when asking
an un related question. I would have expected a better knowledge of
netiquette from an old-timer as you, Pierre :-)

No, I have not heard of any I-pipe port to NXP LPC3250. The ARM core
does not really matter for an ARM port, as the timer, interrupt
controller, and GPIO demux are the only thing which need to be
considered and are not part of the core.

Regards.

-- 
Gilles Chanteperdrix, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [Xenomai-core] [pull request] Fixes and workarounds for the cond issues

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> The following changes since commit af93ec87f975b387243127090b578d57922b38dc:
>>   Gilles Chanteperdrix (1):
>>         posix: fix recursive condvar implementation
>>
>> are available in the git repository at:
>>
>>   git://git.xenomai.org/xenomai-jki.git for-upstream
>>
>> These patches pass basic testings, specifically our extended testsuite,
>> but I'm still unhappy with the workaround. Specifically the fact that we
>> lose -EINTR as valid return code for the Native side is fairly annoying.
>>
>> For that reason, I will continue to work out fixed prologue/epilogue
>> syscalls for both skins that up-to-date user space will be able to
>> benefit from (native kernel space part is already done). The majority of
>> users will continue to update kernel and user space synchronously
>> anyway, for the rest we will provide these workarounds here.
> 
> Let us calm down, and avoid pushing changes which are worse than the
> issue they try and correct. I will not publish anything on these issues
> before this week-end. Instead of modifying the mutex-torture unt test, I
> will try and write a condvar-torture unit test, which exhaustively test
> all the return values of pthread_cond_wait/rt_cond_wait, including
> interruption by signals during the cond_wait, and the epilogue.

Fine with me. By then, we may also have feedback from our field tests.
And should have finished writing the new syscall sets.

Will you also split up the torture test to leave the timed mutex test
case in or should I do this?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [pull request] Fixes and workarounds for the cond issues

[Jan Kiszka]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> The following changes since commit af93ec87f975b387243127090b578d57922b38dc:
>>>   Gilles Chanteperdrix (1):
>>>         posix: fix recursive condvar implementation
>>>
>>> are available in the git repository at:
>>>
>>>   git://git.xenomai.org/xenomai-jki.git for-upstream
>>>
>>> These patches pass basic testings, specifically our extended testsuite,
>>> but I'm still unhappy with the workaround. Specifically the fact that we
>>> lose -EINTR as valid return code for the Native side is fairly annoying.
>>>
>>> For that reason, I will continue to work out fixed prologue/epilogue
>>> syscalls for both skins that up-to-date user space will be able to
>>> benefit from (native kernel space part is already done). The majority of
>>> users will continue to update kernel and user space synchronously
>>> anyway, for the rest we will provide these workarounds here.
>> Let us calm down, and avoid pushing changes which are worse than the
>> issue they try and correct. I will not publish anything on these issues
>> before this week-end. Instead of modifying the mutex-torture unt test, I
>> will try and write a condvar-torture unit test, which exhaustively test
>> all the return values of pthread_cond_wait/rt_cond_wait, including
>> interruption by signals during the cond_wait, and the epilogue.
> 
> Fine with me. By then, we may also have feedback from our field tests.
> And should have finished writing the new syscall sets.
    / \
    /me
> 
> Will you also split up the torture test to leave the timed mutex test
> case in or should I do this?
> 

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [pull request] Fixes and workarounds for the cond issues

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> The following changes since commit af93ec87f975b387243127090b578d57922b38dc:
>>>   Gilles Chanteperdrix (1):
>>>         posix: fix recursive condvar implementation
>>>
>>> are available in the git repository at:
>>>
>>>   git://git.xenomai.org/xenomai-jki.git for-upstream
>>>
>>> These patches pass basic testings, specifically our extended testsuite,
>>> but I'm still unhappy with the workaround. Specifically the fact that we
>>> lose -EINTR as valid return code for the Native side is fairly annoying.
>>>
>>> For that reason, I will continue to work out fixed prologue/epilogue
>>> syscalls for both skins that up-to-date user space will be able to
>>> benefit from (native kernel space part is already done). The majority of
>>> users will continue to update kernel and user space synchronously
>>> anyway, for the rest we will provide these workarounds here.
>> Let us calm down, and avoid pushing changes which are worse than the
>> issue they try and correct. I will not publish anything on these issues
>> before this week-end. Instead of modifying the mutex-torture unt test, I
>> will try and write a condvar-torture unit test, which exhaustively test
>> all the return values of pthread_cond_wait/rt_cond_wait, including
>> interruption by signals during the cond_wait, and the epilogue.
> 
> Fine with me. By then, we may also have feedback from our field tests.
> And should have finished writing the new syscall sets.

Do not bother, I intend to handle all this.

> 
> Will you also split up the torture test to leave the timed mutex test
> case in or should I do this?

Ok. Will add the timeout tests to the mutex torture test.

> 
> Jan
> 


-- 
					    Gilles.

Re: [Xenomai-core] [pull request] Fixes and workarounds for the cond issues

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> The following changes since commit af93ec87f975b387243127090b578d57922b38dc:
>>>>   Gilles Chanteperdrix (1):
>>>>         posix: fix recursive condvar implementation
>>>>
>>>> are available in the git repository at:
>>>>
>>>>   git://git.xenomai.org/xenomai-jki.git for-upstream
>>>>
>>>> These patches pass basic testings, specifically our extended testsuite,
>>>> but I'm still unhappy with the workaround. Specifically the fact that we
>>>> lose -EINTR as valid return code for the Native side is fairly annoying.
>>>>
>>>> For that reason, I will continue to work out fixed prologue/epilogue
>>>> syscalls for both skins that up-to-date user space will be able to
>>>> benefit from (native kernel space part is already done). The majority of
>>>> users will continue to update kernel and user space synchronously
>>>> anyway, for the rest we will provide these workarounds here.
>>> Let us calm down, and avoid pushing changes which are worse than the
>>> issue they try and correct. I will not publish anything on these issues
>>> before this week-end. Instead of modifying the mutex-torture unt test, I
>>> will try and write a condvar-torture unit test, which exhaustively test
>>> all the return values of pthread_cond_wait/rt_cond_wait, including
>>> interruption by signals during the cond_wait, and the epilogue.
>> Fine with me. By then, we may also have feedback from our field tests.
>> And should have finished writing the new syscall sets.
> 
> Do not bother, I intend to handle all this.
> 

That would be wasted effort as I'm half through (POSIX is missing). Will
post my suggestion so that you have at least a chance to pick what you like.

>> Will you also split up the torture test to leave the timed mutex test
>> case in or should I do this?
> 
> Ok. Will add the timeout tests to the mutex torture test.
> 

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [pull request] Fixes and workarounds for the cond issues

[Gilles Chanteperdrix]

Charlton, John wrote:
> I merged some changes from git://git.xenomai.org/xenomai-jki.git for-upstream  to my xenomai-2.5.1 release distribution
> to include the rt_cond_wait and pthread_cond_[timed]wait work arounds.  I also merged changes to the mutex_torture.c.  Everything builds and most tests seem to pass but I get the following output from the mutex-torture tests:

You are probably missng the changes for recursive_cond_wait for the
posix skin which were commited in the development branch. You do not see
it because the new mutex-torture tests were added before the recursive
cond test.

> 
> root@domain.hid# ./mutex-torture-native
> simple_wait
> recursive_wait
> timed_mutex
> FAILURE: timed_waiter, waited 3.870 us
> root@domain.hid# ./mutex-torture-posix
> simple_wait
> recursive_wait
> errorcheck_wait
> timed_mutex
> FAILURE: timed_mutex mutex_destroy: 22 (Invalid argument)
> 
> Do you have suggestions on how to resolve these errors hopefully without moving to the full development branch?

This kind of thing is exactly the reason why I told I would work quietly
on this issue. Things will be ready on monday, but it would help us a
great deal if you could test the development branch on monday, at the
same time as when we are validating it on our test platforms.

Can not do better right now.

-- 
					    Gilles.

Re: [Xenomai-core] [pull request] Fixes and workarounds for the cond issues

[Charlton, John]

I configured and built with linux-2.6.32.7 and xenomai-jki for-upstream snapshot: f98569c8eec5df605f806ff58e789668720805ee. I noticed that you removed the PTHREAD_WARNSW so I removed the call to pthread_set_mode_np to remove the following errors:

PosixThread/PosixThread.cpp:1607: error: 'PTHREAD_WARNSW' was not declared in this scope
PosixThread/PosixThread.cpp:1607: error: 'pthread_set_mode_np' was not declared in this scope

I am able to run all of my user space application code and unit test code which uses CanFestival open source CAN library.  I am also able to run the xeno-test which runs to completion with no errors.  When I run the mutex-torture tests I still get the following errors which I have not looked into in more detail yet:


root@domain.hid# ./mutex-torture-native
simple_wait
recursive_wait
timed_mutex
FAILURE: timed_waiter, waited 4.110 us
root@domain.hid# ./mutex-torture-posix
simple_wait
recursive_wait
errorcheck_wait
timed_mutex
FAILURE: timed_mutex mutex_destroy: 22 (Invalid argument)

I am now looking at xenomai-rpm branch which one is close to 2.5.2 release?

--

John

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org
Sent: Friday, March 05, 2010 1:37 PM
To: Charlton, John
Cc: 'jan.kiszka@domain.hid'; xenomai-core
Subject: Re: [pull request] Fixes and workarounds for the cond issues

Charlton, John wrote:
> I merged some changes from git://git.xenomai.org/xenomai-jki.git 
> for-upstream  to my xenomai-2.5.1 release distribution to include the rt_cond_wait and pthread_cond_[timed]wait work arounds.  I also merged changes to the mutex_torture.c.  Everything builds and most tests seem to pass but I get the following output from the mutex-torture tests:

You are probably missng the changes for recursive_cond_wait for the posix skin which were commited in the development branch. You do not see it because the new mutex-torture tests were added before the recursive cond test.

> 
> root@domain.hid# ./mutex-torture-native simple_wait 
> recursive_wait timed_mutex
> FAILURE: timed_waiter, waited 3.870 us root@domain.hid
> ./mutex-torture-posix simple_wait recursive_wait errorcheck_wait 
> timed_mutex
> FAILURE: timed_mutex mutex_destroy: 22 (Invalid argument)
> 
> Do you have suggestions on how to resolve these errors hopefully without moving to the full development branch?

This kind of thing is exactly the reason why I told I would work quietly on this issue. Things will be ready on monday, but it would help us a great deal if you could test the development branch on monday, at the same time as when we are validating it on our test platforms.

Can not do better right now.

-- 
					    Gilles.

Re: [Xenomai-core] [pull request] Fixes and workarounds for the cond issues

[Gilles Chanteperdrix]

Charlton, John wrote:
> I configured and built with linux-2.6.32.7 and xenomai-jki for-upstream snapshot: f98569c8eec5df605f806ff58e789668720805ee. I noticed that you removed the PTHREAD_WARNSW so I removed the call to pthread_set_mode_np to remove the following errors:
> 
> PosixThread/PosixThread.cpp:1607: error: 'PTHREAD_WARNSW' was not declared in this scope
> PosixThread/PosixThread.cpp:1607: error: 'pthread_set_mode_np' was not declared in this scope

This should come with #include <pthread.h>, provided you use
xeno-config --posix-cflags (soon to be deprecated way)
or xeno-config --skin=posix --cflags
to get the compilation flags.

> 
> I am able to run all of my user space application code and unit test
code which uses CanFestival open source CAN library. I am also able to
run the xeno-test which runs to completion with no errors. When I run
the mutex-torture tests I still get the following errors which I have
not looked into in more detail yet:
> 
> 
> root@domain.hid# ./mutex-torture-native
> simple_wait
> recursive_wait
> timed_mutex
> FAILURE: timed_waiter, waited 4.110 us
> root@domain.hid# ./mutex-torture-posix
> simple_wait
> recursive_wait
> errorcheck_wait
> timed_mutex
> FAILURE: timed_mutex mutex_destroy: 22 (Invalid argument)
> 
> I am now looking at xenomai-rpm branch which one is close to 2.5.2 release?

the master branch of the xenomai-2.5 repository. As explained here:
http://www.xenomai.org/index.php/Main_Page

in the "Fetching the source code repositories"

-- 
					    Gilles.

Re: [Xenomai-core] [pull request] Fixes and workarounds for the cond issues

[Charlton, John]

Yes with the xenomai-2.5 branch latest as of 1900 UTC everything works without error including the mutex-torture tests (output below):

root@domain.hid# ./mutex-torture-native
simple_wait
recursive_wait
timed_mutex
mode_switch
pi_wait
lock_stealing
NOTE: lock_stealing mutex_trylock: not supported
simple_condwait
recursive_condwait
Test OK
root@domain.hid# ./mutex-torture-posix 
simple_wait
recursive_wait
errorcheck_wait
timed_mutex
mode_switch
pi_wait
lock_stealing
NOTE: lock_stealing mutex_trylock: not supported
simple_condwait
recursive_condwait
Test OK
root@domain.hid

pthread_set_mode_np(NULL, PTHREAD_WARNSW) also works with this branch. Thank you for the help.

--

John

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org
Sent: Monday, March 08, 2010 1:47 PM
To: Charlton, John
Cc: 'jan.kiszka@domain.hid'; xenomai-core
Subject: Re: [pull request] Fixes and workarounds for the cond issues

Charlton, John wrote:
> I configured and built with linux-2.6.32.7 and xenomai-jki for-upstream snapshot: f98569c8eec5df605f806ff58e789668720805ee. I noticed that you removed the PTHREAD_WARNSW so I removed the call to pthread_set_mode_np to remove the following errors:
> 
> PosixThread/PosixThread.cpp:1607: error: 'PTHREAD_WARNSW' was not 
> declared in this scope
> PosixThread/PosixThread.cpp:1607: error: 'pthread_set_mode_np' was not 
> declared in this scope

This should come with #include <pthread.h>, provided you use xeno-config --posix-cflags (soon to be deprecated way) or xeno-config --skin=posix --cflags to get the compilation flags.

> 
> I am able to run all of my user space application code and unit test
code which uses CanFestival open source CAN library. I am also able to run the xeno-test which runs to completion with no errors. When I run the mutex-torture tests I still get the following errors which I have not looked into in more detail yet:
> 
> 
> root@domain.hid# ./mutex-torture-native simple_wait 
> recursive_wait timed_mutex
> FAILURE: timed_waiter, waited 4.110 us root@domain.hid
> ./mutex-torture-posix simple_wait recursive_wait errorcheck_wait 
> timed_mutex
> FAILURE: timed_mutex mutex_destroy: 22 (Invalid argument)
> 
> I am now looking at xenomai-rpm branch which one is close to 2.5.2 release?

the master branch of the xenomai-2.5 repository. As explained here:
http://www.xenomai.org/index.php/Main_Page

in the "Fetching the source code repositories"

-- 
					    Gilles.

Re: [Xenomai-core] [pull request] Fixes and workarounds for the cond issues

[Gilles Chanteperdrix]

Charlton, John wrote:
> Yes with the xenomai-2.5 branch latest as of 1900 UTC everything works without error including the mutex-torture tests (output below):
> 
> root@domain.hid# ./mutex-torture-native
> simple_wait
> recursive_wait
> timed_mutex
> mode_switch
> pi_wait
> lock_stealing
> NOTE: lock_stealing mutex_trylock: not supported
> simple_condwait
> recursive_condwait
> Test OK
> root@domain.hid# ./mutex-torture-posix 
> simple_wait
> recursive_wait
> errorcheck_wait
> timed_mutex
> mode_switch
> pi_wait
> lock_stealing
> NOTE: lock_stealing mutex_trylock: not supported
> simple_condwait
> recursive_condwait
> Test OK
> root@domain.hid# 
> 
> pthread_set_mode_np(NULL, PTHREAD_WARNSW) also works with this branch. Thank you for the help.

You also have cond-torture-posix, and cond-torture-native, which should
test, among other things, the fix for the condition variable bug you had.

-- 
					    Gilles.

Re: [Xenomai-core] [pull request] Fixes and workarounds for the cond issues

[Charlton, John]

These tests also pass:

root@domain.hid# ./cond-torture-native
simple_condwait
relative_condwait
absolute_condwait
sig_norestart_condwait
sig_restart_condwait
sig_norestart_condwait_mutex
sig_restart_condwait_mutex
sig_norestart_double
sig_restart_double
cond_destroy_whilewait
Test OK
root@domain.hid# ./cond-torture-posix
simple_condwait
relative_condwait
absolute_condwait
sig_norestart_condwait
sig_restart_condwait
sig_norestart_condwait_mutex
sig_restart_condwait_mutex
sig_norestart_double
sig_restart_double
cond_destroy_whilewait
Test OK
root@domain.hid#
 
If you want me to run other tests let me know.  I have run xeno-test as well as these torture tests.  My unit test code tests a custom sja1000 can driver that I wrote based on the xenomai rtcan_peak_pci.c driver module.  If you want source for that I will send it but it is of limited value since it is written for our custom PLX9030 PCI interface.

--

John

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org
Sent: Monday, March 08, 2010 3:42 PM
To: Charlton, John
Cc: 'jan.kiszka@domain.hid'; xenomai-core
Subject: Re: [pull request] Fixes and workarounds for the cond issues

Charlton, John wrote:
> Yes with the xenomai-2.5 branch latest as of 1900 UTC everything works without error including the mutex-torture tests (output below):
> 
> root@domain.hid# ./mutex-torture-native simple_wait 
> recursive_wait timed_mutex mode_switch pi_wait lock_stealing
> NOTE: lock_stealing mutex_trylock: not supported simple_condwait 
> recursive_condwait Test OK root@domain.hid
> ./mutex-torture-posix simple_wait recursive_wait errorcheck_wait 
> timed_mutex mode_switch pi_wait lock_stealing
> NOTE: lock_stealing mutex_trylock: not supported simple_condwait 
> recursive_condwait Test OK root@domain.hid#
> 
> pthread_set_mode_np(NULL, PTHREAD_WARNSW) also works with this branch. Thank you for the help.

You also have cond-torture-posix, and cond-torture-native, which should test, among other things, the fix for the condition variable bug you had.

-- 
					    Gilles.

Re: [Xenomai-core] [pull request] Fixes and workarounds for the cond issues

[Gilles Chanteperdrix]

Charlton, John wrote:
> I merged some changes from git://git.xenomai.org/xenomai-jki.git
for-upstream to my xenomai-2.5.1 release distribution
> to include the rt_cond_wait and pthread_cond_[timed]wait work
> arounds.
I also merged changes to the mutex_torture.c. Everything builds and most
tests seem to pass but I get the following output from the mutex-torture
tests:
> 
> root@domain.hid# ./mutex-torture-native
> simple_wait
> recursive_wait
> timed_mutex
> FAILURE: timed_waiter, waited 3.870 us
> root@domain.hid# ./mutex-torture-posix
> simple_wait
> recursive_wait
> errorcheck_wait
> timed_mutex
> FAILURE: timed_mutex mutex_destroy: 22 (Invalid argument)
> 
> Do you have suggestions on how to resolve these errors hopefully
> without moving to the full development branch?


Ok. I found and fixed this bug. It was a bug in the testcase. It would
really help us, however, if you could pull the full development branch,
and just give it a quick test to see if it fixes the current issue. It
is our hope that this development branch is close to what 2.5.2 will be.

-- 
					    Gilles.