Re: [Xenomai-core] [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: r...@mcs2:/usr/xenomai/bin# ./mutex-torture-native simple_wait recursive_wait timed_mutex FAILURE: timed_waiter, waited 3.870 us r...@mcs2:/usr/xenomai/bin# ./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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [pull request] Fixes and workarounds for the cond issues
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: r...@mcs2:/usr/xenomai/bin# ./mutex-torture-native simple_wait recursive_wait timed_mutex FAILURE: timed_waiter, waited 4.110 us r...@mcs2:/usr/xenomai/bin# ./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.chanteperd...@xenomai.org] Sent: Friday, March 05, 2010 1:37 PM To: Charlton, John Cc: 'jan.kis...@web.de'; 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. r...@mcs2:/usr/xenomai/bin# ./mutex-torture-native simple_wait recursive_wait timed_mutex FAILURE: timed_waiter, waited 3.870 us r...@mcs2:/usr/xenomai/bin# ./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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [pull request] Fixes and workarounds for the cond issues
Yes with the xenomai-2.5 branch latest as of 1900 UTC everything works without error including the mutex-torture tests (output below): r...@mcs2:/usr/xenomai/bin# ./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 r...@mcs2:/usr/xenomai/bin# ./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 r...@mcs2:/usr/xenomai/bin# 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.chanteperd...@xenomai.org] Sent: Monday, March 08, 2010 1:47 PM To: Charlton, John Cc: 'jan.kis...@web.de'; 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: r...@mcs2:/usr/xenomai/bin# ./mutex-torture-native simple_wait recursive_wait timed_mutex FAILURE: timed_waiter, waited 4.110 us r...@mcs2:/usr/xenomai/bin# ./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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [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): r...@mcs2:/usr/xenomai/bin# ./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 r...@mcs2:/usr/xenomai/bin# ./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 r...@mcs2:/usr/xenomai/bin# 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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [pull request] Fixes and workarounds for the cond issues
These tests also pass: r...@mcs2:/usr/xenomai/bin# ./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 r...@mcs2:/usr/xenomai/bin# ./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 r...@mcs2:/usr/xenomai/bin# 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.chanteperd...@xenomai.org] Sent: Monday, March 08, 2010 3:42 PM To: Charlton, John Cc: 'jan.kis...@web.de'; 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): r...@mcs2:/usr/xenomai/bin# ./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 r...@mcs2:/usr/xenomai/bin# ./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 r...@mcs2:/usr/xenomai/bin# 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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [pull request] Fixes and workarounds for the cond issues
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 mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [pull request] Fixes and workarounds for the cond issues
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [pull request] Fixes and workarounds for the cond issues
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [pull request] Fixes and workarounds for the cond issues
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [pull request] Fixes and workarounds for the cond issues
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
