Re: [Xenomai-core] Xenomai v2.2-rc2
Niklaus Giger wrote: Am Samstag, 20. Mai 2006 23:07 schrieb Philippe Gerum: Here is the second release candidate for the v2.2 branch. Short log follows: Could you please apply the patch below to make xeno-test send e-mails to [EMAIL PROTECTED] I am unsure whether setting sentby='[EMAIL PROTECTED]' is a good idea. Or is this a way to accept e-mails from unkown senders? In any way I think it would be nice if one could accept xeno-test messages from unsubscribed senders. I really would like to collect some real data. Applied, thanks. Thanks in advance. Niklaus Giger Index: scripts/xeno-test.in === --- scripts/xeno-test.in(Revision 1135) +++ scripts/xeno-test.in(Arbeitskopie) @@ -19,7 +19,7 @@ name can be full or relative pathname -v verbose -Msends output to given addr - -m sends output to [EMAIL PROTECTED] + -m sends output to [EMAIL PROTECTED] -U uploads output to given URL # following options are passed thru to latency @@ -167,7 +167,7 @@ logprefix=/tmp/# someplace usually there prepost= # command to run pre, and post test (ex ntpq -p) -email='[EMAIL PROTECTED]' # until formalized +email='[EMAIL PROTECTED]' sentby='[EMAIL PROTECTED]' url= sendit=# send it by m-mail, u-url -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai v2.2-rc2
Niklaus Giger wrote: > posix->tthread:: tthread.c:91 pthread_join(child1, &tmp) == ESRCH > tthread.c:91 pthread_join(child1, &tmp) == ESRCH > > Running libtool --mode=execute gdb ./tthread I can give you the following > call > stack: > tthread.c:89 TEST passed. > tthread.c:91 pthread_join(child1, &tmp) == ESRCH > > Program received signal SIGSEGV, Segmentation fault. > 0x1000e81c in pse51_thread_join (thread=0x6061ff71, value_ptr=0x100f9f00) > at ../../../ksrc/skins/posix/thread.c:409 > 409 if (!pse51_obj_active(thread, PSE51_THREAD_MAGIC, struct > pse51_thread) > (gdb) info stack > #0 0x1000e81c in pse51_thread_join (thread=0x6061ff71, > value_ptr=0x100f9f00) > at ../../../ksrc/skins/posix/thread.c:409 > #1 0x10006734 in root_thread (cookie=0x0) at tthread.c:91 > #2 0x1000d728 in thread_trampoline (cookie=0x100d1838) > at ../../../ksrc/skins/posix/thread.c:56 > #3 0x10050f78 in mvm_thread_trampoline_kroot_ () > #4 0x0ffd10b4 in XenoThread::trampoline_kroot_ () > from /home/buildslave/buildbot/quick-sim/build/sim/vm/.libs/libmvm.so.2 > #5 0x0ffd1150 in XenoThread::body () > from /home/buildslave/buildbot/quick-sim/build/sim/vm/.libs/libmvm.so.2 > #6 0x0ffd2c58 in MvmThread::life () > from /home/buildslave/buildbot/quick-sim/build/sim/vm/.libs/libmvm.so.2 > #7 0x0fba6ad0 in makecontext () from /lib/tls/libc.so.6 > Previous frame inner to this frame (corrupt stack?) > (gdb) > > Do you have any clue? (Doubling the stack in vm/thread.cc didn't help.) This test is really questionable, it tests that pthread_join returns ESRCH when passed a pthread_t argument that is not yet initialized. But if the not yet initialized pthread_t value is an invalid address, it may cause a segmentation fault. The best thing to do is to remove this test. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai v2.2-rc2
Am Freitag, 26. Mai 2006 19:49 schrieb Gilles Chanteperdrix: > Niklaus Giger wrote: > > Do you have any clue? (Doubling the stack in vm/thread.cc didn't help.) > > Automatic re-building does not work for the simulator. So, in case of > segmentation fault, try: > > make clean all check Yes, I noticed this as I was looking for a compile of thread.cc. Therefore I did a clean rebuild (but a little bit different than your receipt). After rebuilding using "make clean all check" under sim and sim/skin/posix/testsuite, I still get the same failure. Regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai v2.2-rc2
Niklaus Giger wrote: > Do you have any clue? (Doubling the stack in vm/thread.cc didn't help.) Automatic re-building does not work for the simulator. So, in case of segmentation fault, try: make clean all check -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai v2.2-rc2
Am Freitag, 26. Mai 2006 18:27 schrieb Gilles Chanteperdrix: > Niklaus Giger wrote: <..> > > Where does the simulator get this configuration from? Can it be changed > > to run tests in periodic and aperiodic mode? > > The nucleus look for the parameter "tick_arg". Over kernel-space, this > parameter is a module parameter; over simulator, this parameter is an > environment variable. So, running: > tick_arg=1000 ./tthread > should make the test run. Thanks for your explanation. I will try to integrate this in the test suite. > > > Would the test be adapedt to emit a "skipping: periodic mode not > > configured" if it is not properly configured? > > An example of bit decay. This test used to be skipped over non periodic > mode. That is exactly the point why I try to run the buildbot. Automatic regression tests should catch these kind of errors. > > Now, it is repaired. Thanks a lot. Such quick fixes motivate me to continue my work. But I get now in http://ngiger.dyndns.org/buildbot/sim/builds/60/step-check_sim/0 the following error: Some problems were reported in: posix->tthread:: tthread.c:91 pthread_join(child1, &tmp) == ESRCH tthread.c:91 pthread_join(child1, &tmp) == ESRCH Running libtool --mode=execute gdb ./tthread I can give you the following call stack: tthread.c:89 TEST passed. tthread.c:91 pthread_join(child1, &tmp) == ESRCH Program received signal SIGSEGV, Segmentation fault. 0x1000e81c in pse51_thread_join (thread=0x6061ff71, value_ptr=0x100f9f00) at ../../../ksrc/skins/posix/thread.c:409 409 if (!pse51_obj_active(thread, PSE51_THREAD_MAGIC, struct pse51_thread) (gdb) info stack #0 0x1000e81c in pse51_thread_join (thread=0x6061ff71, value_ptr=0x100f9f00) at ../../../ksrc/skins/posix/thread.c:409 #1 0x10006734 in root_thread (cookie=0x0) at tthread.c:91 #2 0x1000d728 in thread_trampoline (cookie=0x100d1838) at ../../../ksrc/skins/posix/thread.c:56 #3 0x10050f78 in mvm_thread_trampoline_kroot_ () #4 0x0ffd10b4 in XenoThread::trampoline_kroot_ () from /home/buildslave/buildbot/quick-sim/build/sim/vm/.libs/libmvm.so.2 #5 0x0ffd1150 in XenoThread::body () from /home/buildslave/buildbot/quick-sim/build/sim/vm/.libs/libmvm.so.2 #6 0x0ffd2c58 in MvmThread::life () from /home/buildslave/buildbot/quick-sim/build/sim/vm/.libs/libmvm.so.2 #7 0x0fba6ad0 in makecontext () from /lib/tls/libc.so.6 Previous frame inner to this frame (corrupt stack?) (gdb) Do you have any clue? (Doubling the stack in vm/thread.cc didn't help.) Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai v2.2-rc2
Niklaus Giger wrote: > Am Montag, 22. Mai 2006 13:38 schrieb Gilles Chanteperdrix: > > Niklaus Giger wrote: > > > Am Samstag, 20. Mai 2006 23:07 schrieb Philippe Gerum: > > > > Here is the second release candidate for the v2.2 branch. Short log > > > > > > The trunks builds fine on my four targets on > > > http://ngiger.dyndns.org/buildbot/ > > > > > > I have however still the following errors running the posix simulators > > > (see http://ngiger.dyndns.org/buildbot/sim/builds/59/step-check_sim/0). > > > All others posix and vxworks test pass. > > > The output is: > > > > The tested feature is round-robin scheduling, which only works when the > > system timer is configured in periodic mode; so, when the system timer > > is configured in periodic mode, the test should pass. > Where does the simulator get this configuration from? Can it be changed to > run > tests in periodic and aperiodic mode? The nucleus look for the parameter "tick_arg". Over kernel-space, this parameter is a module parameter; over simulator, this parameter is an environment variable. So, running: tick_arg=1000 ./tthread should make the test run. > > Would the test be adapedt to emit a "skipping: periodic mode not > configured" > if it is not properly configured? An example of bit decay. This test used to be skipped over non periodic mode. Now, it is repaired. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai v2.2-rc2
Hi all! I'm back :-) After some "time on Mars" (http://www.austromars.at) and some vaccation, here are my test results: kernel 2.4.32 Xeno2.2rc2 => testsuite works => RTDM Driver Skeleton works Best regards, Hannes. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai v2.2-rc2
Am Montag, 22. Mai 2006 13:38 schrieb Gilles Chanteperdrix: > Niklaus Giger wrote: > > Am Samstag, 20. Mai 2006 23:07 schrieb Philippe Gerum: > > > Here is the second release candidate for the v2.2 branch. Short log > > > > The trunks builds fine on my four targets on > > http://ngiger.dyndns.org/buildbot/ > > > > I have however still the following errors running the posix simulators > > (see http://ngiger.dyndns.org/buildbot/sim/builds/59/step-check_sim/0). > > All others posix and vxworks test pass. > > The output is: > > The tested feature is round-robin scheduling, which only works when the > system timer is configured in periodic mode; so, when the system timer > is configured in periodic mode, the test should pass. Where does the simulator get this configuration from? Can it be changed to run tests in periodic and aperiodic mode? Would the test be adapedt to emit a "skipping: periodic mode not configured" if it is not properly configured? Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai v2.2-rc2
Niklaus Giger wrote: > Am Samstag, 20. Mai 2006 23:07 schrieb Philippe Gerum: > > Here is the second release candidate for the v2.2 branch. Short log > The trunks builds fine on my four targets on > http://ngiger.dyndns.org/buildbot/ > > I have however still the following errors running the posix simulators > (see http://ngiger.dyndns.org/buildbot/sim/builds/59/step-check_sim/0). All > others posix and vxworks test pass. > The output is: The tested feature is round-robin scheduling, which only works when the system timer is configured in periodic mode; so, when the system timer is configured in periodic mode, the test should pass. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai v2.2-rc2
Am Samstag, 20. Mai 2006 23:07 schrieb Philippe Gerum:
> Here is the second release candidate for the v2.2 branch. Short log
The trunks builds fine on my four targets on
http://ngiger.dyndns.org/buildbot/
I have however still the following errors running the posix simulators
(see http://ngiger.dyndns.org/buildbot/sim/builds/59/step-check_sim/0). All
others posix and vxworks test pass.
The output is:
Some problems were reported in:
posix->tthread:tthread.c:141: Expected sequence: SEQ("slicer1",1); got
SEQ("slicer1",4)
posix->tthread:tthread.c:142: Expected sequence: SEQ("slicer2",1); got
SEQ("slicer2",4)
posix->tthread:tthread.c:143: Expected sequence: SEQ("slicer1",1); got
SEQ("root",1)
posix->tthread:tthread.c:144: Expected sequence: SEQ("slicer2",1); reached end
of recorded sequence.
posix->tthread:tthread.c:145: Expected sequence: SEQ("slicer1",1); reached end
of recorded sequence.
posix->tthread:tthread.c:146: Expected sequence: SEQ("slicer2",1); reached end
of recorded sequence.
posix->tthread:tthread.c:147: Expected sequence: SEQ("slicer1",1); reached end
of recorded sequence.
posix->tthread:tthread.c:148: Expected sequence: SEQ("slicer2",1); reached end
of recorded sequence.
posix->tthread:tthread.c:149: Expected sequence: SEQ("root",1); reached end of
recorded sequence.
posix->tthread:tthread.c:153, test finished: 9 failures/ 46 tests
I have however no time to try to fix them, as I am investing more time into
making xeno-test run automatically on my PPC 405GPr target board.
Best regards
--
Niklaus Giger
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai v2.2-rc2
Am Samstag, 20. Mai 2006 23:07 schrieb Philippe Gerum: > Here is the second release candidate for the v2.2 branch. Short log > follows: Could you please apply the patch below to make xeno-test send e-mails to [EMAIL PROTECTED] I am unsure whether setting sentby='[EMAIL PROTECTED]' is a good idea. Or is this a way to accept e-mails from unkown senders? In any way I think it would be nice if one could accept xeno-test messages from unsubscribed senders. I really would like to collect some real data. Thanks in advance. Niklaus Giger Index: scripts/xeno-test.in === --- scripts/xeno-test.in(Revision 1135) +++ scripts/xeno-test.in(Arbeitskopie) @@ -19,7 +19,7 @@ name can be full or relative pathname -v verbose -Msends output to given addr - -m sends output to [EMAIL PROTECTED] + -m sends output to [EMAIL PROTECTED] -U uploads output to given URL # following options are passed thru to latency @@ -167,7 +167,7 @@ logprefix=/tmp/# someplace usually there prepost= # command to run pre, and post test (ex ntpq -p) -email='[EMAIL PROTECTED]' # until formalized +email='[EMAIL PROTECTED]' sentby='[EMAIL PROTECTED]' url= sendit=# send it by m-mail, u-url ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Xenomai v2.2-rc2
Here is the second release candidate for the v2.2 branch. Short log follows: [x86,ppc64] Fix ugly Adeos-related SMP bug involving kernel-based Xenomai threads. [nucleus] Extend pipeline head optimizations. Provide thread "held" state for later temporal partitioning support. Add PIP resource stealing. Add support for per-process data. Add cleanup handler to synchronization objects. Work around SuSE-originated GCC 4.x bug (optimizer issue) in message pipe support. Fix xnpod_unblock_thread() (don't raise XNBREAK for ready threads). Fix xnpod_start_thread() (error code propagation). Add missing symbol exports. [posix] Update for PIP resource stealing. Set default mutex priority protocol to PTHREAD_PRIO_NONE. [rtdm]Refactor mutex, sema4 and event implementation. Fix rtdm_strncpy_from_user(). Fix PIP handling code. [vxworks] Update for PIP resource stealing. Reset timer upon unload. Fix tick handler return value. Fix stack overflow in demo program. [native] Update for PIP resource stealing. Fix rt_task_delete() when killing a non-shadowed thread. Fix T_JOINABLE bit conflict. [vrtx]Update for PIP resource stealing. [rtai]Update for PIP resource stealing. [testsuite] Allow running multiple tests in parallel. Allow pinning down the sampling task to a specified CPU. Aside of this, all Adeos patches have been upgraded. Please see the ChangeLog for details. http://download.gna.org/xenomai/testing/xenomai-2.2-rc2.tar.bz2 -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
