Re: Re: Re: A fairly small rtnet/Xenomai...

Happy new year to all!

Back in the office, I tried out the patches from Chilles and Philippe.
And yes, it is working now! No crash!
Using these patches, I can now call a system() call out of a rea ltime task that is followed 
by a rt_task_sleep() and a printf() without crash on a 2.6.19 kernel.

Thanks for the support!

Best regards

Mathias
> > here comes a workaround for the COW issue on Linux 2.6.19. The patch
> > relies on a new VM_NOCOW flag which should be set for real-time
> > application if you use Xenomai trunk.
> > 
> > It would be nice if you could test it.
> > 
> 
> You will additionally need to apply this patch to the Xenomai tree in
> order to activate the COW-disable feature:

--

-- 
Mathias Koehrer
mathias_koehrer <at> arcor.de

Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  44,85 €  inkl. DSL- und ISDN-Grundgebühr!

Re: Re: Re: A fairly small rtnet/Xenomai...

On Tue, 2007-01-02 at 09:23 +0100, M. Koehrer wrote:
> Happy new year to all!
> 
> Back in the office, I tried out the patches from Chilles and Philippe.
> And yes, it is working now! No crash!
> Using these patches, I can now call a system() call out of a rea ltime task that is followed 
> by a rt_task_sleep() and a printf() without crash on a 2.6.19 kernel.
> 
> Thanks for the support!
> 
> Best regards
> 
> Mathias
> > > here comes a workaround for the COW issue on Linux 2.6.19. The patch
> > > relies on a new VM_NOCOW flag which should be set for real-time
> > > application if you use Xenomai trunk.
> > > 
> > > It would be nice if you could test it.
> > > 
> > 
> > You will additionally need to apply this patch to the Xenomai tree in
> > order to activate the COW-disable feature:
> 
> 

Great, thanks. Niklaus, could you check the vm-nocow patch for 2.6.14 on
the ppc board (the hcu, IIRC) that exhibited strange faults in
user-space while running the latency test, especially when enabling the
nucleus debug option (the one which also used to cause secondary switch
warnings being sent by Xenomai to the kernel log)? TIA,

Re: Re: A fairly small rtnet/Xenomai...

Am Dienstag, 2. Januar 2007 10:53 schrieb Philippe Gerum:
> On Tue, 2007-01-02 at 09:23 +0100, M. Koehrer wrote:
> > Happy new year to all!
> >
> > Back in the office, I tried out the patches from Chilles and Philippe.
> > And yes, it is working now! No crash!
> > Using these patches, I can now call a system() call out of a rea ltime
> > task that is followed by a rt_task_sleep() and a printf() without crash
> > on a 2.6.19 kernel.
> >
> > Thanks for the support!
> >
> > Best regards
> >
> > Mathias
> >
> > > > here comes a workaround for the COW issue on Linux 2.6.19. The patch
> > > > relies on a new VM_NOCOW flag which should be set for real-time
> > > > application if you use Xenomai trunk.
> > > >
> > > > It would be nice if you could test it.
> > >
> > > You will additionally need to apply this patch to the Xenomai tree in
> > > order to activate the COW-disable feature:
>
> Great, thanks. Niklaus, could you check the vm-nocow patch for 2.6.14 on
> the ppc board (the hcu, IIRC) that exhibited strange faults in
> user-space while running the latency test, especially when enabling the
> nucleus debug option (the one which also used to cause secondary switch
> warnings being sent by Xenomai to the kernel log)? TIA,

parallelport module for measuring external interrupt latency

Dear Xenomai-Users / Developers,

I have finished my work on a parallelport module for measuring external
interrupt latencies. It is based on another kernel-module working on
plain linux. Interrupt latencies are measured via triggering an
interrupt over a connection between data pin 7 and the ACK-pin.

The kernel module loads fine without any problems. When starting the
User-space task the system freezes without any output in the kernel log.
 I was trying to solve the problem for several days now without any
success. I would appreciate, if somebody would have a short look on it.
Maybe its just a small problem which can be fixed easily.

The kernel-module as well as the user-space task are attached.

Thanks in advance and regards,
Markus Franke

PS.: I am aware of the fact that there is already a testcase in the
testsuite for measuring external interrupt latencies. Nevertheless, I
would like to gain experiences in developing with Xenomai and I want to
know why the attached code doesn't work. I will also work with the
testcases in the testsuite soon.

_______________________________________________
Xenomai-help mailing list

Re: parallelport module for measuring external interrupt latency

Markus Franke wrote:
> Dear Xenomai-Users / Developers,
> 
> I have finished my work on a parallelport module for measuring external
> interrupt latencies. It is based on another kernel-module working on
> plain linux. Interrupt latencies are measured via triggering an
> interrupt over a connection between data pin 7 and the ACK-pin.
> 
> The kernel module loads fine without any problems. When starting the
> User-space task the system freezes without any output in the kernel log.
>  I was trying to solve the problem for several days now without any
> success. I would appreciate, if somebody would have a short look on it.
> Maybe its just a small problem which can be fixed easily.
> 
> The kernel-module as well as the user-space task are attached.
> 
> Thanks in advance and regards,
> Markus Franke
> 
> PS.: I am aware of the fact that there is already a testcase in the
> testsuite for measuring external interrupt latencies. Nevertheless, I
> would like to gain experiences in developing with Xenomai and I want to
> know why the attached code doesn't work. I will also work with the
> testcases in the testsuite soon.
> 

...

> 
> // ISR

Re: recommendations for new computer

vleves <at> cim.mcgill.ca wrote:
> Hello all,
> 
> I'm about to buy a new computer and I'd like to make sure that it will
> work with Xenomai (although it won't be its primary use). I'm hesitating
> between building a Core 2 Duo PC or buying a Mac. Are there any
> limitations with respect to Xenomai that I should be aware of? Does anyone
> have experience installing Linux and Xenomai on an intel Mac?

I would expect xenomai to run on a core 2 duo: I am using it on a core
duo and it seems to work correctly. The only oddity I observed on this
platform is the fact that all interrupts go to CPU 0, even if I disable
IRQ balancing. This platform also has the option "constant_tsc"
displayed in /proc/cpuinfo, it seems to mean that the tsc frequency does
not change when the CPU frequency changes, so it is possible to use
xenomai with cpufreq. I have no experience with intel macs.

--

-- 
                                                 Gilles Chanteperdrix

Re: parallelport module for measuring external interrupt latency

Jan Kiszka wrote:
>>// ISR
>>int parport_isr(xnintr_t* cookie)
>>{
>>	rdtsc(t_end);
>>	
>>	outb(0x00,SPPDATAPORT);
>>	
>>#ifdef DEBUG
>>	printk(KERN_INFO "parport_latency: Interrupt fired!!!\n");
>>	printk(KERN_INFO "parport_latency: interruptcount before = %d!!!\n",atomic_read(&interruptcount));
>>#endif
>>	
>>	atomic_inc(&interruptcount);
>>
>>#ifdef DEBUG
>>	printk(KERN_INFO "parport_latency: interruptcount after= %d!!!\n",atomic_read(&interruptcount));
>>#endif
>>
>>	wake_up_interruptible(&intlatpar_queue);
> 
> 
> This is a hard-RT IRQ handler, thus any scheduling Linux service is
> strictly forbidden.
> 
> [Reminds me of the I-pipe debugging service that can catch such faults
> but still needs some integration work...]

Ok I understand. But somehow I have to notify the read()-call that it
can compute the latency value. Do you have any suggestions how to do that?

Re: parallelport module for measuring external interrupt latency

Markus Franke wrote:
> Jan Kiszka wrote:
>>> // ISR
>>> int parport_isr(xnintr_t* cookie)
>>> {
>>> 	rdtsc(t_end);
>>> 	
>>> 	outb(0x00,SPPDATAPORT);
>>> 	
>>> #ifdef DEBUG
>>> 	printk(KERN_INFO "parport_latency: Interrupt fired!!!\n");
>>> 	printk(KERN_INFO "parport_latency: interruptcount before = %d!!!\n",atomic_read(&interruptcount));
>>> #endif
>>> 	
>>> 	atomic_inc(&interruptcount);
>>>
>>> #ifdef DEBUG
>>> 	printk(KERN_INFO "parport_latency: interruptcount after= %d!!!\n",atomic_read(&interruptcount));
>>> #endif
>>>
>>> 	wake_up_interruptible(&intlatpar_queue);
>>
>> This is a hard-RT IRQ handler, thus any scheduling Linux service is
>> strictly forbidden.
>>
>> [Reminds me of the I-pipe debugging service that can catch such faults
>> but still needs some integration work...]
> 
> Ok I understand. But somehow I have to notify the read()-call that it
> can compute the latency value. Do you have any suggestions how to do that?

Latest SVN version: tasklist_lock not exported with UP

Hi all,

using the latest SVN version (#2039) of Xenomai on a 2.6.19.1 kernel (Pentium 4),
I found out that the build is broken if the nucleus skin is compiled as module and
if UP (and not SMP) is selected.
in arch/i386/kernel/ipipe.c
the EXPORT_SYMBOL(tasklist_lock)
is encapsulated in a #ifdef CONFIG_SMP
which is not true for a UP kernel.

Regards

Mathias

--

-- 
Mathias Koehrer
mathias_koehrer <at> arcor.de

Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  44,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: Latest SVN version: tasklist_lock not exported with UP

On Wed, 2007-01-03 at 14:07 +0100, M. Koehrer wrote:
> Hi all,
> 
> using the latest SVN version (#2039) of Xenomai on a 2.6.19.1 kernel (Pentium 4),
> I found out that the build is broken if the nucleus skin is compiled as module and
> if UP (and not SMP) is selected.
> in arch/i386/kernel/ipipe.c
> the EXPORT_SYMBOL(tasklist_lock)
> is encapsulated in a #ifdef CONFIG_SMP
> which is not true for a UP kernel.

Apply this, or disable CONFIG_DEBUG_SPINLOCK until the fix is merged
into the next I-pipe release:

--- arch/i386/kernel/ipipe.c~	2006-12-21 17:55:47.000000000 +0100
+++ arch/i386/kernel/ipipe.c	2007-01-03 14:42:28.000000000 +0100
 <at>  <at>  -900,8 +900,10  <at>  <at> 
 EXPORT_SYMBOL_GPL(__switch_to);
 EXPORT_SYMBOL_GPL(show_stack);
 EXPORT_PER_CPU_SYMBOL_GPL(init_tss);
-#ifdef CONFIG_SMP
+#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK)
 EXPORT_SYMBOL(tasklist_lock);
+#endif /* CONFIG_SMP || CONFIG_DEBUG_SPINLOCK */
+#ifdef CONFIG_SMP
 EXPORT_SYMBOL(__ipipe_logical_cpuid);
 EXPORT_PER_CPU_SYMBOL_GPL(cpu_tlbstate);
 #endif /* CONFIG_SMP */

>