From owner-svn-src-all@freebsd.org Fri Oct 2 14:26:14 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 023DCA0D22D for ; Fri, 2 Oct 2015 14:26:14 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE2541F0F for ; Fri, 2 Oct 2015 14:26:13 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Fri, 2 Oct 2015 14:26:53 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t92EQAJg020591; Fri, 2 Oct 2015 08:26:10 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1443795970.66572.68.camel@freebsd.org> Subject: Re: svn commit: r288492 - head/sys/arm/arm From: Ian Lepore To: Konstantin Belousov Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Fri, 02 Oct 2015 08:26:10 -0600 In-Reply-To: <201510021326.t92DQ0Ds002986@repo.freebsd.org> References: <201510021326.t92DQ0Ds002986@repo.freebsd.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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: Fri, 02 Oct 2015 14:26:14 -0000 On Fri, 2015-10-02 at 13:26 +0000, Konstantin Belousov wrote: > Author: kib > Date: Fri Oct 2 13:25:59 2015 > New Revision: 288492 > URL: https://svnweb.freebsd.org/changeset/base/288492 > > Log: > Do not set 'flush to zero' VFPSCR_FZ bit by default. The correct > implementation of IEEE 754 arithmetic depends on denormals operating > correctly. Both perl test suite and paranoia tripped over the > setting. > > Reported by: Stefan Parvu > Discussed with: andrew > Sponsored by: The FreeBSD Foundation > MFC after: 1 week > > Modified: > head/sys/arm/arm/machdep.c > head/sys/arm/arm/vm_machdep.c > > Modified: head/sys/arm/arm/machdep.c > ============================================================================== > --- head/sys/arm/arm/machdep.c Fri Oct 2 13:21:08 2015 (r288491) > +++ head/sys/arm/arm/machdep.c Fri Oct 2 13:25:59 2015 (r288492) > @@ -1069,7 +1069,7 @@ init_proc0(vm_offset_t kstack) > (thread0.td_kstack + kstack_pages * PAGE_SIZE) - 1; > thread0.td_pcb->pcb_flags = 0; > thread0.td_pcb->pcb_vfpcpu = -1; > - thread0.td_pcb->pcb_vfpstate.fpscr = VFPSCR_DN | VFPSCR_FZ; > + thread0.td_pcb->pcb_vfpstate.fpscr = VFPSCR_DN; > thread0.td_frame = &proc0_tf; > pcpup->pc_curpcb = thread0.td_pcb; > } > > Modified: head/sys/arm/arm/vm_machdep.c > ============================================================================== > --- head/sys/arm/arm/vm_machdep.c Fri Oct 2 13:21:08 2015 (r288491) > +++ head/sys/arm/arm/vm_machdep.c Fri Oct 2 13:25:59 2015 (r288492) > @@ -134,7 +134,7 @@ cpu_fork(register struct thread *td1, re > pcb2->pcb_regs.sf_sp = STACKALIGN(td2->td_frame); > > pcb2->pcb_vfpcpu = -1; > - pcb2->pcb_vfpstate.fpscr = VFPSCR_DN | VFPSCR_FZ; > + pcb2->pcb_vfpstate.fpscr = VFPSCR_DN; > > tf = td2->td_frame; > tf->tf_spsr &= ~PSR_C; > 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 happens 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 required 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. 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 processors and they say the hardware handles all combinations of rounding and flush 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. -- Ian