From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <454B345A.9050606@domain.hid> Date: Fri, 03 Nov 2006 13:21:46 +0100 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Fwd: Re: [Xenomai-help] invalid use of FPU in Xenomai context] References: <4548C170.1000504@domain.hid> <4548F8BE.90809@domain.hid> <454901B6.80606@domain.hid> <454B0FA0.9080307@domain.hid> <454B1363.8080805@domain.hid> <454B15C5.1050803@domain.hid> <454B17A1.7000805@domain.hid> In-Reply-To: <454B17A1.7000805@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDA7EE5E9A3D802555810952B" Sender: jan.kiszka@domain.hid List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: Xenomai help This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDA7EE5E9A3D802555810952B Content-Type: multipart/mixed; boundary="------------020608070803090803040903" This is a multi-part message in MIME format. --------------020608070803090803040903 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable 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 d= ata >>>>> 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 Xeno= mai >>>>>>> pipes. This example uses POSIX message queues, but I had a simil= ar >>>>>>> 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= =2E >>>>>> >>>>>> 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 >=3D= 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 wit= h >>> 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. >=20 > 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. >=20 True. This patch fixes the issue for me. Jan --------------020608070803090803040903 Content-Type: text/plain; name="disable-mmx_memcpy.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="disable-mmx_memcpy.patch" --- arch/i386/lib/mmx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.17.13/arch/i386/lib/mmx.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- 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; =20 - if (unlikely(in_interrupt())) + if (unlikely(!ipipe_root_domain_p || in_interrupt())) return __memcpy(to, from, len); =20 p =3D to; --------------020608070803090803040903-- --------------enigDA7EE5E9A3D802555810952B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFSzRbniDOoMHTA+kRAr1bAJwMM4RM4IhoOAfeOVv7/LGoo/ZDYgCdFjg0 lWa1ZuvuUusbKC4D2AckH5M= =qBOT -----END PGP SIGNATURE----- --------------enigDA7EE5E9A3D802555810952B--