[Xenomai-core] 2.4.32 compilation error + old timer example problem
I checked out xeno.trunk just a few minutes ago. With kernel 2.4.32, kernel compilation fails with this: mq.c: In function `mq_notify': mq.c:475: error: `SIGEV_SIVNAL' undeclared (first use in this function) mq.c:475: error: (Each undeclared identifier is reported only once mq.c:475: error: for each function it appears in.) kernel/xenomai/skins/posix/mq.c SIGEV_SIVNAL = SIGEV_SIGNAL ..with that it succeeds. But still my timer example doesn't work - see: https://mail.gna.org/public/xenomai-help/2005-12/msg00020.html With 2.6.14.3 it works... Thanks for any hints, Happy New Year, Hannes. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] 2.4.32 compilation error + old timer example problem
Jan Kiszka wrote: [...] Yea, maybe that periodic timer mode is not compiled in and rt_timer_start fails in your original example. I think it's off by default now. Yeah, got it! Sorry for not supplying error code earlier! In Xeno source: int xnpod_start_timer (u_long nstick, xnisr_t tickhandler) [...] #ifndef CONFIG_XENO_HW_PERIODIC_TIMER if (nstick != XN_APERIODIC_TICK) return -ENODEV; /* No periodic support */ #endif /* CONFIG_XENO_HW_PERIODIC_TIMER */ ..and guess what: I got -ENODEV back on rt_timer_start! In .config I have # CONFIG_XENO_HW_PERIODIC_TIMER is not set So the puzzle is solved! Just one question: what's the reason why the periodic mode is disabled by default ? Thanks best regards, Hannes. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] 2.4.32 compilation error + old timer example problem
Philippe Gerum wrote: [...] Just one question: what's the reason why the periodic mode is disabled by default ? Because AFAICT, most people would rather use the aperiodic timing mode in usual configurations for a much better accuracy. Since the periodic mode uses the available hw PIT and programs it once (or even some decrementer but without handling the time drift when reprogramming it after each shot), it suffers from cumulated rounding errors of the period. If you look at the jitter results of a trivial periodic loop over a broad timescale, you will see the wakeup time irremediably drift, whilst the average interval between shots remains stable and reasonably accurate. The periodic timer should be used for configurations that only need to enforce delays or timeouts, and not, well, precise timings. Thanks Philippe! If it's for accuracy, keep it that way! Best regards, Hannes. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] SMI-doc improvement / RTDM paper
Hi all! Jan Kiszka wrote: [...] +printk(Xenomai: Intel chipset found but SMI workaround not enabled in kernel\n +configuration. You may encounter high interrupt latencies.\n); Speaking of printk. Since 2.1 I don't see any messages in the kernel log. I bet there is a new switch somewhere, but I can't find it. Any hint appreciated. BTW, Jan, the SMI seems to be disabled now, even if I haven't seen the message of disabling SMI in the klog. Thanks best regards, Hannes. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [Xenomai-help] Xenomai v2.1-rc4
Philippe Gerum wrote: This time, the merge window is closed for good; no kidding. This said, too many changes since -rc3 have taken place for releasing v2.1 without one more -rc iteration, so here is -rc4. Major updates are as follows: - scalable timer management using non-linear access (Gilles) - shared real-time interrupt support (Dmitry) - POSIX updates (Gilles) - UVM fixes (me) - registry support abstraction (me) - RTDM updates (Jan) - building blocks for Debian packaging (Romain Lenglet) http://download.gna.org/xenomai/testing/xenomai-2.1-rc4.tar.bz2 Ciao Philippe! During prepare-kernel.sh I noticed that Adeos/i386 1. (newgen) installed. Links installed. Build system ready. is not printed anymore. Bug or feature ? Best regards, Hannes. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] v2.1-rc4 RTDM bug
Hannes Mayer wrote: Ciao Jan! It doesn't seem to make a difference if one uses RTDM_IRQ_NONE or RTDM_IRQ_HANDLED. With RTDM_IRQ_NONE the IRQ should be passed to linux, right ? But it doesn't seem to happen - this brought up the top problem I've posted a few days ago. Returning XN_ISR_PROPAGATE passes the grabbed timer interrupt to Linux and top works again. Best regards, Hannes. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] v2.1-rc4 RTDM bug
Jan Kiszka wrote: Hannes Mayer wrote: Hannes Mayer wrote: Ciao Jan! It doesn't seem to make a difference if one uses RTDM_IRQ_NONE or RTDM_IRQ_HANDLED. With RTDM_IRQ_NONE the IRQ should be passed to linux, right ? But it doesn't seem to happen - this brought up the top problem I've posted a few days ago. Returning XN_ISR_PROPAGATE passes the grabbed timer interrupt to Linux and top works again. As forwarding interrupts to the non-realtime domain is not a common use-case of realtime device drivers, I decided to drop the propagation support at RTDM level. So if you are including this mechanism in your demo, please mark this pattern as something RTDM drivers should normally NOT do (and explain what's reason for it here). Thanks Jan! I'll add that in a few. Best regards, Hannes. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [Xenomai-help] Xenomai v2.1-rc4
Romain Lenglet wrote: During prepare-kernel.sh I noticed that Adeos/i386 1. (newgen) installed. Links installed. Build system ready. is not printed anymore. Bug or feature ? Feature. --verbose brings this message back, IIRC. I guess that's needed for automated Debian packaging stuff Romain is working on. Well, it was primarily to make it look more like usual Unix tools. And I did not understand why there were messages always printed, and others printed only with --verbose. Anyway, now if nothing is printed it is good news. Error messages are always printed on the error output even if --verbose is not set. Ciao Philippe! Ciao Romain! Thanks! Otherwise RC4 works nicely here :-) Best regards, Hannes. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] SMI-doc improvement / RTDM paper
Hi all! Jan Kiszka wrote: [...] +printk(Xenomai: Intel chipset found but SMI workaround not enabled in kernel\n +configuration. You may encounter high interrupt latencies.\n); Speaking of printk. Since 2.1 I don't see any messages in the kernel log. I bet there is a new switch somewhere, but I can't find it. Any hint appreciated. BTW, Jan, the SMI seems to be disabled now, even if I haven't seen the message of disabling SMI in the klog. Thanks best regards, Hannes.
Re: [Xenomai-core] [PATCH] SMI-doc improvement / RTDM paper
Philippe Gerum wrote: [...] dmesg | grep -i xenomai: ? Yeah, got it now! Sorry for the silly question! I forgot that as of 2.1 everything is compiled into the kernel by default, so when running a testsuite example there are no messages that xeno is loaded or unloaded. Thanks and best regards, Hannes.
[Xenomai-core] ... the rt-preempt patch once been in fusion
Hi all! Well, subject says almost all. I remember there has been an effort to make a fusion/rt-preempt patch conglomerate back then. I'm just curious (as I've just been toying with the Molnar patch) - has that thing been dropped in xeno completely ? Thanks and best regards, Hannes.
Re: [Xenomai-core] Scheduling while atomic
Jan Kiszka wrote: [...] Do you (or anybody else) have a running 2.0.x installation? If so, please test that setup as well. Sure :-) # uname -r 2.6.13.4-adeos-xenomai # cat /proc/xenomai/version 2.0 # ./mutex Running for 2.15 seconds. ALERT: No lock! (lockcnt=0) Offending task: task0 ALERT: No lock! (lockcnt=0) Offending task: task0 ALERT: No lock! (lockcnt=0) Offending task: task0 ALERT: No lock! (lockcnt=0) Offending task: task0 L121: Connection timed out. # cat dump.txt 101001001010101011000110001[...] # ./sem Running for 2.15 seconds. L119: Connection timed out. # cat dump.txt 101001muon:/home/xenomai/atomic# More tests ? Best regards, Hannes.
[Xenomai-core] 2.4.32 compilation error + old timer example problem
I checked out xeno.trunk just a few minutes ago. With kernel 2.4.32, kernel compilation fails with this: mq.c: In function `mq_notify': mq.c:475: error: `SIGEV_SIVNAL' undeclared (first use in this function) mq.c:475: error: (Each undeclared identifier is reported only once mq.c:475: error: for each function it appears in.) kernel/xenomai/skins/posix/mq.c SIGEV_SIVNAL = SIGEV_SIGNAL ..with that it succeeds. But still my timer example doesn't work - see: https://mail.gna.org/public/xenomai-help/2005-12/msg00020.html With 2.6.14.3 it works... Thanks for any hints, Happy New Year, Hannes.
Re: [Xenomai-core] 2.4.32 compilation error + old timer example problem
Hi Jan! Jan Kiszka wrote: Hannes Mayer wrote: I checked out xeno.trunk just a few minutes ago. With kernel 2.4.32, kernel compilation fails with this: mq.c: In function `mq_notify': mq.c:475: error: `SIGEV_SIVNAL' undeclared (first use in this function) mq.c:475: error: (Each undeclared identifier is reported only once mq.c:475: error: for each function it appears in.) kernel/xenomai/skins/posix/mq.c SIGEV_SIVNAL = SIGEV_SIGNAL ..with that it succeeds. But still my timer example doesn't work - see: https://mail.gna.org/public/xenomai-help/2005-12/msg00020.html Is this problem only related to the periodic timer mode? I've modified my example with rt_task_set_periodic as in the rt_serial_uprog example http://www.captain.at/xenomai-timer-task.php and this variant is working. I'm just curious why the original example (#2 on my page) suddenly stopped working (rt_task_sleep seems to do nothing, so the messages from the task are flooding the screen). Thanks best regards, Hannes.
Re: [Xenomai-core] 2.4.32 compilation error + old timer example problem
Jan Kiszka wrote: [...] Yea, maybe that periodic timer mode is not compiled in and rt_timer_start fails in your original example. I think it's off by default now. Yeah, got it! Sorry for not supplying error code earlier! In Xeno source: int xnpod_start_timer (u_long nstick, xnisr_t tickhandler) [...] #ifndef CONFIG_XENO_HW_PERIODIC_TIMER if (nstick != XN_APERIODIC_TICK) return -ENODEV; /* No periodic support */ #endif /* CONFIG_XENO_HW_PERIODIC_TIMER */ ..and guess what: I got -ENODEV back on rt_timer_start! In .config I have # CONFIG_XENO_HW_PERIODIC_TIMER is not set So the puzzle is solved! Just one question: what's the reason why the periodic mode is disabled by default ? Thanks best regards, Hannes.
Re: [Xenomai-core] Dev branch 2.1
Ciao Philippe! prepare-kernel.sh works well - I'd suggest to ask the user for the 3 needed parameters, instead of supplying them as parameters. e.g. # scripts/prepare-kernel.sh Linux directory: [default: /usr/src/linux] : Adeos-patch: [default: none] : Architecture: [default: i386] ...or something like that. ./configure also went well, but then: # make Making all in src make[1]: Entering directory `/usr/src/xenomai-2.1/src' Making all in include make[2]: Entering directory `/usr/src/xenomai-2.1/src/include' make all-recursive make[3]: Entering directory `/usr/src/xenomai-2.1/src/include' Making all in asm-uvm make[4]: Entering directory `/usr/src/xenomai-2.1/src/include/asm-uvm' make[4]: stat:system.h: Too many levels of symbolic links make[4]: *** No rule to make target `system.h', needed by `all-am'. Stop. make[4]: Leaving directory `/usr/src/xenomai-2.1/src/include/asm-uvm' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/src/xenomai-2.1/src/include' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/src/xenomai-2.1/src/include' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/xenomai-2.1/src' make: *** [all-recursive] Error 1 /usr/src/xenomai-2.1/src/include/asm-uvm# ll total 36 -rw-r--r-- 1 root root 12780 2005-11-03 01:03 Makefile -rw-r--r-- 1 cap cap 67 2005-11-02 21:36 Makefile.am -rw-r--r-- 1 cap cap 13046 2005-11-02 21:36 Makefile.in lrwxrwxrwx 1 root root39 2005-11-03 01:03 system.h - ../../.././src/include/asm-uvm/system.h Best regards, Hannes.
Re: [Xenomai-core] Dev branch 2.1
Wolfgang Grandegger wrote: [...] I have realized the same error building out of the source tree for PowerPC. The problem is, that the link is pointing to itself. Apart from that, the ksrc part works fine (at least I can boot the ipipe kernel). If I remove the sym-link and copy .svn/text-base/system.h.svn-base to src/include/asm-uvm/system.h it compliles: muon:/usr/src/xenomai-2.1/src/include/asm-uvm# ll total 36 -rw-r--r-- 1 root root 12780 2005-11-03 01:03 Makefile -rw-r--r-- 1 cap cap 67 2005-11-02 21:36 Makefile.am -rw-r--r-- 1 cap cap 13046 2005-11-02 21:36 Makefile.in lrwxrwxrwx 1 root root39 2005-11-03 01:03 system.h - ../../.././src/include/asm-uvm/system.h muon:/usr/src/xenomai-2.1/src/include/asm-uvm# rm system.h rm: remove symbolic link `system.h'? y muon:/usr/src/xenomai-2.1/src/include/asm-uvm# cp .svn/text-base/system.h.svn-base system.h OK, so far so good. The ipipe kernel boots, I've got a directory /usr/xenomai/ with all accustomed directories, but no modules... Wolfgang, do you have the e.g. xeno_native.ko somewhere ? Best regards, Hannes.
Re: [Xenomai-core] Xenomai v2.0
Jan Kiszka wrote: Bruno Rouchouse wrote: On 10/25/05, Jan Kiszka [EMAIL PROTECTED] wrote: The logo looks nice - who's the designer? Shouldn't (s)he work out the image as well...? I designed the logo. After a couple of beers I got inspired but I would need to drink too much to obtain the same result with the image :) What about a penguin jumping out of a cuckoo clock ;-) Cheers, Hannes.
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
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
...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
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
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
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
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
[Xenomai-core] xenomai.org suggestions
Hi all! Here are some suggestions for the xenomai.org website: * no redirect from xenomai.org to http://snail.fsffrance.org/www.xenomai.org/ * put real-time framework for linux into the page title * add info why registering is cool and what benefits it will offer * make the top-most xeno logo a link back to www.xenomai.org * the house icon (top right) should also link to www.xenomai.org * search icon (top right) should link to the xenomai.org search page (www.xenomai.org/index.php?option=com_searchItemid=5) * put up some general information about the project on the index page, which is visible all the time (incl. strong keywords, so people will find the xeno page when e.g. searching for real time linux etc. These are just things that I'd change - just some hints to enlarge the user experience and to drive more users to the site. Best regards, Hannes. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
