From owner-svn-src-all@freebsd.org Sun Oct 4 07:25:29 2015 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EFB9EA0F3B7; Sun, 4 Oct 2015 07:25:29 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id DA70D1FDC; Sun, 4 Oct 2015 07:25:29 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 2C4E41975; Sun, 4 Oct 2015 07:25:29 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sun, 4 Oct 2015 07:25:27 +0000 From: Glen Barber To: Konstantin Belousov Cc: Ian Lepore , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r288492 - head/sys/arm/arm Message-ID: <20151004072527.GF24586@FreeBSD.org> References: <201510021326.t92DQ0Ds002986@repo.freebsd.org> <1443795970.66572.68.camel@freebsd.org> <20151002152059.GY11284@kib.kiev.ua> <1443803276.66572.72.camel@freebsd.org> <20151003070256.GD11284@kib.kiev.ua> <20151003073040.GE11284@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Zi0sgQQBxRFxMTsj" Content-Disposition: inline In-Reply-To: <20151003073040.GE11284@kib.kiev.ua> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 07:25:30 -0000 --Zi0sgQQBxRFxMTsj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 03, 2015 at 10:30:40AM +0300, Konstantin Belousov wrote: > On Sat, Oct 03, 2015 at 10:02:56AM +0300, Konstantin Belousov wrote: > > On Fri, Oct 02, 2015 at 10:27:56AM -0600, Ian Lepore wrote: > > > On Fri, 2015-10-02 at 18:20 +0300, Konstantin Belousov wrote: > > > > On Fri, Oct 02, 2015 at 08:26:10AM -0600, Ian Lepore wrote: > > > > > Some arm documentation refers to the need for "support code" when= the > > > > > flush-to-zero option is disabled on VFPv2 hardware (which for us = would > > > > > be just the RPi I think). Do we have that support code? What ha= ppens > > > > > if it's missing? I can't actually find any info on exactly what = that > > > > > support code is supposed to do. For all I know, we have the requ= ired > > > > > code in libm. Or maybe what's needed is exception-handling code = in the > > > > > kernel. I can't find any info on what they mean by "support code= " in > > > > > this context. > > > > The fpscr register is user-modifiable, so whatever happens after the > > > > change, could as well happen before it. > > > >=20 > > > > I saw the references to the support code in e.g. ARM v7-A A2.7.5 > > > > Flush-to-zero. But I was sure that the text refers to the modes when > > > > e.g. FZ is cleared and UFE or IXE bits are enabled. In this situati= on, > > > > fault handler must do something to allow the computation to proceed. > > > >=20 > > > > >=20 > > > > > I don't think this is an issue for VFPv3 and later hardware. I've > > > > > looked in a few of the TRMs for different cortex-a series process= ors and > > > > > they say the hardware handles all combinations of rounding and fl= ush to > > > > > zero without support software. But we should probably be on the = lookout > > > > > for reports of misbehaving apps on RPi after this change, just in= case > > > > > this setting has been protecting us from our ignorance there. > > > >=20 > > > > I did found the reference to the support code in the VFP11 TRM, whi= ch in > > > > turns point to > > > > http://infocenter.arm.com/help/index.jsp?topic=3D/com.arm.doc.epm04= 9219/index.html > > > > Does FreeBSD enable and handle this variant of coprocessor ? If ye= s, then > > > > indeed I would need to not enable FZ on the affected hardware. > > > >=20 > > >=20 > > > That link opened a reference to a cortex-a57 chip for me. I've had > > > problems trying to share links to arm's documentation site, something > > > about the way that navbar stuff works makes pasting links not-work. > > I tried to reference > > App Notes and tutorials -> All Application Notes -> AN098 - VFP > > Support Code > >=20 > > >=20 > > > We support one arm11/VFPv2 chipset, the one used on RPi. It's the on= ly > > > actual armv6 chip we support, all the other stuff supported by the ar= ch > > > we call armv6 is really armv7. The TRM for the arm1176JZF-S core used > > > on RPi is the one that mentions needing support code. > >=20 > > Yes, testing on original RPi, done by Glen, demostrates it. The test > > program I used is at > > https://www.kib.kiev.ua/kib/perl_opbasic_arith_175.c > > https://www.kib.kiev.ua/kib/perl_opbasic_arith_175 is the compiled bina= ry > > with -mfloat-abi=3Dsoftfp > >=20 > > Also the following untested on RPi patch should fix this. I verified > > that it still starts with FZ bit cleared, on VFP v3 (RPi 2): > > https://www.kib.kiev.ua/kib/rpi-fz.1.patch > Use https://www.kib.kiev.ua/kib/rpi-fz.2.patch instead, VFP v3 might also > declare that denormals are not supported in hw, apparently. >=20 With the rpi-fz.2.patch applied, cron no longer dumps core, and the perl_opbasic_arith_175.f runs successfully without floating exception. Glen --Zi0sgQQBxRFxMTsj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWENRiAAoJEAMUWKVHj+KTJN4QAJZIgN47ckI97aA9E3hs7xJm ILTy6+ymFo/qGwF3fb7WOynT09iDvqRSnvRlUpVZZG3sFAKH/qHaQ/sjo5BChZND yXq5YIIGjeN+B40143OxeLpzhdQldL6t9Qshqjv3ONOd//hDpAAiqQhHVkdqYR6N AEYsw+01K9apUmzLVBr7qjGwqHb2XQHxy+1VF6EXLI3jV/Inp+GLEgI1NKdeHlMw oyQw2gkkGKy7iY7HvMzWr1gA33J5n3oGsHKT1y0c6VVDh66MDMMZNko0KYBFc7Gz ELXK72ry1zI5HrMUgytQZz3I644q57Qw0dN3ij1/6v6EbQcTufe2bzaPw8JIn2yW BGUwMQ7r/gXNmN3bq/QrSxb7PWnagVbKiFo7uPopEI1Ddw4LNz7CT167tyZ5085z xp1BxHj7VhUbrhfWDwmR9MZgBpG85Qz8nLw7TlETW8NQJCEVguzR0Hy8719TuF4s GVlG7Ufv8TlYUM7fwI6Rwu/iGRBefMuuH4I1egJvGVpC1i91Cz/z98FX7n6TQQAb wRmo42bwzqwL8wBtupm9RwjCBwMXcLSYuBol5hrbI9qIqsv6tsjWDOLRrX5Hmgko XyyU1kVLn6RXubQHONof8v7ap0LCQPJvOEsNQdBNL2XasENKGcb1xf80UO4P+LNI /FEQ3fvw4HmBo2vpPnSD =qsc+ -----END PGP SIGNATURE----- --Zi0sgQQBxRFxMTsj--