[Xenomai-core] Xenomai v2.2

[Xenomai-core] Xenomai v2.2

[Philippe Gerum]

Here is v2.2, basically aiming at higher performances and better Linux
integration compared to the previous series. The major issues we have
been working on for this release are:

o Latency reduction, thanks to a combined work on the I-pipe support
and fast paths of the real-time core. To leverage that, you will need
to upgrade to recent Adeos releases, which provide pipeline head
optimizations.

o Direct syscall interfaces to the VxWorks and VRTX skins are now
available. In other words, it is now possible to run VxWorks and VRTX
applications in user-space context, without resorting to the UVM
machinery (which remains available, though).

o The testsuite has been extended with new tests and benchmarks.

o The POSIX, RTDM and native skin have been significantly updated.
POSIX-wise, this also means that we are getting close to the 1003.1b
specifications, fully delivered in primary execution mode.

o The Adeos support has been upgraded for all architectures.

See the ChangeLog for details.

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

-- 
Philippe.

Re: [Xenomai-core] Xenomai v2.2

[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.

Re: [Xenomai-core] Xenomai v2.2

[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.

Re: [Xenomai-core] Xenomai v2.2

[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.

Re: [Xenomai-core] Xenomai v2.2

[Jan Kiszka]

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

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


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

Re: [Xenomai-core] Xenomai v2.2

[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.

Re: [Xenomai-core] Xenomai v2.2

[Jan Kiszka]

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

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


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

Re: [Xenomai-core] Xenomai v2.2

[Hannes Mayer]

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

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-)


[-- Attachment #2: config-2.4.32-xeno22-captain.gz --]
[-- Type: application/x-gzip, Size: 6436 bytes --]

Re: [Xenomai-core] Xenomai v2.2

[Jan Kiszka]

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

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


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

Re: [Xenomai-core] Xenomai v2.2

[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.

Re: [Xenomai-core] Xenomai v2.2

[Jan Kiszka]

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

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


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

Re: [Xenomai-core] Xenomai v2.2

[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.

Re: [Xenomai-core] Xenomai v2.2

[Jan Kiszka]

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

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


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

Re: [Xenomai-core] Xenomai v2.2

[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@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
-- 
Philippe.

Re: [Xenomai-core] Xenomai v2.2

[Jan Kiszka]

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

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



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

Re: [Xenomai-core] Xenomai v2.2

[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.