From owner-freebsd-amd64@FreeBSD.ORG Tue Sep 23 08:53:52 2003 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7E7F16A4B3 for ; Tue, 23 Sep 2003 08:53:52 -0700 (PDT) Received: from cri.ensmp.fr (orgenoy.ensmp.fr [193.48.171.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23C6943FE9 for ; Tue, 23 Sep 2003 08:53:51 -0700 (PDT) (envelope-from silber@cri.ensmp.fr) Received: from cri.ensmp.fr (silber@marseille [10.2.14.130]) by cri.ensmp.fr (8.11.2/8.11.2/mx-cri-CRI) with ESMTP id h8NFrnn23470 for ; Tue, 23 Sep 2003 17:53:49 +0200 (MEST) Message-ID: <3F7057AF.2050804@cri.ensmp.fr> Date: Tue, 23 Sep 2003 16:24:47 +0200 From: "G.A. Silber" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: FreeBSD 5.1/amd64 on Bi-opteron platform X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2003 15:53:52 -0000 Hello; I'd like to install FreeBSD 5.1/Amd64 on my bi-opteron workstation. I've tried with the FreeBSD mini-iso install disk for amd64 (5.1-RELEASE) but the kernel is crashing at the beginning of the loading procedure with the following error-message: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xffff807fffe78000 fault code = supervisor write, page not present [...] Stopped at 0xffffffffc0464654: decl %ecx The configuration is: - RioWorks HDAMA motherboard * Dual AMD Opteron CPU Socket-940 solution * Supports up to 16GB Registered DDR333 * Integrated ATI RageXL video controller with 8MB memory * Dual Broadcom5702 Gigabit Ethernet controllers onboard * Promise PDC20319, 4-port Serial ATA with RAID 0, 1, 10 - Dual Opteron 244 1.8 GHz - 8 GB RAM ECC - Adaptec SCSI Card 39320-R The station works well with Debian GNU/Linux SMP but in 32 bit mode. Georges. -- Georges-Andre.Silber@ensmp.fr http://www.cri.ensmp.fr/~silber Centre de recherche en informatique, Ecole des mines de Paris 35, rue Saint-Honore, 77305 Fontainebleau cedex, France. ---- Tel: +33(0)1 64 69 48 36 ---------- Fax: +33 (0)1 64 69 48 47 From owner-freebsd-amd64@FreeBSD.ORG Fri Sep 26 07:03:01 2003 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AC8F16A4B3 for ; Fri, 26 Sep 2003 07:03:01 -0700 (PDT) Received: from walton.kettenis.dyndns.org (e115144.upc-e.chello.nl [213.93.115.144]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B3E343FDF for ; Fri, 26 Sep 2003 07:02:59 -0700 (PDT) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2])h8QE2vaM000336 for ; Fri, 26 Sep 2003 16:02:57 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) h8QE2voN055117 for ; Fri, 26 Sep 2003 16:02:57 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost)h8QE2u0R055089; Fri, 26 Sep 2003 16:02:56 +0200 (CEST) Date: Fri, 26 Sep 2003 16:02:56 +0200 (CEST) Message-Id: <200309261402.h8QE2u0R055089@elgar.kettenis.dyndns.org> From: Mark Kettenis To: freebsd-amd64@freebsd.org Subject: Broken PTRACE_GETFPREGS and PTRACE_SETFPREGS X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2003 14:03:01 -0000 Hi folks, The PTRACE_GETFPREGS and PTRACE_SETFPREGS requests are broken on FreeBSD/amd64. In particular, using PTRACE_SETFPREGS is pointless until the program beging traced has executed its first floating-point instruction; that floating-point instruction will reinitialize the precess' floating-point state, overwriting the values set by PTRACE_SETFPREGS. I traced this back to src/sys/amd64/amd64/machdep.c:fill_fpregs() where we read the floating-point state from the pcb, regardless of whether PCB_NPXINITDONE has been set, and set_fpregs() where we don't set PCB_NPXINITDONE, and fail to properly set the floating-point registers if the current process "owns" the FPU. This probably means that /proc is broken too. What puzzles me is that the amd64 code is pretty much identical to the i386, and that everything appears to be working fine there, at least with GDB. The only thing I can think of is that every process executes a floating-point instruction before reaching main(). However, I haven't been able to find such an instruction. Anyway, I think the code is incorrect on the i386 too, and that we just happen not to notice where it matters. The attached patch fixes things for me. The functions fill_fpregs_xmm() and set_fpregs_xmm() can probably be eliminated passing fpregs directly to npxgetregs and npxsetregs. I'll open a bug report with this info. Mark --- src/sys/amd64/amd64/machdep.c.orig Tue Sep 9 21:32:09 2003 +++ src/sys/amd64/amd64/machdep.c Sat Sep 20 11:47:19 2003 @@ -1413,8 +1413,10 @@ set_fpregs_xmm(struct fpreg *fpregs, str int fill_fpregs(struct thread *td, struct fpreg *fpregs) { + struct savefpu sv_xmm; - fill_fpregs_xmm(&td->td_pcb->pcb_save, fpregs); + npxgetregs(td, &sv_xmm); + fill_fpregs_xmm(&sv_xmm, fpregs); return (0); } @@ -1422,8 +1424,10 @@ fill_fpregs(struct thread *td, struct fp int set_fpregs(struct thread *td, struct fpreg *fpregs) { + struct savefpu sv_xmm; - set_fpregs_xmm(fpregs, &td->td_pcb->pcb_save); + set_fpregs_xmm(fpregs, &sv_xmm); + npxsetregs(td, &sv_xmm); return (0); } --- src/sys/amd64/isa/npx.c.orig Fri Jul 25 23:18:52 2003 +++ src/sys/amd64/isa/npx.c Sat Sep 20 11:47:19 2003 @@ -646,7 +646,7 @@ npxsetregs(td, addr) intr_restore(s); bcopy(addr, &td->td_pcb->pcb_save, sizeof(*addr)); } - curthread->td_pcb->pcb_flags |= PCB_NPXINITDONE; + td->td_pcb->pcb_flags |= PCB_NPXINITDONE; } static device_method_t npx_methods[] = { From owner-freebsd-amd64@FreeBSD.ORG Fri Sep 26 07:20:04 2003 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BDC016A4BF for ; Fri, 26 Sep 2003 07:20:04 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F15643FE0 for ; Fri, 26 Sep 2003 07:20:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h8QEK1FY018925 for ; Fri, 26 Sep 2003 07:20:01 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h8QEK1sX018924; Fri, 26 Sep 2003 07:20:01 -0700 (PDT) (envelope-from gnats) Resent-Date: Fri, 26 Sep 2003 07:20:01 -0700 (PDT) Resent-Message-Id: <200309261420.h8QEK1sX018924@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Mark Kettenis Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C587416A4B3 for ; Fri, 26 Sep 2003 07:12:03 -0700 (PDT) Received: from walton.kettenis.dyndns.org (e115144.upc-e.chello.nl [213.93.115.144]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12A154400B for ; Fri, 26 Sep 2003 07:12:02 -0700 (PDT) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2])h8QEC1aM000349 for ; Fri, 26 Sep 2003 16:12:01 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) h8QEBsoN012104 for ; Fri, 26 Sep 2003 16:11:54 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost)h8QEBrKY012055; Fri, 26 Sep 2003 16:11:53 +0200 (CEST) Message-Id: <200309261411.h8QEBrKY012055@elgar.kettenis.dyndns.org> Date: Fri, 26 Sep 2003 16:11:53 +0200 (CEST) From: Mark Kettenis To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: amd64/57250: Broken PTRACE_GETFPREGS and PTRACE_SETFPREGS X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Mark Kettenis List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2003 14:20:04 -0000 >Number: 57250 >Category: amd64 >Synopsis: Broken PTRACE_GETFPREGS and PTRACE_SETFPREGS >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Sep 26 07:20:01 PDT 2003 >Closed-Date: >Last-Modified: >Originator: Mark Kettenis >Release: FreeBSD 5.1-CURRENT amd64 >Organization: >Environment: System: FreeBSD delius.kettenis.dyndns.org 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Sep 21 23:09:00 CEST 2003 kettenis@delius.kettenis.dyndns.org:/usr/obj/usr/src/sys/GENERIC amd64 >Description: The PTRACE_GETFPREGS and PTRACE_SETFPREGS requests are broken on FreeBSD/amd64. In particular, using PTRACE_SETFPREGS is pointless until the program beging traced has executed its first floating-point instruction; that floating-point instruction will reinitialize the precess' floating-point state, overwriting the values set by PTRACE_SETFPREGS. I traced this back to src/sys/amd64/amd64/machdep.c:fill_fpregs() where we read the floating-point state from the pcb, regardless of whether PCB_NPXINITDONE has been set, and set_fpregs() where we don't set PCB_NPXINITDONE, and fail to properly set the floating-point registers if the current process "owns" the FPU. This probably means that /proc is broken too. What puzzles me is that the amd64 code is pretty much identical to the i386, and that everything appears to be working fine there, at least with GDB. The only thing I can think of is that every process executes a floating-point instruction before reaching main(). However, I haven't been able to find such an instruction. Anyway, I think the code is incorrect on the i386 too, and that we just happen not to notice where it matters. >How-To-Repeat: Using GDB, in a function that returns a floating-point value, type "return 3.1415". The caller of this function will see garbage instead of this value. >Fix: The attached patch fixes things for me. The functions fill_fpregs_xmm() and set_fpregs_xmm() can probably be eliminated passing fpregs directly to npxgetregs and npxsetregs. --- src/sys/amd64/amd64/machdep.c.orig Tue Sep 9 21:32:09 2003 +++ src/sys/amd64/amd64/machdep.c Sat Sep 20 11:47:19 2003 @@ -1413,8 +1413,10 @@ set_fpregs_xmm(struct fpreg *fpregs, str int fill_fpregs(struct thread *td, struct fpreg *fpregs) { + struct savefpu sv_xmm; - fill_fpregs_xmm(&td->td_pcb->pcb_save, fpregs); + npxgetregs(td, &sv_xmm); + fill_fpregs_xmm(&sv_xmm, fpregs); return (0); } @@ -1422,8 +1424,10 @@ fill_fpregs(struct thread *td, struct fp int set_fpregs(struct thread *td, struct fpreg *fpregs) { + struct savefpu sv_xmm; - set_fpregs_xmm(fpregs, &td->td_pcb->pcb_save); + set_fpregs_xmm(fpregs, &sv_xmm); + npxsetregs(td, &sv_xmm); return (0); } --- src/sys/amd64/isa/npx.c.orig Fri Jul 25 23:18:52 2003 +++ src/sys/amd64/isa/npx.c Sat Sep 20 11:47:19 2003 @@ -646,7 +646,7 @@ npxsetregs(td, addr) intr_restore(s); bcopy(addr, &td->td_pcb->pcb_save, sizeof(*addr)); } - curthread->td_pcb->pcb_flags |= PCB_NPXINITDONE; + td->td_pcb->pcb_flags |= PCB_NPXINITDONE; } static device_method_t npx_methods[] = { >Release-Note: >Audit-Trail: >Unformatted: