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@xxxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
