Re: [Xenomai-core] rt_task_create and rt_task delete re-scheduling calling task
On 05/14/2012 09:55 AM, Roberto Bielli wrote: Hi, i saw in the documentation that rt_task_create and rt_task_delete should re-scheduling the calling task. rt_task_create may reschedule the calling task, only may, not should. And it happens in the obvious case: when creating a task with a higher priority than the current task. The reason why rt_task_delete may reschedule is documented: Native tasks implement a mechanism by which they are immune from deletion by other tasks while they run into a deemed safe section of code. This feature is used internally by the native skin in order to prevent tasks from being deleted in the middle of a critical section, without resorting to interrupt masking when the latter is not an option. For this reason, the caller of rt_task_delete() might be blocked and a rescheduling take place, waiting for the target task to exit such critical section. Xenomai online documentation may be found here: http://www.xenomai.org/documentation/xenomai-2.6/html/api/index.html And a local copy is installed when you run xenomai package make install. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] rt_task_create and rt_task delete re-scheduling calling task
On 05/14/2012 09:55 AM, Roberto Bielli wrote: P.S. the imx25 now it's perfect. Was only the reentrant interrupt. By the way, now that Linux runs all interrupt handlers with hardware irq disabled, this option is completely useless: it will prevent a low priority irq to interrupt a low priority irq while the high priority interrupt handler is running, but since that handler is already running with hardware interrupts off, this does not add anything. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] porting xenomai on imx25
On 04/19/2012 10:52 AM, Roberto Bielli wrote: Hi Gilles, i found the problem that disable interrupts when execute a task. My kernel for imx25 uses the properties CONFIG_MXC_IRQ_PRIOR in the .config. This properties enable reentrant interrupts so it uses the NIMASK(normal interrupt mask register ) register to disable interrupts with certain priority level. The interrupt of timer is disabled in that cases. i tried to disable this option in the kernel but i have other big problems with the task and so i have to do other tests before saying the conclusions. Do you know if xenomai doesn't work with reentrant interrupts ? Xenomai as it is will not work in that case, and this option is useless as all interrupts handlers are executed with hardware irqs disabled, so your best solution is to try and disable this option. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] porting xenomai on imx25
On 04/19/2012 11:01 AM, Roberto Bielli wrote: have you a .config for imx31 to give me so i can compare them? http://sisyphus.hd.free.fr/~gilles/config-mx31ads-2.6.33 This said, looking at the code, I do not understand how it can break irq delivery. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] IMX25 timer access patch
On 04/19/2012 12:02 PM, Michael Trimarchi wrote: Hi, I will send a proper patch. Is it possible to include in the ipipe-arm branch? Please use the public mailing lists. What exactly are you trying to fix ? What version of kernel ? The ipipe-arm kernels are compile-tested, so, the code as is is correct (except that maybe I did not compile-test imx25). If what you are trying to fix is compilation for non-vanilla kernels, then the answer is no, the ipipe-arm branches only support vanilla kernels. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] IMX25 timer access patch
On 04/19/2012 12:02 PM, Michael Trimarchi wrote: Hi, I will send a proper patch. Is it possible to include in the ipipe-arm branch? Michael Yes, OK. Please resend the patch to the xenomai-core, or adeos-main mailing list, I see ipipe-arm is broken since at least 2.6.33. It compiles but probably does not work. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] IMX25 timer access patch
On 04/19/2012 01:04 PM, Michael Trimarchi wrote: Hi On 04/19/2012 12:55 PM, Gilles Chanteperdrix wrote: On 04/19/2012 12:02 PM, Michael Trimarchi wrote: Hi, I will send a proper patch. Is it possible to include in the ipipe-arm branch? Michael Yes, OK. Please resend the patch to the xenomai-core, or adeos-main mailing list, I see ipipe-arm is broken since at least 2.6.33. It compiles but probably does not work. I will send the two patches for the imx25. Yes, and please provide an accurate commit log: the patch fixes more than imx25. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] porting xenomai on imx25
On 04/18/2012 10:44 AM, Roberto Bielli wrote: Hi Gilles, here find the answers. sorry for the delay. Il 13/04/2012 15:47, Gilles Chanteperdrix ha scritto: On 04/13/2012 10:44 AM, Roberto Bielli wrote: Hi Gilles, you don't feel like to repeat. I'm trying all the things that you told me and i will do all the missing test that you told me. So, what is the result of running your test with unpatched Linux, but with CONFIG_HIGH_RES_TIMERS enabled? the result is the same. With the base linux application and CONFIG_HIGH_RES_TIMERS all it's ok, instead with xenomai application the task with less priority halt the task with higher priority until it sleeps. I send you my .config file and the test with pthread base. You know as well as me that this description of the problem is inaccurate, what really happens is that the timer is programmed but does not tick. What you have to do now is try and understand what is the difference between the way xenomai and linux handle the timer to understand what cause it not to work in xenomai case. If I were you, to understand this difference, I would start by dumping all timer registers values at the time when the problem is detected, that is, before the timer is programmed again. But I am afraid I can not give you more help, ultimately you are the one which is doing the port to imx25, so you are on your own. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] porting xenomai on imx25
On 04/18/2012 12:28 PM, Roberto Bielli wrote: Hi Gilles, i try to give only another accurate information. i made another test: i write a xenomai driver for reading the timer and avic register and i see a strange behaviour. when there is the problem the interrupt is NOT masqueraded in avic but the timer has the interrupt not acked. Ah, that is good news, at least now we have a clue. Note that it could also mean that the timer has ticked, but the irq is not generated for another reason. I think you should dump all the timer registers, and see if anything is wrong by decoding their values with the datasheet. A quick test also, assuming that the write to the MX3_TSTAT regiter in gpt_irq_acknowledge may be posted, try rereading the register after writing it. After this i understand that now are my problems. Do you know somebody that can help me understanding the problem only for xenomai side? If you need someone's help, you need to give access to your board to that person or company. Because indirect debugging is really inefficient: look at how many mails I had to send you over how much time to get you to do what anybody with xenomai experience would have done in just a few hours. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PULL] rt-puts fix, mprotect testsuite
On 04/04/2012 02:56 PM, Jan Kiszka wrote: The following changes since commit 0ef2410a2c9cf7102dead861241bd2d9957e4433: Mask signals in rt_print:printer_loop() (2012-04-02 00:16:41 +0200) are available in the git repository at: git://git.xenomai.org/xenomai-jki.git for-upstream Jan Kiszka (3): Append missing newline to rt_[f]puts output testsuite: Add rt-print buffer flushes to native error paths Add regression test for mprotect on pinned memory Merged. Thanks. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PULL] rt-puts fix, mprotect testsuite
On 04/04/2012 02:56 PM, Jan Kiszka wrote: The following changes since commit 0ef2410a2c9cf7102dead861241bd2d9957e4433: Mask signals in rt_print:printer_loop() (2012-04-02 00:16:41 +0200) are available in the git repository at: git://git.xenomai.org/xenomai-jki.git for-upstream Jan Kiszka (3): Append missing newline to rt_[f]puts output Actually, only puts requires an additional newline, not fputs. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
On 04/12/2012 12:12 PM, Roberto Bielli wrote: Hi Gilles, i found in my trace the function 'xnthread_timeout_handler' that is called in the code where there is the problem. In xenomai there is a topic about that function. ( [Xenomai-core] [BUG?] stalled xeno domain http://www.opensubscriber.com/messages/xenomai-core@gna.org/39.html ) Do you think that can be a similar problem ? No. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] porting xenomai on imx25
On 04/12/2012 06:58 PM, Roberto Bielli wrote: Hi Gilles, you tell me that you are working on imx. Do you know if there is a working xenomai on imx (any kernel or imx version) ? I have tested Xenomai on imx31, imx51, imx53, imx6q. It works on these platforms. Now, what you are doing is in fact porting xenomai on imx25, nobody did that before you, and you are faced with a peculiarity of the timer on this platform. What you should do is: - try to reproduce the problem with an unpatched linux with CONFIG_HIGH_RES_TIMERS - or try and look at the timers registers value at the time when the bug happens to see what is going wrong. Also, the first thing to do when running xenomai on a new platform is to run the latency test. Have you run this test? I feel like I am starting to repeat myself, I do not know if I should continue trying and answering you. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
On 04/11/2012 08:59 AM, Roberto Bielli wrote: Hi Gilles, i try your workaround but nothing is changed. I make another test. I try to comment out all the content of mxc_mask_irq() but the result is the same. (the mxc_mask_irq is used also for acking interrupts but is not correct why it doesn't write in the processor manual) Do you know if there is a code over the mxc_mask_irq that disable the interrupts ? mxc_mask_irq disables the interrupt at interrupt controller level. Generally, you can not avoid to do that. Have you tried reproducing the problem with linux configured with CONFIG_HIGH_RES_TIMERS? -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
On 04/11/2012 08:59 AM, Roberto Bielli wrote: Hi Gilles, i try your workaround but nothing is changed. I make another test. I try to comment out all the content of mxc_mask_irq() but the result is the same. (the mxc_mask_irq is used also for acking interrupts but is not correct why it doesn't write in the processor manual) Do you know if there is a code over the mxc_mask_irq that disable the interrupts ? About interrupt gpio it should be a link with this behaviour ? ( i don't want gpio as interrupts ) No, I do not think it is possible. You do not get to decide whether you want gpio as interrupts or not, the design of the board you use does. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
On 04/10/2012 10:18 AM, Roberto Bielli wrote: Hi Gilles, i learned the ipipe trace that i send you but i don't unserstand why i have three timer reprogramming in few useconds. Can you explain me the behaviour ? Can you resend the trace and give us the time where this happens? Anyway, the timer function must work even if the timer has already been programmed, it is normal to reprogram the timer while it has been programmed for instance when adding or removing a timer. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
On 04/10/2012 10:43 AM, Roberto Bielli wrote: Hi Gilles, I don't find the end of last __ipipe_grab_irq in the trace that i send you. Is it correct ? Yes, because the timer interrupt reschedules and wakes up the periodic task. I had a look at the timer programming events, it is true that the timer ticks more often than it should. Generally, this is an indication that the timer frequency is not what xenomai believe it is. xenomai idea of the timer frequency is given by __ipipe_mach_ticks_per_jiffy. Anyway, this should not cause the timer not to tick, only to tick it more often. What you should do now is try and reproduce the same conditions under an unpatched linux to see if you get the same phenomenon. Did you have a look a the processor errata ? -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
On 04/10/2012 10:58 AM, Roberto Bielli wrote: Hi Gilles, i look at the processor errata but for the imx25 there are no errata elements on timer. I see that tsc uses the same timer. Does xenomai use the tsc for the next timer period ? If you look at the trace, you will see that with the timer@ event that the timer is supposedly programmed for the right time. For instance at -84748, the timer is programmed to tick at -83749, which is around 1000us later and is what we would expect. So, the tsc is out of the issue. The issue is the timer. For the third time I tell you, you should now try and reproduce the same issue with an unpatched linux. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
On 04/10/2012 10:58 AM, Roberto Bielli wrote: Hi Gilles, i look at the processor errata but for the imx25 there are no errata elements on timer. It is strange that you use linux 2.6.31 on imx25: linux 2.6.31 does not support imx25. The I-pipe support has not been written for imx25, so, it is entirely possible that you have to adapt it. See: http://www.xenomai.org/index.php/I-pipe:ArmPorting -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
On 04/10/2012 11:06 AM, Gilles Chanteperdrix wrote: On 04/10/2012 10:58 AM, Roberto Bielli wrote: Hi Gilles, i look at the processor errata but for the imx25 there are no errata elements on timer. It is strange that you use linux 2.6.31 on imx25: linux 2.6.31 does not support imx25. The I-pipe support has not been written for imx25, so, it is entirely possible that you have to adapt it. See: http://www.xenomai.org/index.php/I-pipe:ArmPorting Latest kernels support imx25, and imx25 works like an mx3, not an mx2, can you show me arch/arm/plat-mxc/time.c for your (undoubtedly) patched kernel? -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
On 04/10/2012 11:19 AM, Roberto Bielli wrote: Hi Gilles, the steps for supporting imx25 have been: 1. We buy a board with imx25 2. Our supplier made the porting of linux 2.6.31 freescale with imx25 3. we put a xenomai 2.5.6 and we have adapted for imx25. The only changes is this (because imx25 registers are identical to mx3 ): old: #define timer_is_v2()(cpu_is_mx3() || cpu_is_mx5()) new: #define timer_is_v2()(cpu_is_mx3() || cpu_is_mx25() || cpu_is_mx5()) Yes, but if you use the unchanged adeos patch, it uses if (cpu_is_mx3()) in tsc and timer code, whereas it should use if (timer_is_v2()), timer_is_v2 is not present in vanilla linux code. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
On 04/10/2012 11:21 AM, Roberto Bielli wrote: Hi Gilles, here is my time.c Looks fine, though I do not understand why you do not use timer_is_v2 instead of cpu_is_mx3 || cpu_is_mx25. I think the problem is elsewhere, and I suggest you check whether linux without xenomai has or has not the same issue. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
On 04/10/2012 11:21 AM, Roberto Bielli wrote:
Hi Gilles,
here is my time.c
Though you have not made all the changes I suggested. Here is the time.c
I would use.
--
Gilles.
/*
* linux/arch/arm/plat-mxc/time.c
*
* Copyright (C) 2000-2001 Deep Blue Solutions
* Copyright (C) 2002 Shane Nay (sh...@minirl.com)
* Copyright (C) 2006-2007 Pavel Pisa (pp...@pikron.com)
* Copyright (C) 2008 Juergen Beisert (ker...@pengutronix.de)
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
* MA 02110-1301, USA.
*/
#include linux/interrupt.h
#include linux/irq.h
#include linux/clockchips.h
#include linux/clk.h
#include mach/hardware.h
#include asm/mach/time.h
#include mach/common.h
/* defines common for all i.MX */
#define MXC_TCTL 0x00
#define MXC_TCTL_TEN (1 0)
#define MXC_TPRER 0x04
/* MX1, MX21, MX27 */
#define MX1_2_TCTL_CLK_PCLK1 (1 1)
#define MX1_2_TCTL_IRQEN (1 4)
#define MX1_2_TCTL_FRR (1 8)
#define MX1_2_TCMP 0x08
#define MX1_2_TCN 0x10
#define MX1_2_TSTAT 0x14
/* MX21, MX27 */
#define MX2_TSTAT_CAPT (1 1)
#define MX2_TSTAT_COMP (1 0)
/* MX31, MX35, MX25 */
#define MX3_TCTL_WAITEN (1 3)
#define MX3_TCTL_CLK_IPG (1 6)
#define MX3_TCTL_CLK_PER (2 6)
#define MX3_TCTL_FRR (1 9)
#define MX3_IR 0x0c
#define MX3_TSTAT 0x08
#define MX3_TSTAT_OF1 (1 0)
#define MX3_TCN 0x24
#define MX3_TCMP 0x10
#ifdef CONFIG_IPIPE
#ifdef CONFIG_NO_IDLE_HZ
#error dynamic tick timer not yet supported with IPIPE
#endif /* CONFIG_NO_IDLE_HZ */
int __ipipe_mach_timerint;
EXPORT_SYMBOL(__ipipe_mach_timerint);
int __ipipe_mach_timerstolen = 0;
EXPORT_SYMBOL(__ipipe_mach_timerstolen);
unsigned int __ipipe_mach_ticks_per_jiffy = LATCH;
EXPORT_SYMBOL(__ipipe_mach_ticks_per_jiffy);
static int mxc_timer_initialized;
static unsigned mxc_min_delay;
union tsc_reg {
#ifdef __BIG_ENDIAN
struct {
unsigned long high;
unsigned long low;
};
#else /* __LITTLE_ENDIAN */
struct {
unsigned long low;
unsigned long high;
};
#endif /* __LITTLE_ENDIAN */
unsigned long long full;
};
#ifdef CONFIG_SMP
static union tsc_reg tsc[NR_CPUS];
void __ipipe_mach_get_tscinfo(struct __ipipe_tscinfo *info)
{
info-type = IPIPE_TSC_TYPE_NONE;
}
#else /* !CONFIG_SMP */
static union tsc_reg *tsc;
void __ipipe_mach_get_tscinfo(struct __ipipe_tscinfo *info)
{
info-type = IPIPE_TSC_TYPE_FREERUNNING;
if (cpu_is_mx1()) {
#ifdef CONFIG_ARCH_MX1
info-u.fr.counter = (unsigned *) (TIM1_BASE_ADDR + MX1_2_TCN);
#endif
} else if (cpu_is_mx2()) {
#ifdef CONFIG_ARCH_MX2
info-u.fr.counter = (unsigned *) (GPT1_BASE_ADDR + MX1_2_TCN);
#endif
} else if (cpu_is_mx3() || cpu_is_mx25() ) {
#if defined CONFIG_ARCH_MX3 || defined CONFIG_ARCH_MX25
info-u.fr.counter = (unsigned *) (GPT1_BASE_ADDR + MX3_TCN);
#endif
}
info-u.fr.mask = 0x;
info-u.fr.tsc = tsc-full;
}
#endif /* !CONFIG_SMP */
static void ipipe_mach_update_tsc(void);
#endif /* CONFIG_IPIPE */
#define timer_is_v2() (cpu_is_mx3() || cpu_is_mx25() || cpu_is_mx5())
static struct clock_event_device clockevent_mxc;
static enum clock_event_mode clockevent_mode = CLOCK_EVT_MODE_UNUSED;
static void __iomem *timer_base;
static inline void gpt_irq_disable(void)
{
unsigned int tmp;
if (timer_is_v2())
__raw_writel(0, timer_base + MX3_IR);
else {
tmp = __raw_readl(timer_base + MXC_TCTL);
__raw_writel(tmp ~MX1_2_TCTL_IRQEN, timer_base + MXC_TCTL);
}
}
static inline void gpt_irq_enable(void)
{
if (timer_is_v2())
__raw_writel(10, timer_base + MX3_IR);
else {
__raw_writel(__raw_readl(timer_base + MXC_TCTL) | MX1_2_TCTL_IRQEN,
timer_base + MXC_TCTL);
}
}
static void gpt_irq_acknowledge(void)
{
if (!timer_is_v2()) {
if (cpu_is_mx1())
__raw_writel(0, timer_base + MX1_2_TSTAT);
else
__raw_writel(MX2_TSTAT_CAPT | MX2_TSTAT_COMP, timer_base + MX1_2_TSTAT);
} else
__raw_writel(MX3_TSTAT_OF1, timer_base + MX3_TSTAT);
}
static cycle_t timer_v1_get_cycles(struct clocksource *cs)
{
return __raw_readl(timer_base + MX1_2_TCN);
}
static cycle_t timer_v2_get_cycles(struct clocksource *cs)
{
return __raw_readl(timer_base + MX3_TCN);
}
static struct clocksource clocksource_mxc = {
.name = mxc_timer1,
.rating = 200,
.read = timer_v1_get_cycles,
.mask = CLOCKSOURCE_MASK(32),
.shift = 20,
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
};
Re: [Xenomai-core] preemptive doesn't work
On 04/10/2012 12:39 PM, Roberto Bielli wrote:
Hi Gilles,
i tried your code but th behavior is the same.
Then i tried a linux base app and works correctly.
The tsc physical address passed to user-space looks wrong.
void __ipipe_mach_get_tscinfo(struct __ipipe_tscinfo *info)
{
info-type = IPIPE_TSC_TYPE_FREERUNNING;
if (cpu_is_mx1()) {
#ifdef CONFIG_ARCH_MX1
info-u.fr.counter = (unsigned *) (TIM1_BASE_ADDR + MX1_2_TCN);
#endif
} else if (cpu_is_mx2()) {
#ifdef CONFIG_ARCH_MX2
info-u.fr.counter = (unsigned *) (GPT1_BASE_ADDR + MX1_2_TCN);
#endif
} else if (cpu_is_mx3() || cpu_is_mx25() ) {
#if defined CONFIG_ARCH_MX3 || defined CONFIG_ARCH_MX25
info-u.fr.counter = (unsigned *) (GPT1_BASE_ADDR + MX3_TCN);
#endif
}
info-u.fr.mask = 0x;
info-u.fr.tsc = tsc-full;
}
Here cpu_is_mx2() will return true, and we will not go to cpu_is_mx25().
Are you using the tsc in user-space?
If you are passing --enable-arm-mach=mx2 to xenomai configure
script, you are using the tsc in user-space, and it is a wonder
how it works.
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
On 04/10/2012 12:39 PM, Roberto Bielli wrote: Hi Gilles, i tried your code but th behavior is the same. Then i tried a linux base app and works correctly. In the exact same conditions? With the crunching task running with SCHED_FIFO, priority 1, and the periodic task running with SCHED_FIFO, priority 99, and the linux real-time throttling disabled? -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
On 04/10/2012 02:33 PM, Roberto Bielli wrote: Il 10/04/2012 13:49, Gilles Chanteperdrix ha scritto: On 04/10/2012 12:39 PM, Roberto Bielli wrote: Hi Gilles, i tried your code but th behavior is the same. Then i tried a linux base app and works correctly. In the exact same conditions? With the crunching task running with SCHED_FIFO, priority 1, and the periodic task running with SCHED_FIFO, priority 99, and the linux real-time throttling disabled? Yes, and i see that every LATCH ( about ~10ms ) period the task with higher priority is wakeup. So a task with lower priority is interrupted by timer interrupt and reschedule the task with higher priority. You need CONFIG_HIGH_RES_TIMERS to be in the same case as xenomai. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
On 04/10/2012 02:58 PM, Roberto Bielli wrote: In the xenomai example the task periodic is 2ms not 200us. ( rt_task_sleep( 2ms 000us 000ns ) ); sorry, I misred. And the 10ms is because the default system time period of the timer without xenomai is ~10ms. So a process that execute in linux base can be re-scheduled only when the timer generate an interrupt , the task makes I/O, or sleeps. That is only if you do not use CONFIG_HIGH_RES_TIMERS, in which case you are not in the same configuration as xenomai, and the test does not mean anything. Il 10/04/2012 14:36, Gilles Chanteperdrix ha scritto: On 04/10/2012 02:33 PM, Roberto Bielli wrote: Il 10/04/2012 13:49, Gilles Chanteperdrix ha scritto: On 04/10/2012 12:39 PM, Roberto Bielli wrote: Hi Gilles, i tried your code but th behavior is the same. Then i tried a linux base app and works correctly. In the exact same conditions? With the crunching task running with SCHED_FIFO, priority 1, and the periodic task running with SCHED_FIFO, priority 99, and the linux real-time throttling disabled? Yes, and i see that every LATCH ( about ~10ms ) period the task with higher priority is wakeup. In the example you sent the periodic task was running with a 200us period, not 10ms. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
On 04/06/2012 06:59 PM, Roberto Bielli wrote: Hi Gilles, i made all your modifies and re-read all corect register but the problem is the same. Ok. What I would do at this point is check whether linux has the same issue. You can also check the processor errata to see if there is no issue with the timer. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
On 04/06/2012 05:35 PM, Roberto Bielli wrote: Hi Gilles, excuse me, but i don't understand why i have to read the register after a write. In the imx processor manual i didn't find that behaviour. Read again what I wrote: I do not say you have to, I say you may want to, it is just a trick you may want to try, which I have already seen solving this kind of issues. Besides, that is what the linux clockevent driver does. I would first try reading the status register in the __ipipe_mach_acktimer , and if it does not fix the issue, try the re-read trick. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
On 03/07/2012 07:13 PM, Roberto Bielli wrote: Hi Gilles, this is the trace and the test. It seems that '__ipipe_dispatch_event' last about ~84 milliseconds with disable interrupts. Thanks a lot for your time. Hi Roberto, any news about this issue? Regards. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
On 04/04/2012 11:29 AM, Roberto Bielli wrote:
Hi Gilles,
i have always this big problem but the timer and the avic are programmed
correctly.
There is something else but i don't know what.
In this moment i'm doing another work but soon i want to debug that error.
It is undoubtly a timer ack/program issue. There is no other problem,
the trace is quite clear: the timer is programmed, should tick, but
does not.
I had a look at the imx code again for other reasons, what may be also
missing in __ipipe_mach_acktimer function is a read of the timer status
register. As in:
void __ipipe_mach_acktimer(void)
{
uint32_t tstat;
if (timer_is_v2())
tstat = __raw_readl(timer_base + V2_TSTAT);
else
tstat = __raw_readl(timer_base + MX1_2_TSTAT);
gpt_irq_acknowledge();
}
And put that piece of code in mxc_timer_interrupt in the #ifndef
CONFIG_IPIPE section.
You may also want to issue a register read after programming the
compare register. As in:
void __ipipe_mach_set_dec(unsigned long delay)
{
if (delay mxc_min_delay) {
unsigned long tcmp;
if (!timer_is_v2()) {
tcmp = __raw_readl(timer_base + MX1_2_TCN) + delay;
__raw_writel(tcmp, timer_base + MX1_2_TCMP);
__raw_readl(timer_base + MX1_2_TCN);
} else {
tcmp = __raw_readl(timer_base + V2_TCN) + delay;
__raw_writel(tcmp, timer_base + V2_TCMP);
__raw_readl(timer_base + V2_TCN);
}
} else
ipipe_trigger_irq(__ipipe_mach_timerint);
}
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PULL] rt-puts fix, mprotect testsuite
On 04/04/2012 02:56 PM, Jan Kiszka wrote: The following changes since commit 0ef2410a2c9cf7102dead861241bd2d9957e4433: Mask signals in rt_print:printer_loop() (2012-04-02 00:16:41 +0200) are available in the git repository at: git://git.xenomai.org/xenomai-jki.git for-upstream Jan Kiszka (3): Append missing newline to rt_[f]puts output testsuite: Add rt-print buffer flushes to native error paths As I said, I do not agree with calling rt_print_flush_buffers outside of xenomai libs. If you want to avoid the issue you should use rt_printf only. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PULL] rt-puts fix, mprotect testsuite
On 04/04/2012 03:12 PM, Jan Kiszka wrote: On 2012-04-04 15:02, Gilles Chanteperdrix wrote: On 04/04/2012 02:56 PM, Jan Kiszka wrote: The following changes since commit 0ef2410a2c9cf7102dead861241bd2d9957e4433: Mask signals in rt_print:printer_loop() (2012-04-02 00:16:41 +0200) are available in the git repository at: git://git.xenomai.org/xenomai-jki.git for-upstream Jan Kiszka (3): Append missing newline to rt_[f]puts output testsuite: Add rt-print buffer flushes to native error paths As I said, I do not agree with calling rt_print_flush_buffers outside of xenomai libs. rt_print_flush_buffers is a Xenomai API function that we export for quite a while now. The rt_* functions are about explicit control when what is invoked, both in the native skin and in what used to be rtdk. Also, you can't avoid this function when you interact with libraries that are unwrapped. That said, I can fix that minor issue in leaks differently if you insist. I added rt_print_flush_buffers for xenomai 2.6.0, in order to implement systematic wrapping of printf by the posix skin, my intent was not to really export it. From my point of view, having to call this flush function all over the place reveals a problem in the application. If you use always printf or always rt_printf, you do not need to call this function. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai-git] Jan Kiszka : Add regression test for mprotect on pinned memory
On 04/02/2012 04:09 PM, GIT version control wrote:
Module: xenomai-jki
Branch: for-upstream
Commit: 410e90d085d21dc913f8724efafe6ae75bd3c952
URL:
http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=410e90d085d21dc913f8724efafe6ae75bd3c952
Author: Jan Kiszka jan.kis...@siemens.com
Date: Fri Mar 30 18:06:27 2012 +0200
Add regression test for mprotect on pinned memory
This tests both the original issue of mprotect reintroducing COW pages
to Xenomai processes as well as the recently fixed zero page corruption.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
+static void check_inner(const char *fn, int line, const char *msg,
+ int status, int expected)
+{
+ if (status == expected)
+ return;
+
+ rt_task_set_mode(T_WARNSW, 0, NULL);
+ rt_print_flush_buffers();
(...)
+static void check_value_inner(const char *fn, int line, const char *msg,
+ int value, int expected)
+{
+ if (value == expected)
+ return;
+
+ rt_task_set_mode(T_WARNSW, 0, NULL);
+ rt_print_flush_buffers();
(...)
+void sigdebug_handler(int sig, siginfo_t *si, void *context)
+{
+ unsigned int reason = si-si_value.sival_int;
+
+ rt_print_flush_buffers();
(...)
+
+ rt_task_set_mode(T_WARNSW, 0, NULL);
+ rt_print_flush_buffers();
Maybe you could use posix skin's printf instead of putting calls to
rt_print_flush_buffers all over the place? I did not mean for this call
to be exported, I only added it for internal use by the posix skin.
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Mask signals in rt_print:printer_loop()
On 03/28/2012 07:39 AM, Paul Janzen wrote: common/rt_print: Use sigfillset to actually mask all signals for logging thread. Fixes commit a6dceeb9. Thanks, but patch fails to apply on xenomai 2.6 master branch. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] xenomai-forge: round-robin scheduling in pSOS skin
On 03/15/2012 08:49 PM, Ronny Meeus wrote:
On Thu, Mar 8, 2012 at 3:30 PM, Ronny Meeus ronny.me...@gmail.com wrote:
Hello
I'm are using the xenomai-forge pSOS skin (Mercury).
My application is running on a P4040 (Freescale PPC with 4 cores).
Some code snippets are put in this mail but the complete testcode is
also attached.
I have a test task that just consumes the CPU:
int run_test = 1;
static void perform_work(u_long counter,u_long b,u_long c,u_long d)
{
int i;
while (run_test) {
for (i=0;i10;i++);
(*(unsigned long*)counter)++;
}
while (1) tm_wkafter(1000);
}
If I create 2 instances of this task with the T_SLICE option set:
t_create(WORK,10,0,0,0,tid);
t_start(tid,T_TSLICE, perform_work, args);
I see that only 1 task is consuming CPU.
# taskset 1 ./roundrobin.exe
#.543| [main] SCHED_RT priorities = [1 .. 99]
.656| [main] SCHED_RT.99 reserved for IRQ emulation
.692| [main] SCHED_RT.98 reserved for scheduler-lock emulation
0 - 6602
1 - 0
If I adapt the code so that I call in my init the threadobj_start_rr
function, I see that the load is equally distributed over the 2
threads:
# taskset 1 ./roundrobin.exe
#.557| [main] SCHED_RT priorities = [1 .. 99]
.672| [main] SCHED_RT.99 reserved for IRQ emulation
.708| [main] SCHED_RT.98 reserved for scheduler-lock emulation
0 - 3290
1 - 3291
Here are the questions:
- why is the threadobj_start_rr function not called from the context
of the init of the psos layer.
- why is the roundrobin implemented in this way? If the tasks would be
mapped on the SCHED_RR instead of the SCHED_FF the Linux scheduler
would take care of this.
On the other hand, once the threadobj_start_rr function is called from
my init, and I create the tasks in T_NOTSLICE mode, the time-slicing
is still done.
Thanks.
---
Ronny
Any comments on this?
I am afraid you will have to wait for Philippe to have time to answer
you. I am a bit ignorant about the psos API, but most importantly
completely ignorant of the mercury. I am working on forge, but mostly
with cobalt.
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
On 03/07/2012 07:13 PM, Roberto Bielli wrote: Hi Gilles, this is the trace and the test. It seems that '__ipipe_dispatch_event' last about ~84 milliseconds with disable interrupts. Sorry, I somehow missed this post. I am afraid you are mis-reading the trace. The time spent in user-space gets accounted to __ipipe_dispatch_event, because this is the last instrumented function called before the return to user-space. Interrupts are disabled at this point, this is perfectly normal, but they are probably re-enabled when returning to user-space. What is more problematic, however, is that the timer interrupt did not tick at -83749 like it is supposed to. If it had ticked and the interrupt had been disabled in user-space, you would have taken the interrupt at -35, when __ipipe_syscall_root gets called with interrupts on. So, now, you have to understand why the timer interrupt did not tick. I suggest, when the problem happens, you look at: * the interrupt controller register, to see if the timer interrupt is still masked, if it is masked, then try first commenting out the snippet in arch/arm/plat-mxc/avic.c which declares mxc_mask_irq as the irq_mask_ack callback * the timer registers, to see if the timer was programmed correctly, and is still ticking when the issue happens. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
On 03/13/2012 12:44 PM, Gilles Chanteperdrix wrote: On 03/07/2012 07:13 PM, Roberto Bielli wrote: Hi Gilles, this is the trace and the test. It seems that '__ipipe_dispatch_event' last about ~84 milliseconds with disable interrupts. Sorry, I somehow missed this post. I am afraid you are mis-reading the trace. The time spent in user-space gets accounted to __ipipe_dispatch_event, because this is the last instrumented function called before the return to user-space. Interrupts are disabled at this point, this is perfectly normal, but they are probably re-enabled when returning to user-space. What is more problematic, however, is that the timer interrupt did not tick at -83749 like it is supposed to. If it had ticked and the interrupt had been disabled in user-space, you would have taken the interrupt at -35, when __ipipe_syscall_root gets called with interrupts on. So, now, you have to understand why the timer interrupt did not tick. I suggest, when the problem happens, you look at: * the interrupt controller register, to see if the timer interrupt is still masked, if it is masked, then try first commenting out the snippet in arch/arm/plat-mxc/avic.c which declares mxc_mask_irq as the irq_mask_ack callback * the timer registers, to see if the timer was programmed correctly, and is still ticking when the issue happens. You may also want, in __ipipe_mach_set_dec, to re-read the comparator value after writing it. Sometimes, such things are needed for the write to register to be really taken into account. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
On 03/07/2012 01:59 PM, Roberto Bielli wrote: Hi Gilles, we are sure that when a task execute NO INTERRUPTS arrives in interrupt service routine in assembler in the kernel, until it sleeps. It's not a problem of secondary mode. Show me the trace and I will believe you (approximately fourth time I ask). -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
On 03/06/2012 08:55 AM, Roberto Bielli wrote: Hi, it seems that i have a big problem with preemption. (kernel 2.6.31, arm freescale imx25, xenomai 2.5.6 ) I send a simple application that doesn't work. The task with name 'task2ms' has higher priority than 'taskPrintf', but 'taskPrintf' stop the task 'task2ms' until sleeps. I think i have a problem with ipipe porting. Any idea ? Please try getting a trace with the I-pipe tracer. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
On 03/06/2012 02:00 PM, Roberto Bielli wrote: Hi Gilles, here is the new trace. There is nothing to see on that trace. Please increase the number of trace points, and trigger a trace when you detect a problem., the number of trace points should be sufficient to get the timer programmation which happens before the problem. Also, did you try T_WANRSW ? Please disable the configuration of you mail server which asks me to send a receipt to each every mail you send me. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
On 03/06/2012 04:14 PM, Roberto Bielli wrote: Hi Gilles, i changed the min value of the '__ipipe_mach_set_dec' but the situation is the same. I see with the scope that the task with less priority is not interrupted. In the trace you sent, we clearly saw that it was interrupted by a timer interrupt. It's difficult to see with the ipipe trace the problem so i put the xenomai trace in the application with |xntrace_user_start|/|xntrace_user_stop|. Is the log of xenomai in the same place (/proc/ipipe/trace/max ) of ipipe ? See the latency test for an example of usage of the I-pipe tracer in user-space. When using latency -f the trace is available in /proc/ipipe/trace/frozen. What about T_WARNSW (it is the third time I ask). Also, it would be nice if you could try a more recent version of Xenomai and of the I-pipe patch, say 2.6.0 with the I-pipe patch for 2.6.38. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
On 03/06/2012 04:35 PM, Roberto Bielli wrote: Hi Gilles, about T_WARNSW i see in the /proc/xenomai/stat that my task hasn't change mode (the value of MSW is 0 ) so, it hasn't changed in secondary mode. Or maybe it started in secondary mode and never switched mode? -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Xenomai server down
Hi, xenomai.org server will be down for maintenance during the week-end. Regards. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] high duration of __ipipe_handle_irq
On 03/01/2012 07:03 PM, Roberto Bielli wrote: Hi, i have this problem with xenomai ( 2.5.6 - arm freescale imx25 ): I have a xenomai application that uses more rt_tasks, and i have a strange behaviour. When i run my application the period of *__ipipe_handle_irq* is very long ( ~3ms in some cases ) in the moment that come the *__ipipe_mach_timerint *interrupt and so the other interrupts are very late. Do you know something about this ? I am sorry, but I do not understand your mail. __ipiep_handle_irq is not periodic and this sentence: When i run my application the period of *__ipipe_handle_irq* is very long ( ~3ms in some cases ) in the moment that come the *__ipipe_mach_timerint *interrupt and so the other is not understandable. Please try to describe your problem more clearly, or better, use the I-pipe tracer and record a trace of the problem, and post the relevant part of the trace here. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Built-in libxenomai dependency
On 02/07/2012 05:36 PM, Jan Kiszka wrote: On 2012-02-07 17:28, Gilles Chanteperdrix wrote: This causes a -L/usr/lib to be added on the link-edit command line, which causes the link to fail by finding /usr/lib/libpthread.so instead of the cross-compiler one, and fail. How does libxenomai.la look like? Is it different from a native build? Hmm, there must be some valid way to express library dependencies inside you package. I would say it looks like a famous libtool bug all buildroot, ptxdist and the like tools work around. So, I would tend to give up on this issue, given that it fixes an issue not all that critical. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] Port to AT91SAM9G45
On 02/07/2012 02:01 PM, Gregory CLEMENT wrote: Hello, I've done the port for AT91SAM9G45 on a AT91SAM9M10G45-EK board. The following patch have to be applied on top of the adeos-ipipe-2.6.38.8-arm-1.18-04.patch patch. I also ran latency test under heavy stress using: - hackbench to stress the scheduler - netcat to stress the Ethernet interface and generate a lot of interrupts - ls and dd( reading a /dev/mtdblock and writing on a tmpfs) for global stress I join the results I had after running each latency test during 10 hours. If the results I get seem the correct could you apply this patch in Xenomai? Should I also submit this patch to adeos project? We will merge this patch in the adeos patch, yes. Thanks. Note that xenomai-2.6.0 provides a dohell command in order to generate some load, and a xeno-test script which runs latency under dohell load. Are the results obtained with or without the FCSE option enabled? -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Only export required CFLAGS via xeno-config
On 02/03/2012 03:50 PM, Jan Kiszka wrote: -Werror-implicit-function-declaration is not compatible with C++, and also decisions about -Wall and -pipe should be left to the application. Signed-off-by: Jan Kiszka jan.kis...@siemens.com Had to revert this patch, it causes a build failure when cross-compiling (for ARM, I do not know if it matters). -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Built-in libxenomai dependency
On 02/01/2012 09:21 PM, Gilles Chanteperdrix wrote: On 02/01/2012 04:50 PM, Jan Kiszka wrote: On 2012-02-01 16:38, Gilles Chanteperdrix wrote: On 02/01/2012 04:25 PM, Jan Kiszka wrote: On 2012-02-01 16:17, Gilles Chanteperdrix wrote: On 02/01/2012 03:37 PM, Jan Kiszka wrote: Hi, don't remember anymore: Is there any subtle reason that prevent a change like diff --git a/src/skins/native/Makefile.am b/src/skins/native/Makefile.am index 39eaaed..4cc8859 100644 --- a/src/skins/native/Makefile.am +++ b/src/skins/native/Makefile.am @@ -22,6 +22,9 @@ libnative_la_SOURCES = \ wrappers.c \ wrappers.h +libnative_la_LIBADD = \ +../common/libxenomai.la + libnative_la_CPPFLAGS = \ @XENO_USER_CFLAGS@ \ -I$(top_srcdir)/include diff --git a/src/skins/rtdm/Makefile.am b/src/skins/rtdm/Makefile.am index 8ad74be..2dc0a90 100644 --- a/src/skins/rtdm/Makefile.am +++ b/src/skins/rtdm/Makefile.am @@ -8,6 +8,9 @@ librtdm_la_SOURCES = \ core.c \ init.c +librtdm_la_LIBADD = \ +../common/libxenomai.la + librtdm_la_CPPFLAGS = \ @XENO_USER_CFLAGS@ \ -I$(top_srcdir)/include diff --git a/src/testsuite/latency/Makefile.am b/src/testsuite/latency/Makefile.am index c772c26..6534df5 100644 --- a/src/testsuite/latency/Makefile.am +++ b/src/testsuite/latency/Makefile.am @@ -14,5 +14,4 @@ latency_LDFLAGS = @XENO_USER_LDFLAGS@ latency_LDADD = \ ../../skins/native/libnative.la \ ../../skins/rtdm/librtdm.la \ -../../skins/common/libxenomai.la \ -lpthread -lm i.e. that we let the skin libraries depend on libxenomai and then remove the explicit dependency from our binaries and the xeno-config output? Is there some ordering issue again (we have -lskin before -lxenomai in the ldflags). If possible, this would allow for things like dlopen(libnative.so). It allows xeno-config result to work both with dynamic and static libraries. Static libraries have no dependency system, so, when linking a program whith libnative.a for instance, without libtool, you still have to link it with libxenomai.a. OK, part two could stay, but the dependencies should still be added to the skin libs - if possible. How come you can not dlopen libnative.so, dlopening libxenomai.so before does not work? Dependencies of libnative on libxenomai are not resolved when you open the former even if the latter is already loaded. Maybe you can do this by pulling in all required symbols one by one manually, haven't tried yet. But that would at least be unhandy. What about RTLD_GLOBAL ? Was possibly the reason, need to check back. Still, what prevents stating the existing dependency of libskin on libxenomai? The dance above would than be obsolete. The change is merged. I took the chance to check that static build still built. Unfortunately this change also causes a build failure when cross-compiling for ARM, so, change reverted, too. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Built-in libxenomai dependency
On 02/07/2012 05:22 PM, Jan Kiszka wrote: On 2012-02-07 17:19, Gilles Chanteperdrix wrote: On 02/01/2012 09:21 PM, Gilles Chanteperdrix wrote: On 02/01/2012 04:50 PM, Jan Kiszka wrote: On 2012-02-01 16:38, Gilles Chanteperdrix wrote: On 02/01/2012 04:25 PM, Jan Kiszka wrote: On 2012-02-01 16:17, Gilles Chanteperdrix wrote: On 02/01/2012 03:37 PM, Jan Kiszka wrote: Hi, don't remember anymore: Is there any subtle reason that prevent a change like diff --git a/src/skins/native/Makefile.am b/src/skins/native/Makefile.am index 39eaaed..4cc8859 100644 --- a/src/skins/native/Makefile.am +++ b/src/skins/native/Makefile.am @@ -22,6 +22,9 @@ libnative_la_SOURCES = \ wrappers.c \ wrappers.h +libnative_la_LIBADD = \ + ../common/libxenomai.la + libnative_la_CPPFLAGS = \ @XENO_USER_CFLAGS@ \ -I$(top_srcdir)/include diff --git a/src/skins/rtdm/Makefile.am b/src/skins/rtdm/Makefile.am index 8ad74be..2dc0a90 100644 --- a/src/skins/rtdm/Makefile.am +++ b/src/skins/rtdm/Makefile.am @@ -8,6 +8,9 @@ librtdm_la_SOURCES = \ core.c \ init.c +librtdm_la_LIBADD = \ + ../common/libxenomai.la + librtdm_la_CPPFLAGS = \ @XENO_USER_CFLAGS@ \ -I$(top_srcdir)/include diff --git a/src/testsuite/latency/Makefile.am b/src/testsuite/latency/Makefile.am index c772c26..6534df5 100644 --- a/src/testsuite/latency/Makefile.am +++ b/src/testsuite/latency/Makefile.am @@ -14,5 +14,4 @@ latency_LDFLAGS = @XENO_USER_LDFLAGS@ latency_LDADD = \ ../../skins/native/libnative.la \ ../../skins/rtdm/librtdm.la \ - ../../skins/common/libxenomai.la \ -lpthread -lm i.e. that we let the skin libraries depend on libxenomai and then remove the explicit dependency from our binaries and the xeno-config output? Is there some ordering issue again (we have -lskin before -lxenomai in the ldflags). If possible, this would allow for things like dlopen(libnative.so). It allows xeno-config result to work both with dynamic and static libraries. Static libraries have no dependency system, so, when linking a program whith libnative.a for instance, without libtool, you still have to link it with libxenomai.a. OK, part two could stay, but the dependencies should still be added to the skin libs - if possible. How come you can not dlopen libnative.so, dlopening libxenomai.so before does not work? Dependencies of libnative on libxenomai are not resolved when you open the former even if the latter is already loaded. Maybe you can do this by pulling in all required symbols one by one manually, haven't tried yet. But that would at least be unhandy. What about RTLD_GLOBAL ? Was possibly the reason, need to check back. Still, what prevents stating the existing dependency of libskin on libxenomai? The dance above would than be obsolete. The change is merged. I took the chance to check that static build still built. Unfortunately this change also causes a build failure when cross-compiling for ARM, so, change reverted, too. Indeed unfortunate. Any pointers to logs? This causes a -L/usr/lib to be added on the link-edit command line, which causes the link to fail by finding /usr/lib/libpthread.so instead of the cross-compiler one, and fail. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Only export required CFLAGS via xeno-config
On 02/03/2012 03:50 PM, Jan Kiszka wrote: -Werror-implicit-function-declaration is not compatible with C++, and also decisions about -Wall and -pipe should be left to the application. Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- configure.in | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/configure.in b/configure.in index b2563ee..2185925 100644 --- a/configure.in +++ b/configure.in @@ -448,13 +448,13 @@ else fi AC_MSG_RESULT([done]) -dnl Common CFLAGS and LDFLAGS -XENO_USER_CFLAGS=-D_GNU_SOURCE -D_REENTRANT -Wall -Werror-implicit-function-declaration -pipe -XENO_USER_LDFLAGS= +dnl Exported CFLAGS and LDFLAGS, shared with internal flags +XENO_USER_APP_CFLAGS=-D_GNU_SOURCE -D_REENTRANT +XENO_USER_APP_LDFLAGS= -dnl Exported CFLAGS and LDFLAGS, may be enhanced per-arch below -XENO_USER_APP_CFLAGS=$XENO_USER_CFLAGS -XENO_USER_APP_LDFLAGS=$XENO_USER_LDFLAGS +dnl Internal CFLAGS and LDFLAGS, may be enhanced per-arch below +XENO_USER_CFLAGS=$XENO_USER_CFLAGS -Wall -Werror-implicit-function-declaration -pipe +XENO_USER_LDFLAGS=$XENO_USER_APP_LDFLAGS We do not build C++ code, so I see no problem with using flags incompatible with C++, and customize the flags according to our preferences. Now, the flags returned by xeno-config are another issue, if this is what you want to change, please do not change the flags used to compile xenomai globally. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Only export required CFLAGS via xeno-config
On 02/03/2012 04:22 PM, Gilles Chanteperdrix wrote: On 02/03/2012 03:50 PM, Jan Kiszka wrote: -Werror-implicit-function-declaration is not compatible with C++, and also decisions about -Wall and -pipe should be left to the application. Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- configure.in | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/configure.in b/configure.in index b2563ee..2185925 100644 --- a/configure.in +++ b/configure.in @@ -448,13 +448,13 @@ else fi AC_MSG_RESULT([done]) -dnl Common CFLAGS and LDFLAGS -XENO_USER_CFLAGS=-D_GNU_SOURCE -D_REENTRANT -Wall -Werror-implicit-function-declaration -pipe -XENO_USER_LDFLAGS= +dnl Exported CFLAGS and LDFLAGS, shared with internal flags +XENO_USER_APP_CFLAGS=-D_GNU_SOURCE -D_REENTRANT +XENO_USER_APP_LDFLAGS= -dnl Exported CFLAGS and LDFLAGS, may be enhanced per-arch below -XENO_USER_APP_CFLAGS=$XENO_USER_CFLAGS -XENO_USER_APP_LDFLAGS=$XENO_USER_LDFLAGS +dnl Internal CFLAGS and LDFLAGS, may be enhanced per-arch below +XENO_USER_CFLAGS=$XENO_USER_CFLAGS -Wall -Werror-implicit-function-declaration -pipe +XENO_USER_LDFLAGS=$XENO_USER_APP_LDFLAGS We do not build C++ code, so I see no problem with using flags incompatible with C++, and customize the flags according to our preferences. Now, the flags returned by xeno-config are another issue, if this is what you want to change, please do not change the flags used to compile xenomai globally. Which is exactly what your patch is doing, sorry for the noise, the patch looks fine. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Built-in libxenomai dependency
On 02/01/2012 03:37 PM, Jan Kiszka wrote: Hi, don't remember anymore: Is there any subtle reason that prevent a change like diff --git a/src/skins/native/Makefile.am b/src/skins/native/Makefile.am index 39eaaed..4cc8859 100644 --- a/src/skins/native/Makefile.am +++ b/src/skins/native/Makefile.am @@ -22,6 +22,9 @@ libnative_la_SOURCES = \ wrappers.c \ wrappers.h +libnative_la_LIBADD = \ + ../common/libxenomai.la + libnative_la_CPPFLAGS = \ @XENO_USER_CFLAGS@ \ -I$(top_srcdir)/include diff --git a/src/skins/rtdm/Makefile.am b/src/skins/rtdm/Makefile.am index 8ad74be..2dc0a90 100644 --- a/src/skins/rtdm/Makefile.am +++ b/src/skins/rtdm/Makefile.am @@ -8,6 +8,9 @@ librtdm_la_SOURCES = \ core.c \ init.c +librtdm_la_LIBADD = \ + ../common/libxenomai.la + librtdm_la_CPPFLAGS = \ @XENO_USER_CFLAGS@ \ -I$(top_srcdir)/include diff --git a/src/testsuite/latency/Makefile.am b/src/testsuite/latency/Makefile.am index c772c26..6534df5 100644 --- a/src/testsuite/latency/Makefile.am +++ b/src/testsuite/latency/Makefile.am @@ -14,5 +14,4 @@ latency_LDFLAGS = @XENO_USER_LDFLAGS@ latency_LDADD = \ ../../skins/native/libnative.la \ ../../skins/rtdm/librtdm.la \ - ../../skins/common/libxenomai.la \ -lpthread -lm i.e. that we let the skin libraries depend on libxenomai and then remove the explicit dependency from our binaries and the xeno-config output? Is there some ordering issue again (we have -lskin before -lxenomai in the ldflags). If possible, this would allow for things like dlopen(libnative.so). It allows xeno-config result to work both with dynamic and static libraries. Static libraries have no dependency system, so, when linking a program whith libnative.a for instance, without libtool, you still have to link it with libxenomai.a. How come you can not dlopen libnative.so, dlopening libxenomai.so before does not work? -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Built-in libxenomai dependency
On 02/01/2012 04:25 PM, Jan Kiszka wrote: On 2012-02-01 16:17, Gilles Chanteperdrix wrote: On 02/01/2012 03:37 PM, Jan Kiszka wrote: Hi, don't remember anymore: Is there any subtle reason that prevent a change like diff --git a/src/skins/native/Makefile.am b/src/skins/native/Makefile.am index 39eaaed..4cc8859 100644 --- a/src/skins/native/Makefile.am +++ b/src/skins/native/Makefile.am @@ -22,6 +22,9 @@ libnative_la_SOURCES = \ wrappers.c \ wrappers.h +libnative_la_LIBADD = \ + ../common/libxenomai.la + libnative_la_CPPFLAGS = \ @XENO_USER_CFLAGS@ \ -I$(top_srcdir)/include diff --git a/src/skins/rtdm/Makefile.am b/src/skins/rtdm/Makefile.am index 8ad74be..2dc0a90 100644 --- a/src/skins/rtdm/Makefile.am +++ b/src/skins/rtdm/Makefile.am @@ -8,6 +8,9 @@ librtdm_la_SOURCES = \ core.c \ init.c +librtdm_la_LIBADD = \ + ../common/libxenomai.la + librtdm_la_CPPFLAGS = \ @XENO_USER_CFLAGS@ \ -I$(top_srcdir)/include diff --git a/src/testsuite/latency/Makefile.am b/src/testsuite/latency/Makefile.am index c772c26..6534df5 100644 --- a/src/testsuite/latency/Makefile.am +++ b/src/testsuite/latency/Makefile.am @@ -14,5 +14,4 @@ latency_LDFLAGS = @XENO_USER_LDFLAGS@ latency_LDADD = \ ../../skins/native/libnative.la \ ../../skins/rtdm/librtdm.la \ - ../../skins/common/libxenomai.la \ -lpthread -lm i.e. that we let the skin libraries depend on libxenomai and then remove the explicit dependency from our binaries and the xeno-config output? Is there some ordering issue again (we have -lskin before -lxenomai in the ldflags). If possible, this would allow for things like dlopen(libnative.so). It allows xeno-config result to work both with dynamic and static libraries. Static libraries have no dependency system, so, when linking a program whith libnative.a for instance, without libtool, you still have to link it with libxenomai.a. OK, part two could stay, but the dependencies should still be added to the skin libs - if possible. How come you can not dlopen libnative.so, dlopening libxenomai.so before does not work? Dependencies of libnative on libxenomai are not resolved when you open the former even if the latter is already loaded. Maybe you can do this by pulling in all required symbols one by one manually, haven't tried yet. But that would at least be unhandy. What about RTLD_GLOBAL ? -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Add sigdebug unit test
On 01/26/2012 11:36 AM, Jan Kiszka wrote: On 2012-01-25 19:05, Jan Kiszka wrote: On 2012-01-25 18:44, Gilles Chanteperdrix wrote: On 01/25/2012 06:10 PM, Jan Kiszka wrote: On 2012-01-25 18:02, Gilles Chanteperdrix wrote: On 01/25/2012 05:52 PM, Jan Kiszka wrote: On 2012-01-25 17:47, Jan Kiszka wrote: On 2012-01-25 17:35, Gilles Chanteperdrix wrote: On 01/25/2012 05:21 PM, Jan Kiszka wrote: We had two regressions in this code recently. So test all 6 possible SIGDEBUG reasons, or 5 if the watchdog is not available. Ok for this test, with a few remarks: - this is a regression test, so should go to src/testsuite/regression(/native), and should be added to the xeno-regression-test What are unit test for (as they are defined here)? Looks a bit inconsistent. I put under regression all the tests I have which corresponded to things that failed one time or another in xenomai past. Maybe we could move unit tests under regression. - we already have a regression test for the watchdog called mayday.c, which tests the second watchdog action, please merge mayday.c with sigdebug.c (mayday.c also allows checking the disassembly of the code in the mayday page, a nice feature) It seems to have failed in that important last discipline. Need to check why. Because it didn't check the page content for correctness. But that's now done via the new watchdog test. I can keep the debug output, but the watchdog test of mayday looks obsolete to me. Am I missing something? The watchdog does two things: it first sends a SIGDEBUG, then if the application is still spinning, it sends a SIGSEGV. As far as I understood, you test tests the first case, and mayday tests the second case, so, I agree that mayday should be removed, but whatever it tests should be integrated in the sigdebug test. Err... SIGSEGV is not a feature, it was the bug I fixed today. :) So the test case actually specified a bug as correct behavior. The fallback case is in fact killing the RT task as before. But I'm unsure right now: will this leave the system always in a clean state behind? The test case being a test case and doing nothing particular, I do not see what could go wrong. And if something goes wrong, then it needs fixing. Well, if you kill a RT task while it's running in the kernel, you risk inconsistent system states (held mutexex etc.). In this case the task is supposed to spin in user space. If that is always safe, let's implement the test. Had a closer look: These days the two-stage killing is only useful to catch endless loops in the kernel. User space tasks can't get around being migrated on watchdog events, even when SIGDEBUG is ignored. To trigger the enforced task termination without leaving any broken states behind, there is one option: rt_task_spin. Surprisingly for me, it actually spins in the kernel, thus triggers the second level if waiting long enough. I wonder, though, if that behavior shouldn't be improved, ie. the spinning loop be closed in user space - which would take away that option again. Thoughts? You can also call in an infinite loop, a xenomais syscall which causes a switch to primary mode, but fails. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Add sigdebug unit test
On 01/26/2012 04:06 PM, Jan Kiszka wrote: On 2012-01-26 15:55, Gilles Chanteperdrix wrote: On 01/26/2012 11:36 AM, Jan Kiszka wrote: On 2012-01-25 19:05, Jan Kiszka wrote: On 2012-01-25 18:44, Gilles Chanteperdrix wrote: On 01/25/2012 06:10 PM, Jan Kiszka wrote: On 2012-01-25 18:02, Gilles Chanteperdrix wrote: On 01/25/2012 05:52 PM, Jan Kiszka wrote: On 2012-01-25 17:47, Jan Kiszka wrote: On 2012-01-25 17:35, Gilles Chanteperdrix wrote: On 01/25/2012 05:21 PM, Jan Kiszka wrote: We had two regressions in this code recently. So test all 6 possible SIGDEBUG reasons, or 5 if the watchdog is not available. Ok for this test, with a few remarks: - this is a regression test, so should go to src/testsuite/regression(/native), and should be added to the xeno-regression-test What are unit test for (as they are defined here)? Looks a bit inconsistent. I put under regression all the tests I have which corresponded to things that failed one time or another in xenomai past. Maybe we could move unit tests under regression. - we already have a regression test for the watchdog called mayday.c, which tests the second watchdog action, please merge mayday.c with sigdebug.c (mayday.c also allows checking the disassembly of the code in the mayday page, a nice feature) It seems to have failed in that important last discipline. Need to check why. Because it didn't check the page content for correctness. But that's now done via the new watchdog test. I can keep the debug output, but the watchdog test of mayday looks obsolete to me. Am I missing something? The watchdog does two things: it first sends a SIGDEBUG, then if the application is still spinning, it sends a SIGSEGV. As far as I understood, you test tests the first case, and mayday tests the second case, so, I agree that mayday should be removed, but whatever it tests should be integrated in the sigdebug test. Err... SIGSEGV is not a feature, it was the bug I fixed today. :) So the test case actually specified a bug as correct behavior. The fallback case is in fact killing the RT task as before. But I'm unsure right now: will this leave the system always in a clean state behind? The test case being a test case and doing nothing particular, I do not see what could go wrong. And if something goes wrong, then it needs fixing. Well, if you kill a RT task while it's running in the kernel, you risk inconsistent system states (held mutexex etc.). In this case the task is supposed to spin in user space. If that is always safe, let's implement the test. Had a closer look: These days the two-stage killing is only useful to catch endless loops in the kernel. User space tasks can't get around being migrated on watchdog events, even when SIGDEBUG is ignored. To trigger the enforced task termination without leaving any broken states behind, there is one option: rt_task_spin. Surprisingly for me, it actually spins in the kernel, thus triggers the second level if waiting long enough. I wonder, though, if that behavior shouldn't be improved, ie. the spinning loop be closed in user space - which would take away that option again. Thoughts? You can also call in an infinite loop, a xenomais syscall which causes a switch to primary mode, but fails. Nope, we would be migrated to secondary on xnthread_amok_p when returning to user mode. We need a true kernel loop. But the loop will continue, and the next call to the syscall will cause the thread to re-switch to primary mode. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Add sigdebug unit test
On 01/25/2012 05:21 PM, Jan Kiszka wrote: We had two regressions in this code recently. So test all 6 possible SIGDEBUG reasons, or 5 if the watchdog is not available. Ok for this test, with a few remarks: - this is a regression test, so should go to src/testsuite/regression(/native), and should be added to the xeno-regression-test - we already have a regression test for the watchdog called mayday.c, which tests the second watchdog action, please merge mayday.c with sigdebug.c (mayday.c also allows checking the disassembly of the code in the mayday page, a nice feature) - please make the watchdog test mandatory by default (adding a command line option to skip it for instance), the test should fail if the watchdog is not enabled, because otherwise, it will be easy to forget testing this feature. The wathdog is enabled by default with xenomai 2.6 anyway. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Add sigdebug unit test
On 01/25/2012 05:52 PM, Jan Kiszka wrote: On 2012-01-25 17:47, Jan Kiszka wrote: On 2012-01-25 17:35, Gilles Chanteperdrix wrote: On 01/25/2012 05:21 PM, Jan Kiszka wrote: We had two regressions in this code recently. So test all 6 possible SIGDEBUG reasons, or 5 if the watchdog is not available. Ok for this test, with a few remarks: - this is a regression test, so should go to src/testsuite/regression(/native), and should be added to the xeno-regression-test What are unit test for (as they are defined here)? Looks a bit inconsistent. I put under regression all the tests I have which corresponded to things that failed one time or another in xenomai past. Maybe we could move unit tests under regression. - we already have a regression test for the watchdog called mayday.c, which tests the second watchdog action, please merge mayday.c with sigdebug.c (mayday.c also allows checking the disassembly of the code in the mayday page, a nice feature) It seems to have failed in that important last discipline. Need to check why. Because it didn't check the page content for correctness. But that's now done via the new watchdog test. I can keep the debug output, but the watchdog test of mayday looks obsolete to me. Am I missing something? The watchdog does two things: it first sends a SIGDEBUG, then if the application is still spinning, it sends a SIGSEGV. As far as I understood, you test tests the first case, and mayday tests the second case, so, I agree that mayday should be removed, but whatever it tests should be integrated in the sigdebug test. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Add sigdebug unit test
On 01/25/2012 06:10 PM, Jan Kiszka wrote: On 2012-01-25 18:02, Gilles Chanteperdrix wrote: On 01/25/2012 05:52 PM, Jan Kiszka wrote: On 2012-01-25 17:47, Jan Kiszka wrote: On 2012-01-25 17:35, Gilles Chanteperdrix wrote: On 01/25/2012 05:21 PM, Jan Kiszka wrote: We had two regressions in this code recently. So test all 6 possible SIGDEBUG reasons, or 5 if the watchdog is not available. Ok for this test, with a few remarks: - this is a regression test, so should go to src/testsuite/regression(/native), and should be added to the xeno-regression-test What are unit test for (as they are defined here)? Looks a bit inconsistent. I put under regression all the tests I have which corresponded to things that failed one time or another in xenomai past. Maybe we could move unit tests under regression. - we already have a regression test for the watchdog called mayday.c, which tests the second watchdog action, please merge mayday.c with sigdebug.c (mayday.c also allows checking the disassembly of the code in the mayday page, a nice feature) It seems to have failed in that important last discipline. Need to check why. Because it didn't check the page content for correctness. But that's now done via the new watchdog test. I can keep the debug output, but the watchdog test of mayday looks obsolete to me. Am I missing something? The watchdog does two things: it first sends a SIGDEBUG, then if the application is still spinning, it sends a SIGSEGV. As far as I understood, you test tests the first case, and mayday tests the second case, so, I agree that mayday should be removed, but whatever it tests should be integrated in the sigdebug test. Err... SIGSEGV is not a feature, it was the bug I fixed today. :) So the test case actually specified a bug as correct behavior. The fallback case is in fact killing the RT task as before. But I'm unsure right now: will this leave the system always in a clean state behind? The test case being a test case and doing nothing particular, I do not see what could go wrong. And if something goes wrong, then it needs fixing. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] nucleus: Fix relaxed owner check
On 01/19/2012 05:56 PM, Jan Kiszka wrote: Fix a logic inversion introduced by b75cec1938. This both allows the relaxed-owner check to work again and prevents that we enter an endless signal storm if XNSWREP happens to be set already at this point (as seen in the field). Applied, thanks. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] realtime pipes
On 01/15/2012 01:36 PM, Jan-Erik Lange wrote: Hello, it is possible to access a real-time pipe /dev/rtpx within the kernel space of Linux? Since there is no open function? Real-time pipes are deprecated. Is it therefore possible to communicate between the Xenomai Kernel space and the Linux Kernel space? As mentioned several time, using anything else in kernel-space than the RTDM API is deprecated. If you are interested in the services the RTDM api offers, see: http://www.xenomai.org/documentation/xenomai-2.6/html/api/group__driverapi.html For instance, you can see a section named non-real-time signalling services, which probably answers your question. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] FW: Question about context switching
On 01/12/2012 02:36 PM, Jan-Erik Lange wrote: Date: Wed, 11 Jan 2012 20:03:25 +0100 From: gilles.chanteperd...@xenomai.org To: jan0...@hotmail.de CC: xenomai-core@gna.org Subject: Re: [Xenomai-core] Question about context switching On 01/11/2012 07:12 PM, Jan-Erik Lange wrote: Hello, I have a question about the context switching: Unless that there a rtdm_copy_to_user() available in the rtdm API. Would cause the function copy_to_user() in an xenomai kernel based rt task a switch into the secondary domain? Because copy_to_user() not actually a syscall right? Absolutely no function in kernel-space causes an automatic switch to secondary mode. As Philippe answered to the very first mail you posted to this list, the only events which cause a switch to secondary mode are: - invoking a regular linux syscall - receiving a linux signal (e.g. kill(2) and GDB) - causing a CPU trap (e.g. invalid memory access), hitting a breakpoint (e.g. GDB) All these events only happen for threads in user-space. Sorry I'm new in Xenomai. But is it generaly possible that the xenomai kernel-space task can interact with a common Linux task over this way? I mean is it possible to get data with the standard copy_to_user()-function from the Xenomai kernel-space into the Linux user space? Aren't the adress spaces strictly seperated and you have to need the rt-pipe service to interact between the xenomai kernel space and the linux userspace? drivers should use rtdm_copy_to_user. As most linux kernel services, copy_to_user/copy_from_user may not be safe to be used in primary mode (depending on the architecture). A xenomai kernel-space task has no user-space mapping, so it has no reason to use these services. Whether the address space are strictly separated depend on the architecture and implementation of linux on that archietcture. On some architectures (think uclinux for instance), the user-space/kernel-space division is simply the division between the addresses below 0xC000 and the adresses above. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Question on preempting a linux task
On 01/12/2012 04:58 PM, Jan-Erik Lange wrote: Hello, Does the Xenomai scheduler has to interact with the Linux sheduler in order to preempt the tasks which are managed by it? Or is the Xenomai scheduler repealing the whole linux scheduler when it wants to run a task and and linux is running a task? Best regards Jan No, xenomai may preempt linux in the middle of almost anything, that is the whole point of being based on the adeos patch. However, when a task needs to change scheduler, the two schedulers have to cooperate. If you are interested in the details, see xnshadow_relax and xnshadow_harden in ksrc/nucleus/shadow.c in xenomai sources. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Question about context switching
On 01/11/2012 07:12 PM, Jan-Erik Lange wrote: Hello, I have a question about the context switching: Unless that there a rtdm_copy_to_user() available in the rtdm API. Would cause the function copy_to_user() in an xenomai kernel based rt task a switch into the secondary domain? Because copy_to_user() not actually a syscall right? Absolutely no function in kernel-space causes an automatic switch to secondary mode. As Philippe answered to the very first mail you posted to this list, the only events which cause a switch to secondary mode are: - invoking a regular linux syscall - receiving a linux signal (e.g. kill(2) and GDB) - causing a CPU trap (e.g. invalid memory access), hitting a breakpoint (e.g. GDB) All these events only happen for threads in user-space. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Questio about the Xenomai Scheduler
On 01/08/2012 01:06 PM, Jan-Erik Lange wrote: Is it perhaps this way?: When the RT-Task migrated into the secondary domain, it is scheduled by the Linux-Scheduler: - It inherits the RT-priority from her life in the primary domain and is timely priviliged compared to other tasks scheduled by the linux scheduler, which have a lower priority. No, a linux task with a higher priority than the RT task running in secondary mode may preempt the RT task running in secondary mode. - But it can always be preempted by an RT-Task, that runs in the primary domain and that is scheduled by the Xenomai Scheduler, because this scheduler can preempt all standard linux kernel activities. Yes if root priority inheritance is disabled, not if it is enabled (the default). - Still it is protected from preempting by an Linux interrupt handler, because the I-Pipe is block the interrupts. No, this used to be true a long time ago, but is no longer the case. You have to consider that an RT task running in secondary mode is an ordinary linux task. Only tasks remaining in primary mode are deterministic. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Ipipe breaks my MPC8541 board boot
On 01/03/2012 06:49 PM, Jean-Michel Hautbois wrote:
cpm2_cascade is dedicated to my board, but has nothing impressive :
static void cpm2_cascade(unsigned int irq, struct irq_desc *desc)
{
int cascade_irq;
while ((cascade_irq = cpm2_get_irq()) = 0)
generic_handle_irq(cascade_irq);
Replace generic_handle_irq with ipipe_handle_chained_irq.
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Threads without names confuse rtps
On 12/31/2011 09:01 AM, Christophe Blaess wrote: If a Xenomai thread is created with a NULL name parameter, this way: Applied, thanks. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] user and kernel space
On 01/01/2012 01:56 PM, Jan-Erik Lange wrote: Date: Sat, 31 Dec 2011 16:32:20 +0100 From: gilles.chanteperd...@xenomai.org To: jan0...@hotmail.de CC: xenomai-core@gna.org Subject: Re: [Xenomai-core] user and kernel space On 12/31/2011 12:18 PM, Jan-Erik Lange wrote: Hello, I have a question concerning user space and kernel space. I'm dealing with the native API and I read, that this API provides the same funtkions for both kernel and user space. When looking at the sourcecode of buffer.h for example, there I find a section called public interface. When looking at the function rt_buffer_create(); for example, how does the Implementation von this function in userspace differs to the implementation for this function kernel space? Or is it the same implementation for user and kernel space. For most services such as buffer services, user functions emit system calls which implementation in kernel-space use the corresponding kernel service. There are some exceptions such as mutexes implementation where we try hard to avoid system calls and so provide both a user-space implementation and a kernel-space implementation. Ok, but the names of the API function are the same for user and kernel space. How is it realized to take the implementation A for kernel space and the implementation B for userspace? Is this realzied in the linking process? Yes, kernel and user-space are separated execution space, there is no possible confusion. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] user and kernel space
On 12/31/2011 12:18 PM, Jan-Erik Lange wrote: Hello, I have a question concerning user space and kernel space. I'm dealing with the native API and I read, that this API provides the same funtkions for both kernel and user space. When looking at the sourcecode of buffer.h for example, there I find a section called public interface. When looking at the function rt_buffer_create(); for example, how does the Implementation von this function in userspace differs to the implementation for this function kernel space? Or is it the same implementation for user and kernel space. For most services such as buffer services, user functions emit system calls which implementation in kernel-space use the corresponding kernel service. There are some exceptions such as mutexes implementation where we try hard to avoid system calls and so provide both a user-space implementation and a kernel-space implementation. Another exception is the __xn_rdtsc() function, which relies on most platforms on the same mechanism in user and kernel-space to access the machine high resolution counter, and so has an identical implementation. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] rtdm: add rtdm_printk_ratelimited
On 11/17/2011 12:56 PM, Wolfgang Grandegger wrote: This patch implements a real-time safe rate-limited message printing on kernel console similar to Linux's printk_ratelimited. Applied, thanks. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai 2.6.0 in Debian
On 11/06/2011 11:11 PM, Roland Stigge wrote: Hi, thanks for Xenomai 2.6.0! I'm attaching a patch that's helpful for the integration of Xenomai in Debian (and FHS compliant systems in general), moving the architecture dependent test programs from /usr/share to /usr/lib. Applied, thanks. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Xenomai v2.6.0
Hi, please find Xenomai 2.6.0 at the usual place: http://download.gna.org/xenomai/stable/xenomai-2.6.0.tar.bz2 This new branch started as a reboot of the v2.5 branch, for changes which needed breaking the ABI, said changes being: * a correct handling of signals when waiting for condition variables; * a change in the way thread mode is accessed in user-space, to fix possible leaks depending on the libc; * the automatic switch back to secondary mode after a primary mode system call, for threads running with SCHED_OTHER scheduling policy, except when they hold a mutex. However, at this chance, we also included some new features to this release: * support for a new architecture: sh4; * CLOCK_HOST_REALTIME, a clock synchronized with Linux CLOCK_REALTIME clock, safe to be read when in primary mode; * new analogy drivers for NI 660x and NI 670x boards; * a simplified user-space configuration for the ARM architecture, where the default user-space libraries generated are no longer generated for only one SOC, without any loss of performance; * a simplified xeno-test script, which should now work more reliably, and is based on a xeno-test-run interpreter, which will allow to write different test scenarios; * the beginnings of a regression test suite; * a move of the rtdk library to the common libxenomai library, allowing to have printf being rt-safe when using the posix skin; * pkg-config support, each skin library is available as libxenomai_skin pkg-config package; * and the usual amount of upgrades and adeos patches to follow the linux kernel changes. Enjoy. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] iMX25 problem with gpio and xenomai
On 11/02/2011 02:39 PM, Roberto Bielli wrote: Hi, i'm doing the porting of xenomai version 2.5.6 on imx25 board and i'm looking to start from imx27. I have some problem with gpio. It seems there are spurious interrupts. I would know what xenomai want to know about interrupts (i see ipipe_handle_irq_cond in gpio handler, is it needed ?) and registry save (spin_lock_irqsave in mxc_gpio_set etc...) Please start from http://download.gna.org/adeos/patches/v2.6/arm/adeos-ipipe-2.6.38.8-arm-1.18-03.patch And tell us if you have problems with this patch. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] CPU utilization question
On 10/25/2011 12:19 AM, makarand pradhan wrote: (...) I'm assuming that the ROOT thread captures the %CPU spent in Linux/secnodary and each xenomai thread listed, captures the %CPU in primary domain. If a thread transitions to the secondary, then I'm assuming that the %util in secondary domain will get accounted against ROOT and the actual % usage in primary will get accounted against the thread. You are assuming wrong, the CPU utilization measures the activity of the linux kernel as a whole, including its idle task. So, the sum of all the primary mode tasks and of the ROOT task is always 100%. Question: If the linux process is sleeping, why do I see a CPU util against the process? Why is the CPU % util vary based on the activity I do in the primary domain? rt_printf is a primary mode service which causes activity in secondary mode: the actual printf is done by a plain linux task. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] CPU utilization question
On 10/25/2011 04:18 PM, makarand pradhan wrote: [MP]: Yes. I've noticed that the sum of all tasks is always 100. My question was specifically about a xenomai task that transitions in secondary. e.g. Assume a xenomai task that uses a total of 20% CPU. Of this assume that 10% is spent executing system calls in secondary domain and 10% is spent in the primary domain. I believe that from an accounting perspective, 10% would get accounted against ROOT and the xenomai task will show a CPU util of 10%. Is this accurate? Yes. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] some problems with interrupts
On 10/24/2011 12:14 PM, Roberto Bielli wrote: Hi, i installed the patch 'adeos-ipipe-2.6.31-arm-1.16-02.patch' on a kernel 2.6.31 for imx257 processor. I have a xenomai complex application that read touchscreen events with tslib when pressed. In the kernel log i try these lines: ( the read job is made in a not-realtime thread ) [ cut here ] WARNING: at drivers/input/touchscreen/mxc_tsc.c:599 mxc_tsc_interrupt+0x19c/0x30c [mxc_tsc]() (...) Do you know the meaning in xenomai of this error (so i can modify something to resolve the problem )? This looks more like a warning than an error. At first glance, it has nothing to do with xenomai. Besides, you seem not to be using a mainline version of the kernel, because in the versions I have, there is no drivers/input/touchscreen/mxc_tsc.c, so, it is hard for me to debug this issue. What has file drivers/input/touchscreen/mxc_tsc.c on line 599? You may want to try a more recent version, as linux 2.6.31 starts being seriously outdated. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Xenomai 2.6.0-rc5
Hi, Xenomai 2.6.0-rc5 is available at the usual place: http://download.gna.org/xenomai/testing/xenomai-2.6.0-rc5.tar.bz2 The major change since 2.6.0-rc4 is in analogy drivers sources. A new patch for the ARM architecture was also added, for kernel 2.6.38, including patches for imx51 and imx53 using the freescale linux-2.6-imx git. And finally there are a few minor fixes and cosmetic changes here and there. Here is the shortlog: Alexis Berlemont (1): analogy: quick fix to keep the async buffer below 4GB Daniele Nicolodi (3): build: restore building of xeno-config man page testsuite: add missing include analogy: [ni_pcimio] replace noisy info messages by debug ones Gilles Chanteperdrix (15): wrappers: fix compilation of HOSTRT without TICKDEV arm: fix context switch for linux 2.6.38 testsuite: fix xeno-regression-test help string native: free buffer outside critical section in rt_buffer_delete arm: fix leftover from 392989f410f10ffc228b974ffe26787dff0734f2 arm: change help message for --enable-arm-tsc option nucleus: change default configuration testsuite: fix regression tests location Merge remote branch 'alex/analogy' arm: upgrade patches psos: long/short names issue, take #2 doc: fix README.INSTALL testsuite: various fixes build: bootstrap doc: regenerate Regards. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PULL] KVM awareness / tiny cleanup
On 10/14/2011 01:20 PM, Jan Kiszka wrote: The following changes since commit 31bdadef9018de586bc3fe8de0f37b62b2507785: testsuite: fix regression tests location (2011-10-14 01:46:08 +0200) are available in the git repository at: git://git.xenomai.org/xenomai-jki.git for-upstream Jan Kiszka (2): nucleus: Privatize __xnpod_reset_thread Are we sure that we do not have any out-of-tree users for this feature? -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH xenomai-head] testsuite: fix compiler error 'SIGALRM, undeclared'
On 10/12/2011 11:44 AM, Wolfgang Grandegger wrote: Signed-off-by: Wolfgang Grandegger w...@denx.de --- src/testsuite/regression/posix/leaks.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/testsuite/regression/posix/leaks.c b/src/testsuite/regression/posix/leaks.c index 7326572..f9dd34d 100644 --- a/src/testsuite/regression/posix/leaks.c +++ b/src/testsuite/regression/posix/leaks.c @@ -6,6 +6,7 @@ #include fcntl.h #include sys/mman.h #include semaphore.h +#include signal.h #include mqueue.h #include nucleus/heap.h Applied, thanks. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH xenomai-head] testsuite: fix compiler error 'SIGALRM, undeclared'
On 10/12/2011 01:04 PM, Daniele Nicolodi wrote: On 12/10/11 12:59, Gilles Chanteperdrix wrote: On 10/12/2011 11:44 AM, Wolfgang Grandegger wrote: Signed-off-by: Wolfgang Grandegger w...@denx.de --- src/testsuite/regression/posix/leaks.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/testsuite/regression/posix/leaks.c b/src/testsuite/regression/posix/leaks.c index 7326572..f9dd34d 100644 --- a/src/testsuite/regression/posix/leaks.c +++ b/src/testsuite/regression/posix/leaks.c @@ -6,6 +6,7 @@ #include fcntl.h #include sys/mman.h #include semaphore.h +#include signal.h #include mqueue.h #include nucleus/heap.h Applied, thanks. Wans't that the same error fixed by commit aa44db3d5ee270c3b92a1017f7c136ffa1e2cc4d? Indeed. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] patch: testsuite: add missing include
On 10/04/2011 03:37 PM, Daniele Nicolodi wrote: Hello, the posix/leks regression test in the test suite failed to build on debian testing due to a missing include. The attached patch fixes the problem. Applied as well, thanks. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] patch: build: restore building of xeno-config man page
On 10/04/2011 03:36 PM, Daniele Nicolodi wrote: Hello, here is a simple patch to the build system to restore the building of xeno-config man page. It got lost some time ago. I noticed that it was missing because debian packages failed to build. Applied, thanks. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Analogy: idx_write_subd field in a4l_desc_t
On 10/04/2011 09:58 AM, Daniele Nicolodi wrote:
On 01/10/11 20:07, Gilles Chanteperdrix wrote:
For API / ABI compatibility reasons, I waited a major release before
removing the fields idx_{read, write}_subd. I should have thought
twice before removing their initializations. I will fix that soon,
sorry.
2.6 is a new major release, and not out yet, so, if you want to remove
something, it is still time.
If we are open to some partially backward incompatible changes I propose
to also change the meaning of the a4l_desc_t board_name field, to really
be the board name, instead of the driver name. I find this information
more useful when enumerating devices in my setup.
I would also like to propose a patch to demote some messages, logged at
each interrupt, in the ni_pcimio driver from the info to the debug
level. I run continuous acquisitions and those kernel messages pollute
my syslog with not much added value and fill my disc with redundant
information.
If you want things merged, send the patches, they will reach
xenomai-head repository through Alex.
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Xenomai 2.6.0-rc4
Hi, here is the 4th release candidate for Xenomai 2.6.0: http://download.gna.org/xenomai/testing/xenomai-2.6.0-rc4.tar.bz2 Novelties since -rc3 include: - a fix for the long names issue on psos+ - a fix for the build issue of mscan on mpc52xx (please Wolfgang, have a look at the patch, to see if you like it:) http://git.xenomai.org/?p=xenomai-head.git;a=commitdiff;h=d22fd231db7eb0af8e77ec570efb89e578e13781;hp=4a2188f049e96fc59aa7c4a7a9d058075f3d79e8 - a new version of the I-pipe patch for linux 3.0 on ppc. This should be the last release candidate. Regards. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC 0/1] Class driver for raw Ethernet packets
On 09/27/2011 07:00 PM, Richard Cochran wrote: On Tue, Sep 27, 2011 at 06:26:44PM +0200, Jan Kiszka wrote: On 2011-09-27 18:05, Richard Cochran wrote: That's a common misunderstanding: RTnet is a networking stack with many _optional_ components (like RTmac, RTcfg etc.). I would bet that it's more frequently used today in minimal setups, i.e. just the core, some driver, and either PF_PACKET or UDP/IP. I understood about the modular design, but I really want to know if rtnet will help me if I want to use of the industrial Ethernet protocols. AFAICT, rtnet really doesn't offer these. So I'll ask the direct question once again. Does rtnet help me with industrial Ethernet (apart from the rtnet protocols), or not? Unless rtnet implements (or helps to implement) these, it is kind of silly to say, your way won't work, you should use rtnet instead. I don't know PowerLink or Profinet, but I do know EtherCAT and IEC 61850, and those two can surely be implemented on the interface that I am talking about. It works, but it won't give you a deterministic control loop as you still have Linux in the game. It really depends on how the driver is written. While my gianfar example does make use of normal Linux driver interrupts, it would not necessarily have to do so. I was simply hoping to collect some new ideas how to address the driver maintenance issue in a better way but without dropping key features needed for RT networking. Something like let's add generic RT channels to Linux upstream drivers and then only patch them fit RTDM. Not sure if that works, but it would come with a vision how to keep things more maintainable. Well, can you turn the issue around and convince me that writing a rtnet driver is the best way to acheive raw Ethernet packet access? From the point of view of someone a bit external to the rtnet project, rtnet is a TCP/IP stack, which contains the stack, useless for your purposes, but defines an interface between drivers and the stack. By following this interface to write a driver on one-side, and support for raw packets on the other side you get: - raw packets support for all drivers in rtnet repository - TCP/IP support for the NIC you wrote a driver for. As for the in-kernel driver patch versus out-of-tree driver, in-kernel driver will have to be adapted for each release of the linux kernel, when porting the I-pipe patch, and that is quickly going to become a nightmare. You talk about the rtnet driver model, but is it described anywhere? (BTW rtnet/Documentation/README.drvporting is horrible. It is just a random list of 40+ odd points without any sense. That document gave me the impression that developing an rtnet driver is a kind of extended hack until it starts working.) README.drvporting is frightening at first, but in fact, the job to port a network driver to rtnet is not so hard. Thanks, Richard ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] P2020 support for ftrace with ipipe 2.12-01 and xeno 2.5.5.1
On 09/23/2011 09:58 AM, Jean-Michel Hautbois wrote: Hi List, I am trying to use ftrace on a P2020 board, using the following : - Linux 2.6.35-11 - Xenomai 2.5.5.1 (or 2.5.6, same problem) - ipipe 2.12-01 I launch it using : $ mkdir /tmp/debug $ mount -t debugfs nodev /tmp/debug $ cd /tmp/debug/tracing $ echo function_graph current_tracer The last one fails (it hangs the CPU, I cannot do anything than hard reset). Do you know what could cause that ? As I can't have any trace, I don't really know how to go further, and before using a BDI I would like to know if it is a known issue, as I could not find anything related to this in the recent changes... Thanks in advance for your help, Regards, JM Does the I-pipe tracer work? See: http://www.xenomai.org/index.php/I-pipe:Tracer -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] P2020 support for ftrace with ipipe 2.12-01 and xeno 2.5.5.1
On 09/23/2011 11:49 AM, Jean-Michel Hautbois wrote: OK, I have more traces (a few :)) : I meant the I-pipe tracer alone. The I-pipe tracer intead of other ftrace tracers. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Xenomai 2.6.0-rc3
Hi, here comes xenomai v2.6.0-rc3: http://download.gna.org/xenomai/testing/xenomai-2.6.0-rc3.tar.bz2 New since -rc2: - fix of vxworks services taskDelete and taskDeleteForce; - SCHED_FIFO threads switching to SCHED_OTHER while holding a mutex are sent a SIGDEBUG signal when releasing the mutex; - add the beginning of a regression tests suite. Known remaining issues: - mscan driver not building on mpc5xxx with linux 3.0, see: http://sisyphus.hd.free.fr/~gilles/bx/lite5200/3.0.4-ppc_6xx-gcc-4.2.2/log.html#1 - issue with 4 characters ids in the psos skin. Regards. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Port to stmp3xxx (arm based)
On 09/17/2011 05:15 PM, Bertold Van den Bergh wrote: Hello, I am trying to port Xenomai to the freescale stmp3xxx cpu (I.MX233). I added TSC code from plat-s3c24xx as this processor also uses a 16 bit downcounter based timer. I run the system tick counter and the TSC freerunning counter at 32KHz (I plan to speed it up to increase precision but I have a question about that). I have monitored the TSC output and it is a monotonic count without jumps forward or backward. Xenomai and linux boots fine. I can also start xenomai tasks, and they even appear to work to some extent. The mask member filled by __ipipe_mach_get_tscinfo is wrong, the right mask for a 16 bits counter is 0x -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Port to stmp3xxx (arm based)
On 09/18/2011 04:43 PM, Bertold Van den Bergh wrote: Hello, Thanks for the reply. The timer register has the following layout: bit 0-15: reload, bit 16-31: counter. Thats why I put 0x. Looking at the code this cannot work so I added an extra field to indicate the shift after applying the mask. You should really upgrade your I-pipe tree to a more recent one, where the support for tsc emulation was factored. You would add the new case to the tsc implementations in kernel-space, and nowhere else. When you are done, please send a patch. Now the userspace latency test prorgam gives valid latencies, sadly it's still -1ms to 3ms latency. How should I proceed troubleshooting this? Looking at the ipipe trace it looks the task is brought op quite fast after the interrupt fires so I think it is set at the wrong time, I'm going to look into this. The I-pipe tracer has a trace point at the point where the timer was supposed to tick. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Policy switching and XNOTHER maintenance
On 09/18/2011 05:24 PM, Jan Kiszka wrote: On 2011-09-18 17:18, Gilles Chanteperdrix wrote: What about: diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c index 21cc191..7fe44a1 100644 --- a/ksrc/nucleus/shadow.c +++ b/ksrc/nucleus/shadow.c @@ -2756,9 +2756,12 @@ static inline void do_setsched_event(struct task_struct *p, int priority) union xnsched_policy_param param; struct xnsched *sched; -if (!thread || p-policy != SCHED_FIFO) +if (!thread || (p-policy != SCHED_FIFO p-policy != SCHED_OTHER)) return; +if (p-policy == SCHED_OTHER) +priority = 0; + /* * Linux's priority scale is a subset of the core pod's * priority scale, so there is no need to bound the priority No other policies can be issued against the Linux part of a shadow? Then it's OK. I just don't recall the details here ATM. Jan This should be OK, according to the comment: * BIG FAT WARNING: Change of scheduling parameters from the * Linux side are propagated only to threads that belong to * the Xenomai RT scheduling class. Threads from other classes * are remain unaffected, since we could not map this * information 1:1 between Linux and Xenomai. */ -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Port to stmp3xxx (arm based)
On 09/18/2011 04:43 PM, Bertold Van den Bergh wrote: Hello, Thanks for the reply. The timer register has the following layout: bit 0-15: reload, bit 16-31: counter. Thats why I put 0x. Looking at the code this cannot work so I added an extra field to indicate the shift after applying the mask. Now the userspace latency test prorgam gives valid latencies, sadly it's still -1ms to 3ms latency. How should I proceed troubleshooting this? Looking at the ipipe trace it looks the task is brought op quite fast after the interrupt fires so I think it is set at the wrong time, I'm going to look into this. Note that you probably have not enabled CONFIG_IPIPE_TRACE_MCOUNT, you should enable it to get more complete traces. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Policy switching and XNOTHER maintenance
On 09/11/2011 04:29 PM, Jan Kiszka wrote:
On 2011-09-11 16:24, Gilles Chanteperdrix wrote:
On 09/11/2011 12:50 PM, Jan Kiszka wrote:
Hi all,
just looked into the hrescnt issue again, specifically the corner case
of a shadow thread switching from real-time policy to SCHED_OTHER.
Doing this while holding a mutex looks invalid.
Looking at POSIX e.g., is there anything in the spec that makes this
invalid? If the kernel preserves or established proper priority
boosting, I do not see what could break in principle.
It is nothing I would design into some app, but we should somehow handle
it (doc update or code adjustments).
If we do not do it, the current code is valid.
Except for its dependency on XNOTHER which is not updated on RT-NORMAL
transitions.
The fact that this update did not take place made the code work. No
negative rescnt could happen with that code.
Anyway, here is a patch to allow switching back from RT to NORMAL, but
send a SIGDEBUG to a thread attempting to release a mutex while its
counter is already 0. We end up avoiding a big chunk of code that would
have been useful for a really strange corner case.
diff --git a/examples/native/sigdebug.c b/examples/native/sigdebug.c
index e20714b..7b840f9 100644
--- a/examples/native/sigdebug.c
+++ b/examples/native/sigdebug.c
@@ -34,6 +34,8 @@ static const char *reason_str[] = {
[SIGDEBUG_MIGRATE_PRIOINV] = affected by priority inversion,
[SIGDEBUG_NOMLOCK] = missing mlockall,
[SIGDEBUG_WATCHDOG] = runaway thread,
+[SIGDEBUG_SCHED_CHANGE_W_MX] =
+switched to SCHED_OTHER policy with mutex held,
};
void warn_upon_switch(int sig, siginfo_t *si, void *context)
diff --git a/include/asm-generic/syscall.h b/include/asm-generic/syscall.h
index a9cdc87..5b6c764 100644
--- a/include/asm-generic/syscall.h
+++ b/include/asm-generic/syscall.h
@@ -61,6 +61,7 @@ typedef struct xnsysinfo {
#define SIGDEBUG_MIGRATE_PRIOINV 4
#define SIGDEBUG_NOMLOCK 5
#define SIGDEBUG_WATCHDOG 6
+#define SIGDEBUG_SCHED_CHANGE_W_MX 7
#ifdef __KERNEL__
diff --git a/include/nucleus/sched-idle.h b/include/nucleus/sched-idle.h
index 6399a17..3cc7185 100644
--- a/include/nucleus/sched-idle.h
+++ b/include/nucleus/sched-idle.h
@@ -39,6 +39,7 @@ extern struct xnsched_class xnsched_class_idle;
static inline void __xnsched_idle_setparam(struct xnthread *thread,
const union xnsched_policy_param *p)
{
+ xnthread_set_state(thread, XNOTHER);
thread-cprio = p-idle.prio;
}
diff --git a/include/nucleus/sched-rt.h b/include/nucleus/sched-rt.h
index 71f655c..d17b058 100644
--- a/include/nucleus/sched-rt.h
+++ b/include/nucleus/sched-rt.h
@@ -86,6 +86,10 @@ static inline void __xnsched_rt_setparam(struct xnthread
*thread,
const union xnsched_policy_param *p)
{
thread-cprio = p-rt.prio;
+ if (thread-cprio)
+ xnthread_clear_state(thread, XNOTHER);
+ else
+ xnthread_set_state(thread, XNOTHER);
}
static inline void __xnsched_rt_getparam(struct xnthread *thread,
diff --git a/ksrc/nucleus/pod.c b/ksrc/nucleus/pod.c
index 9a02e80..d1f 100644
--- a/ksrc/nucleus/pod.c
+++ b/ksrc/nucleus/pod.c
@@ -1896,16 +1896,6 @@ int __xnpod_set_thread_schedparam(struct xnthread
*thread,
xnsched_putback(thread);
#ifdef CONFIG_XENO_OPT_PERVASIVE
- /*
-* A non-real-time shadow may upgrade to real-time FIFO
-* scheduling, but the latter may never downgrade to
-* SCHED_NORMAL Xenomai-wise. In the valid case, we clear
-* XNOTHER to reflect the change. Note that we keep handling
-* non real-time shadow specifics in higher code layers, not
-* to pollute the core scheduler with peculiarities.
-*/
- if (sched_class == xnsched_class_rt sched_param-rt.prio 0)
- xnthread_clear_state(thread, XNOTHER);
if (propagate) {
if (xnthread_test_state(thread, XNRELAX))
xnshadow_renice(thread);
diff --git a/ksrc/nucleus/sched-sporadic.c b/ksrc/nucleus/sched-sporadic.c
index fd37c21..587be4a 100644
--- a/ksrc/nucleus/sched-sporadic.c
+++ b/ksrc/nucleus/sched-sporadic.c
@@ -258,6 +258,7 @@ static void xnsched_sporadic_setparam(struct xnthread
*thread,
}
}
+ xnthread_clear_state(thread, XNOTHER);
thread-cprio = p-pss.current_prio;
}
diff --git a/ksrc/nucleus/sched-tp.c b/ksrc/nucleus/sched-tp.c
index 43a548e..2423e81 100644
--- a/ksrc/nucleus/sched-tp.c
+++ b/ksrc/nucleus/sched-tp.c
@@ -100,6 +100,7 @@ static void xnsched_tp_setparam(struct xnthread *thread,
{
struct xnsched *sched = thread-sched;
+ xnthread_clear_state(thread, XNOTHER);
thread-tps = sched-tp.partitions[p-tp.ptid];
thread-cprio = p-tp.prio;
}
diff --git a/ksrc/nucleus/synch.c b/ksrc/nucleus/synch.c
index
Re: [Xenomai-core] Policy switching and XNOTHER maintenance
On 09/16/2011 10:13 PM, Gilles Chanteperdrix wrote:
On 09/11/2011 04:29 PM, Jan Kiszka wrote:
On 2011-09-11 16:24, Gilles Chanteperdrix wrote:
On 09/11/2011 12:50 PM, Jan Kiszka wrote:
Hi all,
just looked into the hrescnt issue again, specifically the corner case
of a shadow thread switching from real-time policy to SCHED_OTHER.
Doing this while holding a mutex looks invalid.
Looking at POSIX e.g., is there anything in the spec that makes this
invalid? If the kernel preserves or established proper priority
boosting, I do not see what could break in principle.
It is nothing I would design into some app, but we should somehow handle
it (doc update or code adjustments).
If we do not do it, the current code is valid.
Except for its dependency on XNOTHER which is not updated on RT-NORMAL
transitions.
The fact that this update did not take place made the code work. No
negative rescnt could happen with that code.
Anyway, here is a patch to allow switching back from RT to NORMAL, but
send a SIGDEBUG to a thread attempting to release a mutex while its
counter is already 0. We end up avoiding a big chunk of code that would
have been useful for a really strange corner case.
Here comes version 2:
diff --git a/include/nucleus/sched-idle.h b/include/nucleus/sched-idle.h
index 6399a17..417170f 100644
--- a/include/nucleus/sched-idle.h
+++ b/include/nucleus/sched-idle.h
@@ -39,6 +39,8 @@ extern struct xnsched_class xnsched_class_idle;
static inline void __xnsched_idle_setparam(struct xnthread *thread,
const union xnsched_policy_param *p)
{
+ if (xnthread_test_state(thread, XNSHADOW))
+ xnthread_clear_state(thread, XNOTHER);
thread-cprio = p-idle.prio;
}
diff --git a/include/nucleus/sched-rt.h b/include/nucleus/sched-rt.h
index 71f655c..cc1cefa 100644
--- a/include/nucleus/sched-rt.h
+++ b/include/nucleus/sched-rt.h
@@ -86,6 +86,12 @@ static inline void __xnsched_rt_setparam(struct xnthread
*thread,
const union xnsched_policy_param *p)
{
thread-cprio = p-rt.prio;
+ if (xnthread_test_state(thread, XNSHADOW)) {
+ if (thread-cprio)
+ xnthread_clear_state(thread, XNOTHER);
+ else
+ xnthread_set_state(thread, XNOTHER);
+ }
}
static inline void __xnsched_rt_getparam(struct xnthread *thread,
diff --git a/ksrc/nucleus/pod.c b/ksrc/nucleus/pod.c
index 9a02e80..d1f 100644
--- a/ksrc/nucleus/pod.c
+++ b/ksrc/nucleus/pod.c
@@ -1896,16 +1896,6 @@ int __xnpod_set_thread_schedparam(struct xnthread
*thread,
xnsched_putback(thread);
#ifdef CONFIG_XENO_OPT_PERVASIVE
- /*
-* A non-real-time shadow may upgrade to real-time FIFO
-* scheduling, but the latter may never downgrade to
-* SCHED_NORMAL Xenomai-wise. In the valid case, we clear
-* XNOTHER to reflect the change. Note that we keep handling
-* non real-time shadow specifics in higher code layers, not
-* to pollute the core scheduler with peculiarities.
-*/
- if (sched_class == xnsched_class_rt sched_param-rt.prio 0)
- xnthread_clear_state(thread, XNOTHER);
if (propagate) {
if (xnthread_test_state(thread, XNRELAX))
xnshadow_renice(thread);
diff --git a/ksrc/nucleus/sched-sporadic.c b/ksrc/nucleus/sched-sporadic.c
index fd37c21..ffc9bab 100644
--- a/ksrc/nucleus/sched-sporadic.c
+++ b/ksrc/nucleus/sched-sporadic.c
@@ -258,6 +258,8 @@ static void xnsched_sporadic_setparam(struct xnthread
*thread,
}
}
+ if (xnthread_test_state(thread, XNSHADOW))
+ xnthread_clear_state(thread, XNOTHER);
thread-cprio = p-pss.current_prio;
}
diff --git a/ksrc/nucleus/sched-tp.c b/ksrc/nucleus/sched-tp.c
index 43a548e..a2af1d3 100644
--- a/ksrc/nucleus/sched-tp.c
+++ b/ksrc/nucleus/sched-tp.c
@@ -100,6 +100,8 @@ static void xnsched_tp_setparam(struct xnthread *thread,
{
struct xnsched *sched = thread-sched;
+ if (xnthread_test_state(thread, XNSHADOW))
+ xnthread_clear_state(thread, XNOTHER);
thread-tps = sched-tp.partitions[p-tp.ptid];
thread-cprio = p-tp.prio;
}
diff --git a/ksrc/nucleus/synch.c b/ksrc/nucleus/synch.c
index b956e46..47bc0c5 100644
--- a/ksrc/nucleus/synch.c
+++ b/ksrc/nucleus/synch.c
@@ -684,9 +684,13 @@ xnsynch_release_thread(struct xnsynch *synch, struct
xnthread *lastowner)
XENO_BUGON(NUCLEUS, !testbits(synch-status, XNSYNCH_OWNER));
- if (xnthread_test_state(lastowner, XNOTHER))
- xnthread_dec_rescnt(lastowner);
- XENO_BUGON(NUCLEUS, xnthread_get_rescnt(lastowner) 0);
+ if (xnthread_test_state(lastowner, XNOTHER)) {
+ if (xnthread_get_rescnt(lastowner) == 0)
+ xnshadow_send_sig(lastowner, SIGDEBUG
Re: [Xenomai-core] Undefined 'pc_sysrootdir' in libxenomai_posix.pc ?
On 09/12/2011 11:08 AM, Gilles Chanteperdrix wrote:
On 09/12/2011 10:27 AM, varname wrote:
Trying to use pkg-config with 2.6.0-rc2 results in the following error
message:
Variable 'pc_sysrootdir' not defined in
'/home/test/usr/xenomai-2.6.0-rc2/lib/pkgconfig/libxenomai_posix.pc'
Same behaviour in rc1.
Removing ${pc_sysrootdir} seems to work, but I'm not sure that is the
correct fix for this.
No, the correct use of pkg-config is to pass the PKG_CONFIG_SYSROOT_DIR
environment variable.
if the staging variable contains the directory which was used as DESTDIR
when installing xenomai, you should run pkg-config with the following
environment variables set:
PKG_CONFIG_LIBDIR=${staging}/usr/lib/pkgconfig:${staging}/usr/share/pkgconfig
PKG_CONFIG_SYSROOT_DIR=${staging}
See:
http://www.flameeyes.eu/autotools-mythbuster/pkgconfig/cross-compiling.html
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Policy switching and XNOTHER maintenance
On 09/11/2011 12:50 PM, Jan Kiszka wrote: Hi all, just looked into the hrescnt issue again, specifically the corner case of a shadow thread switching from real-time policy to SCHED_OTHER. Doing this while holding a mutex looks invalid. If we do not do it, the current code is valid. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Xenomai 2.6.0-rc2
Hi, here comes xenomai v2.6.0-rc2: http://download.gna.org/xenomai/testing/xenomai-2.6.0-rc2.tar.bz2 New since -rc1 are: - the latest upgrades of analogy, including support for NI 660x and NI 670x - build and run-time fixes for powerpc Known remaining issues: - mscan driver not building on mpc5xxx with linux 3.0, see: http://sisyphus.hd.free.fr/~gilles/bx/lite5200/3.0.4-ppc_6xx-gcc-4.2.2/log.html#1 - SCHED_FIFO threads switching to SCHED_OTHER policy while holding a mutex Regards. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai-help] Xenomai 2.6.0-rc1
On 09/06/2011 11:15 PM, Philippe Gerum wrote: On Tue, 2011-09-06 at 20:19 +0200, Gilles Chanteperdrix wrote: On 09/06/2011 05:10 PM, Philippe Gerum wrote: On Tue, 2011-09-06 at 16:53 +0200, Philippe Gerum wrote: On Tue, 2011-09-06 at 16:53 +0200, Philippe Gerum wrote: On Tue, 2011-09-06 at 16:19 +0200, Gilles Chanteperdrix wrote: On 09/06/2011 03:27 PM, Philippe Gerum wrote: On Tue, 2011-09-06 at 13:31 +0200, Gilles Chanteperdrix wrote: On 09/04/2011 10:52 PM, Gilles Chanteperdrix wrote: Hi, The first release candidate for the 2.6.0 version may be downloaded here: http://download.gna.org/xenomai/testing/xenomai-2.6.0-rc1.tar.bz2 Hi, currently 2.6.0-rc1 fails to build on 2.4 kernel, with errors related to vfile support. Do we really want to still support 2.4 kernels? That would not be a massive loss, but removing linux 2.4 support is more than a few hunks here and there, so this may not be the right thing to do ATM. Besides, it would be better not to leave the few linux 2.4 users out there without upgrade path to xenomai 2.6, since this will be the last maintained version from the Xenomai 2.x architecture. That stuff does not compile likely because the Config.in bits are not up to date, blame it on me. I'll make this build over linux 2.4 and commit the result today. No problem, I was not looking for someone to blame... Since you are at it, I have problems compiling the nios2 kernel too, but I am not sure I got the proper configuration file. HEAD builds fine based on the attached .config. Btw we now only support the MMU version (2.6.35.2) of this kernel over Xenomai 2.6. Reference tree is available there: url = git://sopc.et.ntust.edu.tw/git/linux-2.6.git branch = nios2mmu nommu support is discontinued for nios2 - people who depend on it should stick with Xenomai 2.5.x. Ok, still not building, maybe the commit number mentioned in the README is not up-to-date? The commit # is correct, but I suspect that your kernel tree does not have the files normally created by the SOPC builder anymore, these can't (may not actually) be included in the pipeline patch. In short, your tree might be missing the bits corresponding to the fpga design your build for, so basic symbols like HRCLOCK* and HRTIMER* are undefined. I'm building for a cyclone 3c25 from the NEEK kit, with SOPC files available from arch/nios2/boards/neek. Any valuable files in there on your side? (typically, include/asm/custom_fpga.h should contain definitions for our real-time clocks and timers) I create a file arch/nios2/hardware.mk, which contains: SYSPTF = /path/to/std_1s10.ptf CPU = cpu EXEMEM = sdram Then run the kernel compilation as for any other platform. Is it not sufficient? Perhaps my .ptf file is outdated? -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai-help] Xenomai 2.6.0-rc1
On 09/04/2011 10:52 PM, Gilles Chanteperdrix wrote: Hi, The first release candidate for the 2.6.0 version may be downloaded here: http://download.gna.org/xenomai/testing/xenomai-2.6.0-rc1.tar.bz2 Hi, currently 2.6.0-rc1 fails to build on 2.4 kernel, with errors related to vfile support. Do we really want to still support 2.4 kernels? Regards. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai-help] Xenomai 2.6.0-rc1
On 09/06/2011 03:27 PM, Philippe Gerum wrote: On Tue, 2011-09-06 at 13:31 +0200, Gilles Chanteperdrix wrote: On 09/04/2011 10:52 PM, Gilles Chanteperdrix wrote: Hi, The first release candidate for the 2.6.0 version may be downloaded here: http://download.gna.org/xenomai/testing/xenomai-2.6.0-rc1.tar.bz2 Hi, currently 2.6.0-rc1 fails to build on 2.4 kernel, with errors related to vfile support. Do we really want to still support 2.4 kernels? That would not be a massive loss, but removing linux 2.4 support is more than a few hunks here and there, so this may not be the right thing to do ATM. Besides, it would be better not to leave the few linux 2.4 users out there without upgrade path to xenomai 2.6, since this will be the last maintained version from the Xenomai 2.x architecture. That stuff does not compile likely because the Config.in bits are not up to date, blame it on me. I'll make this build over linux 2.4 and commit the result today. No problem, I was not looking for someone to blame... Since you are at it, I have problems compiling the nios2 kernel too, but I am not sure I got the proper configuration file. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
