Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> 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. > > This second way would not work correctly with kernel-space threads, so, > if we wanted to implement it, we would still need to disable the mmx > memcpy in string.h for kernel-space threads, i.e. if current is not > safe. >
True. This patch fixes the issue for me. Jan
---
arch/i386/lib/mmx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.17.13/arch/i386/lib/mmx.c
===================================================================
--- linux-2.6.17.13.orig/arch/i386/lib/mmx.c
+++ linux-2.6.17.13/arch/i386/lib/mmx.c
@@ -32,7 +32,7 @@ void *_mmx_memcpy(void *to, const void *
void *p;
int i;
- if (unlikely(in_interrupt()))
+ if (unlikely(!ipipe_root_domain_p || in_interrupt()))
return __memcpy(to, from, len);
p = to;
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
