Re: Smokey GDB test
On 24/07/2019 6:46 PM, Jan Kiszka wrote:
On 24.07.19 08:33, hauptmech via Xenomai wrote:
The smokey GDB test was failing for me.
Xenomai was built with ./configure --enable-smp --enable-pshared on a x86_64
system with cobalt
GCC version (Ubuntu 7.4.0-lubuntu1~18.04.1) 7.4.0
GDB version (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Running the test by hand I found gdb complaining that it did not know the type
of the expressions.
Casting the type in the expressions as below fixed things for me:
diff --git a/testsuite/smokey/gdb/gdb.c b/testsuite/smokey/gdb/gdb.c
index 2fad3da19..538346a04 100644
--- a/testsuite/smokey/gdb/gdb.c
+++ b/testsuite/smokey/gdb/gdb.c
@@ -285,15 +285,15 @@ static int run_gdb(struct smokey_test *t, int argc, char
*const argv[])
smokey_trace("resume in primary");
send_command("c\n", 1);
- eval_expression("primary_mode", "1");
+ eval_expression("(int)primary_mode", "1");
send_command("c\n", 1);
smokey_trace("synchronous stop");
- eval_expression("thread_loops==expected_loops", "1");
+ eval_expression("(unsigned long long)thread_loops==(unsigned long
long)expected_loops", "1");
send_command("c\n", 1);
smokey_trace("synchronous continue");
- eval_expression("thread_loops==expected_loops", "1");
+ eval_expression("(unsigned long long)thread_loops==(unsigned long
long)expected_loops", "1");
send_command("q\n", 0);
pause();
Was this with
https://gitlab.denx.de/Xenomai/xenomai/commit/d48071ae92754119e504202d486cd87762c46cbb
applied?
Jan
No. And I would expect the -g flag to solve the problem. Sorry for the
false alarm.
Smokey GDB test
The smokey GDB test was failing for me.
Xenomai was built with ./configure --enable-smp --enable-pshared on a
x86_64 system with cobalt
GCC version (Ubuntu 7.4.0-lubuntu1~18.04.1) 7.4.0
GDB version (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Running the test by hand I found gdb complaining that it did not know
the type of the expressions.
Casting the type in the expressions as below fixed things for me:
diff --git a/testsuite/smokey/gdb/gdb.c b/testsuite/smokey/gdb/gdb.c
index 2fad3da19..538346a04 100644
--- a/testsuite/smokey/gdb/gdb.c
+++ b/testsuite/smokey/gdb/gdb.c
@@ -285,15 +285,15 @@ static int run_gdb(struct smokey_test *t, int
argc, char *const argv[])
smokey_trace("resume in primary");
send_command("c\n", 1);
- eval_expression("primary_mode", "1");
+ eval_expression("(int)primary_mode", "1");
send_command("c\n", 1);
smokey_trace("synchronous stop");
- eval_expression("thread_loops==expected_loops", "1");
+ eval_expression("(unsigned long
long)thread_loops==(unsigned long long)expected_loops", "1");
send_command("c\n", 1);
smokey_trace("synchronous continue");
- eval_expression("thread_loops==expected_loops", "1");
+ eval_expression("(unsigned long
long)thread_loops==(unsigned long long)expected_loops", "1");
send_command("q\n", 0);
pause();
Re: prepare-kernel.sh
I just ran into this problem as well. It wasn't until a kernel build failed part way through and I did a bit of googling that I figured out to guess which kernel version would work with which branch by reading the git comments. It would be useful to add a known good ipipe/kernel version combo for the stable branch to https://gitlab.denx.de/Xenomai/xenomai/wikis/Start_Here#user-content-gathering-the-linux-kernel-bits Or if this is considered too much of a moving target, a note in the same place to read the git commit comments and what to look for to identify which kernel is likely good. -Hauptmech On 24/07/2019 1:44 AM, Jan Kiszka via Xenomai wrote: On 23.07.19 14:37, alessio margan via Xenomai wrote: Hi all, I got this error when trying to configure the kernel 4.19.57 with the procedure that I used so far. Is there something new that I miss (base) embedded@com-exp:/usr/local/src/xenomai.git(stable/v3.0.x)$ 4.19 requires Xenomai master. Jan
Re: [Xenomai] posix/stdio.h error: ?size_t? does not name a type
On 12/28/2012 04:01 PM, Gilles Chanteperdrix wrote: On 12/28/2012 01:26 PM, Mariusz Janiak wrote: Hi After successful Xenomai 2.6.2 installation (with Gilles help), I have started building OROCOS 2.6 with xeno support, and once again I went into trouble. This time I am not sure that it is a Xenomai related bug. The problem is following from /worek/install/orocos-toolchain-xeno/rtt/rtt/transports/mqueue/MQLib.hpp:42, from /worek/install/orocos-toolchain-xeno/rtt/rtt/transports/mqueue/MQLib.cpp:40: /usr/xenomai/include/xenomai/posix/stdio.h:30:1: error: ?size_t? does not name a type make[2]: *** [rtt/transports/mqueue/CMakeFiles/rtt-transport-mqueue-xenomai_plugin.dir/MQLib.cpp.o] Błąd 1 I have found one thread related to this problem http://www.xenomai.org/pipermail/xenomai/2012-September/026143.html Adding #include in /usr/xenomai/include/xenomai/posix/stdio.h have solved my problem, but I don't know if it is a suitable solution. Hi Mariusz, thanks for the report. Could you tell me which distribution and which version you are using? We are certainly not going to include unistd.h in stdio.h, the fact that size_t is not defined indicates that something else is wrong as there are services supposedly defined in stdio.h which use size_t. Regards. http://gcc.gnu.org/gcc-4.7/porting_to.html (search for unistd.h) The correct fix is probably to add unistd.h to MQLib.hpp (and other include files that are missing it) Mariusz ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
[Xenomai] [PATCH] Asciidoc versions of the man pages
Asciidoc versions of the man pages. Still TBD is updating the contents of the man pages to match the present software where needed. -hauptmech -- next part -- A non-text attachment was scrubbed... Name: asciidoc_manpages.patch Type: text/x-patch Size: 26892 bytes Desc: not available URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20121218/ae6d8a08/attachment.bin> ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] How does the adeos and xenomai project stay synchronized with the linux kernel project?
On 12/16/2012 03:11 PM, Gilles Chanteperdrix wrote: On 12/16/2012 02:41 PM, hauptmech wrote: I'm coming to the documentation with relatively fresh eyes. If you give me a user on the wiki I'm happy to do a little gardening. Things like the [getting started] page which is useful but not linked to anymore. Perhaps a buffer page between the wiki and the git page with a little description of the repos and how they fit into the development workflow (where a link to denx could go). The "getting started" page is unfinished (contains empty paragraphs), and outdated (contains dead links and references to things like the simulator which is currently not really usable) at the same time. I do not believe we have the resources to maintain such a page up-to-date. Do you mind if your list of documentation wants goes into the wiki (at the taskmarket I guess)? From my point of view, what we need is: - up to date manual pages of the binaries in xenomai distribution, in the xenomai sources, we can start from the current manual pages, but some of them are outdated and we should convert them to asciidoc so that more people can work on them, and we can put the html versions on the web site (with automatic update, as currently happens for the API documentation and README.INSTALL/TROUBLESHOOTING) Do the asciidoc man page sources go in doc/asciidoc or doc/man? I'm a bit shaky with automake/Makefile scripts, if someone can shim Makefile.am with the code to call 'a2x -f manpage $SOURCEFILE' in the right location then I don't mind converting them. An example... CLOCKTEST(1) :doctype: manpage NAME clocktest - Xenomai Clock Test SYNOPSIS *clocktest* ['OPTIONS'] DESCRIPTION --- *clocktest* is part of the Xenomai test suite and tests the Clock. For each CPU, it repeatedly prints a time offset (compared to the reference gettimeofday()), a drift value, the number of warps and the maximum warp in microseconds. For this program to work, you need to run a suitable Xenomai enabled kernel with the respective module (xeno_posix). OPTIONS --- *-C *:: clock to be tested, default=0 (CLOCK_REALTIME=0, CLOCK_MONOTONIC=1, CLOCK_HOST_REALTIME=42) *-T *:: default=0 (Never stop, ^C to end) *-D*:: print extra diagnostics for CLOCK_HOST_REALTIME AUTHOR -- *clocktest* was written by Jan Kiszka . This man page was written by Roland Stigge . - some thematic pages on the wiki such as: . calibrating your system with xeno-test . influence of the various Linux kernel options on latencies on at least the arm and x86 platforms - and hyperlinks, for instance at the end of README.INSTALL point to the "calibrating your system" page, and in this page, have an hyperlink to the xeno-test and latency test manual pages, in the page "porting the I-pipe-core patch to a new ARM board", mention the tools that can be used to debug the various issues, and have an hyperlink to their manual page. - a user guide, the "porting posix applications to xenomai" page, was my attempt of a user-guide, but it has a very specialized goal, whereas part of the information it contains is general to anyone writing posix applications for xenomai, and evern applications in general. - something we have talked about but has long gone forgotten, have some kind of database of the latency results sortable by a mix of measurement type, load type, kernel versions, configuration options, processors or SOCs. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Documentation and WIKI
On 12/16/2012 10:30 PM, Gilles Chanteperdrix wrote: On 12/16/2012 10:12 PM, hauptmech wrote: On 12/16/2012 09:19 PM, Gilles Chanteperdrix wrote: On 12/16/2012 08:20 PM, hauptmech wrote: I'd like to propose a buffer page between the menu options and non-wiki pages. Specifically GIT repositories and Installing. A couple reasons... One it's unexpected, as conventionally links to outside pages are marked as such in a wiki. Two: a wiki page between the menu and the external page allows us to put some summary info to help ease the reader into the bigger document and add useful tidbits (like the existance of denx) Examples of buffer pages are at: http://www.xenomai.org/index.php/Install_Xenomai http://www.xenomai.org/index.php/GIT_repositories Link them in (I don't have permission) if you agree. The "getting started" page is unfinished (contains empty paragraphs), and outdated (contains dead links and references to things like the simulator which is currently not really usable) at the same time. I do not believe we have the resources to maintain such a page up-to-date. I think the getting started page is a nice little introduction. I've had a pass at cleaning it up. http://www.xenomai.org/index.php/Getting_Started There's more that could be done but if it looks ok, consider linking to it from the menu 'Start here' It is sort of a replacement of "Start here", so, from my point of view, it should be the "Start here" page, and also contain what the "Start here" page contains (namely, the link to the "porting posix applications to xenomai", and all the links to all the API documentation versions). I see what you mean. The Documentation Summary (start here) is nicely compact, I wouldn't want to ruin it. What about calling 'getting started' 'beginners guide' and inserting a link to it between 'Start here' and 'Installing'? I think the farther the information (in count of navigation hops) is from the main page, the less it is likely to be found, and this is verified by the statistics on page accesses. So, I suggest the "Getting started" guide, or whatever its name should be directly accessible from the main page. I agree. I meant inserting a left side wiki menu link in the documentation section between "Start Here" and "Installing" ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Documentation and WIKI
On 12/16/2012 09:19 PM, Gilles Chanteperdrix wrote: On 12/16/2012 08:20 PM, hauptmech wrote: I'd like to propose a buffer page between the menu options and non-wiki pages. Specifically GIT repositories and Installing. A couple reasons... One it's unexpected, as conventionally links to outside pages are marked as such in a wiki. Two: a wiki page between the menu and the external page allows us to put some summary info to help ease the reader into the bigger document and add useful tidbits (like the existance of denx) Examples of buffer pages are at: http://www.xenomai.org/index.php/Install_Xenomai http://www.xenomai.org/index.php/GIT_repositories Link them in (I don't have permission) if you agree. The "getting started" page is unfinished (contains empty paragraphs), and outdated (contains dead links and references to things like the simulator which is currently not really usable) at the same time. I do not believe we have the resources to maintain such a page up-to-date. I think the getting started page is a nice little introduction. I've had a pass at cleaning it up. http://www.xenomai.org/index.php/Getting_Started There's more that could be done but if it looks ok, consider linking to it from the menu 'Start here' It is sort of a replacement of "Start here", so, from my point of view, it should be the "Start here" page, and also contain what the "Start here" page contains (namely, the link to the "porting posix applications to xenomai", and all the links to all the API documentation versions). I see what you mean. The Documentation Summary (start here) is nicely compact, I wouldn't want to ruin it. What about calling 'getting started' 'beginners guide' and inserting a link to it between 'Start here' and 'Installing'? ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
[Xenomai] Documentation and WIKI
I'd like to propose a buffer page between the menu options and non-wiki pages. Specifically GIT repositories and Installing. A couple reasons... One it's unexpected, as conventionally links to outside pages are marked as such in a wiki. Two: a wiki page between the menu and the external page allows us to put some summary info to help ease the reader into the bigger document and add useful tidbits (like the existance of denx) Examples of buffer pages are at: http://www.xenomai.org/index.php/Install_Xenomai http://www.xenomai.org/index.php/GIT_repositories Link them in (I don't have permission) if you agree. The "getting started" page is unfinished (contains empty paragraphs), and outdated (contains dead links and references to things like the simulator which is currently not really usable) at the same time. I do not believe we have the resources to maintain such a page up-to-date. I think the getting started page is a nice little introduction. I've had a pass at cleaning it up. http://www.xenomai.org/index.php/Getting_Started There's more that could be done but if it looks ok, consider linking to it from the menu 'Start here' I agree with you, we have some information on the wiki, but it seems hard to find, seeing how people are asking again and again the same questions about configuring an x86 kernel, which are answered and hyperlinked in at least three pages on the web site. It must mean that people are not seeing it as they navigate. It is a bit spread out. And to be honest, 'troubleshooting' is not where I'd go looking for configuration info. On the other hand, some people just need lots and lots of repetition before it sinks into the skull. -hauptmech ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] How does the adeos and xenomai project stay synchronized with the linux kernel project?
I'm coming to the documentation with relatively fresh eyes. If you give me a user on the wiki I'm happy to do a little gardening. Things like the [getting started] page which is useful but not linked to anymore. Perhaps a buffer page between the wiki and the git page with a little description of the repos and how they fit into the development workflow (where a link to denx could go). I have made xenomai source packages for pacman (Archlinux + a few others) for arm last year and just now x86. However since archlinux tends to use a minimally patched vanilla kernel it's not as exciting as debian. More embedded below... On 12/15/2012 12:47 PM, Gilles Chanteperdrix wrote: On 12/14/2012 11:12 PM, Philippe Gerum wrote: We never updated the Adeos patches for minor linux releases routinely, this has never been our policy, and will likely never be the case. This would just involve way too much work for our bandwidth. We are focusing on major releases. So you seem to be expecting something we never delivered in the past anyway. Ok, I wasn't expecting anything. I just didn't understand. However, the pace of our Adeos updates for major kernel releases has slowed down over the past three years, definitely. This said, we have support for kernel 3.4 and in some cases 3.5, for the main architecture ports we maintain, it's not lagging that far behind. The availability of ipipe for 3.4/3.5 (x86) is not apparent from the website nor the patches in the xenomai source. So my question is (with the deepest respect for the effort it must take) why? Because we all have to deal with priorities and available resources, this is no different for the Xenomai maintainers. Speaking for myself here, porting the I-pipe patch (for the ARM architecture in my case) to new versions of Linux is the most boring part of the job, and since I do it on my free time, I tend to procrastinate. Which is why for instance the I-pipe patch for 3.5 has been available since august, and I did the port to the ARM architecture only last week-end (shame on me...). Does all the work involve expertise with the kernel? I realize that having a inexpert 'helper' for a lot of tasks just creates extra work but if that's not the case here, perhaps a help-wanted post on the wiki and some documentation on the process would attract someone wanting to learn or help. Anyway, I think the real problem for an end user is the frequency of Xenomai releases, not of the I-pipe patches, because we probably should have made a release of Xenomai as soon as the patch for 3.4 has been available on all architectures. But on the other hand, if you look at the core-3.4 branch in the git repository, you will see that staying some time on that patch allowed us to fix many issues. I look forward to the release when it does happen. -hauptmech ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
[Xenomai] How does the adeos and xenomai project stay synchronized with the linux kernel project?
(apologies for the previous incomplete email) I've used and followed Xenomai off and on since it forked from RTAI. I'm building a new xenomai x86 system after a few years of doing other things. I'm noticing that the adeos patches are few and relatively old compared to the kernel for the x86 architecture. Kernel version 3.2 has moved from .21 to .35 for instance. Meanwhile my (non-rt) systems all use 3.4 or 3.6. So my question is (with the deepest respect for the effort it must take) why? Why do the adeos patches lag so much? Also why were the linux-3.2.21 x86 patch typos which prevent compilation not fixed? When such basic thing is not taken care of it makes me doubt the integrity of the whole project. In my community (robotics) xenomai is the go-to RT system for me and most of my peers. However the xenomai roadmap and task-market are bitrotted and there don't seem to be project status updates on the wiki or mailing list which makes it hard to contribute or make plans. I guess I just want to call attention to the fact that things are looking a little rough at xenomai.org and ask whether passers by like myself should try to help a little or move on? kind regards, hauptmech ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
[Xenomai] How does the adeos and xenomai project stay synchronized with the linux kernel project?
I've used and followed Xenomai off and on since it forked from RTAI. I'm building a new xenomai x86 system after a few years of doing other things. I'm noticing that the adeos patches are few and relatively old compared to the kernel for the x86 architecture. Kernel version 3.2 has moved from .21 to .35 for instance. So my question is (with the deepest respect for the effort it must take) why? Is ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
