Re: Which version of preempt_realtime to use?

["Jürgen Mell" <mell@hedrich-winders.com>]

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