Re: [Fwd: Re: [Xenomai-help] invalid use of FPU in Xenomai context]

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]

Jeff Webb wrote:
> Jan Kiszka wrote:
>> Jeff Webb wrote:
>>> Does anyone else have an AMD system that can verify my results?
>>
>> I have an old Athlon 800. Maybe we are lucky and it exposes the problem
>> when the kernel is optimised for it. I'm going to give this a try, but
>> it may take a few days (and a free time slot).
> 
> Thank you.  I appreciate you giving it a try when you get some free
> time.  I was able to work around the problem by writing the queue data
> in smaller chunks (or use an i686 kernel), so I am not in urgent need of
> an immediate fix.  I do think it's important to fix this bug eventually,
> so I didn't want it to slip through the cracks.
> 
>>> The problem seems to be connected with the size of writes to Xenomai
>>> pipes.  This example uses POSIX message queues, but I had a similar
>>> problem a while back with RTAI pipes.  Maybe this tells us the problem
>>> is in the nucleus pipe code?  Just a guess.  The problem seems to affect
>>> both 2.4 and 2.6 systems, and goes back to at least Xenomai 2.2.1.
>>
>> Maybe, maybe not. Pipes remain fairly unrelated to FPU usage, so there
>> is still /at least/ one piece missing in the puzzle.
> 
> True.  It is very strange that the amount of data in the write call ends
> up affecting the FPU context.

I found the reason: "3-dimensional" memcpy (__memcpy3d/_mmx_memcpy)

http://lxr.free-electrons.com/source/include/asm-i386/string.h#285

It's an optimised memcpy for 3DNow CPUs that is used with blocks >= 512
bytes. It messes up with the FPU state and may get trapped by other
issues as well (blind access to "current" in order to test
in_interrupt()). I don't have an answer for this right now beyond "don't
switch on AMD optimisations when using Xenomai". But that's a bit
unsatisfying.

Another way would be to wrap any memcpy access from Xenomai context, but
that's likely impractical (think of all the drivers).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]