Which version of preempt_realtime to use?

Which version of preempt_realtime to use?

[Esben Nielsen]

Hey,

I am going to suggest that we use preempt_realtime for a _real_ project
(i.e. costumers will depend on it). We will run on standeard x86 (maybe
x86_64) hardware and will only need serial interfaces for realtime
perposes. Security is not an issue. Which version of preempt_realtime
should I pick?

Esben

Re: Which version of preempt_realtime to use?

[Carsten Emde]

Esben,

> I am going to suggest that we use preempt_realtime for a _real_ project
> (i.e. costumers will depend on it). We will run on standeard x86 (maybe
> x86_64) hardware and will only need serial interfaces for realtime
> purposes. Security is not an issue. Which version of preempt_realtime
> should I pick?
The latest and greatest *and* most stable version is 2.6.24.7-rt26. As
far as I know (but maybe others know better), there are no unresolved
issues with this "Latest Stable". The kernel release 2.6.24 may not
contain sufficient architecture support for PPC and ARM, but the large
majority of x86 based processors and chipsets is well supported.

Please report, if anything does not work as expected.

	--Carsten.

Re: Which version of preempt_realtime to use?

[Jürgen Mell]

>
> Esben,
>
>   
>> I am going to suggest that we use preempt_realtime for a _real_ project
>> (i.e. costumers will depend on it). We will run on standeard x86 (maybe
>> x86_64) hardware and will only need serial interfaces for realtime
>> purposes. Security is not an issue. Which version of preempt_realtime
>> should I pick?
>>     
> The latest and greatest *and* most stable version is 2.6.24.7-rt26. As
> far as I know (but maybe others know better), there are no unresolved
> issues with this "Latest Stable". The kernel release 2.6.24 may not
> contain sufficient architecture support for PPC and ARM, but the large
> majority of x86 based processors and chipsets is well supported.
>
> Please report, if anything does not work as expected.
>   
The only thing which is missing for me from the 2.6.24.7-rt series is
the patch
"x86-fpu-fix-config_preempt-y-corruption-of-application-s-fpu-stack.patch"
, GIT commit
 870568b39064cab2dd971fe57969916036982862 from mainline 2.6.25. This
might cause trouble with applications which are using floating point
arithmetics. Otherwise I am using the 2.6.24.7-rt series on a machine
control for a 16 axes machine and it is working mostly well. There are
only some points where I get big delays (up to some milliseconds) with
my timer routine, where normally delays are below 50 microseconds. Up to
now I could not find the application ( X ??) which is causing this.

Bye,
           Jürgen

-- 
Jürgen Mell (Software-Entwicklung)           mell@hedrich.com
Tel.:  +49-511-762-18226                     http://www.hedrich.com
FAX :  +49-511-762-18225
Mobil: +49-160-7428156
--------------------------------------------------------------------------------
HEDRICH winding systems GmbH
An der Universität 2 (im PZH)
D-30823 Garbsen (GERMANY)
--------------------------------------------------------------------------------
Geschäftsführer: Karsten Adam, Markus Gerth, Friedrich Frech
Handelsregister: Wetzlar, HRB 4768
Steuernr.: 020/235/20110                     USt-IdNr.: DE 258258279
-------------------------------------------------------------------------------- 

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Which version of preempt_realtime to use?

[Robert Schwebel]

Jürgen,

On Mon, Jan 19, 2009 at 09:45:58PM +0100, Jürgen Mell wrote:
> The only thing which is missing for me from the 2.6.24.7-rt series is
> the patch
> "x86-fpu-fix-config_preempt-y-corruption-of-application-s-fpu-stack.patch"
> , GIT commit
>  870568b39064cab2dd971fe57969916036982862 from mainline 2.6.25. This
> might cause trouble with applications which are using floating point
> arithmetics. Otherwise I am using the 2.6.24.7-rt series on a machine
> control for a 16 axes machine and it is working mostly well. There are
> only some points where I get big delays (up to some milliseconds) with
> my timer routine, where normally delays are below 50 microseconds. Up to
> now I could not find the application ( X ??) which is causing this.

Can you reproduce these long latencies with cyclictest, or does it only
happen with your code?

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Which version of preempt_realtime to use?

[Pradyumna Sampath]

Hi Robert, Jurgen,

On Tue, Jan 20, 2009 at 1:19 PM, Robert Schwebel
<r.schwebel@pengutronix.de> wrote:
>
> Can you reproduce these long latencies with cyclictest, or does it only
> happen with your code?
>

A few months ago, I had hit some really long latencies when ptpd (1588
time synch) was trying to synchronize from 1970 to the current time.
After the time change we could observe some really long latencies.
Maybe, your device might also be

Here is the post I made about it.
http://marc.info/?l=linux-rt-users&m=122111918015981&w=4

regards
/prady
-- 
http://prady.in

Re: Which version of preempt_realtime to use?

[Esben Nielsen]

On Mon, 2009-01-19 at 21:45 +0100, Jürgen Mell wrote:
> >
> > Esben,
> >
> >   
> >> I am going to suggest that we use preempt_realtime for a _real_ project
> >> (i.e. costumers will depend on it). We will run on standeard x86 (maybe
> >> x86_64) hardware and will only need serial interfaces for realtime
> >> purposes. Security is not an issue. Which version of preempt_realtime
> >> should I pick?
> >>     
> > The latest and greatest *and* most stable version is 2.6.24.7-rt26. As
> > far as I know (but maybe others know better), there are no unresolved
> > issues with this "Latest Stable". The kernel release 2.6.24 may not
> > contain sufficient architecture support for PPC and ARM, but the large
> > majority of x86 based processors and chipsets is well supported.
> >
> > Please report, if anything does not work as expected.
> >   
> The only thing which is missing for me from the 2.6.24.7-rt series is
> the patch
> "x86-fpu-fix-config_preempt-y-corruption-of-application-s-fpu-stack.patch"
> , GIT commit
>  870568b39064cab2dd971fe57969916036982862 from mainline 2.6.25. This
> might cause trouble with applications which are using floating point
> arithmetics. Otherwise I am using the 2.6.24.7-rt series on a machine
> control for a 16 axes machine and it is working mostly well. There are
> only some points where I get big delays (up to some milliseconds) with
> my timer routine, where normally delays are below 50 microseconds. Up to
> now I could not find the application ( X ??) which is causing this.
> 
> Bye,
>            Jürgen
> 

Which GIT-tree are you refering to?

Is there at all an up-to-date GIT repository with preempt realtime?

Esben

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Which version of preempt_realtime to use?

[Jürgen Mell]

Esben Nielsen schrieb:
> On Mon, 2009-01-19 at 21:45 +0100, Jürgen Mell wrote:
>   
>>> Esben,
>>>
>>>   
>>>       
>>>> I am going to suggest that we use preempt_realtime for a _real_ project
>>>> (i.e. costumers will depend on it). We will run on standeard x86 (maybe
>>>> x86_64) hardware and will only need serial interfaces for realtime
>>>> purposes. Security is not an issue. Which version of preempt_realtime
>>>> should I pick?
>>>>     
>>>>         
>>> The latest and greatest *and* most stable version is 2.6.24.7-rt26. As
>>> far as I know (but maybe others know better), there are no unresolved
>>> issues with this "Latest Stable". The kernel release 2.6.24 may not
>>> contain sufficient architecture support for PPC and ARM, but the large
>>> majority of x86 based processors and chipsets is well supported.
>>>
>>> Please report, if anything does not work as expected.
>>>   
>>>       
>> The only thing which is missing for me from the 2.6.24.7-rt series is
>> the patch
>> "x86-fpu-fix-config_preempt-y-corruption-of-application-s-fpu-stack.patch"
>> , GIT commit
>>  870568b39064cab2dd971fe57969916036982862 from mainline 2.6.25. This
>> might cause trouble with applications which are using floating point
>> arithmetics. Otherwise I am using the 2.6.24.7-rt series on a machine
>> control for a 16 axes machine and it is working mostly well. There are
>> only some points where I get big delays (up to some milliseconds) with
>> my timer routine, where normally delays are below 50 microseconds. Up to
>> now I could not find the application ( X ??) which is causing this.
>>
>> Bye,
>>            Jürgen
>>
>>     
>
> Which GIT-tree are you refering to?
>   
The patch was included in the standard mainline kernel 2.6.25.
> Is there at all an up-to-date GIT repository with preempt realtime?
>   

As far as know, the RT tree is maintained now in a GIT repository, but I 
do not know whether it is ready to use already.

  Jürgen

-- 
Jürgen Mell (Software-Entwicklung)           mell@hedrich.com
Tel.:  +49-511-762-18226                     http://www.hedrich.com
FAX :  +49-511-762-18225
Mobil: +49-160-7428156
--------------------------------------------------------------------------------
HEDRICH winding systems GmbH
An der Universität 2 (im PZH)
D-30823 Garbsen (GERMANY)
--------------------------------------------------------------------------------
Geschäftsführer: Karsten Adam, Markus Gerth, Friedrich Frech
Handelsregister: Wetzlar, HRB 4768
Steuernr.: 020/235/20110                     USt-IdNr.: DE 258258279
-------------------------------------------------------------------------------- 


--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Which version of preempt_realtime to use?

[Thomas Gleixner]

Prady,

On Tue, 20 Jan 2009, Pradyumna Sampath wrote:

> Hi Robert, Jurgen,
> 
> On Tue, Jan 20, 2009 at 1:19 PM, Robert Schwebel
> <r.schwebel@pengutronix.de> wrote:
> >
> > Can you reproduce these long latencies with cyclictest, or does it only
> > happen with your code?
> >
> 
> A few months ago, I had hit some really long latencies when ptpd (1588
> time synch) was trying to synchronize from 1970 to the current time.
> After the time change we could observe some really long latencies.
> Maybe, your device might also be
> 
> Here is the post I made about it.
> http://marc.info/?l=linux-rt-users&m=122111918015981&w=4

Fix for the kernel warning is below. The warning is a false positive
caused by the huge time jump.

You said that your application is showing weird behaviour after the
time was set. 

Is your application using CLOCK_REALTIME ABSTIME timers ? We have had
bug reports in the past where people run into problems with code like
that:

	while (1) {
	      clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &next, NULL);
	      ...
	      next += interval;
	}

If the clock is set into the future then the above loop will try to
catch up for quite a while until next is past now. Using
CLOCK_REALTIME/ABSTIME timers needs to be aware of the fact that
CLOCK_REALTIME can be set and handle such a case gracefully.

Thanks,

	tglx
---

Subject: hrtimer: prevent negative expiry value after clock_was_set()
From: Thomas Gleixner <tglx@linutronix.de>
Date: Sun, 25 Jan 2009 11:31:36 +0100

Impact: prevent false positive WARN_ON() in clockevents_program_event()

clock_was_set() changes the base->offset of CLOCK_REALTIME and
enforces the reprogramming of the clockevent device to expire timers
which are based on CLOCK_REALTIME. If the clock change is large enough
then the subtraction of the timer expiry value and base->offset can
become negative which triggers the warning in
clockevents_program_event(). 

Check the subtraction result and set a negative value to 0.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 kernel/hrtimer.c |    7 +++++++
 1 file changed, 7 insertions(+)

Index: linux-2.6-rt/kernel/hrtimer.c
===================================================================
--- linux-2.6-rt.orig/kernel/hrtimer.c
+++ linux-2.6-rt/kernel/hrtimer.c
@@ -405,6 +405,13 @@ static void hrtimer_force_reprogram(stru
 			continue;
 		timer = rb_entry(base->first, struct hrtimer, node);
 		expires = ktime_sub(timer->expires, base->offset);
+		/*
+		 * clock_was_set has changed base->offset, so the
+		 * result might be negative. Fix it up to prevent a
+		 * false positive in clockevents_program_event()
+		 */
+		if (expires.tv64 < 0)
+			expires.tv64 = 0;
 		if (expires.tv64 < cpu_base->expires_next.tv64)
 			cpu_base->expires_next = expires;
 	}

Re: Which version of preempt_realtime to use?

[Jürgen Mell]

Esben,
> On Mon, 2009-01-19 at 21:45 +0100, Jürgen Mell wrote:
>   
>>> Esben,
>>>
>>>   
>>>       
>>>> I am going to suggest that we use preempt_realtime for a _real_ project
>>>> (i.e. costumers will depend on it). We will run on standeard x86 (maybe
>>>> x86_64) hardware and will only need serial interfaces for realtime
>>>> purposes. Security is not an issue. Which version of preempt_realtime
>>>> should I pick?
>>>>     
>>>>         
>>> The latest and greatest *and* most stable version is 2.6.24.7-rt26. As
>>> far as I know (but maybe others know better), there are no unresolved
>>> issues with this "Latest Stable". The kernel release 2.6.24 may not
>>> contain sufficient architecture support for PPC and ARM, but the large
>>> majority of x86 based processors and chipsets is well supported.
>>>
>>> Please report, if anything does not work as expected.
>>>   
>>>       
>> The only thing which is missing for me from the 2.6.24.7-rt series is
>> the patch
>> "x86-fpu-fix-config_preempt-y-corruption-of-application-s-fpu-stack.patch"
>> , GIT commit
>>  870568b39064cab2dd971fe57969916036982862 from mainline 2.6.25. This
>> might cause trouble with applications which are using floating point
>> arithmetics. Otherwise I am using the 2.6.24.7-rt series on a machine
>> control for a 16 axes machine and it is working mostly well. There are
>> only some points where I get big delays (up to some milliseconds) with
>> my timer routine, where normally delays are below 50 microseconds. Up to
>> now I could not find the application ( X ??) which is causing this.
>>
>> Bye,
>>            Jürgen
>>
>>     
Thomas Gleixner, Carsten Emde and OSADL helped to track down the
problem. The latency occurs while the X server is calling cache
invalidate instructions in the drm code. According to Thomas, this is a
known problem and might be addressed in later kernel versions. Thomas is
clarifying the situation with the drm developers.

For the time being, I disabled the i810 drm driver and switched to the
standard framebuffer device. My test machine is running now for two days
with a maximum latency detected by cyclictest of 110 micro-seconds (38
µs average), which is completely suitable for my application. The
performance impact of the frame buffer driver versus the i810 driver is
not too bad so I can live pretty well with this solution.

Many thanks to Thomas, Carsten and the people at OSADL for their help!

Bye,
              Jürgen

-- 
Jürgen Mell (Software-Entwicklung)           mell@hedrich.com
Tel.:  +49-511-762-18226                     http://www.hedrich.com
FAX :  +49-511-762-18225
Mobil: +49-160-7428156
--------------------------------------------------------------------------------
HEDRICH winding systems GmbH
An der Universität 2 (im PZH)
D-30823 Garbsen (GERMANY)
--------------------------------------------------------------------------------
Geschäftsführer: Karsten Adam, Markus Gerth, Friedrich Frech
Handelsregister: Wetzlar, HRB 4768
Steuernr.: 020/235/20110                     USt-IdNr.: DE 258258279
-------------------------------------------------------------------------------- 

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html