Jan Kiszka wrote:
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).
I see other ways to solve this issue:
- either we disable the use of the mmx memcpy in string.h if
ipipe_current_domain is not root
- or we allow the exception to happen for threads in primary mode with
the XNFPU bit set and call xnarch_restore_fpu in xnpod_fault_handler in
this case.
--
Gilles Chanteperdrix
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
