Re: [Xenomai-core] Xenomai v2.2

2006-07-23 Thread Jan Kiszka
Hannes Mayer wrote:
 Hi Jan!
 
 Jan Kiszka wrote:
 What about addr2line -e vmlinux -f c01d68b2?
 
 # addr2line -e vmlinux -f c01d68b2
 xnshadow_ppd_insert
 shadow.c:0
 
 Ok, will keep you posted!
 
 Tante grazie e buon fine settimana,
 Hannes.
 

Please try make clean before rebuilding your 2.4 kernel with a
different timer support. For me this fixed the issue (2.4 build system
seems to fail catching all dependencies, thus some struct sizes don't
get updated consistently).

The only thing that still puzzles me is that my crash happened at a
different code line. Anyway, might be due to other .config differences.

This digging in 2.4 over x86 was worthwhile: Two further corner-case
bugs found, though not all fixed yet.

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Xenomai v2.2

2006-07-23 Thread Hannes Mayer

Ciao Jan!

Jan Kiszka wrote:
[...]

Please try make clean before rebuilding your 2.4 kernel with a


Indeed, make clean does a wonder :-)
BTW, is there any way to reconfigure the periodic timer ?
Not that I wanna use it - I'm fine with the more accurate aperiodic
timer, but just curious.


This digging in 2.4 over x86 was worthwhile: Two further corner-case
bugs found, though not all fixed yet.


First, I'm sorry that I didn't consider make clean, but then this
issue led to find two previously unknown bugs.
From your last email to the list I guess the TSC thingie is one,
what is the other one ? Anything serious ?

Thanks a lot,
Hannes.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Xenomai v2.2

2006-07-23 Thread Jan Kiszka
Hannes Mayer wrote:
 Ciao Jan!
 
 Jan Kiszka wrote:
 [...]
 Please try make clean before rebuilding your 2.4 kernel with a
 
 Indeed, make clean does a wonder :-)

Good, no further bugs hidden. :)

 BTW, is there any way to reconfigure the periodic timer ?
 Not that I wanna use it - I'm fine with the more accurate aperiodic
 timer, but just curious.

E.g. via rt_timer_set_mode(tick_period) (native skin). If you enable the
periodic mode at compile time, you can use this call from your app to
tweak it during runtime. Additionally, there is the tick_arg module
parameter (or the xeno_nucleus.tick_arg kernel parameter) to set the
timer at startup.

 
 This digging in 2.4 over x86 was worthwhile: Two further corner-case
 bugs found, though not all fixed yet.
 
 First, I'm sorry that I didn't consider make clean, but then this
 issue led to find two previously unknown bugs.
 From your last email to the list I guess the TSC thingie is one,
 what is the other one ? Anything serious ?

Not really. Try to compile the native skin as module under 2.4...

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Xenomai v2.2

2006-07-23 Thread Philippe Gerum
On Sun, 2006-07-23 at 19:15 +0200, Jan Kiszka wrote:
 Hannes Mayer wrote:
  Hi Jan!
  
  Jan Kiszka wrote:
  What about addr2line -e vmlinux -f c01d68b2?
  
  # addr2line -e vmlinux -f c01d68b2
  xnshadow_ppd_insert
  shadow.c:0
  
  Ok, will keep you posted!
  
  Tante grazie e buon fine settimana,
  Hannes.
  
 
 Please try make clean before rebuilding your 2.4 kernel with a
 different timer support. For me this fixed the issue (2.4 build system
 seems to fail catching all dependencies, thus some struct sizes don't
 get updated consistently).
 

For the record, I did run into the very same issue this afternoon while
trying to reproduce this crash on 2.4.32: invalid dereference from
kernel at offset #240 when starting the latency test, right after having
armed the periodic timing support from a previous configuration that
lacked it. A clean rebuild did fix the issue.

 The only thing that still puzzles me is that my crash happened at a
 different code line. Anyway, might be due to other .config differences.
 
 This digging in 2.4 over x86 was worthwhile: Two further corner-case
 bugs found, though not all fixed yet.
 
 Jan
 
 ___
 Xenomai-core mailing list
 Xenomai-core@gna.org
 https://mail.gna.org/listinfo/xenomai-core
-- 
Philippe.



___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Xenomai v2.2

2006-07-22 Thread Hannes Mayer

Hi Jan!

Jan Kiszka wrote:
[...]

Hmm, 2.4 limitation. There used to by some tool called ksymoops for
this. Please give it a try.


hmm...so far I haven't figured out how to use ksymoops, but I got this:

# addr2line -e vmlinux -f c0126f46
__ipipe_dispatch_event
??:0
# addr2line -e vmlinux -f c01160d1
schedule
??:0
# addr2line -e vmlinux -f c01266c7
flush_scheduled_tasks
??:0
# addr2line -e vmlinux -f c0105000
_stext
??:0
# addr2line -e vmlinux -f c0105080
init
main.c:0
# addr2line -e vmlinux -f c010739e
arch_kernel_thread
??:0
# addr2line -e vmlinux -f c0105070
init
main.c:0

Does this help ?
If not, please advise with ksymoops. (btw, there is no .ksyms file
in /var/log/ksymoops for the boot oops)


.config later


Find my kernel config attached. Note that the same config without
the periodic timer works flawlessly.

Thanks a lot,
Hannes 8-)



config-2.4.32-xeno22-captain.gz
Description: GNU Zip compressed data
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Xenomai v2.2

2006-07-22 Thread Jan Kiszka
Hannes Mayer wrote:
 Hi Jan!
 
 Jan Kiszka wrote:
 [...]
 Hmm, 2.4 limitation. There used to by some tool called ksymoops for
 this. Please give it a try.
 
 hmm...so far I haven't figured out how to use ksymoops, but I got this:

ksymoops  your-kernel-log

If you have nothing in your local logs, try to redirect the kernel
output to a serial port and capture it on a second box over null-modem.

 
 # addr2line -e vmlinux -f c0126f46
 __ipipe_dispatch_event
 ??:0
 # addr2line -e vmlinux -f c01160d1
 schedule
 ??:0
 # addr2line -e vmlinux -f c01266c7
 flush_scheduled_tasks
 ??:0
 # addr2line -e vmlinux -f c0105000
 _stext
 ??:0
 # addr2line -e vmlinux -f c0105080
 init
 main.c:0
 # addr2line -e vmlinux -f c010739e
 arch_kernel_thread
 ??:0
 # addr2line -e vmlinux -f c0105070
 init
 main.c:0
 
 Does this help ?

What about addr2line -e vmlinux -f c01d68b2?

 If not, please advise with ksymoops. (btw, there is no .ksyms file
 in /var/log/ksymoops for the boot oops)

/proc/ksyms?

 
 .config later
 
 Find my kernel config attached. Note that the same config without
 the periodic timer works flawlessly.

I still got no oops here, even with LAPIC on (one of the major
differences in our configs). Maybe I will try your original config later.

But there is definitely something fishy about
adeos-ipipe-2.4.32-i386-1.2-05: my Linux clock runs about twice as fast
as it should. This doesn't happen with a comparable 2.6 setup. I still
need to check what happens without CONFIG_XENO_OPT_TIMING_PERIODIC...
Uuh, what's this now? The oops, just with inverted .config! And it's
inside qemu - no chance to escape then. 8)

Ok, will keep you posted!

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Xenomai v2.2

2006-07-22 Thread Hannes Mayer

Hi Jan!

Jan Kiszka wrote:

What about addr2line -e vmlinux -f c01d68b2?


# addr2line -e vmlinux -f c01d68b2
xnshadow_ppd_insert
shadow.c:0


Ok, will keep you posted!


Tante grazie e buon fine settimana,
Hannes.


___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Xenomai v2.2

2006-07-20 Thread Hannes Mayer

Hi Jan!

Jan Kiszka wrote:
[...]

When you THEN try compiling the driver within the kernel build again,
does it still work? I bet it will, because this was likely some issue of
a half-baked kernel. I also re-checked this and noticed no problems
loading the driver.


I didn't replace the original makefile.
Did you check with 2.4.32 ?


ret = rt_task_wait_period(overrun);


...this call requires primary mode anyway and will take care for a
switch back.


Aha! Now it makes sense to me!


  // we are in secondary mode now


Why? I suspect this comment is some kind of left-over of older code


Yes.


(also given the dead variable irq_time above).


Well, I kept this to show how a timestamp can be obtained.
I added a comment.
I also added stuff to my notes page.

Thanks a lot,
Hannes.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Xenomai v2.2

2006-07-20 Thread Hannes Mayer

Jan Kiszka wrote:

Hannes Mayer wrote:

...out of curiosity and to test an older example, I compiled
in periodic timer support, recompiled and then it oopses
at boot. Screenshot:
http://www.captain.at/tmp/dsc05081.jpg
*shrugs*


.config please. And it would also be more helpful if you could switch on
debug symbols so that the oopses tell us where they happened. So this
happened during boot or when running your test?


debug symbols ? Can't find anything else the debug option in kernel
hacking and in xeno-nucleus. Just enabled both, but no more info
at the oops. Oops at booting, BTW.
.config later

Thanks,
Hannes.


___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Xenomai v2.2

2006-07-20 Thread Jan Kiszka
Hannes Mayer wrote:
 Jan Kiszka wrote:
 Hannes Mayer wrote:
 ...out of curiosity and to test an older example, I compiled
 in periodic timer support, recompiled and then it oopses
 at boot. Screenshot:
 http://www.captain.at/tmp/dsc05081.jpg
 *shrugs*

 .config please. And it would also be more helpful if you could switch on
 debug symbols so that the oopses tell us where they happened. So this
 happened during boot or when running your test?
 
 debug symbols ? Can't find anything else the debug option in kernel
 hacking and in xeno-nucleus. Just enabled both, but no more info
 at the oops. Oops at booting, BTW.

Hmm, 2.4 limitation. There used to by some tool called ksymoops for
this. Please give it a try.

 .config later

Looking forward. Meanwhile I actually have a 2.4 kernel running here
(and found two compilation quirks in my code at this chance). Though I
switched on periodic mode, no oops here. And xeno_16550A loads fine as well.

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Xenomai v2.2

2006-07-19 Thread Hannes Mayer

Ciao Philippe et al.!

Philippe Gerum wrote:
[...]

http://download.gna.org/xenomai/stable/xenomai-2.2.0.tar.bz2


Congratulations on the newest release! :-)

I've encountered a probably minor problem:
I compiled the 16550A driver as module (everything else into
the kernel), but when modprobing it said:
couldn't find the kernel version the module was compiled for

I then recompiled the module with an own makefile, then it
worked.

Jan, I also updated the serial port example (I got my devel
machine working again, so I tested on 2.2.0 today :-).
Re. mode-change explanation in your original email:
I read thru them again and couldn't find what important
stuff I left out. Please enlighten. Thanks :-)

Best regards,
Hannes.


___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Xenomai v2.2

2006-07-19 Thread Hannes Mayer


...out of curiosity and to test an older example, I compiled
in periodic timer support, recompiled and then it oopses
at boot. Screenshot:
http://www.captain.at/tmp/dsc05081.jpg
*shrugs*

Best regards,
Hannes.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Xenomai v2.2

2006-07-19 Thread Jan Kiszka
Hannes Mayer wrote:
 
 ...out of curiosity and to test an older example, I compiled
 in periodic timer support, recompiled and then it oopses
 at boot. Screenshot:
 http://www.captain.at/tmp/dsc05081.jpg
 *shrugs*

.config please. And it would also be more helpful if you could switch on
debug symbols so that the oopses tell us where they happened. So this
happened during boot or when running your test?

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Xenomai v2.2

2006-07-19 Thread Jan Kiszka
Hannes Mayer wrote:
 Ciao Philippe et al.!
 
 Philippe Gerum wrote:
 [...]
 http://download.gna.org/xenomai/stable/xenomai-2.2.0.tar.bz2
 
 Congratulations on the newest release! :-)
 
 I've encountered a probably minor problem:
 I compiled the 16550A driver as module (everything else into
 the kernel), but when modprobing it said:
 couldn't find the kernel version the module was compiled for
 
 I then recompiled the module with an own makefile, then it
 worked.

When you THEN try compiling the driver within the kernel build again,
does it still work? I bet it will, because this was likely some issue of
a half-baked kernel. I also re-checked this and noticed no problems
loading the driver.

 
 Jan, I also updated the serial port example (I got my devel
 machine working again, so I tested on 2.2.0 today :-).
 Re. mode-change explanation in your original email:
 I read thru them again and couldn't find what important
 stuff I left out. Please enlighten. Thanks :-)

Ok, let's go through the code I just collected from your side:

 void write_task_proc(void *arg) {
   int ret;
   ssize_t sz = sizeof(RTIME);
   ssize_t written = 0;
   unsigned char buf[17] = CAPTAIN WAS HERE\0;
   unsigned long overrun;
 
   ret = rt_task_set_periodic(NULL, TM_NOW, 
 rt_timer_ns2ticks(write_task_period_ns));
   if (ret) {
 printf(WTASK_PREFIX error while set periodic, code %d\n,ret);
 goto exit_write_task;
   }
 
   while (1) {
 /* switch to primary mode */
 ret = rt_task_set_mode(0, T_PRIMARY, NULL);

Not needed because...

 if (ret) {
   printf(WTASK_PREFIX error while rt_task_set_mode, code %d\n,ret);
   goto exit_write_task;
 }
 ret = rt_task_wait_period(overrun);

...this call requires primary mode anyway and will take care for a
switch back.

 if (ret) {
   printf(WTASK_PREFIX error while rt_task_wait_period, code %d\n,ret);
   goto exit_write_task;
 }
 sz = sizeof(buf);
 written = rt_dev_write(my_fd, buf, sizeof(buf));
 printf(WTASK_PREFIX rt_dev_write written=%d sz=%d\n, written, sz);
 if (written != sz ) {
   if (written  0 ) {
 printf(WTASK_PREFIX error while rt_dev_write, code %d\n,written);
   } else {
 printf(WTASK_PREFIX only %d / %d byte transmitted\n,written, sz);
   }
   goto exit_write_task;
 }
   }
 exit_write_task:
   if (my_state  STATE_FILE_OPENED) {
 if (!close_file( my_fd, RTSER_FILE  (write))) {
   my_state = ~STATE_FILE_OPENED;
 }
   }
   printf(WTASK_PREFIX exit\n);
 }

 void read_task_proc(void *arg) {
   int ret;
 //  RTIME irq_time   = 0;
   ssize_t sz = sizeof(RTIME);
   ssize_t red = 0;
   struct rtser_event rx_event;
   unsigned char buf[17];
 
   // we are in secondary mode now

Why? I suspect this comment is some kind of left-over of older code
(also given the dead variable irq_time above).

Keep in mind that real-time tasks always start in primary mode (I once
suggested to invert this for SCHED_OTHER / prio-0 tasks, but that's only
a concept yet).

   while (1) {
 /* switch to primary mode */
 ret = rt_task_set_mode(0, T_PRIMARY, NULL);
 if (ret) {
   printf(RTASK_PREFIX error while rt_task_set_mode, code %d\n,ret);
   goto exit_read_task;
 }
 /* waiting for event */
 // be careful not to do printf or so here. Otherwise rt_dev_ioctl
 //returns with an error, because we're not in hard real time
 //anymore (primary mode)

Partially true. Older revisions of Xenomai and this particular driver
(16550A) did fail this way. But now we simply switch over automatically
if some service is called from the wrong context.

The only still existing exception are (very rare!) services that are
provided for both contexts. In the 16550A driver: RTSER_RTIOC_SET_CONFIG
with RTSER_SET_TIMESTAMP_HISTORY set in the config mask must run in
non-RT context if the open call did so as well - consistent buffer
allocation from the same type of memory pool.

So, this means you can kill the set_mode, just like in my version I
suggested to cross-check. :)

 ret = rt_dev_ioctl(my_fd, RTSER_RTIOC_WAIT_EVENT, rx_event );
 if (ret) {
   printf(RTASK_PREFIX error while RTSER_RTIOC_WAIT_EVENT, code 
 %d\n,ret);
   goto exit_read_task;
 }
 //irq_time = rx_event.rxpend_timestamp;
 sz = sizeof(buf);
 red = rt_dev_read(my_fd, buf, sizeof(buf));
 if (red == sz ) {
   printf(RTASK_PREFIX rt_dev_read=%s\n,buf);
 } else {
   if (red  0 ) {
 printf(RTASK_PREFIX error while rt_dev_read, code %d\n,red);
   } else {
 printf(RTASK_PREFIX only %d / %d byte received \n,red,sz);
   }
   goto exit_read_task;
 }
   }
 exit_read_task:
   if (my_state  STATE_FILE_OPENED) {
 if (!close_file( my_fd, READ_FILE  (rtser))) {
   my_state = ~STATE_FILE_OPENED;
 }
   }
   printf(RTASK_PREFIX exit\n);
 }

Jan




signature.asc
Description: OpenPGP digital signature

Re: [Xenomai-core] Xenomai v2.2

2006-07-18 Thread Philippe Gerum
On Tue, 2006-07-18 at 15:05 +0200, Philippe Gerum wrote:
 Here is v2.2,

Unfortunately, the Adeos 2.6.14-1.3-04 patch for ppc shipped with the
release is broken. PowerPC users will need to upgrade to -05, which can
be downloaded from the usual place:

http://download.gna.org/adeos/patches/v2.6/ppc/adeos-ipipe-2.6.14-ppc-1.3-05.patch

Sorry for the inconvenience.

-- 
Philippe.



___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Xenomai v2.2-rc2

2006-06-04 Thread Philippe Gerum

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
   -M email   sends output to given addr
-  -m   sends output to [EMAIL PROTECTED]
+  -m   sends output to [EMAIL PROTECTED]
   -U url 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

2006-05-27 Thread Gilles Chanteperdrix
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

2006-05-26 Thread Niklaus Giger
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

2006-05-26 Thread 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

-- 


Gilles Chanteperdrix.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Xenomai v2.2-rc2

2006-05-24 Thread Hannes Mayer

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

2006-05-21 Thread Niklaus Giger
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
   -M email   sends output to given addr
-  -m   sends output to [EMAIL PROTECTED]
+  -m   sends output to [EMAIL PROTECTED]
   -U url 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


Re: [Xenomai-core] Xenomai v2.2-rc2

2006-05-21 Thread Niklaus Giger
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