Re: [Xenomai] [Emc-developers] new RTOS status: Scheduler (?) lockup on ARM
the suspicion now turned to the DHCP lease setting and RTC time warp issues - the Beaglebone doesnt have an RTC so it starts up at 1-1-1970 the first DHCP lease still has 1970 timestamps, but eventually the RTC is set with ntpdate and it could be this causes confusion the thing which is hard to believe for me: loss of IP connectivity - conceivable; kernel hang - why? question: does a RTC time warp have any possible bearing on Xenomai operations? - Michael ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] [CRITICAL PATCH] ipipe: Re-read domain context after IRQ processing
On 01/21/2013 12:30 PM, Jan Kiszka wrote: On 2013-01-18 21:09, Jan Kiszka wrote: On 2013-01-18 20:04, Jan Kiszka wrote: On 2013-01-18 18:04, Jan Kiszka wrote: On 2013-01-18 17:37, Philippe Gerum wrote: On 01/18/2013 04:38 PM, Jan Kiszka wrote: This fixes a nasty bug on SMP boxes: We may migrate to root in the context of an IRQ handler, and then also to a different CPU. Therefore, we must not use domain contexts read before the invocation but update them afterward or use stable information like the domain reference. Ack. Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- We are still facing stalled, unkillable RT processes despite this fix, Is TASK_HARDENING still lingering in task-state despite the recent switch_tail fix, or is this something different? Patch is applied, but I didn't check this detail yet. I just found a potential SMP race in schedule_linux_call, patch follows. But now I triggered XENO_BUGON(NUCLEUS, need_resched == 0); for unknown reasons... Probably found the problem - or at least another one: XNINLOCK must be used with xnsched::lflags, not status. It is set/cleared by the RTDM spin locks outside nklock. Will patch that and retest. Wasn't able to run all tests yet, but it looked promising so far. Will finish this on Monday. Looks stable now according to the testers. Ok, we are good to go for the 2.6.2 re-release then. -- Gilles. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Xenomai and normal linux application - Wait time with select() not reliable
On 01/21/2013 01:06 PM, Jens Köhler wrote: Hello Gilles, I did not understand your latests statement. What do you mean with If you expect a task using a Linux semaphore to have bounded latencies, you misunderstood the way Xenomai works. Do you think it should work without problems, without delays, latencies? Do you know if someone has already used linux semaphores in a xenomai thread? What do you recommend to find reason and a solution? Using a Linux semaphore causes a switch to secondary mode, which means potentially unbounded latencies. Please keep the list in CC. -- Gilles. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] [Emc-developers] new RTOS status: Scheduler (?) lockup on ARM
Am 21.01.2013 um 12:56 schrieb Gilles Chanteperdrix: On 01/21/2013 12:43 PM, Michael Haberler wrote: the suspicion now turned to the DHCP lease setting and RTC time warp issues - the Beaglebone doesnt have an RTC so it starts up at 1-1-1970 the first DHCP lease still has 1970 timestamps, but eventually the RTC is set with ntpdate and it could be this causes confusion the thing which is hard to believe for me: loss of IP connectivity - conceivable; kernel hang - why? question: does a RTC time warp have any possible bearing on Xenomai operations? No, it should not, Xenomai uses its own clock, which is set only once upon boot, so, is unaffected by Linux wallclock time changes... or should be. it might not be Xenomai after all. Uhum. the bughunt safari tribe has decided to focus on class 'duh' problems and resolves to shut up until red hands are spotted. -- btw the upgrade to the ipipe patch in master made all xeno-regression-test problems go away - thanks! -Michael ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] [Emc-developers] new RTOS status: Scheduler (?) lockup on ARM
On 01/21/2013 02:32 PM, Michael Haberler wrote: Am 21.01.2013 um 12:56 schrieb Gilles Chanteperdrix: On 01/21/2013 12:43 PM, Michael Haberler wrote: the suspicion now turned to the DHCP lease setting and RTC time warp issues - the Beaglebone doesnt have an RTC so it starts up at 1-1-1970 the first DHCP lease still has 1970 timestamps, but eventually the RTC is set with ntpdate and it could be this causes confusion the thing which is hard to believe for me: loss of IP connectivity - conceivable; kernel hang - why? question: does a RTC time warp have any possible bearing on Xenomai operations? No, it should not, Xenomai uses its own clock, which is set only once upon boot, so, is unaffected by Linux wallclock time changes... or should be. it might not be Xenomai after all. Uhum. the bughunt safari tribe has decided to focus on class 'duh' problems and resolves to shut up until red hands are spotted. I would still put the check in the timer set_next_event callback, just in case... -- Gilles. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
[Xenomai] Fwd: Help regarding Benchmarking
We are Embedded system students who are writing a driver for a PCI-DIOT 48 card using RTDM on Xenomai.We plan to do some benchmarking with respect to : 1. response latency (to external events which will be serviced through interrupts) 2. jitter If you could provide us with some standard experiments that can be performed to help benchmark, we would be obliged Regards, Abhimanyu Varde Sivakiran Kodali ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] [Emc-developers] new RTOS status: Scheduler (?) lockup on ARM
Am 21.01.2013 um 20:10 schrieb Gilles Chanteperdrix: On 01/21/2013 02:32 PM, Michael Haberler wrote: Am 21.01.2013 um 12:56 schrieb Gilles Chanteperdrix: question: does a RTC time warp have any possible bearing on Xenomai operations? No, it should not, Xenomai uses its own clock, which is set only once upon boot, so, is unaffected by Linux wallclock time changes... or should be. it might not be Xenomai after all. Uhum. the bughunt safari tribe has decided to focus on class 'duh' problems and resolves to shut up until red hands are spotted. I would still put the check in the timer set_next_event callback, just in case... I assume Bas will give the postmortem shortly - he nailed the issue; the RTC boot timewarp makes for a lost DHCP lease midflight and NFS freezing, making it look like a kernel hang. relieved, - Michael ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
[Xenomai] Building xenomai with latest buildroot snapshot.
I was able to compile Xenomai under buildroot 2011.11 without too much trouble, however I'm now trying to do the same with the latest buildroot snapshot. Unfortunately it seems buildroot no longer has an easy option to select a kernel compatible with Xenomai. I looked in xenomai-2.6.1/ksrc/arch/x86/patches and there are three of them adeos-ipipe-2.6.37.6-x86-2.9-02.patch adeos-ipipe-2.6.38.8-x86-2.11-01.patch ipipe-core-3.2.21-x86-1.patch Can someone please explain what this ipipe-core thing is? Are these interchangeable (they are similar sizes)? Do I have to stick to 2.6.37.6 kernel to stand any chance of getting this working? kind regards, Biff. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Building xenomai with latest buildroot snapshot.
- Original Message - From: Gilles Chanteperdrix gilles.chanteperd...@xenomai.org On 01/21/2013 10:36 PM, bifferos wrote: I was able to compile Xenomai under buildroot 2011.11 without too much trouble, however I'm now trying to do the same with the latest buildroot snapshot. Unfortunately it seems buildroot no longer has an easy option to select a kernel compatible with Xenomai. I looked in xenomai-2.6.1/ksrc/arch/x86/patches and there are three of them adeos-ipipe-2.6.37.6-x86-2.9-02.patch adeos-ipipe-2.6.38.8-x86-2.11-01.patch ipipe-core-3.2.21-x86-1.patch Can someone please explain what this ipipe-core thing is? I am desperately looking for a mail from Philippe where he explained it, but can not find it back. Maybe he can give some explanations. Are these interchangeable (they are similar sizes)? Yes. OK, thanks, I will give 3.2.21 a go then. Do I have to stick to 2.6.37.6 kernel to stand any chance of getting this working? The newer versions should work, though I would recommend to wait for the next release which should happen in the next few days. Also note that I guess you are using Xenomai on the bifferboard, since I also guess the processor on this board does not have a tsc, it will be emulated using the PIT, which is slow, so, unless you can provide another hardware timer with a lower latency, which will work starting with the I-pipe core for Linux 3.4, you should turn off CONFIG_XENO_OPT_STATS to improve latencies. Thanks for the tip, actually I am trying to simply compile an ISO image to run under VirtualBox at the moment, so latencies are way down on my list. My notes are here: https://sites.google.com/site/bifferboard/Home/boards-with-1mb-flash/buildroot/xenomai It all seems like a bit of a hack, so my next task is to try to create a buildroot package to allow choosing the trivial-periodic demo and installing it from the Buildroot config menu. kind regards, Biff. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] GPIO Interrupts problem with RTDM
On Sunday 20 January 2013, Gilles Chanteperdrix wrote: On 01/20/2013 01:13 AM, Paul wrote: About the fact that interrupts are not detected : This may be a generic issue, which I thought was fixed, but may not be. Could you try the following patch? http://git.xenomai.org/?p=ipipe-gch.git;a=commit;h=c14c79d29fed822 675 60c7bf26d628ef4d39f5b7 Gilles: Looked at the patch and got as far as the changes in kernel/ipipe/timer.c:ipipe_timer_stop() - Correct me if I'm wrong, but this patch is based on a 3.5.7 parent without GENERIC_CLOCKEVENTS ? Yes, this patch is based on 3.5.7 and is used with and without GENERIC_CLOCKEVENTS. Short version: Updated my kernel to 3.5.7 and backported the Raspberry Pi changes from 3.6.11 and added in the ipipe support. Interrupts are not being recognised unless irq_set_irq_type() is called. Digging through the rtdm, nucleus, and ipipe code, at no point is irq_chip-irq_set_type() called - Also have a problem that none of the ipipe_pic_muter fields are set, so __ipipe_enable_irqdesc() friends do nothing. Noticed XN_ISR_EDGE equates to a falling edge trigger - irq_set_irq_type() allows for rising, level, or falling edge triggers. At some point, it may be advantageous to be able to select one of the three. Will continue digging and add a routine in bcm2708_gpio.c to set the ipipe_pic_muter fields in the morning. Regards, Paul. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Frustrating experience with Xenomai
Hi Willy, On 01/21/2013 06:43 PM, Willy Lambert wrote: Here is a first try. http://www.xenomai.org/index.php/Building_kernel Don't hesitate to comment/correct this. I will add some links later to : _ a good complete kernel building guide (if you have some please share) _ x86 configure hints wiki page. The end is a bit specific to Debian/Ubuntu distros. Is it a problem ? Should I rework this ? Nice write-up. I've done the same thing on the LinuxCNC website. Feel free to comment, fix, borrow, ignore http://wiki.linuxcnc.org/cgi-bin/wiki.pl?XenomaiKernel John ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
