Gilles Chanteperdrix wrote: > 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
This is what came to my mind as well meanwhile. > - 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. Given that this is a special case for a subset of x86[_64] CPUs, I rather think we should go for the first variant. Should be simpler. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
