From owner-freebsd-amd64@FreeBSD.ORG Mon Jul 16 02:18:20 2012 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D34E106566B; Mon, 16 Jul 2012 02:18:20 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0034E8FC0C; Mon, 16 Jul 2012 02:18:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6G2IJLm008226; Mon, 16 Jul 2012 02:18:19 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6G2IJJA008222; Mon, 16 Jul 2012 02:18:19 GMT (envelope-from linimon) Date: Mon, 16 Jul 2012 02:18:19 GMT Message-Id: <201207160218.q6G2IJJA008222@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-ports-bugs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: ports/169734: net-p2p/rtorrent to 0.9.2. freeze X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 02:18:20 -0000 Old Synopsis: rtorrent to 0.9.2. freeze New Synopsis: net-p2p/rtorrent to 0.9.2. freeze Responsible-Changed-From-To: freebsd-amd64->freebsd-ports-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jul 16 02:17:50 UTC 2012 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=169734 From owner-freebsd-amd64@FreeBSD.ORG Mon Jul 16 03:13:06 2012 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D64291065677; Mon, 16 Jul 2012 03:13:06 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 904D28FC1A; Mon, 16 Jul 2012 03:13:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6G3D6BE015922; Mon, 16 Jul 2012 03:13:06 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6G3D6Qw015918; Mon, 16 Jul 2012 03:13:06 GMT (envelope-from linimon) Date: Mon, 16 Jul 2012 03:13:06 GMT Message-Id: <201207160313.q6G3D6Qw015918@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-bugs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: bin/169779: [patch] powerd(8) doesn't honor the -n flag X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 03:13:07 -0000 Old Synopsis: [patch] powerd doesn't honor the -n flag New Synopsis: [patch] powerd(8) doesn't honor the -n flag Responsible-Changed-From-To: freebsd-amd64->freebsd-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jul 16 03:12:31 UTC 2012 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=169779 From owner-freebsd-amd64@FreeBSD.ORG Mon Jul 16 03:54:41 2012 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 962D710657C6; Mon, 16 Jul 2012 03:54:41 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6573D8FC1D; Mon, 16 Jul 2012 03:54:41 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6G3sewN085740; Sun, 15 Jul 2012 23:54:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6G3seb6085735; Mon, 16 Jul 2012 03:54:40 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 16 Jul 2012 03:54:40 GMT Message-Id: <201207160354.q6G3seb6085735@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 03:54:41 -0000 TB --- 2012-07-16 01:30:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-16 01:30:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-16 01:30:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-07-16 01:30:00 - cleaning the object tree TB --- 2012-07-16 01:30:00 - cvsupping the source tree TB --- 2012-07-16 01:30:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-07-16 01:31:09 - building world TB --- 2012-07-16 01:31:09 - CROSS_BUILD_TESTING=YES TB --- 2012-07-16 01:31:09 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-16 01:31:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-16 01:31:09 - SRCCONF=/dev/null TB --- 2012-07-16 01:31:09 - TARGET=amd64 TB --- 2012-07-16 01:31:09 - TARGET_ARCH=amd64 TB --- 2012-07-16 01:31:09 - TZ=UTC TB --- 2012-07-16 01:31:09 - __MAKE_CONF=/dev/null TB --- 2012-07-16 01:31:09 - cd /src TB --- 2012-07-16 01:31:09 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 16 01:31:10 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -fno-strict-aliasing -DIPSEC -DSCTP -DINET6 -DNETGRAPH -DIPX -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/netstat/atalk.c cc -O2 -pipe -fno-strict-aliasing -DIPSEC -DSCTP -DINET6 -DNETGRAPH -DIPX -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/netstat/mroute6.c cc -O2 -pipe -fno-strict-aliasing -DIPSEC -DSCTP -DINET6 -DNETGRAPH -DIPX -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/netstat/ipsec.c cc -O2 -pipe -fno-strict-aliasing -DIPSEC -DSCTP -DINET6 -DNETGRAPH -DIPX -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/netstat/bpf.c cc -O2 -pipe -fno-strict-aliasing -DIPSEC -DSCTP -DINET6 -DNETGRAPH -DIPX -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/netstat/pfkey.c cc -O2 -pipe -fno-strict-aliasing -DIPSEC -DSCTP -DINET6 -DNETGRAPH -DIPX -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/netstat/sctp.c /src/usr.bin/netstat/sctp.c: In function 'sctp_print_address': /src/usr.bin/netstat/sctp.c:201: error: 'union sctp_sockstore' has no member named 'sin' *** Error code 1 Stop in /src/usr.bin/netstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-16 03:54:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-16 03:54:40 - ERROR: failed to build world TB --- 2012-07-16 03:54:40 - 6289.46 user 871.78 system 8679.97 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-amd64@FreeBSD.ORG Mon Jul 16 08:49:17 2012 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 80B2F106578D; Mon, 16 Jul 2012 08:49:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 470DC8FC1B; Mon, 16 Jul 2012 08:49:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6G8nGL4045503; Mon, 16 Jul 2012 04:49:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6G8nGmR045500; Mon, 16 Jul 2012 08:49:16 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 16 Jul 2012 08:49:16 GMT Message-Id: <201207160849.q6G8nGmR045500@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 08:49:17 -0000 TB --- 2012-07-16 06:10:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-16 06:10:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-16 06:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-07-16 06:10:00 - cleaning the object tree TB --- 2012-07-16 06:14:50 - cvsupping the source tree TB --- 2012-07-16 06:14:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-07-16 06:21:01 - building world TB --- 2012-07-16 06:21:01 - CROSS_BUILD_TESTING=YES TB --- 2012-07-16 06:21:01 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-16 06:21:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-16 06:21:01 - SRCCONF=/dev/null TB --- 2012-07-16 06:21:01 - TARGET=amd64 TB --- 2012-07-16 06:21:01 - TARGET_ARCH=amd64 TB --- 2012-07-16 06:21:01 - TZ=UTC TB --- 2012-07-16 06:21:01 - __MAKE_CONF=/dev/null TB --- 2012-07-16 06:21:01 - cd /src TB --- 2012-07-16 06:21:01 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 16 06:21:02 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -fno-strict-aliasing -DIPSEC -DSCTP -DINET6 -DNETGRAPH -DIPX -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/netstat/atalk.c cc -O2 -pipe -fno-strict-aliasing -DIPSEC -DSCTP -DINET6 -DNETGRAPH -DIPX -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/netstat/mroute6.c cc -O2 -pipe -fno-strict-aliasing -DIPSEC -DSCTP -DINET6 -DNETGRAPH -DIPX -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/netstat/ipsec.c cc -O2 -pipe -fno-strict-aliasing -DIPSEC -DSCTP -DINET6 -DNETGRAPH -DIPX -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/netstat/bpf.c cc -O2 -pipe -fno-strict-aliasing -DIPSEC -DSCTP -DINET6 -DNETGRAPH -DIPX -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/netstat/pfkey.c cc -O2 -pipe -fno-strict-aliasing -DIPSEC -DSCTP -DINET6 -DNETGRAPH -DIPX -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/netstat/sctp.c /src/usr.bin/netstat/sctp.c: In function 'sctp_print_address': /src/usr.bin/netstat/sctp.c:201: error: 'union sctp_sockstore' has no member named 'sin' *** Error code 1 Stop in /src/usr.bin/netstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-16 08:49:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-16 08:49:16 - ERROR: failed to build world TB --- 2012-07-16 08:49:16 - 6276.32 user 860.53 system 9556.07 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-amd64@FreeBSD.ORG Mon Jul 16 11:08:41 2012 Return-Path: Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAC9A106564A for ; Mon, 16 Jul 2012 11:08:41 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D40E68FC1D for ; Mon, 16 Jul 2012 11:08:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6GB8fd9093897 for ; Mon, 16 Jul 2012 11:08:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6GB8eMO093894 for freebsd-amd64@FreeBSD.org; Mon, 16 Jul 2012 11:08:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 16 Jul 2012 11:08:40 GMT Message-Id: <201207161108.q6GB8eMO093894@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-amd64@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-amd64@FreeBSD.org X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 11:08:42 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o amd64/168659 amd64 [boot] FreeBSD 9 - Crash upon booting off install CD ( o amd64/167582 amd64 Compile of MySQL NDB Cluster Fails 8.2 AMD64 o amd64/167543 amd64 [kernel] Install FreeBSD can show error message with c o amd64/167393 amd64 [boot] MacBook4,1 hangs on SMP boot o amd64/166639 amd64 [boot] Syscons issue Intel D2700 o amd64/166229 amd64 [boot] Unable to install FreeBSD 9 on Acer Extensa 522 o amd64/165850 amd64 [build] 8.3-RC1 (amd64): world doesn't build with CPUT o amd64/165845 amd64 [build] Unable to build kernel on 8.2-STABLE o amd64/165351 amd64 [boot] Error while installing or booting the freeBSD O o amd64/164773 amd64 [boot] 9.0 amd64 fails to boot on HP DL145 G3 [regress o amd64/164707 amd64 FreeBSD 9 installer does not work with IBM uefi o amd64/164643 amd64 Kernel Panic at 9.0-RELEASE o amd64/164619 amd64 when logged in as root the user and group applications o amd64/164457 amd64 [install] Can't install FreeBSD 9.0 (amd64) on HP Blad o amd64/164301 amd64 [install] 9.0 - Can't install, no DHCP lease o amd64/164136 amd64 after fresh install 8.1 release or 8.2 release the har o amd64/164116 amd64 [boot] FreeBSD 9.0-RELEASE installations mediums fails o amd64/164089 amd64 FreeBSD-9.0-RELEASE-amd64-memstick.img does not boot o amd64/164073 amd64 /etc/rc warning after booting o amd64/164036 amd64 [keyboard] Moused fails on 9_0_RELENG o amd64/163736 amd64 Freebsd 8.2 with MPD5 and about 100 PPPoE clients pani o amd64/163710 amd64 setjump in userboot.so causes stack corruption o amd64/163625 amd64 Install problems of RC3 amd64 on ASRock N68 GE3 UCC o amd64/163568 amd64 hard drive naming o amd64/163285 amd64 when installing gnome2-lite not all dependent packages o amd64/163284 amd64 print manager failed to install correctly o amd64/163114 amd64 no boot on Via Nanao netbook Samsung NC20 o amd64/163092 amd64 FreeBSD 9.0-RC2 fails to boot from raid-z2 if AHCI is o amd64/163048 amd64 normal user cant mount ntfs-3g o amd64/162936 amd64 fails boot and destabilizes other OSes on FreeBSD 9 RC o amd64/162489 amd64 After some time X blanks the screen and does not respo o amd64/162314 amd64 not able to install FreeBSD-8.2-RELEASE-amd64-dvd1 as o amd64/162219 amd64 [REGRESSION] In KDE 4.7.2 cant enable OpenGL,in 4.6.5 o amd64/162170 amd64 Unable to install due to freeze at "run_interrupt_driv o amd64/161974 amd64 FreeBSD 9 new installer installs succesful, renders ma o kern/160833 amd64 Keyboard USB doesn't work o amd64/157386 amd64 [powerd] Enabling powerd(8) with default settings on I o amd64/156106 amd64 [boot] boot0 fails to start o amd64/155135 amd64 [boot] Does Not Boot On a Very Standard Hardware o amd64/154957 amd64 [boot] Install boot CD won't boot up - keeps rebooting o amd64/154629 amd64 [panic] Fatal trap 9: general protection fault while i o amd64/153935 amd64 [hang] system hangs while trying to do 'shutdown -h no o amd64/153831 amd64 [boot] CD bootloader won't on Tyan s2912G2nr o amd64/153496 amd64 [hyper-v] [install] Install on Hyper-V leaves corrupt o amd64/153372 amd64 [panic] kernel panic o amd64/153175 amd64 [amd64] Kernel Panic on only FreeBSD 8 amd64 o amd64/152874 amd64 [install] 8.1 install fails where 7.3 works due to lac o amd64/152430 amd64 [boot] HP ProLiant Microserver n36l cannot boot into i o amd64/145991 amd64 [NOTES] [patch] Add a requires line to /sys/amd64/conf o amd64/144405 amd64 [build] [patch] include /usr/obj/lib32 in cleanworld t s amd64/143173 amd64 [ata] Promise FastTrack TX4 + SATA DVD, installer can' p amd64/141413 amd64 [hang] Tyan 2881 m3289 SMDC freeze o amd64/137942 amd64 [pci] 8.0-BETA2 having problems with Asus M2N-SLI-delu o amd64/127640 amd64 [amd64] gcc(1) will not build shared libraries with -f o amd64/115194 amd64 LCD screen remains blank after Dell XPS M1210 lid is c 55 problems total. From owner-freebsd-amd64@FreeBSD.ORG Tue Jul 17 05:40:11 2012 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37A231065675 for ; Tue, 17 Jul 2012 05:40:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 107058FC16 for ; Tue, 17 Jul 2012 05:40:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6H5eAm2053250 for ; Tue, 17 Jul 2012 05:40:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6H5eAr7053249; Tue, 17 Jul 2012 05:40:10 GMT (envelope-from gnats) Resent-Date: Tue, 17 Jul 2012 05:40:10 GMT Resent-Message-Id: <201207170540.q6H5eAr7053249@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, Ed Alley Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3A88106566B for ; Tue, 17 Jul 2012 05:36:24 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id C41A28FC0C for ; Tue, 17 Jul 2012 05:36:24 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id q6H5aOUs053863 for ; Tue, 17 Jul 2012 05:36:24 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id q6H5aOjI053829; Tue, 17 Jul 2012 05:36:24 GMT (envelope-from nobody) Message-Id: <201207170536.q6H5aOjI053829@red.freebsd.org> Date: Tue, 17 Jul 2012 05:36:24 GMT From: Ed Alley To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 X-Mailman-Approved-At: Tue, 17 Jul 2012 11:12:36 +0000 Cc: Subject: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jul 2012 05:40:11 -0000 >Number: 169927 >Category: amd64 >Synopsis: siginfo, si_code for fpe errors when error occurs using the SSE math processor >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Tue Jul 17 05:40:10 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Ed Alley >Release: 8.2-RELEASE amd64 >Organization: >Environment: System: FreeBSD epos.domos.org 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Mon Jun 25 00:07:01 PDT 2012 wea@epos.domos.org:/usr/src/sys/amd64/compile/EPOS.6 amd64 machine is an Intel i5 x86-64 >Description: According to sigaction(2) by choosing SA_SIGINGO as one of the sa_flags one can catch sigfpe signals. What is returned to the signal handler for the sigfpe is a structure defined in siginfo(3). Within that structure: the si_code entry gives the error code as defined in siginfo(3) man page. This is useful when de-bugging a large code, because one can retrieve not only the actual fpe error: divide by zero, overflow or etc, but also the location of the error is also returned. For FPE errors using the x87 everything works fine, but when the SSE is used for floating point calculations the si_code that is returned is always zero. I have a fix for this which I have included as a patch for FreeBSD 8.2 release. I have been applying this fix since I got my 64-bit box since FreeBSD 7.x. I have not sent this patch in, since I had assumed that the problem would get fixed in later releases. However, that has not been the case so here is the patch (upgraded to version 8.2) that I have been using. To apply the patch, just cd into /usr/src/sys/amd64 and apply the patch. It will operate on two files in the directory amd64: trap.c and fpu.c. In trap.c a single line will be replaced as can be seen in the patch. This line occurs in the user trap switch for the case: T_XMMFLT. The line ucode = 0; is replaced with ucode = fputrap(); This then will call the fputrap() code similarly to the T_ARITHTRAP case. The process fputrap() is found in file fpu.c which is where the rest of the patch operates. In function fputrap() I added additional code to access the mxcsr status bits. These are then ORed into the status code before the argument to the fpetable[] is calculated. Following the x87 case, before I return, I zero out the error flags in the mxcsr register. Let me know if this is useful, also I have not found an equivalent instruction to the fnclex (that zeros out the x87 error flags) for easily zeroing out the mxcsr error flags, so I have resorted to anding them out of a memory copy of the mxcsr that I loaded earlier and then storing it back into the register. With these changes in place, my kernel now handles SIMD fpe errors (trap code 29) and returns the mxcsr decoded error in the si_code entry of the siginfo_t structure. >How-To-Repeat: >Fix: Patch attached with submission follows: diff -Naur amd64-orig/fpu.c amd64/fpu.c --- amd64-orig/fpu.c 2012-06-24 18:59:36.000000000 -0700 +++ amd64/fpu.c 2012-07-16 22:07:19.000000000 -0700 @@ -72,7 +72,8 @@ #define fnstsw(addr) __asm __volatile("fnstsw %0" : "=am" (*(addr))) #define fxrstor(addr) __asm __volatile("fxrstor %0" : : "m" (*(addr))) #define fxsave(addr) __asm __volatile("fxsave %0" : "=m" (*(addr))) -#define ldmxcsr(csr) __asm __volatile("ldmxcsr %0" : : "m" (csr)) +#define ldmxcsr(addr) __asm __volatile("ldmxcsr %0" : : "m" (*(addr))) +#define stmxcsr(addr) __asm __volatile("stmxcsr %0" : "=m" (*(addr))) #define start_emulating() __asm __volatile( \ "smsw %%ax; orb %0,%%al; lmsw %%ax" \ : : "n" (CR0_TS) : "ax") @@ -87,7 +88,8 @@ void fnstsw(caddr_t addr); void fxsave(caddr_t addr); void fxrstor(caddr_t addr); -void ldmxcsr(u_int csr); +void ldmxcsr(caddr_t addr); +void stmxcsr(caddr_t addr); void start_emulating(void); void stop_emulating(void); @@ -95,6 +97,7 @@ #define GET_FPU_CW(thread) ((thread)->td_pcb->pcb_save->sv_env.en_cw) #define GET_FPU_SW(thread) ((thread)->td_pcb->pcb_save->sv_env.en_sw) +#define GET_MXCSR(thread) ((thread)->td_pcb->pcb_save->sv_env.en_mxcsr) typedef u_char bool_t; @@ -126,7 +129,7 @@ control = __INITIAL_FPUCW__; fldcw(control); mxcsr = __INITIAL_MXCSR__; - ldmxcsr(mxcsr); + ldmxcsr(&mxcsr); if (PCPU_GET(cpuid) == 0) { fxsave(&fpu_initialstate); if (fpu_initialstate.sv_env.en_mxcsr_mask) @@ -356,6 +359,7 @@ fputrap() { u_short control, status; + u_int mxcsr; critical_enter(); @@ -367,13 +371,18 @@ if (PCPU_GET(fpcurthread) != curthread) { control = GET_FPU_CW(curthread); status = GET_FPU_SW(curthread); + mxcsr = GET_MXCSR(curthread); + status |= (mxcsr & 0x3f); } else { fnstcw(&control); fnstsw(&status); + stmxcsr(&mxcsr); + status |= (mxcsr & 0x3f); + fnclex(); /* Clear the x87 error bits */ + mxcsr &= ~0x3f; /* Clear the mxcsr error bits */ + ldmxcsr(&mxcsr); } - if (PCPU_GET(fpcurthread) == curthread) - fnclex(); critical_exit(); return (fpetable[status & ((~control & 0x3f) | 0x40)]); } diff -Naur amd64-orig/trap.c amd64/trap.c --- amd64-orig/trap.c 2012-06-24 23:58:01.000000000 -0700 +++ amd64/trap.c 2012-07-16 21:51:56.000000000 -0700 @@ -435,7 +435,9 @@ break; case T_XMMFLT: /* SIMD floating-point exception */ - ucode = 0; /* XXX */ + ucode = fputrap(); + if (ucode == -1) + goto userout; i = SIGFPE; break; } >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Tue Jul 17 13:25:59 2012 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2622B1065672; Tue, 17 Jul 2012 13:25:59 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 9F8A28FC08; Tue, 17 Jul 2012 13:25:58 +0000 (UTC) Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q6HDPtxl015994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2012 23:25:56 +1000 Date: Tue, 17 Jul 2012 23:25:55 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Ed Alley In-Reply-To: <201207170536.q6H5aOjI053829@red.freebsd.org> Message-ID: <20120717214246.J6986@besplex.bde.org> References: <201207170536.q6H5aOjI053829@red.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-gnats-submit@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jul 2012 13:25:59 -0000 On Tue, 17 Jul 2012, Ed Alley wrote: >> Description: > According to sigaction(2) by choosing SA_SIGINGO as one of the sa_flags > one can catch sigfpe signals. What is returned to the signal handler > for the sigfpe is a structure defined in siginfo(3). Within that > structure: the si_code entry gives the error code as defined in siginfo(3) > man page. This is useful when de-bugging a large code, > because one can retrieve not only the actual fpe error: divide by zero, > overflow or etc, but also the location of the error is also returned. It's interesting that anyone even enables SIGFPE for FP exceptions (I tried to keep them as the default for critical exceptions, but was OBE. SIGFPE now normally means (!F)PE for integer division by 0.) > For FPE errors using the x87 everything works fine, but when > the SSE is used for floating point calculations the si_code that > is returned is always zero. I have a fix for this which I have > included as a patch for FreeBSD 8.2 release. I have been applying > this fix since I got my 64-bit box since FreeBSD 7.x. I have not > sent this patch in, since I had assumed that the problem would get > fixed in later releases. However, that has not been the case so > here is the patch (upgraded to version 8.2) that I have been using. > > To apply the patch, just cd into /usr/src/sys/amd64 and apply the > patch. It will operate on two files in the directory amd64: > trap.c and fpu.c. i386 has the same bug. > In trap.c a single line will be replaced as can be seen in the patch. > This line occurs in the user trap switch for the case: T_XMMFLT. The > line ucode = 0; is replaced with ucode = fputrap(); This then will call > the fputrap() code similarly to the T_ARITHTRAP case. I didn't know that it had a different exception number. > The process fputrap() is found in file fpu.c which is where the > rest of the patch operates. In function fputrap() I added additional > code to access the mxcsr status bits. These are then ORed into > the status code before the argument to the fpetable[] is calculated. > > Following the x87 case, before I return, I zero out the error flags > in the mxcsr register. Let me know if this is useful, also I have > not found an equivalent instruction to the fnclex (that zeros out > the x87 error flags) for easily zeroing out the mxcsr error flags, > so I have resorted to anding them out of a memory copy of the mxcsr > that I loaded earlier and then storing it back into the register. This shouldn't be done. The fnclex is both a bug and a feature (mostly a bug). The corresponding clearing of the mxcsr bits is just a bug. Reason for the fnclex: it clears the fault condition, so that buggy SIGFPE handlers can return and have the main code not immediately fault again. But the behaviour is still undefined. In particular, the i387 FP stack may be corrupt (unless the SIGFPE handler actually understands FP and has fixed up the stack, but if it understands FP then it won't depend on the fnclex, and it won't simply return). It is better for the fault to repeat endlessly. Most faults including SIGFPE for integer division by 0 repeat endlessly, which tells you that you have a buggy fault handler that returns. History of the fnclex and of other FP bugs in signal handling: - in FreeBSD-[1-4], the i387 exception handling was: - save the status word in the "saved exception status word" in the PCB - fnclex - starting in about FreeBSD-4, encode the saved status word in the signal code. This loses some info. - call the signal handler with the same FP context as the normal process, except for the saved exception status word. This was bad, but it was easy for a SIGFPE handler to fix up the state. Fixing up the status word was most complicated. After about FreeBSD-4, the the signal code might have been enough (convert it back to a status word). If not, the saved exception status word was recoverable via the sigcontext pointer. - return to the normal process with the same FP context as left by the signal handler. This was OK for SIGFPE handlers (they could fix up everything except the status word without using the complications of the sigcontext pointer or the different unportabilities given by the signal code and other siginfo things (siginfo was mostly unavailable then), but very bad for non-SIGFPE signal handlers, since any FP in the signal handler would corrupt the FP context for the normal process. - gdb never understood the sigcontext pointer, but it used to understand the saved exception status word after I made it do this in FreeBSD 1 or 2. It printed status for both the normal status word and the saved one. - most of this was broken in FreeBSD-5. Now, the i387 exception handling is (and similarly for amd64): - save the status word in a local variable. It never reaches the PCB. - fnclex, as before - encode the old status word in the signal code, as before - call the signal handler with an independent context. This is bad, but it makes it harders for a SIGFPE handler to fix up the state. Especially the status word, since that was clobbered after not saving it except in the local variable. The handler can retrieve the FP state using either the sigcontext pointer or siginfo, but that gives the clobbered status word. Now the signal code gives the only trace of the exception bits in the old status word. - switch back to the normal FP context after returning from the signal handler. - current gdb no longer understands the saved exception status word, on old kernels that have it. It is much further from understanding the full switched state. In FreeBSD-[1-4], you could easily see the normal process's FP state in a signal handler since it wasn't switched, and you could fix it up manually by editing it. Now you have the same complications as a SIGFPE handler that does fixups -- it is hard to even see this state. I think you can still do it manually by looking at in the stack. Perhaps this can be done using gdb macros. An average signal handler doesn't declare sigcontext or siginfo pointers (or even the signal code), so to debug it you might need to add the declarations and recompile, or possibly fake them using macros. I haven't actually tried this. On why clobbering the mxcsr status is even less useful: - for the i387, the trap happens on the next non-control FP instruction after the one that caused the exception. Not repeating the fault on this next (hopefully non-problematic) instruction almost makes sense. - for SSE, the trap happens on the one that causes the exception. It's good to repeat this fault. > With these changes in place, my kernel now handles SIMD fpe errors > (trap code 29) and returns the mxcsr decoded error in the si_code entry of the > siginfo_t structure. > diff -Naur amd64-orig/fpu.c amd64/fpu.c > --- amd64-orig/fpu.c 2012-06-24 18:59:36.000000000 -0700 > +++ amd64/fpu.c 2012-07-16 22:07:19.000000000 -0700 > ... > @@ -356,6 +359,7 @@ > fputrap() > { > u_short control, status; > + u_int mxcsr; > > critical_enter(); > > @@ -367,13 +371,18 @@ > if (PCPU_GET(fpcurthread) != curthread) { > control = GET_FPU_CW(curthread); > status = GET_FPU_SW(curthread); > + mxcsr = GET_MXCSR(curthread); > + status |= (mxcsr & 0x3f); Lots of tab and other whitespace lossage. This change and the one to call fputrap() for T_XMMFLT, and similarly for i386, might be enough. > } else { > fnstcw(&control); > fnstsw(&status); > + stmxcsr(&mxcsr); > + status |= (mxcsr & 0x3f); > + fnclex(); /* Clear the x87 error bits */ > + mxcsr &= ~0x3f; /* Clear the mxcsr error bits */ > + ldmxcsr(&mxcsr); Best not to touch either. > } > > - if (PCPU_GET(fpcurthread) == curthread) > - fnclex(); Try removing this too. > critical_exit(); > return (fpetable[status & ((~control & 0x3f) | 0x40)]); > } Here are some of my old changes to npxtrap(). They mainly ifdef out the fnclex: % Index: npx.c % =================================================================== % RCS file: /home/ncvs/src/sys/i386/isa/npx.c,v % retrieving revision 1.152 % diff -u -2 -r1.152 npx.c % --- npx.c 19 Jun 2004 22:24:16 -0000 1.152 % +++ npx.c 22 Apr 2006 11:58:31 -0000 % @@ -578,5 +624,5 @@ % */ % static char fpetable[128] = { % - 0, % + -1, /* 0 - no unmasked exception (probably bogus IRQ13) */ % FPE_FLTINV, /* 1 - INV */ % FPE_FLTUND, /* 2 - DNML */ % @@ -642,5 +688,5 @@ % FPE_FLTDIV, /* 3E - DNML | DZ | OFL | UFL | IMP */ % FPE_FLTINV, /* 3F - INV | DNML | DZ | OFL | UFL | IMP */ % - FPE_FLTSUB, /* 40 - STK */ % + -1, /* 40 - STK, but no unmasked exception so no trap */ % FPE_FLTSUB, /* 41 - INV | STK */ % FPE_FLTUND, /* 42 - DNML | STK */ These -1's are supposed to give a unique error for cases that shouldn't happen. % @@ -751,7 +806,16 @@ % } % % + /* Ignore some spurious traps. */ % + if ((status & ~control & 0x3f) == 0) { % + intr_restore(saveintr); % + return (-1); % + } IIRC, this is mainly for old IRQ13 exception handling. % + % +#if 0 % + /* XXX this clobbers the status. */ % if (PCPU_GET(fpcurthread) == curthread) % fnclex(); % - intr_restore(savecrit); % +#endif % + intr_restore(saveintr); Kill the fnclex. Unrelated renaming of savecrit (savecrit is a bogus name, since there are no critical sections here). % return (fpetable[status & ((~control & 0x3f) | 0x40)]); % } The only effect that I noticed from killing the fnclex was that some of my old test programs with buggy SIGFPE handling appear to hang (they actually fault endlessly). They were depending on the signal handler to return and then fixed up the FP state after it returned. The signal handler was too standards-conforming and just set a flag of type sig_atomic_t. The quick fix was to use a FreeBSD-4-compat signal handler so that the signal handler can corrupt the normal process state; then just add an fnclex to it (it is now very non-standards-conforming). Configuring to use a FreeBSD-4-compat signal handler in FreeBSD-5+ is nontrivial, but I force this configuration anyway for portability. With FreeBSD-5+ signal handlers, the signal handler would need an enormous amount of code to apply the fnclex to the normal process state. Note that with SSE, everyone has had the endless-faulting behaviour for most FP unmasked exceptions on amd64, since T_XMMFLT wasn't connected to fputrap() and fputrap() didn't clobber the status anwyay. So everyone must have gotten used to this. Except, hardly anyone unmasks FP exceptions. I only unmask them for debugging. Bruce From owner-freebsd-amd64@FreeBSD.ORG Tue Jul 17 13:30:13 2012 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4245B106568D for ; Tue, 17 Jul 2012 13:30:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DBC948FC1D for ; Tue, 17 Jul 2012 13:30:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6HDUCC1029741 for ; Tue, 17 Jul 2012 13:30:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6HDUCuJ029738; Tue, 17 Jul 2012 13:30:12 GMT (envelope-from gnats) Date: Tue, 17 Jul 2012 13:30:12 GMT Message-Id: <201207171330.q6HDUCuJ029738@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Bruce Evans Cc: Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Evans List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 13:30:13 -0000 The following reply was made to PR amd64/169927; it has been noted by GNATS. From: Bruce Evans To: Ed Alley Cc: freebsd-gnats-submit@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor Date: Tue, 17 Jul 2012 23:25:55 +1000 (EST) On Tue, 17 Jul 2012, Ed Alley wrote: >> Description: > According to sigaction(2) by choosing SA_SIGINGO as one of the sa_flags > one can catch sigfpe signals. What is returned to the signal handler > for the sigfpe is a structure defined in siginfo(3). Within that > structure: the si_code entry gives the error code as defined in siginfo(3) > man page. This is useful when de-bugging a large code, > because one can retrieve not only the actual fpe error: divide by zero, > overflow or etc, but also the location of the error is also returned. It's interesting that anyone even enables SIGFPE for FP exceptions (I tried to keep them as the default for critical exceptions, but was OBE. SIGFPE now normally means (!F)PE for integer division by 0.) > For FPE errors using the x87 everything works fine, but when > the SSE is used for floating point calculations the si_code that > is returned is always zero. I have a fix for this which I have > included as a patch for FreeBSD 8.2 release. I have been applying > this fix since I got my 64-bit box since FreeBSD 7.x. I have not > sent this patch in, since I had assumed that the problem would get > fixed in later releases. However, that has not been the case so > here is the patch (upgraded to version 8.2) that I have been using. > > To apply the patch, just cd into /usr/src/sys/amd64 and apply the > patch. It will operate on two files in the directory amd64: > trap.c and fpu.c. i386 has the same bug. > In trap.c a single line will be replaced as can be seen in the patch. > This line occurs in the user trap switch for the case: T_XMMFLT. The > line ucode = 0; is replaced with ucode = fputrap(); This then will call > the fputrap() code similarly to the T_ARITHTRAP case. I didn't know that it had a different exception number. > The process fputrap() is found in file fpu.c which is where the > rest of the patch operates. In function fputrap() I added additional > code to access the mxcsr status bits. These are then ORed into > the status code before the argument to the fpetable[] is calculated. > > Following the x87 case, before I return, I zero out the error flags > in the mxcsr register. Let me know if this is useful, also I have > not found an equivalent instruction to the fnclex (that zeros out > the x87 error flags) for easily zeroing out the mxcsr error flags, > so I have resorted to anding them out of a memory copy of the mxcsr > that I loaded earlier and then storing it back into the register. This shouldn't be done. The fnclex is both a bug and a feature (mostly a bug). The corresponding clearing of the mxcsr bits is just a bug. Reason for the fnclex: it clears the fault condition, so that buggy SIGFPE handlers can return and have the main code not immediately fault again. But the behaviour is still undefined. In particular, the i387 FP stack may be corrupt (unless the SIGFPE handler actually understands FP and has fixed up the stack, but if it understands FP then it won't depend on the fnclex, and it won't simply return). It is better for the fault to repeat endlessly. Most faults including SIGFPE for integer division by 0 repeat endlessly, which tells you that you have a buggy fault handler that returns. History of the fnclex and of other FP bugs in signal handling: - in FreeBSD-[1-4], the i387 exception handling was: - save the status word in the "saved exception status word" in the PCB - fnclex - starting in about FreeBSD-4, encode the saved status word in the signal code. This loses some info. - call the signal handler with the same FP context as the normal process, except for the saved exception status word. This was bad, but it was easy for a SIGFPE handler to fix up the state. Fixing up the status word was most complicated. After about FreeBSD-4, the the signal code might have been enough (convert it back to a status word). If not, the saved exception status word was recoverable via the sigcontext pointer. - return to the normal process with the same FP context as left by the signal handler. This was OK for SIGFPE handlers (they could fix up everything except the status word without using the complications of the sigcontext pointer or the different unportabilities given by the signal code and other siginfo things (siginfo was mostly unavailable then), but very bad for non-SIGFPE signal handlers, since any FP in the signal handler would corrupt the FP context for the normal process. - gdb never understood the sigcontext pointer, but it used to understand the saved exception status word after I made it do this in FreeBSD 1 or 2. It printed status for both the normal status word and the saved one. - most of this was broken in FreeBSD-5. Now, the i387 exception handling is (and similarly for amd64): - save the status word in a local variable. It never reaches the PCB. - fnclex, as before - encode the old status word in the signal code, as before - call the signal handler with an independent context. This is bad, but it makes it harders for a SIGFPE handler to fix up the state. Especially the status word, since that was clobbered after not saving it except in the local variable. The handler can retrieve the FP state using either the sigcontext pointer or siginfo, but that gives the clobbered status word. Now the signal code gives the only trace of the exception bits in the old status word. - switch back to the normal FP context after returning from the signal handler. - current gdb no longer understands the saved exception status word, on old kernels that have it. It is much further from understanding the full switched state. In FreeBSD-[1-4], you could easily see the normal process's FP state in a signal handler since it wasn't switched, and you could fix it up manually by editing it. Now you have the same complications as a SIGFPE handler that does fixups -- it is hard to even see this state. I think you can still do it manually by looking at in the stack. Perhaps this can be done using gdb macros. An average signal handler doesn't declare sigcontext or siginfo pointers (or even the signal code), so to debug it you might need to add the declarations and recompile, or possibly fake them using macros. I haven't actually tried this. On why clobbering the mxcsr status is even less useful: - for the i387, the trap happens on the next non-control FP instruction after the one that caused the exception. Not repeating the fault on this next (hopefully non-problematic) instruction almost makes sense. - for SSE, the trap happens on the one that causes the exception. It's good to repeat this fault. > With these changes in place, my kernel now handles SIMD fpe errors > (trap code 29) and returns the mxcsr decoded error in the si_code entry of the > siginfo_t structure. > diff -Naur amd64-orig/fpu.c amd64/fpu.c > --- amd64-orig/fpu.c 2012-06-24 18:59:36.000000000 -0700 > +++ amd64/fpu.c 2012-07-16 22:07:19.000000000 -0700 > ... > @@ -356,6 +359,7 @@ > fputrap() > { > u_short control, status; > + u_int mxcsr; > > critical_enter(); > > @@ -367,13 +371,18 @@ > if (PCPU_GET(fpcurthread) != curthread) { > control = GET_FPU_CW(curthread); > status = GET_FPU_SW(curthread); > + mxcsr = GET_MXCSR(curthread); > + status |= (mxcsr & 0x3f); Lots of tab and other whitespace lossage. This change and the one to call fputrap() for T_XMMFLT, and similarly for i386, might be enough. > } else { > fnstcw(&control); > fnstsw(&status); > + stmxcsr(&mxcsr); > + status |= (mxcsr & 0x3f); > + fnclex(); /* Clear the x87 error bits */ > + mxcsr &= ~0x3f; /* Clear the mxcsr error bits */ > + ldmxcsr(&mxcsr); Best not to touch either. > } > > - if (PCPU_GET(fpcurthread) == curthread) > - fnclex(); Try removing this too. > critical_exit(); > return (fpetable[status & ((~control & 0x3f) | 0x40)]); > } Here are some of my old changes to npxtrap(). They mainly ifdef out the fnclex: % Index: npx.c % =================================================================== % RCS file: /home/ncvs/src/sys/i386/isa/npx.c,v % retrieving revision 1.152 % diff -u -2 -r1.152 npx.c % --- npx.c 19 Jun 2004 22:24:16 -0000 1.152 % +++ npx.c 22 Apr 2006 11:58:31 -0000 % @@ -578,5 +624,5 @@ % */ % static char fpetable[128] = { % - 0, % + -1, /* 0 - no unmasked exception (probably bogus IRQ13) */ % FPE_FLTINV, /* 1 - INV */ % FPE_FLTUND, /* 2 - DNML */ % @@ -642,5 +688,5 @@ % FPE_FLTDIV, /* 3E - DNML | DZ | OFL | UFL | IMP */ % FPE_FLTINV, /* 3F - INV | DNML | DZ | OFL | UFL | IMP */ % - FPE_FLTSUB, /* 40 - STK */ % + -1, /* 40 - STK, but no unmasked exception so no trap */ % FPE_FLTSUB, /* 41 - INV | STK */ % FPE_FLTUND, /* 42 - DNML | STK */ These -1's are supposed to give a unique error for cases that shouldn't happen. % @@ -751,7 +806,16 @@ % } % % + /* Ignore some spurious traps. */ % + if ((status & ~control & 0x3f) == 0) { % + intr_restore(saveintr); % + return (-1); % + } IIRC, this is mainly for old IRQ13 exception handling. % + % +#if 0 % + /* XXX this clobbers the status. */ % if (PCPU_GET(fpcurthread) == curthread) % fnclex(); % - intr_restore(savecrit); % +#endif % + intr_restore(saveintr); Kill the fnclex. Unrelated renaming of savecrit (savecrit is a bogus name, since there are no critical sections here). % return (fpetable[status & ((~control & 0x3f) | 0x40)]); % } The only effect that I noticed from killing the fnclex was that some of my old test programs with buggy SIGFPE handling appear to hang (they actually fault endlessly). They were depending on the signal handler to return and then fixed up the FP state after it returned. The signal handler was too standards-conforming and just set a flag of type sig_atomic_t. The quick fix was to use a FreeBSD-4-compat signal handler so that the signal handler can corrupt the normal process state; then just add an fnclex to it (it is now very non-standards-conforming). Configuring to use a FreeBSD-4-compat signal handler in FreeBSD-5+ is nontrivial, but I force this configuration anyway for portability. With FreeBSD-5+ signal handlers, the signal handler would need an enormous amount of code to apply the fnclex to the normal process state. Note that with SSE, everyone has had the endless-faulting behaviour for most FP unmasked exceptions on amd64, since T_XMMFLT wasn't connected to fputrap() and fputrap() didn't clobber the status anwyay. So everyone must have gotten used to this. Except, hardly anyone unmasks FP exceptions. I only unmask them for debugging. Bruce From owner-freebsd-amd64@FreeBSD.ORG Tue Jul 17 13:44:37 2012 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9D614106566B; Tue, 17 Jul 2012 13:44:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 350AE8FC15; Tue, 17 Jul 2012 13:44:37 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6HDidgY087285; Tue, 17 Jul 2012 16:44:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q6HDiQZX022955; Tue, 17 Jul 2012 16:44:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6HDiQEX022954; Tue, 17 Jul 2012 16:44:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 17 Jul 2012 16:44:26 +0300 From: Konstantin Belousov To: Bruce Evans Message-ID: <20120717134426.GJ2676@deviant.kiev.zoral.com.ua> References: <201207170536.q6H5aOjI053829@red.freebsd.org> <20120717214246.J6986@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJFRpmOek+ZRSQoz" Content-Disposition: inline In-Reply-To: <20120717214246.J6986@besplex.bde.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-gnats-submit@freebsd.org, freebsd-amd64@freebsd.org, Ed Alley Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jul 2012 13:44:37 -0000 --IJFRpmOek+ZRSQoz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable It was on my TODO list for long time. Lets handle amd64 first, both for native and compat32. I think the following should be somewhat better variant. I do leave the fnclex there for x87. diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c index a7812b7..34cf8d4 100644 --- a/sys/amd64/amd64/fpu.c +++ b/sys/amd64/amd64/fpu.c @@ -73,6 +73,7 @@ __FBSDID("$FreeBSD$"); #define fxrstor(addr) __asm __volatile("fxrstor %0" : : "m" (*(addr))) #define fxsave(addr) __asm __volatile("fxsave %0" : "=3Dm" (*(addr))) #define ldmxcsr(csr) __asm __volatile("ldmxcsr %0" : : "m" (csr)) +#define stmxcsr(addr) __asm __volatile("stmxcsr %0" : : "m" (*(addr))) =20 static __inline void xrstor(char *addr, uint64_t mask) @@ -105,6 +106,7 @@ void fnstsw(caddr_t addr); void fxsave(caddr_t addr); void fxrstor(caddr_t addr); void ldmxcsr(u_int csr); +void stmxcsr(u_int csr); void xrstor(char *addr, uint64_t mask); void xsave(char *addr, uint64_t mask); =20 @@ -113,9 +115,6 @@ void xsave(char *addr, uint64_t mask); #define start_emulating() load_cr0(rcr0() | CR0_TS) #define stop_emulating() clts() =20 -#define GET_FPU_CW(thread) ((thread)->td_pcb->pcb_save->sv_env.en_cw) -#define GET_FPU_SW(thread) ((thread)->td_pcb->pcb_save->sv_env.en_sw) - CTASSERT(sizeof(struct savefpu) =3D=3D 512); CTASSERT(sizeof(struct xstate_hdr) =3D=3D 64); CTASSERT(sizeof(struct savefpu_ymm) =3D=3D 832); @@ -514,11 +513,15 @@ static char fpetable[128] =3D { }; =20 /* - * Preserve the FP status word, clear FP exceptions, then generate a SIGFP= E. + * Preserve the FP status word, clear FP exceptions for x87, then + * generate a SIGFPE. + * + * Clearing exceptions was necessary mainly to avoid IRQ13 bugs and is + * engraved in our i386 ABI. We now depend on longjmp() restoring a + * usable state. Restoring the state or examining it might fail if we + * didn't clear exceptions. * - * Clearing exceptions is necessary mainly to avoid IRQ13 bugs. We now - * depend on longjmp() restoring a usable state. Restoring the state - * or examining it might fail if we didn't clear exceptions. + * For SSE exceptions, the exceptions are not cleared. * * The error code chosen will be one of the FPE_... macros. It will be * sent as the second argument to old BSD-style signal handlers and as @@ -531,8 +534,9 @@ static char fpetable[128] =3D { * solution for signals other than SIGFPE. */ int -fputrap() +fputrap_x87(void) { + struct savefpu *pcb_save; u_short control, status; =20 critical_enter(); @@ -543,19 +547,43 @@ fputrap() * wherever they are. */ if (PCPU_GET(fpcurthread) !=3D curthread) { - control =3D GET_FPU_CW(curthread); - status =3D GET_FPU_SW(curthread); + pcb_save =3D curthread->td_pcb->pcb_save; + control =3D pcb_save->sv_env.en_cw; + status =3D pcb_save->sv_env.en_sw; } else { fnstcw(&control); fnstsw(&status); + fnclex(); } =20 - if (PCPU_GET(fpcurthread) =3D=3D curthread) - fnclex(); critical_exit(); return (fpetable[status & ((~control & 0x3f) | 0x40)]); } =20 +int +fputrap_sse(void) +{ + u_int mxcsr; + u_short control, status; + + critical_enter(); + + /* + * Coomparing with the x87 #MF handler, we do not clear + * exceptions from the mxcsr. + */ + if (PCPU_GET(fpcurthread) !=3D curthread) + mxcsr =3D curthread->td_pcb->pcb_save->sv_env.en_mxcsr; + else + stmxcsr(&mxcsr); + + critical_exit(); + + status =3D mxcsr & 0x3f; + control =3D (mxcsr >> 16) & 0x3f; + return (fpetable[status & (~control | 0x40)]); +} + /* * Implement device not available (DNA) exception * diff --git a/sys/amd64/amd64/trap.c b/sys/amd64/amd64/trap.c index 75e15e0..57d1cc2 100644 --- a/sys/amd64/amd64/trap.c +++ b/sys/amd64/amd64/trap.c @@ -328,7 +328,7 @@ trap(struct trapframe *frame) break; =20 case T_ARITHTRAP: /* arithmetic trap */ - ucode =3D fputrap(); + ucode =3D fputrap_x87(); if (ucode =3D=3D -1) goto userout; i =3D SIGFPE; @@ -442,7 +442,9 @@ trap(struct trapframe *frame) break; =20 case T_XMMFLT: /* SIMD floating-point exception */ - ucode =3D 0; /* XXX */ + ucode =3D fputrap_sse(); + if (ucode =3D=3D -1) + goto userout; i =3D SIGFPE; break; } diff --git a/sys/amd64/include/fpu.h b/sys/amd64/include/fpu.h index 98a016b..7d0f0ea 100644 --- a/sys/amd64/include/fpu.h +++ b/sys/amd64/include/fpu.h @@ -62,7 +62,8 @@ int fpusetregs(struct thread *td, struct savefpu *addr, char *xfpustate, size_t xfpustate_size); int fpusetxstate(struct thread *td, char *xfpustate, size_t xfpustate_size); -int fputrap(void); +int fputrap_sse(void); +int fputrap_x87(void); void fpuuserinited(struct thread *td); struct fpu_kern_ctx *fpu_kern_alloc_ctx(u_int flags); void fpu_kern_free_ctx(struct fpu_kern_ctx *ctx); --IJFRpmOek+ZRSQoz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAFbDkACgkQC3+MBN1Mb4gPfgCeI7OF9u6tfuHgPoVp/bUfG1kc iksAn1q9GtduJNGtll0dZd2X336LRijE =kkdY -----END PGP SIGNATURE----- --IJFRpmOek+ZRSQoz-- From owner-freebsd-amd64@FreeBSD.ORG Tue Jul 17 13:50:10 2012 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B1F121065673 for ; Tue, 17 Jul 2012 13:50:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9282E8FC0C for ; Tue, 17 Jul 2012 13:50:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6HDoA5K033798 for ; Tue, 17 Jul 2012 13:50:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6HDoAJS033797; Tue, 17 Jul 2012 13:50:10 GMT (envelope-from gnats) Date: Tue, 17 Jul 2012 13:50:10 GMT Message-Id: <201207171350.q6HDoAJS033797@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Konstantin Belousov Cc: Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Konstantin Belousov List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 13:50:10 -0000 The following reply was made to PR amd64/169927; it has been noted by GNATS. From: Konstantin Belousov To: Bruce Evans Cc: Ed Alley , freebsd-gnats-submit@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor Date: Tue, 17 Jul 2012 16:44:26 +0300 --IJFRpmOek+ZRSQoz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable It was on my TODO list for long time. Lets handle amd64 first, both for native and compat32. I think the following should be somewhat better variant. I do leave the fnclex there for x87. diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c index a7812b7..34cf8d4 100644 --- a/sys/amd64/amd64/fpu.c +++ b/sys/amd64/amd64/fpu.c @@ -73,6 +73,7 @@ __FBSDID("$FreeBSD$"); #define fxrstor(addr) __asm __volatile("fxrstor %0" : : "m" (*(addr))) #define fxsave(addr) __asm __volatile("fxsave %0" : "=3Dm" (*(addr))) #define ldmxcsr(csr) __asm __volatile("ldmxcsr %0" : : "m" (csr)) +#define stmxcsr(addr) __asm __volatile("stmxcsr %0" : : "m" (*(addr))) =20 static __inline void xrstor(char *addr, uint64_t mask) @@ -105,6 +106,7 @@ void fnstsw(caddr_t addr); void fxsave(caddr_t addr); void fxrstor(caddr_t addr); void ldmxcsr(u_int csr); +void stmxcsr(u_int csr); void xrstor(char *addr, uint64_t mask); void xsave(char *addr, uint64_t mask); =20 @@ -113,9 +115,6 @@ void xsave(char *addr, uint64_t mask); #define start_emulating() load_cr0(rcr0() | CR0_TS) #define stop_emulating() clts() =20 -#define GET_FPU_CW(thread) ((thread)->td_pcb->pcb_save->sv_env.en_cw) -#define GET_FPU_SW(thread) ((thread)->td_pcb->pcb_save->sv_env.en_sw) - CTASSERT(sizeof(struct savefpu) =3D=3D 512); CTASSERT(sizeof(struct xstate_hdr) =3D=3D 64); CTASSERT(sizeof(struct savefpu_ymm) =3D=3D 832); @@ -514,11 +513,15 @@ static char fpetable[128] =3D { }; =20 /* - * Preserve the FP status word, clear FP exceptions, then generate a SIGFP= E. + * Preserve the FP status word, clear FP exceptions for x87, then + * generate a SIGFPE. + * + * Clearing exceptions was necessary mainly to avoid IRQ13 bugs and is + * engraved in our i386 ABI. We now depend on longjmp() restoring a + * usable state. Restoring the state or examining it might fail if we + * didn't clear exceptions. * - * Clearing exceptions is necessary mainly to avoid IRQ13 bugs. We now - * depend on longjmp() restoring a usable state. Restoring the state - * or examining it might fail if we didn't clear exceptions. + * For SSE exceptions, the exceptions are not cleared. * * The error code chosen will be one of the FPE_... macros. It will be * sent as the second argument to old BSD-style signal handlers and as @@ -531,8 +534,9 @@ static char fpetable[128] =3D { * solution for signals other than SIGFPE. */ int -fputrap() +fputrap_x87(void) { + struct savefpu *pcb_save; u_short control, status; =20 critical_enter(); @@ -543,19 +547,43 @@ fputrap() * wherever they are. */ if (PCPU_GET(fpcurthread) !=3D curthread) { - control =3D GET_FPU_CW(curthread); - status =3D GET_FPU_SW(curthread); + pcb_save =3D curthread->td_pcb->pcb_save; + control =3D pcb_save->sv_env.en_cw; + status =3D pcb_save->sv_env.en_sw; } else { fnstcw(&control); fnstsw(&status); + fnclex(); } =20 - if (PCPU_GET(fpcurthread) =3D=3D curthread) - fnclex(); critical_exit(); return (fpetable[status & ((~control & 0x3f) | 0x40)]); } =20 +int +fputrap_sse(void) +{ + u_int mxcsr; + u_short control, status; + + critical_enter(); + + /* + * Coomparing with the x87 #MF handler, we do not clear + * exceptions from the mxcsr. + */ + if (PCPU_GET(fpcurthread) !=3D curthread) + mxcsr =3D curthread->td_pcb->pcb_save->sv_env.en_mxcsr; + else + stmxcsr(&mxcsr); + + critical_exit(); + + status =3D mxcsr & 0x3f; + control =3D (mxcsr >> 16) & 0x3f; + return (fpetable[status & (~control | 0x40)]); +} + /* * Implement device not available (DNA) exception * diff --git a/sys/amd64/amd64/trap.c b/sys/amd64/amd64/trap.c index 75e15e0..57d1cc2 100644 --- a/sys/amd64/amd64/trap.c +++ b/sys/amd64/amd64/trap.c @@ -328,7 +328,7 @@ trap(struct trapframe *frame) break; =20 case T_ARITHTRAP: /* arithmetic trap */ - ucode =3D fputrap(); + ucode =3D fputrap_x87(); if (ucode =3D=3D -1) goto userout; i =3D SIGFPE; @@ -442,7 +442,9 @@ trap(struct trapframe *frame) break; =20 case T_XMMFLT: /* SIMD floating-point exception */ - ucode =3D 0; /* XXX */ + ucode =3D fputrap_sse(); + if (ucode =3D=3D -1) + goto userout; i =3D SIGFPE; break; } diff --git a/sys/amd64/include/fpu.h b/sys/amd64/include/fpu.h index 98a016b..7d0f0ea 100644 --- a/sys/amd64/include/fpu.h +++ b/sys/amd64/include/fpu.h @@ -62,7 +62,8 @@ int fpusetregs(struct thread *td, struct savefpu *addr, char *xfpustate, size_t xfpustate_size); int fpusetxstate(struct thread *td, char *xfpustate, size_t xfpustate_size); -int fputrap(void); +int fputrap_sse(void); +int fputrap_x87(void); void fpuuserinited(struct thread *td); struct fpu_kern_ctx *fpu_kern_alloc_ctx(u_int flags); void fpu_kern_free_ctx(struct fpu_kern_ctx *ctx); --IJFRpmOek+ZRSQoz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAFbDkACgkQC3+MBN1Mb4gPfgCeI7OF9u6tfuHgPoVp/bUfG1kc iksAn1q9GtduJNGtll0dZd2X336LRijE =kkdY -----END PGP SIGNATURE----- --IJFRpmOek+ZRSQoz-- From owner-freebsd-amd64@FreeBSD.ORG Tue Jul 17 15:14:33 2012 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 37F171065672 for ; Tue, 17 Jul 2012 15:14:33 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id AE3AD8FC15 for ; Tue, 17 Jul 2012 15:14:32 +0000 (UTC) Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q6HFETGI027987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2012 01:14:31 +1000 Date: Wed, 18 Jul 2012 01:14:29 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov In-Reply-To: <201207171350.q6HDoAJS033797@freefall.freebsd.org> Message-ID: <20120717235622.C7417@besplex.bde.org> References: <201207171350.q6HDoAJS033797@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-amd64@freebsd.org Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jul 2012 15:14:33 -0000 On Tue, 17 Jul 2012, Konstantin Belousov wrote: > It was on my TODO list for long time. Lets handle amd64 first, both for > native and compat32. > > I think the following should be somewhat better variant. I do leave > the fnclex there for x87. Too large for me. Although the exceptions are different, the exception handlers are essentially the same. Remove the fnclex too. Then the exception handlers will be even more similar. > diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c > index a7812b7..34cf8d4 100644 > --- a/sys/amd64/amd64/fpu.c > +++ b/sys/amd64/amd64/fpu.c > ... > @@ -113,9 +115,6 @@ void xsave(char *addr, uint64_t mask); > #define start_emulating() load_cr0(rcr0() | CR0_TS) > #define stop_emulating() clts() > =20 > -#define GET_FPU_CW(thread) ((thread)->td_pcb->pcb_save->sv_env.en_cw) > -#define GET_FPU_SW(thread) ((thread)->td_pcb->pcb_save->sv_env.en_sw) > - > CTASSERT(sizeof(struct savefpu) =3D=3D 512); > CTASSERT(sizeof(struct xstate_hdr) =3D=3D 64); > CTASSERT(sizeof(struct savefpu_ymm) =3D=3D 832); Good to remove this. > @@ -514,11 +513,15 @@ static char fpetable[128] =3D { > }; > =20 > /* > - * Preserve the FP status word, clear FP exceptions, then generate a SIGFP= > E. > + * Preserve the FP status word, clear FP exceptions for x87, then > + * generate a SIGFPE. > + * > + * Clearing exceptions was necessary mainly to avoid IRQ13 bugs and is > + * engraved in our i386 ABI. We now depend on longjmp() restoring a > + * usable state. Restoring the state or examining it might fail if we > + * didn't clear exceptions. Hrmph. Someone already broken the ABI and enabled the trap in longjmp() by removing the fninit in longjmp(). Examining the state won't trap, since it is a no-wait instruction (fnstsw or fnstenv). Clearing the state in the kernel doesn't even fix longjmp(), since longjmp() will still trap if it is called before the kernel trap clobbers the status: fldz fld1 fdiv %st,%st(1) # exception; trap pending call longjmp # traps on the non-control fldcw I think this has to be written in asm to cause a problem. Similar C code: foo = one / zero; longjmp(); must translate to something like: fldz fld1 fdiv %st,%st(1) # exception; trap pending fstpl foo # ABI and/or C abstract machine requires # this to be put this away before function # call # trap now; bogus fnclex in kernel call longjmp # no trap later The ABI problem only affects FreeBSD-4-compat signal handlers. FreeBSD-5+ signal handlers get a clean FP state, so they won't trap in longjmp(). The fnclex was a hack to let signal handlers run with n unclean FP state without faulting again. The undefined behaviour that results when a SIGFPE handler returns is not part of an ABI. It seems to be necessary to use fnstenv; copy cw; fldenv to fix longjmp(). I used fninit because it is faster and the ABI and or the C abstract machine used to not support the exception status. > * > - * Clearing exceptions is necessary mainly to avoid IRQ13 bugs. We now > - * depend on longjmp() restoring a usable state. Restoring the state > - * or examining it might fail if we didn't clear exceptions. > + * For SSE exceptions, the exceptions are not cleared. > * > * The error code chosen will be one of the FPE_... macros. It will be > * sent as the second argument to old BSD-style signal handlers and as > @@ -531,8 +534,9 @@ static char fpetable[128] =3D { > * solution for signals other than SIGFPE. > */ > int > -fputrap() > +fputrap_x87(void) > { > + struct savefpu *pcb_save; > u_short control, status; > =20 > critical_enter(); > @@ -543,19 +547,43 @@ fputrap() > * wherever they are. > */ > if (PCPU_GET(fpcurthread) !=3D curthread) { > - control =3D GET_FPU_CW(curthread); > - status =3D GET_FPU_SW(curthread); > + pcb_save =3D curthread->td_pcb->pcb_save; > + control =3D pcb_save->sv_env.en_cw; > + status =3D pcb_save->sv_env.en_sw; > } else { > fnstcw(&control); > fnstsw(&status); > + fnclex(); > } > =20 > - if (PCPU_GET(fpcurthread) =3D=3D curthread) > - fnclex(); > critical_exit(); > return (fpetable[status & ((~control & 0x3f) | 0x40)]); > } Hmm, the separate trap handlers are more needed, yet more broken, than I first thought. I first thouught that it was necessary to merge the statuses like the patch in the PR does. After all, fenv(3) can do no better. The control words had better be the same (after masking with 0x3f), or the signal code will be nonsense. fenv(3) depends on this too. The separate trap handlers allow use to use the control word that matches the status word and the signal code to be only for the hardware that generated the trap. However, this is worse than useless, since the signal code doesn't encode which hardware generated the trap. > =20 > +int > +fputrap_sse(void) The 'fpu' name is more bogus than usual. This is not an fpu trap, but an sse trap. There is a related problem with the trap name. It is T_XMMFLT. But this trap can presumably also be caused by YMM and newer extensions (AVX?). > +{ > + u_int mxcsr; > + u_short control, status; > + > + critical_enter(); > + > + /* > + * Coomparing with the x87 #MF handler, we do not clear > + * exceptions from the mxcsr. > + */ > + if (PCPU_GET(fpcurthread) !=3D curthread) > + mxcsr =3D curthread->td_pcb->pcb_save->sv_env.en_mxcsr; > + else > + stmxcsr(&mxcsr); > + > + critical_exit(); > + > + status =3D mxcsr & 0x3f; > + control =3D (mxcsr >> 16) & 0x3f; > + return (fpetable[status & (~control | 0x40)]); The 0x40 bit doesn't exist in the mxcsr status and ORing it in here has no effect. Replace the last 3 lines by: return (fpetable[(status & (control >> 16)) & 0x3f]; > +} > + > /* > * Implement device not available (DNA) exception > * > diff --git a/sys/amd64/amd64/trap.c b/sys/amd64/amd64/trap.c > index 75e15e0..57d1cc2 100644 > --- a/sys/amd64/amd64/trap.c > +++ b/sys/amd64/amd64/trap.c > @@ -328,7 +328,7 @@ trap(struct trapframe *frame) > break; > =20 > case T_ARITHTRAP: /* arithmetic trap */ > - ucode =3D fputrap(); > + ucode =3D fputrap_x87(); > if (ucode =3D=3D -1) > goto userout; > i =3D SIGFPE; > @@ -442,7 +442,9 @@ trap(struct trapframe *frame) > break; > =20 > case T_XMMFLT: /* SIMD floating-point exception */ > - ucode =3D 0; /* XXX */ > + ucode =3D fputrap_sse(); > + if (ucode =3D=3D -1) > + goto userout; The T_FOO code could be encoded here, but I think there is no space to spare, and any extension would further complicate the decoding. Not many SIGFPE handlers understand the current encoding. > i =3D SIGFPE; > break; > } So I still want a single kernel exception handle that merges the statuses. Bruce From owner-freebsd-amd64@FreeBSD.ORG Tue Jul 17 15:27:38 2012 Return-Path: Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90BAE106564A for ; Tue, 17 Jul 2012 15:27:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id 0DEA58FC0C for ; Tue, 17 Jul 2012 15:27:37 +0000 (UTC) Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q6HFRTP6025993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2012 01:27:30 +1000 Date: Wed, 18 Jul 2012 01:27:29 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans In-Reply-To: <20120717235622.C7417@besplex.bde.org> Message-ID: <20120718011942.D7642@besplex.bde.org> References: <201207171350.q6HDoAJS033797@freefall.freebsd.org> <20120717235622.C7417@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-amd64@FreeBSD.org Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jul 2012 15:27:38 -0000 On Wed, 18 Jul 2012, Bruce Evans wrote: > On Tue, 17 Jul 2012, Konstantin Belousov wrote: >> ... >> + status =3D mxcsr & 0x3f; >> + control =3D (mxcsr >> 16) & 0x3f; >> + return (fpetable[status & (~control | 0x40)]); > > The 0x40 bit doesn't exist in the mxcsr status and ORing it in here has > no effect. Replace the last 3 lines by: > > return (fpetable[(status & (control >> 16)) & 0x3f]; Change status and control to mxcsr here, and remove the status and control variables. > .. > So I still want a single kernel exception handle that merges the statuses. Merge the independent statuses modified by their independent controls: return (fpetable[(fpsw & ((~fpcw & 0x3f) | 0x40)) | ((mxcsr & (mxcsr >> 16)) & 0x3f)]); Use the same trap handler that reads all these statuses and controls. Bruce From owner-freebsd-amd64@FreeBSD.ORG Tue Jul 17 16:04:19 2012 Return-Path: Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52016106564A for ; Tue, 17 Jul 2012 16:04:19 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id D81998FC08 for ; Tue, 17 Jul 2012 16:04:18 +0000 (UTC) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q6HG4CTF026574 for ; Wed, 18 Jul 2012 02:04:12 +1000 Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q6HG3wOl012957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2012 02:04:04 +1000 Date: Wed, 18 Jul 2012 02:03:58 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans In-Reply-To: <20120718011942.D7642@besplex.bde.org> Message-ID: <20120718014222.V7761@besplex.bde.org> References: <201207171350.q6HDoAJS033797@freefall.freebsd.org> <20120717235622.C7417@besplex.bde.org> <20120718011942.D7642@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-amd64@FreeBSD.org Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jul 2012 16:04:19 -0000 On Wed, 18 Jul 2012, Bruce Evans wrote: > On Wed, 18 Jul 2012, Bruce Evans wrote: >> .. >> So I still want a single kernel exception handle that merges the statuses. > > Merge the independent statuses modified by their independent controls: > > return (fpetable[(fpsw & ((~fpcw & 0x3f) | 0x40)) | > ((mxcsr & (mxcsr >> 16)) & 0x3f)]); > > Use the same trap handler that reads all these statuses and controls. Changed my mind again. Need sleep. Merging the traps breaks the rule that i387 traps occur on the first non-control instruction after the one that causes the exception. There may be mixed code like this: fldz fld1 fdiv %st,%st(1) # i387 exception now; i387 trap pending load $0 into %xmm0 load $1 into %xmm1 divsd %xmm0,%xmm1 # SSE exception now; SSE trap now Debuggers can see both exception states including the i387 trap pending, provided the i387 trap is not bogusly cleared, either by never clearing it in the kernel trap handler or by using a separate trap handler that doesn't clear it for T_XMMFLT. They can even figure out that an SSE trap occurred, because the i387 trap is still pending. ... fnop # i387 trap on first non-control FP instr... Apart from doing the bogus fnclex for T_XMMFLT and the delayed effect of i387 status bits, merging or not merging the statuses makes little difference, since if a status bit is set and is not masked according to its control word, then it will generate a trap soon if it didn't genearate the current one. Bruce From owner-freebsd-amd64@FreeBSD.ORG Tue Jul 17 17:09:21 2012 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21FB3106566B for ; Tue, 17 Jul 2012 17:09:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 8358B8FC0A for ; Tue, 17 Jul 2012 17:09:20 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6HH9SOO013368; Tue, 17 Jul 2012 20:09:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q6HH9G7n023980; Tue, 17 Jul 2012 20:09:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6HH9FW2023979; Tue, 17 Jul 2012 20:09:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 17 Jul 2012 20:09:15 +0300 From: Konstantin Belousov To: Bruce Evans Message-ID: <20120717170915.GL2676@deviant.kiev.zoral.com.ua> References: <201207171350.q6HDoAJS033797@freefall.freebsd.org> <20120717235622.C7417@besplex.bde.org> <20120718011942.D7642@besplex.bde.org> <20120718014222.V7761@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EEx6GiKZGZ1wKUra" Content-Disposition: inline In-Reply-To: <20120718014222.V7761@besplex.bde.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-amd64@freebsd.org Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jul 2012 17:09:21 -0000 --EEx6GiKZGZ1wKUra Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 18, 2012 at 02:03:58AM +1000, Bruce Evans wrote: > On Wed, 18 Jul 2012, Bruce Evans wrote: >=20 > >On Wed, 18 Jul 2012, Bruce Evans wrote: > >>.. > >>So I still want a single kernel exception handle that merges the status= es. > > > >Merge the independent statuses modified by their independent controls: > > > > return (fpetable[(fpsw & ((~fpcw & 0x3f) | 0x40)) | > > ((mxcsr & (mxcsr >> 16)) & 0x3f)]); > > > >Use the same trap handler that reads all these statuses and controls. >=20 > Changed my mind again. Need sleep. Merging the traps breaks the rule > that i387 traps occur on the first non-control instruction after the > one that causes the exception. There may be mixed code like this: >=20 > fldz > fld1 > fdiv %st,%st(1) # i387 exception now; i387 trap pending > load $0 into %xmm0 > load $1 into %xmm1 > divsd %xmm0,%xmm1 # SSE exception now; SSE trap now >=20 > Debuggers can see both exception states including the i387 trap pending, > provided the i387 trap is not bogusly cleared, either by never clearing > it in the kernel trap handler or by using a separate trap handler that > doesn't clear it for T_XMMFLT. They can even figure out that an SSE > trap occurred, because the i387 trap is still pending. >=20 > ... > fnop # i387 trap on first non-control FP instr... >=20 > Apart from doing the bogus fnclex for T_XMMFLT and the delayed effect of > i387 status bits, merging or not merging the statuses makes little > difference, since if a status bit is set and is not masked according > to its control word, then it will generate a trap soon if it didn't > genearate the current one. The trap number is available for SA_SIGINFO type of handlers with si_trapno member of siginfo_t. I think this is final argument to have separate fputrap_{x87,sse} functions. For amd64, SSE hardware is FPU, so I do not see much wrong with the name. I changed fputrap_sse() according to your suggestion. diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c index a7812b7..356b3ac 100644 --- a/sys/amd64/amd64/fpu.c +++ b/sys/amd64/amd64/fpu.c @@ -73,6 +73,7 @@ __FBSDID("$FreeBSD$"); #define fxrstor(addr) __asm __volatile("fxrstor %0" : : "m" (*(addr))) #define fxsave(addr) __asm __volatile("fxsave %0" : "=3Dm" (*(addr))) #define ldmxcsr(csr) __asm __volatile("ldmxcsr %0" : : "m" (csr)) +#define stmxcsr(addr) __asm __volatile("stmxcsr %0" : : "m" (*(addr))) =20 static __inline void xrstor(char *addr, uint64_t mask) @@ -105,6 +106,7 @@ void fnstsw(caddr_t addr); void fxsave(caddr_t addr); void fxrstor(caddr_t addr); void ldmxcsr(u_int csr); +void stmxcsr(u_int csr); void xrstor(char *addr, uint64_t mask); void xsave(char *addr, uint64_t mask); =20 @@ -113,9 +115,6 @@ void xsave(char *addr, uint64_t mask); #define start_emulating() load_cr0(rcr0() | CR0_TS) #define stop_emulating() clts() =20 -#define GET_FPU_CW(thread) ((thread)->td_pcb->pcb_save->sv_env.en_cw) -#define GET_FPU_SW(thread) ((thread)->td_pcb->pcb_save->sv_env.en_sw) - CTASSERT(sizeof(struct savefpu) =3D=3D 512); CTASSERT(sizeof(struct xstate_hdr) =3D=3D 64); CTASSERT(sizeof(struct savefpu_ymm) =3D=3D 832); @@ -514,11 +513,15 @@ static char fpetable[128] =3D { }; =20 /* - * Preserve the FP status word, clear FP exceptions, then generate a SIGFP= E. + * Preserve the FP status word, clear FP exceptions for x87, then + * generate a SIGFPE. + * + * Clearing exceptions was necessary mainly to avoid IRQ13 bugs and is + * engraved in our i386 ABI. We now depend on longjmp() restoring a + * usable state. Restoring the state or examining it might fail if we + * didn't clear exceptions. * - * Clearing exceptions is necessary mainly to avoid IRQ13 bugs. We now - * depend on longjmp() restoring a usable state. Restoring the state - * or examining it might fail if we didn't clear exceptions. + * For SSE exceptions, the exceptions are not cleared. * * The error code chosen will be one of the FPE_... macros. It will be * sent as the second argument to old BSD-style signal handlers and as @@ -531,8 +534,9 @@ static char fpetable[128] =3D { * solution for signals other than SIGFPE. */ int -fputrap() +fputrap_x87(void) { + struct savefpu *pcb_save; u_short control, status; =20 critical_enter(); @@ -543,19 +547,40 @@ fputrap() * wherever they are. */ if (PCPU_GET(fpcurthread) !=3D curthread) { - control =3D GET_FPU_CW(curthread); - status =3D GET_FPU_SW(curthread); + pcb_save =3D curthread->td_pcb->pcb_save; + control =3D pcb_save->sv_env.en_cw; + status =3D pcb_save->sv_env.en_sw; } else { fnstcw(&control); fnstsw(&status); + fnclex(); } =20 - if (PCPU_GET(fpcurthread) =3D=3D curthread) - fnclex(); critical_exit(); return (fpetable[status & ((~control & 0x3f) | 0x40)]); } =20 +int +fputrap_sse(void) +{ + u_int mxcsr; + + critical_enter(); + + /* + * Coomparing with the x87 #MF handler, we do not clear + * exceptions from the mxcsr. + */ + if (PCPU_GET(fpcurthread) !=3D curthread) + mxcsr =3D curthread->td_pcb->pcb_save->sv_env.en_mxcsr; + else + stmxcsr(&mxcsr); + + critical_exit(); + + return (fpetable[(mxcsr & (mxcsr >> 16)) & 0x3f]); +} + /* * Implement device not available (DNA) exception * diff --git a/sys/amd64/amd64/trap.c b/sys/amd64/amd64/trap.c index 75e15e0..57d1cc2 100644 --- a/sys/amd64/amd64/trap.c +++ b/sys/amd64/amd64/trap.c @@ -328,7 +328,7 @@ trap(struct trapframe *frame) break; =20 case T_ARITHTRAP: /* arithmetic trap */ - ucode =3D fputrap(); + ucode =3D fputrap_x87(); if (ucode =3D=3D -1) goto userout; i =3D SIGFPE; @@ -442,7 +442,9 @@ trap(struct trapframe *frame) break; =20 case T_XMMFLT: /* SIMD floating-point exception */ - ucode =3D 0; /* XXX */ + ucode =3D fputrap_sse(); + if (ucode =3D=3D -1) + goto userout; i =3D SIGFPE; break; } diff --git a/sys/amd64/include/fpu.h b/sys/amd64/include/fpu.h index 98a016b..7d0f0ea 100644 --- a/sys/amd64/include/fpu.h +++ b/sys/amd64/include/fpu.h @@ -62,7 +62,8 @@ int fpusetregs(struct thread *td, struct savefpu *addr, char *xfpustate, size_t xfpustate_size); int fpusetxstate(struct thread *td, char *xfpustate, size_t xfpustate_size); -int fputrap(void); +int fputrap_sse(void); +int fputrap_x87(void); void fpuuserinited(struct thread *td); struct fpu_kern_ctx *fpu_kern_alloc_ctx(u_int flags); void fpu_kern_free_ctx(struct fpu_kern_ctx *ctx); --EEx6GiKZGZ1wKUra Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAFnDoACgkQC3+MBN1Mb4ieJACgndEzfeGT+kCl//cGsh38AbgU ReEAn3p16o10AVdF+k4b9xFRDZaEYkOm =HxFX -----END PGP SIGNATURE----- --EEx6GiKZGZ1wKUra-- From owner-freebsd-amd64@FreeBSD.ORG Tue Jul 17 18:26:27 2012 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3FAB2106566C for ; Tue, 17 Jul 2012 18:26:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 9DF178FC1B for ; Tue, 17 Jul 2012 18:26:26 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6HIQWW6018998; Tue, 17 Jul 2012 21:26:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q6HIQJVV024413; Tue, 17 Jul 2012 21:26:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6HIQJfO024412; Tue, 17 Jul 2012 21:26:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 17 Jul 2012 21:26:19 +0300 From: Konstantin Belousov To: Bruce Evans Message-ID: <20120717182619.GN2676@deviant.kiev.zoral.com.ua> References: <201207171350.q6HDoAJS033797@freefall.freebsd.org> <20120717235622.C7417@besplex.bde.org> <20120718011942.D7642@besplex.bde.org> <20120718014222.V7761@besplex.bde.org> <20120717170915.GL2676@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rPgHZmYkQ+bUEpVC" Content-Disposition: inline In-Reply-To: <20120717170915.GL2676@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-amd64@freebsd.org Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jul 2012 18:26:27 -0000 --rPgHZmYkQ+bUEpVC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 17, 2012 at 08:09:15PM +0300, Konstantin Belousov wrote: > On Wed, Jul 18, 2012 at 02:03:58AM +1000, Bruce Evans wrote: > > On Wed, 18 Jul 2012, Bruce Evans wrote: > >=20 > > >On Wed, 18 Jul 2012, Bruce Evans wrote: > > >>.. > > >>So I still want a single kernel exception handle that merges the stat= uses. > > > > > >Merge the independent statuses modified by their independent controls: > > > > > > return (fpetable[(fpsw & ((~fpcw & 0x3f) | 0x40)) | > > > ((mxcsr & (mxcsr >> 16)) & 0x3f)]); > > > > > >Use the same trap handler that reads all these statuses and controls. > >=20 > > Changed my mind again. Need sleep. Merging the traps breaks the rule > > that i387 traps occur on the first non-control instruction after the > > one that causes the exception. There may be mixed code like this: > >=20 > > fldz > > fld1 > > fdiv %st,%st(1) # i387 exception now; i387 trap pending > > load $0 into %xmm0 > > load $1 into %xmm1 > > divsd %xmm0,%xmm1 # SSE exception now; SSE trap now > >=20 > > Debuggers can see both exception states including the i387 trap pending, > > provided the i387 trap is not bogusly cleared, either by never clearing > > it in the kernel trap handler or by using a separate trap handler that > > doesn't clear it for T_XMMFLT. They can even figure out that an SSE > > trap occurred, because the i387 trap is still pending. > >=20 > > ... > > fnop # i387 trap on first non-control FP instr... > >=20 > > Apart from doing the bogus fnclex for T_XMMFLT and the delayed effect of > > i387 status bits, merging or not merging the statuses makes little > > difference, since if a status bit is set and is not masked according > > to its control word, then it will generate a trap soon if it didn't > > genearate the current one. >=20 > The trap number is available for SA_SIGINFO type of handlers with > si_trapno member of siginfo_t. I think this is final argument to have > separate fputrap_{x87,sse} functions. >=20 > For amd64, SSE hardware is FPU, so I do not see much wrong with the name. >=20 > I changed fputrap_sse() according to your suggestion. Below is the actually tested patch. After it, I put the test program. diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c index a7812b7..ae241ce 100644 --- a/sys/amd64/amd64/fpu.c +++ b/sys/amd64/amd64/fpu.c @@ -73,6 +73,7 @@ __FBSDID("$FreeBSD$"); #define fxrstor(addr) __asm __volatile("fxrstor %0" : : "m" (*(addr))) #define fxsave(addr) __asm __volatile("fxsave %0" : "=3Dm" (*(addr))) #define ldmxcsr(csr) __asm __volatile("ldmxcsr %0" : : "m" (csr)) +#define stmxcsr(addr) __asm __volatile("stmxcsr %0" : : "m" (*(addr))) =20 static __inline void xrstor(char *addr, uint64_t mask) @@ -105,6 +106,7 @@ void fnstsw(caddr_t addr); void fxsave(caddr_t addr); void fxrstor(caddr_t addr); void ldmxcsr(u_int csr); +void stmxcsr(u_int csr); void xrstor(char *addr, uint64_t mask); void xsave(char *addr, uint64_t mask); =20 @@ -113,9 +115,6 @@ void xsave(char *addr, uint64_t mask); #define start_emulating() load_cr0(rcr0() | CR0_TS) #define stop_emulating() clts() =20 -#define GET_FPU_CW(thread) ((thread)->td_pcb->pcb_save->sv_env.en_cw) -#define GET_FPU_SW(thread) ((thread)->td_pcb->pcb_save->sv_env.en_sw) - CTASSERT(sizeof(struct savefpu) =3D=3D 512); CTASSERT(sizeof(struct xstate_hdr) =3D=3D 64); CTASSERT(sizeof(struct savefpu_ymm) =3D=3D 832); @@ -514,11 +513,15 @@ static char fpetable[128] =3D { }; =20 /* - * Preserve the FP status word, clear FP exceptions, then generate a SIGFP= E. + * Preserve the FP status word, clear FP exceptions for x87, then + * generate a SIGFPE. + * + * Clearing exceptions was necessary mainly to avoid IRQ13 bugs and is + * engraved in our i386 ABI. We now depend on longjmp() restoring a + * usable state. Restoring the state or examining it might fail if we + * didn't clear exceptions. * - * Clearing exceptions is necessary mainly to avoid IRQ13 bugs. We now - * depend on longjmp() restoring a usable state. Restoring the state - * or examining it might fail if we didn't clear exceptions. + * For SSE exceptions, the exceptions are not cleared. * * The error code chosen will be one of the FPE_... macros. It will be * sent as the second argument to old BSD-style signal handlers and as @@ -531,8 +534,9 @@ static char fpetable[128] =3D { * solution for signals other than SIGFPE. */ int -fputrap() +fputrap_x87(void) { + struct savefpu *pcb_save; u_short control, status; =20 critical_enter(); @@ -543,19 +547,40 @@ fputrap() * wherever they are. */ if (PCPU_GET(fpcurthread) !=3D curthread) { - control =3D GET_FPU_CW(curthread); - status =3D GET_FPU_SW(curthread); + pcb_save =3D curthread->td_pcb->pcb_save; + control =3D pcb_save->sv_env.en_cw; + status =3D pcb_save->sv_env.en_sw; } else { fnstcw(&control); fnstsw(&status); + fnclex(); } =20 - if (PCPU_GET(fpcurthread) =3D=3D curthread) - fnclex(); critical_exit(); return (fpetable[status & ((~control & 0x3f) | 0x40)]); } =20 +int +fputrap_sse(void) +{ + u_int mxcsr; + + critical_enter(); + + /* + * Coomparing with the x87 #MF handler, we do not clear + * exceptions from the mxcsr. + */ + if (PCPU_GET(fpcurthread) !=3D curthread) + mxcsr =3D curthread->td_pcb->pcb_save->sv_env.en_mxcsr; + else + stmxcsr(&mxcsr); + + critical_exit(); + + return (fpetable[(mxcsr & (~mxcsr >> 7)) & 0x3f]); +} + /* * Implement device not available (DNA) exception * diff --git a/sys/amd64/amd64/trap.c b/sys/amd64/amd64/trap.c index 75e15e0..57d1cc2 100644 --- a/sys/amd64/amd64/trap.c +++ b/sys/amd64/amd64/trap.c @@ -328,7 +328,7 @@ trap(struct trapframe *frame) break; =20 case T_ARITHTRAP: /* arithmetic trap */ - ucode =3D fputrap(); + ucode =3D fputrap_x87(); if (ucode =3D=3D -1) goto userout; i =3D SIGFPE; @@ -442,7 +442,9 @@ trap(struct trapframe *frame) break; =20 case T_XMMFLT: /* SIMD floating-point exception */ - ucode =3D 0; /* XXX */ + ucode =3D fputrap_sse(); + if (ucode =3D=3D -1) + goto userout; i =3D SIGFPE; break; } diff --git a/sys/amd64/include/fpu.h b/sys/amd64/include/fpu.h index 98a016b..7d0f0ea 100644 --- a/sys/amd64/include/fpu.h +++ b/sys/amd64/include/fpu.h @@ -62,7 +62,8 @@ int fpusetregs(struct thread *td, struct savefpu *addr, char *xfpustate, size_t xfpustate_size); int fpusetxstate(struct thread *td, char *xfpustate, size_t xfpustate_size); -int fputrap(void); +int fputrap_sse(void); +int fputrap_x87(void); void fpuuserinited(struct thread *td); struct fpu_kern_ctx *fpu_kern_alloc_ctx(u_int flags); void fpu_kern_free_ctx(struct fpu_kern_ctx *ctx); fpuex.c: /* $Id: fpuex.c,v 1.2 2012/07/17 18:22:54 kostik Exp kostik $ */ #include #include #include #include #include #include #include #include #include #if defined(__amd64__) #include #elif defined(__i386__) #include #endif static void handler(int signo __unused, siginfo_t *info, void *v) { ucontext_t *uap; mcontext_t *mc; #if defined(__amd64__) struct savefpu *sf; #elif defined(__i386__) struct savexmm *sf; #endif uap =3D v; mc =3D &uap->uc_mcontext; sf =3D &mc->mc_fpstate; printf("intr handler: trapno %d code %d cw 0x%04x sw 0x%04x mxcsr 0x%08x i= p 0x%lx\n", info->si_trapno, info->si_code, #if defined(__amd64__) sf->sv_env.en_cw, sf->sv_env.en_sw, sf->sv_env.en_mxcsr, sf->sv_env.en_rip #elif defined(__i386__) sf->sv_env.en_cw, sf->sv_env.en_sw, sf->sv_env.en_mxcsr, (unsigned long)sf->sv_env.en_fip #endif ); exit(0); } double a[3]; double x(void) __attribute__((noinline)); double x(void) { a[3] =3D a[0] / a[1]; return (a[3]); } int main(void) { struct sigaction sa; uint32_t mxcsr; uint16_t cw; bzero(&sa, sizeof(sa)); sa.sa_sigaction =3D handler; sa.sa_flags =3D SA_SIGINFO; if (sigaction(SIGFPE, &sa, NULL) =3D=3D -1) err(1, "sigaction SIGFPE"); mxcsr =3D 0; __asm __volatile("ldmxcsr %0" : : "m" (mxcsr)); #ifdef __i386__ cw =3D 0; __asm __volatile("fldcw %0" : : "m" (cw)); #endif a[0] =3D 1.0; a[1] =3D 0.0; x(); return (0); } --rPgHZmYkQ+bUEpVC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAFrksACgkQC3+MBN1Mb4guEgCg8skWvaBfYXP+FvQ4+2MRXXTE HV4AnigWyJuxpnD8pd735LIUj0BuWd7G =515j -----END PGP SIGNATURE----- --rPgHZmYkQ+bUEpVC-- From owner-freebsd-amd64@FreeBSD.ORG Tue Jul 17 21:50:15 2012 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC02B106566C for ; Tue, 17 Jul 2012 21:50:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8BA1D8FC0C for ; Tue, 17 Jul 2012 21:50:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6HLoFXK096743 for ; Tue, 17 Jul 2012 21:50:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6HLoFvB096742; Tue, 17 Jul 2012 21:50:15 GMT (envelope-from gnats) Date: Tue, 17 Jul 2012 21:50:15 GMT Message-Id: <201207172150.q6HLoFvB096742@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Mark Linimon X-Mailman-Approved-At: Tue, 17 Jul 2012 22:06:27 +0000 Cc: Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mark Linimon List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 21:50:15 -0000 The following reply was made to PR amd64/169927; it has been noted by GNATS. From: Mark Linimon To: bug-followup@FreeBSD.org Cc: Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor Date: Tue, 17 Jul 2012 16:49:45 -0500 ----- Forwarded message from Konstantin Belousov ----- Date: Tue, 17 Jul 2012 20:09:15 +0300 From: Konstantin Belousov To: Bruce Evans Cc: freebsd-amd64@freebsd.org Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor User-Agent: Mutt/1.4.2.3i On Wed, Jul 18, 2012 at 02:03:58AM +1000, Bruce Evans wrote: > Apart from doing the bogus fnclex for T_XMMFLT and the delayed effect of > i387 status bits, merging or not merging the statuses makes little > difference, since if a status bit is set and is not masked according > to its control word, then it will generate a trap soon if it didn't > genearate the current one. The trap number is available for SA_SIGINFO type of handlers with si_trapno member of siginfo_t. I think this is final argument to have separate fputrap_{x87,sse} functions. For amd64, SSE hardware is FPU, so I do not see much wrong with the name. I changed fputrap_sse() according to your suggestion. diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c index a7812b7..356b3ac 100644 --- a/sys/amd64/amd64/fpu.c +++ b/sys/amd64/amd64/fpu.c @@ -73,6 +73,7 @@ __FBSDID("$FreeBSD$"); #define fxrstor(addr) __asm __volatile("fxrstor %0" : : "m" (*(addr))) #define fxsave(addr) __asm __volatile("fxsave %0" : "=m" (*(addr))) #define ldmxcsr(csr) __asm __volatile("ldmxcsr %0" : : "m" (csr)) +#define stmxcsr(addr) __asm __volatile("stmxcsr %0" : : "m" (*(addr))) static __inline void xrstor(char *addr, uint64_t mask) @@ -105,6 +106,7 @@ void fnstsw(caddr_t addr); void fxsave(caddr_t addr); void fxrstor(caddr_t addr); void ldmxcsr(u_int csr); +void stmxcsr(u_int csr); void xrstor(char *addr, uint64_t mask); void xsave(char *addr, uint64_t mask); @@ -113,9 +115,6 @@ void xsave(char *addr, uint64_t mask); #define start_emulating() load_cr0(rcr0() | CR0_TS) #define stop_emulating() clts() -#define GET_FPU_CW(thread) ((thread)->td_pcb->pcb_save->sv_env.en_cw) -#define GET_FPU_SW(thread) ((thread)->td_pcb->pcb_save->sv_env.en_sw) - CTASSERT(sizeof(struct savefpu) == 512); CTASSERT(sizeof(struct xstate_hdr) == 64); CTASSERT(sizeof(struct savefpu_ymm) == 832); @@ -514,11 +513,15 @@ static char fpetable[128] = { }; /* - * Preserve the FP status word, clear FP exceptions, then generate a SIGFPE. + * Preserve the FP status word, clear FP exceptions for x87, then + * generate a SIGFPE. + * + * Clearing exceptions was necessary mainly to avoid IRQ13 bugs and is + * engraved in our i386 ABI. We now depend on longjmp() restoring a + * usable state. Restoring the state or examining it might fail if we + * didn't clear exceptions. * - * Clearing exceptions is necessary mainly to avoid IRQ13 bugs. We now - * depend on longjmp() restoring a usable state. Restoring the state - * or examining it might fail if we didn't clear exceptions. + * For SSE exceptions, the exceptions are not cleared. * * The error code chosen will be one of the FPE_... macros. It will be * sent as the second argument to old BSD-style signal handlers and as @@ -531,8 +534,9 @@ static char fpetable[128] = { * solution for signals other than SIGFPE. */ int -fputrap() +fputrap_x87(void) { + struct savefpu *pcb_save; u_short control, status; critical_enter(); @@ -543,19 +547,40 @@ fputrap() * wherever they are. */ if (PCPU_GET(fpcurthread) != curthread) { - control = GET_FPU_CW(curthread); - status = GET_FPU_SW(curthread); + pcb_save = curthread->td_pcb->pcb_save; + control = pcb_save->sv_env.en_cw; + status = pcb_save->sv_env.en_sw; } else { fnstcw(&control); fnstsw(&status); + fnclex(); } - if (PCPU_GET(fpcurthread) == curthread) - fnclex(); critical_exit(); return (fpetable[status & ((~control & 0x3f) | 0x40)]); } +int +fputrap_sse(void) +{ + u_int mxcsr; + + critical_enter(); + + /* + * Coomparing with the x87 #MF handler, we do not clear + * exceptions from the mxcsr. + */ + if (PCPU_GET(fpcurthread) != curthread) + mxcsr = curthread->td_pcb->pcb_save->sv_env.en_mxcsr; + else + stmxcsr(&mxcsr); + + critical_exit(); + + return (fpetable[(mxcsr & (mxcsr >> 16)) & 0x3f]); +} + /* * Implement device not available (DNA) exception * diff --git a/sys/amd64/amd64/trap.c b/sys/amd64/amd64/trap.c index 75e15e0..57d1cc2 100644 --- a/sys/amd64/amd64/trap.c +++ b/sys/amd64/amd64/trap.c @@ -328,7 +328,7 @@ trap(struct trapframe *frame) break; case T_ARITHTRAP: /* arithmetic trap */ - ucode = fputrap(); + ucode = fputrap_x87(); if (ucode == -1) goto userout; i = SIGFPE; @@ -442,7 +442,9 @@ trap(struct trapframe *frame) break; case T_XMMFLT: /* SIMD floating-point exception */ - ucode = 0; /* XXX */ + ucode = fputrap_sse(); + if (ucode == -1) + goto userout; i = SIGFPE; break; } diff --git a/sys/amd64/include/fpu.h b/sys/amd64/include/fpu.h index 98a016b..7d0f0ea 100644 --- a/sys/amd64/include/fpu.h +++ b/sys/amd64/include/fpu.h @@ -62,7 +62,8 @@ int fpusetregs(struct thread *td, struct savefpu *addr, char *xfpustate, size_t xfpustate_size); int fpusetxstate(struct thread *td, char *xfpustate, size_t xfpustate_size); -int fputrap(void); +int fputrap_sse(void); +int fputrap_x87(void); void fpuuserinited(struct thread *td); struct fpu_kern_ctx *fpu_kern_alloc_ctx(u_int flags); void fpu_kern_free_ctx(struct fpu_kern_ctx *ctx); ----- End forwarded message ----- From owner-freebsd-amd64@FreeBSD.ORG Tue Jul 17 22:00:30 2012 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C1BBD106566B for ; Tue, 17 Jul 2012 22:00:30 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A32698FC08 for ; Tue, 17 Jul 2012 22:00:30 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6HM0U9K097181 for ; Tue, 17 Jul 2012 22:00:30 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6HM0U6Z097180; Tue, 17 Jul 2012 22:00:30 GMT (envelope-from gnats) Date: Tue, 17 Jul 2012 22:00:30 GMT Message-Id: <201207172200.q6HM0U6Z097180@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Mark Linimon X-Mailman-Approved-At: Tue, 17 Jul 2012 22:19:47 +0000 Cc: Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mark Linimon List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 22:00:30 -0000 The following reply was made to PR amd64/169927; it has been noted by GNATS. From: Mark Linimon To: bug-followup@FreeBSD.org Cc: Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor Date: Tue, 17 Jul 2012 16:50:18 -0500 ----- Forwarded message from Konstantin Belousov ----- Date: Tue, 17 Jul 2012 21:26:19 +0300 From: Konstantin Belousov To: Bruce Evans Cc: freebsd-amd64@freebsd.org Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor On Tue, Jul 17, 2012 at 08:09:15PM +0300, Konstantin Belousov wrote: > The trap number is available for SA_SIGINFO type of handlers with > si_trapno member of siginfo_t. I think this is final argument to have > separate fputrap_{x87,sse} functions. > > For amd64, SSE hardware is FPU, so I do not see much wrong with the name. > > I changed fputrap_sse() according to your suggestion. Below is the actually tested patch. After it, I put the test program. diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c index a7812b7..ae241ce 100644 --- a/sys/amd64/amd64/fpu.c +++ b/sys/amd64/amd64/fpu.c @@ -73,6 +73,7 @@ __FBSDID("$FreeBSD$"); #define fxrstor(addr) __asm __volatile("fxrstor %0" : : "m" (*(addr))) #define fxsave(addr) __asm __volatile("fxsave %0" : "=m" (*(addr))) #define ldmxcsr(csr) __asm __volatile("ldmxcsr %0" : : "m" (csr)) +#define stmxcsr(addr) __asm __volatile("stmxcsr %0" : : "m" (*(addr))) static __inline void xrstor(char *addr, uint64_t mask) @@ -105,6 +106,7 @@ void fnstsw(caddr_t addr); void fxsave(caddr_t addr); void fxrstor(caddr_t addr); void ldmxcsr(u_int csr); +void stmxcsr(u_int csr); void xrstor(char *addr, uint64_t mask); void xsave(char *addr, uint64_t mask); @@ -113,9 +115,6 @@ void xsave(char *addr, uint64_t mask); #define start_emulating() load_cr0(rcr0() | CR0_TS) #define stop_emulating() clts() -#define GET_FPU_CW(thread) ((thread)->td_pcb->pcb_save->sv_env.en_cw) -#define GET_FPU_SW(thread) ((thread)->td_pcb->pcb_save->sv_env.en_sw) - CTASSERT(sizeof(struct savefpu) == 512); CTASSERT(sizeof(struct xstate_hdr) == 64); CTASSERT(sizeof(struct savefpu_ymm) == 832); @@ -514,11 +513,15 @@ static char fpetable[128] = { }; /* - * Preserve the FP status word, clear FP exceptions, then generate a SIGFPE. + * Preserve the FP status word, clear FP exceptions for x87, then + * generate a SIGFPE. + * + * Clearing exceptions was necessary mainly to avoid IRQ13 bugs and is + * engraved in our i386 ABI. We now depend on longjmp() restoring a + * usable state. Restoring the state or examining it might fail if we + * didn't clear exceptions. * - * Clearing exceptions is necessary mainly to avoid IRQ13 bugs. We now - * depend on longjmp() restoring a usable state. Restoring the state - * or examining it might fail if we didn't clear exceptions. + * For SSE exceptions, the exceptions are not cleared. * * The error code chosen will be one of the FPE_... macros. It will be * sent as the second argument to old BSD-style signal handlers and as @@ -531,8 +534,9 @@ static char fpetable[128] = { * solution for signals other than SIGFPE. */ int -fputrap() +fputrap_x87(void) { + struct savefpu *pcb_save; u_short control, status; critical_enter(); @@ -543,19 +547,40 @@ fputrap() * wherever they are. */ if (PCPU_GET(fpcurthread) != curthread) { - control = GET_FPU_CW(curthread); - status = GET_FPU_SW(curthread); + pcb_save = curthread->td_pcb->pcb_save; + control = pcb_save->sv_env.en_cw; + status = pcb_save->sv_env.en_sw; } else { fnstcw(&control); fnstsw(&status); + fnclex(); } - if (PCPU_GET(fpcurthread) == curthread) - fnclex(); critical_exit(); return (fpetable[status & ((~control & 0x3f) | 0x40)]); } +int +fputrap_sse(void) +{ + u_int mxcsr; + + critical_enter(); + + /* + * Coomparing with the x87 #MF handler, we do not clear + * exceptions from the mxcsr. + */ + if (PCPU_GET(fpcurthread) != curthread) + mxcsr = curthread->td_pcb->pcb_save->sv_env.en_mxcsr; + else + stmxcsr(&mxcsr); + + critical_exit(); + + return (fpetable[(mxcsr & (~mxcsr >> 7)) & 0x3f]); +} + /* * Implement device not available (DNA) exception * diff --git a/sys/amd64/amd64/trap.c b/sys/amd64/amd64/trap.c index 75e15e0..57d1cc2 100644 --- a/sys/amd64/amd64/trap.c +++ b/sys/amd64/amd64/trap.c @@ -328,7 +328,7 @@ trap(struct trapframe *frame) break; case T_ARITHTRAP: /* arithmetic trap */ - ucode = fputrap(); + ucode = fputrap_x87(); if (ucode == -1) goto userout; i = SIGFPE; @@ -442,7 +442,9 @@ trap(struct trapframe *frame) break; case T_XMMFLT: /* SIMD floating-point exception */ - ucode = 0; /* XXX */ + ucode = fputrap_sse(); + if (ucode == -1) + goto userout; i = SIGFPE; break; } diff --git a/sys/amd64/include/fpu.h b/sys/amd64/include/fpu.h index 98a016b..7d0f0ea 100644 --- a/sys/amd64/include/fpu.h +++ b/sys/amd64/include/fpu.h @@ -62,7 +62,8 @@ int fpusetregs(struct thread *td, struct savefpu *addr, char *xfpustate, size_t xfpustate_size); int fpusetxstate(struct thread *td, char *xfpustate, size_t xfpustate_size); -int fputrap(void); +int fputrap_sse(void); +int fputrap_x87(void); void fpuuserinited(struct thread *td); struct fpu_kern_ctx *fpu_kern_alloc_ctx(u_int flags); void fpu_kern_free_ctx(struct fpu_kern_ctx *ctx); fpuex.c: /* $Id: fpuex.c,v 1.2 2012/07/17 18:22:54 kostik Exp kostik $ */ #include #include #include #include #include #include #include #include #include #if defined(__amd64__) #include #elif defined(__i386__) #include #endif static void handler(int signo __unused, siginfo_t *info, void *v) { ucontext_t *uap; mcontext_t *mc; #if defined(__amd64__) struct savefpu *sf; #elif defined(__i386__) struct savexmm *sf; #endif uap = v; mc = &uap->uc_mcontext; sf = &mc->mc_fpstate; printf("intr handler: trapno %d code %d cw 0x%04x sw 0x%04x mxcsr 0x%08x ip 0x%lx\n", info->si_trapno, info->si_code, #if defined(__amd64__) sf->sv_env.en_cw, sf->sv_env.en_sw, sf->sv_env.en_mxcsr, sf->sv_env.en_rip #elif defined(__i386__) sf->sv_env.en_cw, sf->sv_env.en_sw, sf->sv_env.en_mxcsr, (unsigned long)sf->sv_env.en_fip #endif ); exit(0); } double a[3]; double x(void) __attribute__((noinline)); double x(void) { a[3] = a[0] / a[1]; return (a[3]); } int main(void) { struct sigaction sa; uint32_t mxcsr; uint16_t cw; bzero(&sa, sizeof(sa)); sa.sa_sigaction = handler; sa.sa_flags = SA_SIGINFO; if (sigaction(SIGFPE, &sa, NULL) == -1) err(1, "sigaction SIGFPE"); mxcsr = 0; __asm __volatile("ldmxcsr %0" : : "m" (mxcsr)); #ifdef __i386__ cw = 0; __asm __volatile("fldcw %0" : : "m" (cw)); #endif a[0] = 1.0; a[1] = 0.0; x(); return (0); } ----- End forwarded message ----- From owner-freebsd-amd64@FreeBSD.ORG Tue Jul 17 22:30:15 2012 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A1A30106566B for ; Tue, 17 Jul 2012 22:30:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 721888FC1A for ; Tue, 17 Jul 2012 22:30:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6HMUFBU000624 for ; Tue, 17 Jul 2012 22:30:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6HMUFUa000621; Tue, 17 Jul 2012 22:30:15 GMT (envelope-from gnats) Date: Tue, 17 Jul 2012 22:30:15 GMT Message-Id: <201207172230.q6HMUFUa000621@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: =?iso-8859-1?Q?J=E9r=F4me_Lebel?= X-Mailman-Approved-At: Tue, 17 Jul 2012 22:44:36 +0000 Cc: Subject: Re: amd64/166639: [boot] Syscons issue Intel D2700 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?iso-8859-1?Q?J=E9r=F4me_Lebel?= List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 22:30:15 -0000 The following reply was made to PR amd64/166639; it has been noted by GNATS. From: =?iso-8859-1?Q?J=E9r=F4me_Lebel?= To: bug-followup@FreeBSD.org, lebel.jerome@gmail.com Cc: Subject: Re: amd64/166639: [boot] Syscons issue Intel D2700 Date: Wed, 18 Jul 2012 00:29:01 +0200 I was able to make my screen working with : vidcontrol MODE_27 vidcontrol -f iso I'm not sure how to put that into rc.conf From owner-freebsd-amd64@FreeBSD.ORG Tue Jul 17 22:40:16 2012 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0BA011065674 for ; Tue, 17 Jul 2012 22:40:16 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E0AB38FC24 for ; Tue, 17 Jul 2012 22:40:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6HMeFH5003367 for ; Tue, 17 Jul 2012 22:40:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6HMeFAB003366; Tue, 17 Jul 2012 22:40:15 GMT (envelope-from gnats) Date: Tue, 17 Jul 2012 22:40:15 GMT Message-Id: <201207172240.q6HMeFAB003366@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: =?iso-8859-1?Q?J=E9r=F4me_Lebel?= X-Mailman-Approved-At: Tue, 17 Jul 2012 23:22:01 +0000 Cc: Subject: Re: amd64/166639: [boot] Syscons issue Intel D2700 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?iso-8859-1?Q?J=E9r=F4me_Lebel?= List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 22:40:16 -0000 The following reply was made to PR amd64/166639; it has been noted by GNATS. From: =?iso-8859-1?Q?J=E9r=F4me_Lebel?= To: bug-followup@FreeBSD.org, lebel.jerome@gmail.com Cc: Subject: Re: amd64/166639: [boot] Syscons issue Intel D2700 Date: Wed, 18 Jul 2012 00:34:10 +0200 Just in case that's useful for this bug : freebsd-test16# vidcontrol -i mode mode# flags type size font window linear = buffer = --------------------------------------------------------------------------= ---- 0 (0x000) 0x00000001 T 40x25 8x8 0xb8000 32k 32k = 0x00000000 32k 1 (0x001) 0x00000001 T 40x25 8x8 0xb8000 32k 32k = 0x00000000 32k 2 (0x002) 0x00000001 T 80x25 8x8 0xb8000 32k 32k = 0x00000000 32k 3 (0x003) 0x00000001 T 80x25 8x8 0xb8000 32k 32k = 0x00000000 32k 4 (0x004) 0x00000003 G 320x200x2 C 8x8 0xb8000 32k 32k = 0x00000000 32k 5 (0x005) 0x00000003 G 320x200x2 C 8x8 0xb8000 32k 32k = 0x00000000 32k 6 (0x006) 0x00000003 G 640x200x1 C 8x8 0xb8000 32k 32k = 0x00000000 32k 13 (0x00d) 0x00000003 G 320x200x4 4 8x8 0xa0000 64k 64k = 0x00000000 256k 14 (0x00e) 0x00000003 G 640x200x4 4 8x8 0xa0000 64k 64k = 0x00000000 256k 16 (0x010) 0x00000003 G 640x350x2 2 8x14 0xa0000 64k 64k = 0x00000000 128k 18 (0x012) 0x00000003 G 640x350x4 4 8x14 0xa0000 64k 64k = 0x00000000 256k 19 (0x013) 0x00000001 T 40x25 8x14 0xb8000 32k 32k = 0x00000000 32k 20 (0x014) 0x00000001 T 40x25 8x14 0xb8000 32k 32k = 0x00000000 32k 21 (0x015) 0x00000001 T 80x25 8x14 0xb8000 32k 32k = 0x00000000 32k 22 (0x016) 0x00000001 T 80x25 8x14 0xb8000 32k 32k = 0x00000000 32k 23 (0x017) 0x00000001 T 40x25 8x16 0xb8000 32k 32k = 0x00000000 32k 24 (0x018) 0x00000001 T 80x25 8x16 0xb8000 32k 32k = 0x00000000 32k 26 (0x01a) 0x00000003 G 640x480x4 4 8x16 0xa0000 64k 64k = 0x00000000 256k 27 (0x01b) 0x00000003 G 640x480x4 4 8x16 0xa0000 64k 64k = 0x00000000 256k 28 (0x01c) 0x00000003 G 320x200x8 P 8x8 0xa0000 64k 64k = 0x00000000 64k 30 (0x01e) 0x00000001 T 80x50 8x8 0xb8000 32k 32k = 0x00000000 32k 32 (0x020) 0x00000001 T 80x30 8x16 0xb8000 32k 32k = 0x00000000 32k 34 (0x022) 0x00000001 T 80x60 8x8 0xb8000 32k 32k = 0x00000000 32k 37 (0x025) 0x00000003 G 320x240x8 V 8x8 0xa0000 64k 64k = 0x00000000 256k 112 (0x070) 0x00000000 T 80x43 8x8 0xb8000 32k 32k = 0x00000000 32k 113 (0x071) 0x00000001 T 80x43 8x8 0xb8000 32k 32k = 0x00000000 32k freebsd-test16# vidcontrol -i adpater vidcontrol: getting active vty: Inappropriate ioctl for device freebsd-test16# cat adapter=20 fb0: vga0, type:VGA (5), flags:0x7007f initial mode:24, current mode:27, BIOS mode:3 frame buffer window:0xa0000, buffer size:0x40000 window size:0x10000, origin:0x0 display start address (0, 0), scan line width:80 reserved:0x0 From owner-freebsd-amd64@FreeBSD.ORG Wed Jul 18 00:32:33 2012 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6D671065675 for ; Wed, 18 Jul 2012 00:32:33 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id 47DBC8FC0A for ; Wed, 18 Jul 2012 00:32:33 +0000 (UTC) Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q6I0WNrK018861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2012 10:32:30 +1000 Date: Wed, 18 Jul 2012 10:32:23 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Mark Linimon In-Reply-To: <201207172150.q6HLoFvB096742@freefall.freebsd.org> Message-ID: <20120718103210.E834@besplex.bde.org> References: <201207172150.q6HLoFvB096742@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-amd64@freebsd.org Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 00:32:33 -0000 On Tue, 17 Jul 2012, Mark Linimon wrote: > The following reply was made to PR amd64/169927; it has been noted by GNATS. I'm replying to Mark's forwarding of this, but gnats isn't in the Cc list so it will not be noted by gnats, again. > On Wed, Jul 18, 2012 at 02:03:58AM +1000, Bruce Evans wrote: > > Apart from doing the bogus fnclex for T_XMMFLT and the delayed effect of > > i387 status bits, merging or not merging the statuses makes little > > difference, since if a status bit is set and is not masked according > > to its control word, then it will generate a trap soon if it didn't > > genearate the current one. > > The trap number is available for SA_SIGINFO type of handlers with > si_trapno member of siginfo_t. I think this is final argument to have > separate fputrap_{x87,sse} functions. OK. Also, you can tell instruction that faulted, provided there are no spurious faults. I think spurious faults can only occur for IRQ13 exception handling which was never supported for amd64 and is no longer supported for i386. My old test program that is broken by not clobbering the status was mainly for finding and fixing such spurious faults. I never owned an i387 or i486SX and had to break i486 exception handling to test IRQ13. > For amd64, SSE hardware is FPU, so I do not see much wrong with the name. No, FPU is a only part of SSE hardware (or separate from it, with separate interfaces from it to x87 and xmm registers, and these registers possibly layered under futher extensions. T_XMMFLT The names are sort of backwards: - T_XMMFLT: /* SIMD floating-point exception */ If the name is correct, then this can occur for non-FPU things (most xmm instructions are not for the FPU). But more likely the comment is correct, and this can only occur for FPU things from SIMD instructions. - fputrap_x87: This is not an x87 trap under fpu, but an x87-fpu trap under npx. - fputrap_sse: This is not an sse trap under fpu, but one of - an xmm-possibly-non-fpu trap under npx (if T_XMMFLT is correct) - a simd-fpu trap under npx (if the comment is correct) I checked a few xmm instructions in old amd64 manuals and could only find T_XMMFLT for FPU ones. It's spelled #XF or OSXMMEXCPT in the manuals -- CPU manufacturers also have problems naming things according to their layering when the layering is subject to extension. Other relevant exceptions are all common to x87/simd-fpu or cpu. For the maxpd instruction they are: - Invalid opcode, #UD: this mainly happens when simd is not supported or is turned off and an attempt was made to execute an simd instruction. It also happens when there is an #XF but simd is turned off (I don't see how #XF can happen while simd is turened off). - Device not available, #NM: we use a common handler - Stack, #AS - General protection, #GO - Page fault, #FP - SIMD Floating-Point Exception, #XF: I copied these descriptions verbatim. Another CPU manufacturer bug here is that this description is capitalized but none of the others is.) - IE and DE sub-exceptions (no others can occur for MAXPD). > I changed fputrap_sse() according to your suggestion. It's still too large for me :-). > diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c > index a7812b7..356b3ac 100644 > --- a/sys/amd64/amd64/fpu.c > +++ b/sys/amd64/amd64/fpu.c > @@ -514,11 +513,15 @@ static char fpetable[128] = { > }; > > /* > - * Preserve the FP status word, clear FP exceptions, then generate a SIGFPE. > + * Preserve the FP status word, clear FP exceptions for x87, then > + * generate a SIGFPE. This is out of date about preserving the status word. > + * > + * Clearing exceptions was necessary mainly to avoid IRQ13 bugs and is > + * engraved in our i386 ABI. We now depend on longjmp() restoring a > + * usable state. Restoring the state or examining it might fail if we > + * didn't clear exceptions. > * > - * Clearing exceptions is necessary mainly to avoid IRQ13 bugs. We now > - * depend on longjmp() restoring a usable state. Restoring the state > - * or examining it might fail if we didn't clear exceptions. This should be deleted in a separate commit. I think the comment is more out of date than before: before: - this is amd64, and never supported IRQ13 - this is amd64, and longjmp() always restored a usable state - we don't depend on longjmp() restoring a usable state now, on either amd64 or i386, except for BSD-43 and FreeBSD-4 signal handlers. amd64 never supported either of these, except in the i386 compat layer. Your changes are too large and complete :-). But they are not large and complete enough to make the fnclex clobbering depend on the signal handler. After: - this is amd64, so the i386 ABI is irrelevant except in the compat layer. However, since amd64 has always done the fnclex clobbering, it is really part of the x87 ABI. > + * For SSE exceptions, the exceptions are not cleared. > * > * The error code chosen will be one of the FPE_... macros. It will be > * sent as the second argument to old BSD-style signal handlers and as > @@ -531,8 +534,9 @@ static char fpetable[128] = { > * solution for signals other than SIGFPE. > */ > int > -fputrap() > +fputrap_x87(void) > ... Good cleanups in this function. > +int > +fputrap_sse(void) > +{ > + u_int mxcsr; > + > + critical_enter(); > + > + /* > + * Coomparing with the x87 #MF handler, we do not clear > + * exceptions from the mxcsr. > + */ Spelling error. This is already covered in too much detail in the big comment before the functions. Don't repeat it here. > + if (PCPU_GET(fpcurthread) != curthread) > + mxcsr = curthread->td_pcb->pcb_save->sv_env.en_mxcsr; > + else > + stmxcsr(&mxcsr); > + > + critical_exit(); > + Style bug (extra blank line). The others are necessary, but become unnecessary after removing the comment. > + return (fpetable[(mxcsr & (mxcsr >> 16)) & 0x3f]); > +} > + > /* > * Implement device not available (DNA) exception > * Cleaning this up gives code that is small enogh for me: int fputrap_sse(void) { u_int mxcsr; critical_enter(); if (PCPU_GET(fpcurthread) != curthread) mxcsr = curthread->td_pcb->pcb_save->sv_env.en_mxcsr; else stmxcsr(&mxcsr); critical_exit(); return (fpetable[(mxcsr & (mxcsr >> 16)) & 0x3f]); } I forgot to replace your patch by the newer one before replying. Just noticed another style/efficiency bug: this should use curpcb, not curthread->td_pcb. I don't like the curpcb global, but as long as it exists, it should be used. Every time I looked at removing this global, it seemed better to keep it. C code can easily use curthread->td_pcb instead of curpcb, and this is faster if curthread is cached. But CURPCB is easier to use in asm. Similarly in fputrap_x87(). Not similarly for i386. i386 still uses the GET_FPU_CW/SW() macros, and these take a thread arg (which is named badly as `thread' instead of the normal td) and can't use curpcb. The cleanup here goes with your removal of these macros. I now quote your newer patch for the fputrap_x87() cleanup: > @@ -531,8 +534,9 @@ static char fpetable[128] = { > * solution for signals other than SIGFPE. > */ > int > -fputrap() > +fputrap_x87(void) > { > + struct savefpu *pcb_save; No need for this before or after. Let the compiler cache it. Just use curpcb now. > u_short control, status; > > critical_enter(); > @@ -543,19 +547,40 @@ fputrap() > * wherever they are. > */ > if (PCPU_GET(fpcurthread) != curthread) { > - control = GET_FPU_CW(curthread); > - status = GET_FPU_SW(curthread); > + pcb_save = curthread->td_pcb->pcb_save; > + control = pcb_save->sv_env.en_cw; > + status = pcb_save->sv_env.en_sw; Change to: control = curpcb->pcb_save->sv_env.en_cw; status = curpcb->pcb_save->sv_env.en_sw; ... i386 used curpcb near here in FreeBSD-3, but was changed to use a macro in FreeBSD-4. However, the macro still used curpcb, since it was a special one that was only used in npx_intr() and thus didn't need to start with a general td arg. Bruce From owner-freebsd-amd64@FreeBSD.ORG Wed Jul 18 02:30:27 2012 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 987D6106564A for ; Wed, 18 Jul 2012 02:30:27 +0000 (UTC) (envelope-from roy@sparkstation.net) Received: from mail.sparkstation.net (mail.sparkstation.net [112.140.184.189]) by mx1.freebsd.org (Postfix) with ESMTP id 26EC68FC0A for ; Wed, 18 Jul 2012 02:30:26 +0000 (UTC) Received: (qmail 31559 invoked from network); 18 Jul 2012 10:23:44 +0800 Received: from 148.202-128-186.unknown.qala.com.sg (HELO RoyMB-Air.local) (202.128.186.148) by mail.sparkstation.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Jul 2012 10:23:44 +0800 Message-ID: <50061E30.70002@sparkstation.net> Date: Wed, 18 Jul 2012 10:23:44 +0800 From: Roy Chia User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-amd64@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Intel i5-2300 fault 8.3 amd kernel fatal trap when detecting CPU, SMP issue X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 02:30:27 -0000 Hi Guys, Did anyone run Freebsd amd64 on Intel i5-2300 successfully before? I keep getting Fatal trap 12: page fault while in kernel mode when trying to run? However im able to run the os with smp off. Any suggestion? Thanks! Roy From owner-freebsd-amd64@FreeBSD.ORG Wed Jul 18 03:41:41 2012 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F006C1065670 for ; Wed, 18 Jul 2012 03:41:41 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id A2B408FC14 for ; Wed, 18 Jul 2012 03:41:41 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q6I3fCt1005129; Tue, 17 Jul 2012 21:41:36 -0600 From: Erich Dollansky To: freebsd-amd64@freebsd.org Date: Wed, 18 Jul 2012 10:30:01 +0700 User-Agent: KMail/1.13.7 (FreeBSD/8.3-STABLE; KDE/4.7.4; amd64; ; ) References: <50061E30.70002@sparkstation.net> In-Reply-To: <50061E30.70002@sparkstation.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207181030.02047.erichfreebsdlist@ovitrap.com> Cc: Subject: Re: Intel i5-2300 fault 8.3 amd kernel fatal trap when detecting CPU, SMP issue X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 03:41:42 -0000 Hi, On Wednesday 18 July 2012 09:23:44 Roy Chia wrote: > Hi Guys, > > Did anyone run Freebsd amd64 on Intel i5-2300 successfully before? > I ran/run 8.3, 9.0 and now 10.0 on an i7. I have read that there are problems with virtualisation. It also fails on the i7 if certain flags are set in the BIOS. Can you check your BIOS for anything which seems to be related. Sorry, I do not know more. It just should help you to find the route to success. Erich > I keep getting Fatal trap 12: page fault while in kernel mode when > trying to run? However im able to run the os with smp off. > > Any suggestion? > > Thanks! > Roy > > > > > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" > > From owner-freebsd-amd64@FreeBSD.ORG Wed Jul 18 03:52:32 2012 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAA741065670 for ; Wed, 18 Jul 2012 03:52:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 2D1FB8FC0C for ; Wed, 18 Jul 2012 03:52:30 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6I3qXId066519; Wed, 18 Jul 2012 06:52:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q6I3qKeq027862; Wed, 18 Jul 2012 06:52:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6I3qK88027861; Wed, 18 Jul 2012 06:52:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 18 Jul 2012 06:52:20 +0300 From: Konstantin Belousov To: Bruce Evans Message-ID: <20120718035220.GO2676@deviant.kiev.zoral.com.ua> References: <201207172150.q6HLoFvB096742@freefall.freebsd.org> <20120718103210.E834@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Thv7PGoFpDPJ7Oar" Content-Disposition: inline In-Reply-To: <20120718103210.E834@besplex.bde.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Mark Linimon , freebsd-amd64@freebsd.org Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 03:52:33 -0000 --Thv7PGoFpDPJ7Oar Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 18, 2012 at 10:32:23AM +1000, Bruce Evans wrote: > On Tue, 17 Jul 2012, Mark Linimon wrote: >=20 > >The following reply was made to PR amd64/169927; it has been noted by=20 > >GNATS. >=20 > I'm replying to Mark's forwarding of this, but gnats isn't in the Cc list > so it will not be noted by gnats, again. >=20 > >On Wed, Jul 18, 2012 at 02:03:58AM +1000, Bruce Evans wrote: > >> Apart from doing the bogus fnclex for T_XMMFLT and the delayed effect = of > >> i387 status bits, merging or not merging the statuses makes little > >> difference, since if a status bit is set and is not masked according > >> to its control word, then it will generate a trap soon if it didn't > >> genearate the current one. > > > >The trap number is available for SA_SIGINFO type of handlers with > >si_trapno member of siginfo_t. I think this is final argument to have > >separate fputrap_{x87,sse} functions. >=20 > OK. Also, you can tell instruction that faulted, provided there are > no spurious faults. I think spurious faults can only occur for IRQ13 > exception handling which was never supported for amd64 and is no longer > supported for i386. My old test program that is broken by not clobbering > the status was mainly for finding and fixing such spurious faults. > I never owned an i387 or i486SX and had to break i486 exception handling > to test IRQ13. 486SX+487 never used irq13 as well, since 487 was the 'full' DX package, which turned off SX socket. =2E.. > >+ > >+ /* > >+ * Coomparing with the x87 #MF handler, we do not clear > >+ * exceptions from the mxcsr. > >+ */ >=20 > Spelling error. >=20 > This is already covered in too much detail in the big comment before > the functions. Don't repeat it here. Removed. >=20 >=20 > >+ if (PCPU_GET(fpcurthread) !=3D curthread) > >+ mxcsr =3D curthread->td_pcb->pcb_save->sv_env.en_mxcsr; > >+ else > >+ stmxcsr(&mxcsr); > >+ > >+ critical_exit(); > >+ >=20 > Style bug (extra blank line). The others are necessary, but become > unnecessary after removing the comment. >=20 > >+ return (fpetable[(mxcsr & (mxcsr >> 16)) & 0x3f]); > >+} > >+ > > /* > > * Implement device not available (DNA) exception > > * >=20 > Cleaning this up gives code that is small enogh for me: >=20 > int > fputrap_sse(void) > { > u_int mxcsr; >=20 > critical_enter(); > if (PCPU_GET(fpcurthread) !=3D curthread) > mxcsr =3D curthread->td_pcb->pcb_save->sv_env.en_mxcsr; > else > stmxcsr(&mxcsr); > critical_exit(); > return (fpetable[(mxcsr & (mxcsr >> 16)) & 0x3f]); > } Ok. >=20 > I forgot to replace your patch by the newer one before replying. >=20 > Just noticed another style/efficiency bug: this should use curpcb, > not curthread->td_pcb. I don't like the curpcb global, but as > long as it exists, it should be used. Every time I looked at > removing this global, it seemed better to keep it. C code can > easily use curthread->td_pcb instead of curpcb, and this is faster > if curthread is cached. But CURPCB is easier to use in asm. I changed to use curpcb (its use is indeed mainly for asm context switch code). I do want to use pcb_save though, see below. >=20 > Similarly in fputrap_x87(). >=20 > Not similarly for i386. i386 still uses the GET_FPU_CW/SW() macros, > and these take a thread arg (which is named badly as `thread' instead > of the normal td) and can't use curpcb. The cleanup here goes with > your removal of these macros. >=20 > I now quote your newer patch for the fputrap_x87() cleanup: >=20 > > @@ -531,8 +534,9 @@ static char fpetable[128] =3D { > > * solution for signals other than SIGFPE. > > */ > > int > > -fputrap() > > +fputrap_x87(void) > > { > > + struct savefpu *pcb_save; >=20 > No need for this before or after. Let the compiler cache it. Just use > curpcb now. The curpcb access shall be spelled as PCPU_GET(curpcb). Please note that compiler is not allowed to cache the accesses, since there is __asm __volatile expression to indirect through %gs-prefixed read. >=20 > > u_short control, status; > > > > critical_enter(); > > @@ -543,19 +547,40 @@ fputrap() > > * wherever they are. > > */ > > if (PCPU_GET(fpcurthread) !=3D curthread) { > > - control =3D GET_FPU_CW(curthread); > > - status =3D GET_FPU_SW(curthread); > > + pcb_save =3D curthread->td_pcb->pcb_save; > > + control =3D pcb_save->sv_env.en_cw; > > + status =3D pcb_save->sv_env.en_sw; >=20 > Change to: >=20 > control =3D curpcb->pcb_save->sv_env.en_cw; > status =3D curpcb->pcb_save->sv_env.en_sw; >=20 > ... >=20 > i386 used curpcb near here in FreeBSD-3, but was changed to use a macro > in FreeBSD-4. However, the macro still used curpcb, since it was a > special one that was only used in npx_intr() and thus didn't need to > start with a general td arg. diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c index a7812b7..f88aba7 100644 --- a/sys/amd64/amd64/fpu.c +++ b/sys/amd64/amd64/fpu.c @@ -73,6 +73,7 @@ __FBSDID("$FreeBSD$"); #define fxrstor(addr) __asm __volatile("fxrstor %0" : : "m" (*(addr))) #define fxsave(addr) __asm __volatile("fxsave %0" : "=3Dm" (*(addr))) #define ldmxcsr(csr) __asm __volatile("ldmxcsr %0" : : "m" (csr)) +#define stmxcsr(addr) __asm __volatile("stmxcsr %0" : : "m" (*(addr))) =20 static __inline void xrstor(char *addr, uint64_t mask) @@ -105,6 +106,7 @@ void fnstsw(caddr_t addr); void fxsave(caddr_t addr); void fxrstor(caddr_t addr); void ldmxcsr(u_int csr); +void stmxcsr(u_int csr); void xrstor(char *addr, uint64_t mask); void xsave(char *addr, uint64_t mask); =20 @@ -113,9 +115,6 @@ void xsave(char *addr, uint64_t mask); #define start_emulating() load_cr0(rcr0() | CR0_TS) #define stop_emulating() clts() =20 -#define GET_FPU_CW(thread) ((thread)->td_pcb->pcb_save->sv_env.en_cw) -#define GET_FPU_SW(thread) ((thread)->td_pcb->pcb_save->sv_env.en_sw) - CTASSERT(sizeof(struct savefpu) =3D=3D 512); CTASSERT(sizeof(struct xstate_hdr) =3D=3D 64); CTASSERT(sizeof(struct savefpu_ymm) =3D=3D 832); @@ -514,11 +513,15 @@ static char fpetable[128] =3D { }; =20 /* - * Preserve the FP status word, clear FP exceptions, then generate a SIGFP= E. + * Preserve the FP status word, clear FP exceptions for x87, then + * generate a SIGFPE. + * + * Clearing exceptions was necessary mainly to avoid IRQ13 bugs and is + * engraved in our i386 ABI. We now depend on longjmp() restoring a + * usable state. Restoring the state or examining it might fail if we + * didn't clear exceptions. * - * Clearing exceptions is necessary mainly to avoid IRQ13 bugs. We now - * depend on longjmp() restoring a usable state. Restoring the state - * or examining it might fail if we didn't clear exceptions. + * For SSE exceptions, the exceptions are not cleared. * * The error code chosen will be one of the FPE_... macros. It will be * sent as the second argument to old BSD-style signal handlers and as @@ -531,8 +534,9 @@ static char fpetable[128] =3D { * solution for signals other than SIGFPE. */ int -fputrap() +fputrap_x87(void) { + struct savefpu *pcb_save; u_short control, status; =20 critical_enter(); @@ -543,19 +547,33 @@ fputrap() * wherever they are. */ if (PCPU_GET(fpcurthread) !=3D curthread) { - control =3D GET_FPU_CW(curthread); - status =3D GET_FPU_SW(curthread); + pcb_save =3D PCPU_GET(curpcb)->pcb_save; + control =3D pcb_save->sv_env.en_cw; + status =3D pcb_save->sv_env.en_sw; } else { fnstcw(&control); fnstsw(&status); + fnclex(); } =20 - if (PCPU_GET(fpcurthread) =3D=3D curthread) - fnclex(); critical_exit(); return (fpetable[status & ((~control & 0x3f) | 0x40)]); } =20 +int +fputrap_sse(void) +{ + u_int mxcsr; + + critical_enter(); + if (PCPU_GET(fpcurthread) !=3D curthread) + mxcsr =3D PCPU_GET(curpcb)->pcb_save->sv_env.en_mxcsr; + else + stmxcsr(&mxcsr); + critical_exit(); + return (fpetable[(mxcsr & (~mxcsr >> 7)) & 0x3f]); +} + /* * Implement device not available (DNA) exception * diff --git a/sys/amd64/amd64/trap.c b/sys/amd64/amd64/trap.c index 75e15e0..57d1cc2 100644 --- a/sys/amd64/amd64/trap.c +++ b/sys/amd64/amd64/trap.c @@ -328,7 +328,7 @@ trap(struct trapframe *frame) break; =20 case T_ARITHTRAP: /* arithmetic trap */ - ucode =3D fputrap(); + ucode =3D fputrap_x87(); if (ucode =3D=3D -1) goto userout; i =3D SIGFPE; @@ -442,7 +442,9 @@ trap(struct trapframe *frame) break; =20 case T_XMMFLT: /* SIMD floating-point exception */ - ucode =3D 0; /* XXX */ + ucode =3D fputrap_sse(); + if (ucode =3D=3D -1) + goto userout; i =3D SIGFPE; break; } diff --git a/sys/amd64/include/fpu.h b/sys/amd64/include/fpu.h index 98a016b..7d0f0ea 100644 --- a/sys/amd64/include/fpu.h +++ b/sys/amd64/include/fpu.h @@ -62,7 +62,8 @@ int fpusetregs(struct thread *td, struct savefpu *addr, char *xfpustate, size_t xfpustate_size); int fpusetxstate(struct thread *td, char *xfpustate, size_t xfpustate_size); -int fputrap(void); +int fputrap_sse(void); +int fputrap_x87(void); void fpuuserinited(struct thread *td); struct fpu_kern_ctx *fpu_kern_alloc_ctx(u_int flags); void fpu_kern_free_ctx(struct fpu_kern_ctx *ctx); --Thv7PGoFpDPJ7Oar Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAGMvQACgkQC3+MBN1Mb4jANACfabMhOJxDnqO0u9dDdYGB13cS FwAAoLLoJI8BmEAqeFdED3836xOMSXef =NSzJ -----END PGP SIGNATURE----- --Thv7PGoFpDPJ7Oar-- From owner-freebsd-amd64@FreeBSD.ORG Wed Jul 18 04:36:20 2012 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03CB91065674 for ; Wed, 18 Jul 2012 04:36:20 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id 8D22E8FC0A for ; Wed, 18 Jul 2012 04:36:19 +0000 (UTC) Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q6I4aGxT001857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2012 14:36:17 +1000 Date: Wed, 18 Jul 2012 14:36:16 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov In-Reply-To: <20120718035220.GO2676@deviant.kiev.zoral.com.ua> Message-ID: <20120718140523.X1862@besplex.bde.org> References: <201207172150.q6HLoFvB096742@freefall.freebsd.org> <20120718103210.E834@besplex.bde.org> <20120718035220.GO2676@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Mark Linimon , freebsd-amd64@freebsd.org Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 04:36:20 -0000 On Wed, 18 Jul 2012, Konstantin Belousov wrote: > On Wed, Jul 18, 2012 at 10:32:23AM +1000, Bruce Evans wrote: >> OK. Also, you can tell instruction that faulted, provided there are >> no spurious faults. I think spurious faults can only occur for IRQ13 >> exception handling which was never supported for amd64 and is no longer >> supported for i386. My old test program that is broken by not clobbering >> the status was mainly for finding and fixing such spurious faults. >> I never owned an i387 or i486SX and had to break i486 exception handling >> to test IRQ13. > 486SX+487 never used irq13 as well, since 487 was the 'full' DX package, > which turned off SX socket. The 487 is still a separate package. I thought it had to use IRQ13 to communicate with the 486SX since the NE# (?) and ERR# (?) pins only work for a single package. Do they actually work for the separate package? >> Just noticed another style/efficiency bug: this should use curpcb, >> not curthread->td_pcb. I don't like the curpcb global, but as >> long as it exists, it should be used. Every time I looked at >> removing this global, it seemed better to keep it. C code can >> easily use curthread->td_pcb instead of curpcb, and this is faster >> if curthread is cached. But CURPCB is easier to use in asm. > I changed to use curpcb (its use is indeed mainly for asm context switch > code). I do want to use pcb_save though, see below. >> ... >> I now quote your newer patch for the fputrap_x87() cleanup: >> >>> @@ -531,8 +534,9 @@ static char fpetable[128] = { >>> * solution for signals other than SIGFPE. >>> */ >>> int >>> -fputrap() >>> +fputrap_x87(void) >>> { >>> + struct savefpu *pcb_save; >> >> No need for this before or after. Let the compiler cache it. Just use >> curpcb now. > The curpcb access shall be spelled as PCPU_GET(curpcb). Please note that > compiler is not allowed to cache the accesses, since there is __asm > __volatile expression to indirect through %gs-prefixed read. Fix curpcb then. curthread was de-pessimized to use __pure2 and to not use __volatile. I could never this to work to cache curthread when I ried it, but it apparently works in -current. curpcb is no more fragile than curthread without the __volatile. Especially in fputrap*() where they are accessed under critical_enter(). They are switched at the same time. Any locking in pcpu access functions for them would be useless, since it goes away when the function returns. Apparently they are sufficiently locked by the logic of the code (unlike fpucurthread, which requires the critical_enter()). curthread is the only pcpu variable important enough to have a special access function in amd64 pcpu.h. curpcb is not very important, but spelling it curpcb = __curpcb() instead of PCPU_GET(curpcb) is simpler for clients as well as faster. > diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c > ... OK except for the curpcb caching and the fnclex removal, which should be done separately. Speaking of ABI changes, the default i386 FP rounding precision (and collateral gcc bugs) should have been changed from 53 to 64 bits a few years ago, after libc (printf) and libm started working around the old gcc precision bugs well enough. That will be really painful for compat code. Bruce From owner-freebsd-amd64@FreeBSD.ORG Wed Jul 18 05:10:03 2012 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E696106564A for ; Wed, 18 Jul 2012 05:10:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id A1D668FC12 for ; Wed, 18 Jul 2012 05:10:02 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6I5ABmO073281; Wed, 18 Jul 2012 08:10:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q6I59wj2028201; Wed, 18 Jul 2012 08:09:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6I59wLo028200; Wed, 18 Jul 2012 08:09:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 18 Jul 2012 08:09:58 +0300 From: Konstantin Belousov To: Bruce Evans Message-ID: <20120718050958.GQ2676@deviant.kiev.zoral.com.ua> References: <201207172150.q6HLoFvB096742@freefall.freebsd.org> <20120718103210.E834@besplex.bde.org> <20120718035220.GO2676@deviant.kiev.zoral.com.ua> <20120718140523.X1862@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="s3R87C3fwYeCSZ0b" Content-Disposition: inline In-Reply-To: <20120718140523.X1862@besplex.bde.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Mark Linimon , freebsd-amd64@freebsd.org Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 05:10:03 -0000 --s3R87C3fwYeCSZ0b Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 18, 2012 at 02:36:16PM +1000, Bruce Evans wrote: > On Wed, 18 Jul 2012, Konstantin Belousov wrote: >=20 > >On Wed, Jul 18, 2012 at 10:32:23AM +1000, Bruce Evans wrote: > >>OK. Also, you can tell instruction that faulted, provided there are > >>no spurious faults. I think spurious faults can only occur for IRQ13 > >>exception handling which was never supported for amd64 and is no longer > >>supported for i386. My old test program that is broken by not clobberi= ng > >>the status was mainly for finding and fixing such spurious faults. > >>I never owned an i387 or i486SX and had to break i486 exception handling > >>to test IRQ13. > >486SX+487 never used irq13 as well, since 487 was the 'full' DX package, > >which turned off SX socket. >=20 > The 487 is still a separate package. I thought it had to use IRQ13 to > communicate with the 486SX since the NE# (?) and ERR# (?) pins only > work for a single package. Do they actually work for the separate > package? 487 packaged the whole CPU, it is not add-on FPU like 387. 486SX was turned off (electrically, AFAIR) when 487 was installed. >=20 > >>Just noticed another style/efficiency bug: this should use curpcb, > >>not curthread->td_pcb. I don't like the curpcb global, but as > >>long as it exists, it should be used. Every time I looked at > >>removing this global, it seemed better to keep it. C code can > >>easily use curthread->td_pcb instead of curpcb, and this is faster > >>if curthread is cached. But CURPCB is easier to use in asm. > >I changed to use curpcb (its use is indeed mainly for asm context switch > >code). I do want to use pcb_save though, see below. > >>... > >>I now quote your newer patch for the fputrap_x87() cleanup: > >> > >>>@@ -531,8 +534,9 @@ static char fpetable[128] =3D { > >>> * solution for signals other than SIGFPE. > >>> */ > >>> int > >>>-fputrap() > >>>+fputrap_x87(void) > >>> { > >>>+ struct savefpu *pcb_save; > >> > >>No need for this before or after. Let the compiler cache it. Just use > >>curpcb now. > >The curpcb access shall be spelled as PCPU_GET(curpcb). Please note that > >compiler is not allowed to cache the accesses, since there is __asm > >__volatile expression to indirect through %gs-prefixed read. >=20 > Fix curpcb then. curthread was de-pessimized to use __pure2 and to not > use __volatile. I could never this to work to cache curthread when I=20 > ried it, but it apparently works in -current. >=20 > curpcb is no more fragile than curthread without the __volatile. > Especially in fputrap*() where they are accessed under critical_enter(). > They are switched at the same time. Any locking in pcpu access functions > for them would be useless, since it goes away when the function returns. > Apparently they are sufficiently locked by the logic of the code > (unlike fpucurthread, which requires the critical_enter()). >=20 > curthread is the only pcpu variable important enough to have a special > access function in amd64 pcpu.h. curpcb is not very important, but > spelling it curpcb =3D __curpcb() instead of PCPU_GET(curpcb) is > simpler for clients as well as faster. >=20 > >diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c > >... >=20 > OK except for the curpcb caching and the fnclex removal, which should > be done separately. curpcb() could be implemented like this for amd64 only: diff --git a/sys/amd64/include/pcb.h b/sys/amd64/include/pcb.h index 22cbbe2..3417c52 100644 --- a/sys/amd64/include/pcb.h +++ b/sys/amd64/include/pcb.h @@ -144,6 +144,17 @@ void makectx(struct trapframe *, struct pcb *); int savectx(struct pcb *) __returns_twice; void resumectx(struct pcb *); =20 +static __inline __pure2 struct pcb * +__curpcb(void) +{ + struct pcb *pcb; + + __asm("movq %%gs:%1,%0" : "=3Dr" (pcb) + : "i" (offsetof(struct pcpu, pc_curpcb))); + return (pcb); +} +#define curpcb (__curpcb()) + #endif =20 #endif /* _AMD64_PCB_H_ */ diff --git a/sys/sys/user.h b/sys/sys/user.h index accb7c3..ab1c7a7 100644 --- a/sys/sys/user.h +++ b/sys/sys/user.h @@ -35,6 +35,7 @@ #ifndef _SYS_USER_H_ #define _SYS_USER_H_ =20 +#include #include #ifndef _KERNEL /* stuff that *used* to be included by user.h, or is now needed */ Please note the location in pcb.h an not in machine/pcpu.h, where it cannot work for technical reasons (struct pcpu is not defined yet). This should be committed separetely, together with the pass over amd64/ to convert PCPU_GET(curpcb) into curpcb(). Do you agree with committing the PR fix as is and adding the curpcb() later= ? And removing fnclex() later (it seems I convinced enough for its removal). --s3R87C3fwYeCSZ0b Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAGRSYACgkQC3+MBN1Mb4hZqgCfT2huy84BV5OvSd3MX/KFG6kr +twAoOxaFP3EY9GfZSG2Nso+Rka0Qi2V =bPlt -----END PGP SIGNATURE----- --s3R87C3fwYeCSZ0b-- From owner-freebsd-amd64@FreeBSD.ORG Wed Jul 18 06:59:48 2012 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F94F106564A for ; Wed, 18 Jul 2012 06:59:48 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id E26CB8FC14 for ; Wed, 18 Jul 2012 06:59:47 +0000 (UTC) Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q6I6xc1f004698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2012 16:59:39 +1000 Date: Wed, 18 Jul 2012 16:59:38 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov In-Reply-To: <20120718050958.GQ2676@deviant.kiev.zoral.com.ua> Message-ID: <20120718153554.O2195@besplex.bde.org> References: <201207172150.q6HLoFvB096742@freefall.freebsd.org> <20120718103210.E834@besplex.bde.org> <20120718035220.GO2676@deviant.kiev.zoral.com.ua> <20120718140523.X1862@besplex.bde.org> <20120718050958.GQ2676@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Mark Linimon , freebsd-amd64@freebsd.org Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 06:59:49 -0000 On Wed, 18 Jul 2012, Konstantin Belousov wrote: > On Wed, Jul 18, 2012 at 02:36:16PM +1000, Bruce Evans wrote: >> On Wed, 18 Jul 2012, Konstantin Belousov wrote: > ... >>> The curpcb access shall be spelled as PCPU_GET(curpcb). Please note that >>> compiler is not allowed to cache the accesses, since there is __asm >>> __volatile expression to indirect through %gs-prefixed read. >> >> Fix curpcb then. curthread was de-pessimized to use __pure2 and to not >> use __volatile. I could never this to work to cache curthread when I >> ried it, but it apparently works in -current. > .. > curpcb() could be implemented like this for amd64 only: Similarly for i386? > diff --git a/sys/amd64/include/pcb.h b/sys/amd64/include/pcb.h > index 22cbbe2..3417c52 100644 > --- a/sys/amd64/include/pcb.h > +++ b/sys/amd64/include/pcb.h > @@ -144,6 +144,17 @@ void makectx(struct trapframe *, struct pcb *); > int savectx(struct pcb *) __returns_twice; > void resumectx(struct pcb *); > > +static __inline __pure2 struct pcb * > +__curpcb(void) > +{ > + struct pcb *pcb; > + > + __asm("movq %%gs:%1,%0" : "=r" (pcb) > + : "i" (offsetof(struct pcpu, pc_curpcb))); pc_curpcb is only a pointer, so there is no need for pcb.h to be used (any more than proc.h is neaded for __curthread()). I think this can go in machine/pcpu.h next to __curthread(). Or machine/cpuinfo can provide the an alternative to PCPU_GET() without __volatile and sys/pcpu.h can do this. __curthread() avoids a dependency on sys/pcpu.h by hard-coding the offset of pc_curthread as 0. This hack seems to be unnecessary, Including machine/pcpu.h without going through sys/pcpu.h should be an error. This error is only in a few low tier files: - i386/xen/pcpu.h: this bogusly includes machine/pcpu.h after already including sys/cpu.h - mips/cavium/octeon_machdep.c - mips/cavium/uart_dev_oct16550.c - powerpc/include/platform.h - xen/evtchn.h. xen code is horrible. In i386/include/xen/xen_os.h, as part of this file's namespace pollution, it claims to include sys/time.h for pcpu.h. But actually sys/time.h only provides moderate namespace pollution that doesn't include pcpu.h. It is another style bug to include sys/time.h directly. sys/time.h is standard namespace pollution in sys/param.h in the _KERNEL case. So amd64 can apparently safely put this function in machine/pcpu.h. i386 might have to untangle the xen pollution. Other arches aren't directly affected, since they don't have npx. I wondered if they even had curpcb (if not then pc_curpcb should be in the MD fields). Grep shows that they have considerable variation and messes. At lease ia64 doesn't use the "MI" pc_curpcb. There is similar variation and messes for pcpup. > + return (pcb); > +} > +#define curpcb (__curpcb()) > + > #endif > > #endif /* _AMD64_PCB_H_ */ > diff --git a/sys/sys/user.h b/sys/sys/user.h > index accb7c3..ab1c7a7 100644 > --- a/sys/sys/user.h > +++ b/sys/sys/user.h > @@ -35,6 +35,7 @@ > #ifndef _SYS_USER_H_ > #define _SYS_USER_H_ > > +#include Too much namespace pollution for me. > #include Putting the definiton in machine/pcpu.h should avoid changing the prerequistes for machine/pcb.h. > #ifndef _KERNEL > /* stuff that *used* to be included by user.h, or is now needed */ > > Please note the location in pcb.h an not in machine/pcpu.h, where it > cannot work for technical reasons (struct pcpu is not defined yet). Not applicable -- see above. > This should be committed separetely, together with the pass over amd64/ > to convert PCPU_GET(curpcb) into curpcb(). > > Do you agree with committing the PR fix as is and adding the curpcb() later ? > And removing fnclex() later (it seems I convinced enough for its removal). OK. Bruce From owner-freebsd-amd64@FreeBSD.ORG Wed Jul 18 08:10:07 2012 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A64DD106566C for ; Wed, 18 Jul 2012 08:10:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id EC3698FC16 for ; Wed, 18 Jul 2012 08:10:06 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6I8AFaP089617; Wed, 18 Jul 2012 11:10:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q6I8A388029629; Wed, 18 Jul 2012 11:10:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6I8A3gl029628; Wed, 18 Jul 2012 11:10:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 18 Jul 2012 11:10:03 +0300 From: Konstantin Belousov To: Bruce Evans Message-ID: <20120718081003.GT2676@deviant.kiev.zoral.com.ua> References: <201207172150.q6HLoFvB096742@freefall.freebsd.org> <20120718103210.E834@besplex.bde.org> <20120718035220.GO2676@deviant.kiev.zoral.com.ua> <20120718140523.X1862@besplex.bde.org> <20120718050958.GQ2676@deviant.kiev.zoral.com.ua> <20120718153554.O2195@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r3KnbM2MoJFBL7Dl" Content-Disposition: inline In-Reply-To: <20120718153554.O2195@besplex.bde.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Mark Linimon , freebsd-amd64@freebsd.org Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 08:10:07 -0000 --r3KnbM2MoJFBL7Dl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 18, 2012 at 04:59:38PM +1000, Bruce Evans wrote: > On Wed, 18 Jul 2012, Konstantin Belousov wrote: > Putting the definiton in machine/pcpu.h should avoid changing the > prerequistes for machine/pcb.h. >=20 > >#ifndef _KERNEL > >/* stuff that *used* to be included by user.h, or is now needed */ > > > >Please note the location in pcb.h an not in machine/pcpu.h, where it > >cannot work for technical reasons (struct pcpu is not defined yet). >=20 > Not applicable -- see above. No, this cannot work. machine/pcpu.h defines PCPU_MD_FIELDS which is used to provide md part of the struct pcpu. --r3KnbM2MoJFBL7Dl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAGb1oACgkQC3+MBN1Mb4jEFQCaAgpuAFFs7r3vztxohafveppt uIsAoInFYepYsGdWYspxlKRlZcfSVsMO =KSHW -----END PGP SIGNATURE----- --r3KnbM2MoJFBL7Dl-- From owner-freebsd-amd64@FreeBSD.ORG Wed Jul 18 14:57:15 2012 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B72FB1065673; Wed, 18 Jul 2012 14:57:14 +0000 (UTC) (envelope-from kib@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8AC868FC0A; Wed, 18 Jul 2012 14:57:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6IEvETU054178; Wed, 18 Jul 2012 14:57:14 GMT (envelope-from kib@freefall.freebsd.org) Received: (from kib@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6IEvERO054174; Wed, 18 Jul 2012 14:57:14 GMT (envelope-from kib) Date: Wed, 18 Jul 2012 14:57:14 GMT Message-Id: <201207181457.q6IEvERO054174@freefall.freebsd.org> To: kib@FreeBSD.org, freebsd-amd64@FreeBSD.org, take@FreeBSD.org From: kib@FreeBSD.org X-Mailman-Approved-At: Wed, 18 Jul 2012 15:21:17 +0000 Cc: Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 14:57:15 -0000 Synopsis: siginfo, si_code for fpe errors when error occurs using the SSE math processor Responsible-Changed-From-To: freebsd-amd64->take Responsible-Changed-By: kib Responsible-Changed-When: Wed Jul 18 14:57:00 UTC 2012 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=169927 From owner-freebsd-amd64@FreeBSD.ORG Wed Jul 18 16:12:00 2012 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43C99106566B for ; Wed, 18 Jul 2012 16:12:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 86A0E8FC0C for ; Wed, 18 Jul 2012 16:11:59 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6IGC11W040867; Wed, 18 Jul 2012 19:12:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q6IGBmQK032323; Wed, 18 Jul 2012 19:11:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6IGBmn8032322; Wed, 18 Jul 2012 19:11:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 18 Jul 2012 19:11:48 +0300 From: Konstantin Belousov To: Bruce Evans Message-ID: <20120718161148.GV2676@deviant.kiev.zoral.com.ua> References: <201207172150.q6HLoFvB096742@freefall.freebsd.org> <20120718103210.E834@besplex.bde.org> <20120718035220.GO2676@deviant.kiev.zoral.com.ua> <20120718140523.X1862@besplex.bde.org> <20120718050958.GQ2676@deviant.kiev.zoral.com.ua> <20120718153554.O2195@besplex.bde.org> <20120718081003.GT2676@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HqPpMaT+a6TeY/Q4" Content-Disposition: inline In-Reply-To: <20120718081003.GT2676@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-amd64@freebsd.org Subject: curpcb X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 16:12:00 -0000 --HqPpMaT+a6TeY/Q4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 18, 2012 at 11:10:03AM +0300, Konstantin Belousov wrote: > On Wed, Jul 18, 2012 at 04:59:38PM +1000, Bruce Evans wrote: > > On Wed, 18 Jul 2012, Konstantin Belousov wrote: > > Putting the definiton in machine/pcpu.h should avoid changing the > > prerequistes for machine/pcb.h. > >=20 > > >#ifndef _KERNEL > > >/* stuff that *used* to be included by user.h, or is now needed */ > > > > > >Please note the location in pcb.h an not in machine/pcpu.h, where it > > >cannot work for technical reasons (struct pcpu is not defined yet). > >=20 > > Not applicable -- see above. > No, this cannot work. machine/pcpu.h defines PCPU_MD_FIELDS which is used > to provide md part of the struct pcpu. Below is the tested patch which converts all users of PCPU_GET(curpcb) for amd64. diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c index f88aba7..fe4bcf1 100644 --- a/sys/amd64/amd64/fpu.c +++ b/sys/amd64/amd64/fpu.c @@ -327,7 +327,7 @@ fpuexit(struct thread *td) critical_enter(); if (curthread =3D=3D PCPU_GET(fpcurthread)) { stop_emulating(); - fpusave(PCPU_GET(curpcb)->pcb_save); + fpusave(curpcb->pcb_save); start_emulating(); PCPU_SET(fpcurthread, 0); } @@ -547,7 +547,7 @@ fputrap_x87(void) * wherever they are. */ if (PCPU_GET(fpcurthread) !=3D curthread) { - pcb_save =3D PCPU_GET(curpcb)->pcb_save; + pcb_save =3D curpcb->pcb_save; control =3D pcb_save->sv_env.en_cw; status =3D pcb_save->sv_env.en_sw; } else { @@ -567,7 +567,7 @@ fputrap_sse(void) =20 critical_enter(); if (PCPU_GET(fpcurthread) !=3D curthread) - mxcsr =3D PCPU_GET(curpcb)->pcb_save->sv_env.en_mxcsr; + mxcsr =3D curpcb->pcb_save->sv_env.en_mxcsr; else stmxcsr(&mxcsr); critical_exit(); @@ -609,7 +609,7 @@ fpudna(void) * Record new context early in case frstor causes a trap. */ PCPU_SET(fpcurthread, curthread); - pcb =3D PCPU_GET(curpcb); + pcb =3D curpcb; =20 fpu_clean_state(); =20 @@ -970,7 +970,7 @@ fpu_kern_thread(u_int flags) { struct pcb *pcb; =20 - pcb =3D PCPU_GET(curpcb); + pcb =3D curpcb; KASSERT((curthread->td_pflags & TDP_KTHREAD) !=3D 0, ("Only kthread may use fpu_kern_thread")); KASSERT(pcb->pcb_save =3D=3D get_pcb_user_save_pcb(pcb), @@ -987,5 +987,5 @@ is_fpu_kern_thread(u_int flags) =20 if ((curthread->td_pflags & TDP_KTHREAD) =3D=3D 0) return (0); - return ((PCPU_GET(curpcb)->pcb_flags & PCB_KERNFPU) !=3D 0); + return ((curpcb->pcb_flags & PCB_KERNFPU) !=3D 0); } diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c index 8044fe5..cd3ebc5 100644 --- a/sys/amd64/amd64/machdep.c +++ b/sys/amd64/amd64/machdep.c @@ -996,7 +996,7 @@ exec_setregs(struct thread *td, struct image_params *im= gp, u_long stack) pcb->pcb_dr3 =3D 0; pcb->pcb_dr6 =3D 0; pcb->pcb_dr7 =3D 0; - if (pcb =3D=3D PCPU_GET(curpcb)) { + if (pcb =3D=3D curpcb) { /* * Clear the debug registers on the running * CPU, otherwise they will end up affecting diff --git a/sys/amd64/amd64/trap.c b/sys/amd64/amd64/trap.c index 57d1cc2..d035a7e 100644 --- a/sys/amd64/amd64/trap.c +++ b/sys/amd64/amd64/trap.c @@ -520,9 +520,8 @@ trap(struct trapframe *frame) frame->tf_rip =3D (long)fsbase_load_fault; goto out; } - if (PCPU_GET(curpcb)->pcb_onfault !=3D NULL) { - frame->tf_rip =3D - (long)PCPU_GET(curpcb)->pcb_onfault; + if (curpcb->pcb_onfault !=3D NULL) { + frame->tf_rip =3D (long)curpcb->pcb_onfault; goto out; } break; @@ -708,7 +707,7 @@ trap_pfault(frame, usermode) * it normally, and panic immediately. */ if (!usermode && (td->td_intr_nesting_level !=3D 0 || - PCPU_GET(curpcb)->pcb_onfault =3D=3D NULL)) { + curpcb->pcb_onfault =3D=3D NULL)) { trap_fatal(frame, eva); return (-1); } @@ -764,8 +763,8 @@ trap_pfault(frame, usermode) nogo: if (!usermode) { if (td->td_intr_nesting_level =3D=3D 0 && - PCPU_GET(curpcb)->pcb_onfault !=3D NULL) { - frame->tf_rip =3D (long)PCPU_GET(curpcb)->pcb_onfault; + curpcb->pcb_onfault !=3D NULL) { + frame->tf_rip =3D (long)curpcb->pcb_onfault; return (0); } trap_fatal(frame, eva); diff --git a/sys/amd64/include/pcb.h b/sys/amd64/include/pcb.h index 22cbbe2..d814902 100644 --- a/sys/amd64/include/pcb.h +++ b/sys/amd64/include/pcb.h @@ -144,6 +144,17 @@ void makectx(struct trapframe *, struct pcb *); int savectx(struct pcb *) __returns_twice; void resumectx(struct pcb *); =20 +static __inline __pure2 struct pcb * +__curpcb(void) +{ + struct pcb *pcb; + + __asm("movq %%gs:%1,%0" : "=3Dr" (pcb) + : "m" (((struct pcpu *)NULL)->pc_curpcb)); + return (pcb); +} +#define curpcb (__curpcb()) + #endif =20 #endif /* _AMD64_PCB_H_ */ diff --git a/sys/sys/user.h b/sys/sys/user.h index accb7c3..ab1c7a7 100644 --- a/sys/sys/user.h +++ b/sys/sys/user.h @@ -35,6 +35,7 @@ #ifndef _SYS_USER_H_ #define _SYS_USER_H_ =20 +#include #include #ifndef _KERNEL /* stuff that *used* to be included by user.h, or is now needed */ --HqPpMaT+a6TeY/Q4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAG4EMACgkQC3+MBN1Mb4itQgCgkv18eX4mYzsCvunFVKGRZaV1 OrMAoMwpCnf+YQQ6PHButBnkUltL7p7s =rmjd -----END PGP SIGNATURE----- --HqPpMaT+a6TeY/Q4-- From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 19 03:10:40 2012 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 70444106566B for ; Thu, 19 Jul 2012 03:10:40 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail34.syd.optusnet.com.au (mail34.syd.optusnet.com.au [211.29.133.218]) by mx1.freebsd.org (Postfix) with ESMTP id E292B8FC15 for ; Thu, 19 Jul 2012 03:10:39 +0000 (UTC) Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail34.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q6J3ATmA012239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2012 13:10:31 +1000 Date: Thu, 19 Jul 2012 13:10:29 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov In-Reply-To: <20120718081003.GT2676@deviant.kiev.zoral.com.ua> Message-ID: <20120719111846.G780@besplex.bde.org> References: <201207172150.q6HLoFvB096742@freefall.freebsd.org> <20120718103210.E834@besplex.bde.org> <20120718035220.GO2676@deviant.kiev.zoral.com.ua> <20120718140523.X1862@besplex.bde.org> <20120718050958.GQ2676@deviant.kiev.zoral.com.ua> <20120718153554.O2195@besplex.bde.org> <20120718081003.GT2676@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Mark Linimon , freebsd-amd64@freebsd.org Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 03:10:40 -0000 On Wed, 18 Jul 2012, Konstantin Belousov wrote: > On Wed, Jul 18, 2012 at 04:59:38PM +1000, Bruce Evans wrote: >> On Wed, 18 Jul 2012, Konstantin Belousov wrote: >> Putting the definiton in machine/pcpu.h should avoid changing the >> prerequistes for machine/pcb.h. >> >>> #ifndef _KERNEL >>> /* stuff that *used* to be included by user.h, or is now needed */ >>> >>> Please note the location in pcb.h an not in machine/pcpu.h, where it >>> cannot work for technical reasons (struct pcpu is not defined yet). >> >> Not applicable -- see above. > No, this cannot work. machine/pcpu.h defines PCPU_MD_FIELDS which is used > to provide md part of the struct pcpu. I see. Oops. But this problem is easy to avoid. There are at least the following alternatives: (1) hard-code the offset, as for curthread. This is ugly, but not too hard to maintain. The offset has been 4 * sizeof(struct thread *), for more than 10 years, and you can't change this without breaking the ABI. (2) #define the offset, as in raw asm code. The offset is #define'd in assym.s. This would give too much namespace pollution and bloat (unless a short assym.non-s is used). (3) use a macro instead of an inline function. Inline functions tend to require much more namespace pollution than macros, and this is an example of that. This is essentially the method that we already use. We define define the macro PCPU_GET(). We could define curpcb as PCPU_GET(curpcb). Instead, we write PCPU_GET(curpcb) everywhere that we want the value. I didn't like the roto-tilling of the source code for this and other pcpu fields, and we didn't do it for curproc (we roto-tilled curproc to curthread instead). Both curthread and curpcb are not as volatile as the other fields, so it is technically slightly incorrect to use the general volatile PCPU_GET() for them. We already use a de-volatalized PCPU_GET() for curthread. This was originally just an optimization and a de-obfuscation. PCPU_GET() expands to really horrible, hard-to debug code. It was so horrible and bloated that it broke compiling, so peter changed curthread to use an inline function in 2003. This is only done for some arches (just amd64 and i386?), and sys/pcpu.h still defines curthread as PCPU_GET(curthread) if it is not already defined. The inline function was originally equivalent to PCPU_GET(). It used a volatile asm and wasn't pure2. But since it was independent of PCPU_GET(), it was easier to optimize. To do the same thing for curpcb, provide a PCPU_NONVOLATILE_GET() which is the same as PCPU_GET() without the volatile in the asm, and #define curpcb as PCPU_NONVOLATILE_GET(curpcb). Or maybe start with the inline function used for curthread, and macroize it. This could be used for curthread too, but I think we want to keep it as an inline function since the macro expansions are still horrible. BTW, can you explain the locking for the pcpu access functions? It seems to be quite broken, with the volatile in the asms neither necessary nor sufficient. PCPU_PTR() seems to be almost unusable, but it is used. Here is the i386 version of __PCPU_GET(): % #define __PCPU_GET(name) __extension__ ({ \ % __pcpu_type(name) __res; \ % struct __s { \ % u_char __b[MIN(sizeof(__res), 4)]; \ % } __s; \ % \ % if (sizeof(__res) == 1 || sizeof(__res) == 2 || \ % sizeof(__res) == 4) { \ % __asm __volatile("mov %%fs:%1,%0" \ % : "=r" (__s) \ % : "m" (*(struct __s *)(__pcpu_offset(name)))); \ % *(struct __s *)(void *)&__res = __s; \ This part is more or less OK. It is subtle. The pcpu data starting at %fs:0 is volatile (or at least variable), and so is its address. Its address is not a C address, but is the constant 0 in %fs-space. %fs is equivalent to a volatile C pointer. When %fs changes, it is normally the responsibility of the caller to lock things so that this is not a problem or so that %fs can't change. (The %fs descriptor doesn't actually change, but the %fs data does). There are some important special cases where no locking is required: - for pc_curthread. This cannot change (except in context-switching code). The CPU running the code can change unless the caller locks things. Then %fs changes, but pc_curthread is switched so that it is the same for the new CPU as for the old CPU. - for pc_curpcb. This is switched like pc_curthread. - I don't know of any other pcpu variables that are as easy to use or as obviously correctly locked as the above 2. - counter variables. Now you want the %fs pointer to change to track the CPU. % } else { \ % __res = *__PCPU_PTR(name); \ __PCPU_PTR() seems to be almost unusable, and this is not one of the few cases where it is usable. Here it is used for wide or unusually-sized fields where atomic access is especially problematic, yet it does even less that the above to give atomicity. First consider using it in all cases to replace the above: - using it for fields like pc_curthead would be very broken. The pointer doesn't change, so if there is a context switch between reading the pointer and following it, the pointer reads the data for the wrong CPU. For pc_cuthread, the new pointer will give the old thread which is what curthread should return, but the old pointer will give some unrelated thread (whatever the old CPU is running now). - for counter variables, there is no problem. We don't care whether the pointer is for the new CPU or the old one, provided the access is atomic, and here I am only considering the case where accesses are natuarally atomic. (We actually use different access functions for counters so that things like incrementing counters is atomic.) Now consider it for wide data. The pointer doesn't change so the multiple accesses needed for the wide data are at least for the same CPU. This gives the same atomicity problems as for C pointers. The caller needs to lock. But PCPU_GET() is supposed to be a general interface. Its atomicity shouldn't depend on the size of the data. % } \ % __res; \ % }) What happens for arches where PCPU_GET() uses a C pointer? I don't see how this can work for fields that are switched like pc_curthread. Well, here is what happens in some cases: - on ia64, PCPU_GET() uses the C pointer pcpu which is a fixed register. curthread works because it doesn't use PCPU_GET() (it uses a __pure2 non-volatile asm similarly to i386). curpcb works beause it is not used. - sparc64 is similar to ia64 except it gives even more examples of the special switched fields: pcpu is C pointer in a fixed register; curpcb is a C pointer in another fixed register; curthread uses a __pure2 non-volatile asm similarly to ia64. Why is asm used for curthread on ia64 and sparc64? The asm seems to have no magic, but just follows the C pointer. Ah, this seems to be just bogus. Old versions did have magic -- they used a volatile asm and didn't use __pure2, but they were optimized like the x86 versions 2 years ago. So the problem seems to be well understood for the switched fields, and to not exist for counters. Other cases are hopefully handled by locking. Here are some that aren't: - PCPU_GET/SET(switchtime) in kern_resource.c. The accesses are only proc locked AFAIK. switchtime is uint64_t, so accesses to it are non-atomic on 32-bit arches. - PCPU_GET/SET(switchtime) in kern_synch.c and sched_*.c. Now the accesses are thread locked or sched_locked, which had better be enough (it is all that locks switching pc_curthread too?). - in clock code, there is a lot of thread locking, but this is localized and not all of the pcpu accesses are covered by it. Apparently, clock code depends on being called in fast interrupt handle context to give locking for pcpu. PCPU accesses are surprisingly rare except for counters, so there don't seem to be many problems. Most uses of PCP_PTR() are reasonable, since they are in places like subr_witness.c that should know to lock. I would remove the one in PCPU_GET(). This would break mainly the switchtime accesses on i386 and force callers to use PCPU_GET() and know that they need locking. Bruce From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 19 12:31:53 2012 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C4E01065673 for ; Thu, 19 Jul 2012 12:31:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 512C88FC0C for ; Thu, 19 Jul 2012 12:31:52 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6JCVqDh059354; Thu, 19 Jul 2012 15:31:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q6JCVegD008863; Thu, 19 Jul 2012 15:31:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6JCVcex008862; Thu, 19 Jul 2012 15:31:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 19 Jul 2012 15:31:38 +0300 From: Konstantin Belousov To: Bruce Evans Message-ID: <20120719123138.GG2676@deviant.kiev.zoral.com.ua> References: <201207172150.q6HLoFvB096742@freefall.freebsd.org> <20120718103210.E834@besplex.bde.org> <20120718035220.GO2676@deviant.kiev.zoral.com.ua> <20120718140523.X1862@besplex.bde.org> <20120718050958.GQ2676@deviant.kiev.zoral.com.ua> <20120718153554.O2195@besplex.bde.org> <20120718081003.GT2676@deviant.kiev.zoral.com.ua> <20120719111846.G780@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ijywFOGgtBfiIjQx" Content-Disposition: inline In-Reply-To: <20120719111846.G780@besplex.bde.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Mark Linimon , freebsd-amd64@freebsd.org Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 12:31:53 -0000 --ijywFOGgtBfiIjQx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 19, 2012 at 01:10:29PM +1000, Bruce Evans wrote: > On Wed, 18 Jul 2012, Konstantin Belousov wrote: >=20 > >On Wed, Jul 18, 2012 at 04:59:38PM +1000, Bruce Evans wrote: > >>On Wed, 18 Jul 2012, Konstantin Belousov wrote: > >>Putting the definiton in machine/pcpu.h should avoid changing the > >>prerequistes for machine/pcb.h. > >> > >>>#ifndef _KERNEL > >>>/* stuff that *used* to be included by user.h, or is now needed */ > >>> > >>>Please note the location in pcb.h an not in machine/pcpu.h, where it > >>>cannot work for technical reasons (struct pcpu is not defined yet). > >> > >>Not applicable -- see above. > >No, this cannot work. machine/pcpu.h defines PCPU_MD_FIELDS which is used > >to provide md part of the struct pcpu. >=20 > I see. Oops. >=20 > But this problem is easy to avoid. There are at least the following > alternatives: > (1) hard-code the offset, as for curthread. This is ugly, but not too > hard to maintain. The offset has been 4 * sizeof(struct thread *), > for more than 10 years, and you can't change this without breaking > the ABI. I did this, adding CTASSERTs. See the patch below. > (2) #define the offset, as in raw asm code. The offset is #define'd in > assym.s. This would give too much namespace pollution and bloat > (unless a short assym.non-s is used). > (3) use a macro instead of an inline function. Inline functions tend to > require much more namespace pollution than macros, and this is an > example of that. This is essentially the method that we already > use. We define define the macro PCPU_GET(). We could define curpcb > as PCPU_GET(curpcb). Instead, we write PCPU_GET(curpcb) > everywhere that we want the value. >=20 > I didn't like the roto-tilling of the source code for this and > other pcpu fields, and we didn't do it for curproc (we roto-tilled > curproc to curthread instead). Both curthread and curpcb are not > as volatile as the other fields, so it is technically slightly > incorrect to use the general volatile PCPU_GET() for them. We > already use a de-volatalized PCPU_GET() for curthread. This was > originally just an optimization and a de-obfuscation. PCPU_GET() > expands to really horrible, hard-to debug code. It was so horrible > and bloated that it broke compiling, so peter changed curthread > to use an inline function in 2003. This is only done for some > arches (just amd64 and i386?), and sys/pcpu.h still defines > curthread as PCPU_GET(curthread) if it is not already defined. > The inline function was originally equivalent to PCPU_GET(). It > used a volatile asm and wasn't pure2. But since it was independent > of PCPU_GET(), it was easier to optimize. >=20 > To do the same thing for curpcb, provide a PCPU_NONVOLATILE_GET() > which is the same as PCPU_GET() without the volatile in the asm, > and #define curpcb as PCPU_NONVOLATILE_GET(curpcb). Or maybe > start with the inline function used for curthread, and macroize it. >=20 > This could be used for curthread too, but I think we want to keep it > as an inline function since the macro expansions are still horrible. I do not like this, prefer the inline functions approach. >=20 > BTW, can you explain the locking for the pcpu access functions? It seems > to be quite broken, with the volatile in the asms neither necessary nor > sufficient. PCPU_PTR() seems to be almost unusable, but it is used. > Here is the i386 version of __PCPU_GET(): >=20 > % #define __PCPU_GET(name) __extension__ ({ \ > % __pcpu_type(name) __res; \ > % struct __s { \ > % u_char __b[MIN(sizeof(__res), 4)]; \ > % } __s; \ > % \ > % if (sizeof(__res) =3D=3D 1 || sizeof(__res) =3D=3D 2 || \ > % sizeof(__res) =3D=3D 4) { \ > % __asm __volatile("mov %%fs:%1,%0" \ > % : "=3Dr" (__s) \ > % : "m" (*(struct __s *)(__pcpu_offset(name)))); \ > % *(struct __s *)(void *)&__res =3D __s; \ >=20 > This part is more or less OK. It is subtle. The pcpu data starting at > %fs:0 is volatile (or at least variable), and so is its address. Its > address is not a C address, but is the constant 0 in %fs-space. %fs is > equivalent to a volatile C pointer. When %fs changes, it is normally > the responsibility of the caller to lock things so that this is not a > problem or so that %fs can't change. (The %fs descriptor doesn't > actually change, but the %fs data does). There are some important special > cases where no locking is required: > - for pc_curthread. This cannot change (except in context-switching > code). The CPU running the code can change unless the caller locks > things. Then %fs changes, but pc_curthread is switched so that it > is the same for the new CPU as for the old CPU. > - for pc_curpcb. This is switched like pc_curthread. > - I don't know of any other pcpu variables that are as easy to use or > as obviously correctly locked as the above 2. > - counter variables. Now you want the %fs pointer to change to track > the CPU. They are 'locked' by the fact that the increment is atomic regarind context switches and interrupts, since CPU guarantees that interrupts only happen on exact instruction boundaries. >=20 > % } else { \ > % __res =3D *__PCPU_PTR(name); \ >=20 > __PCPU_PTR() seems to be almost unusable, and this is not one of the > few cases where it is usable. Here it is used for wide or unusually-sized > fields where atomic access is especially problematic, yet it does even > less that the above to give atomicity. First consider using it in all > cases to replace the above: > - using it for fields like pc_curthead would be very broken. The pointer > doesn't change, so if there is a context switch between reading the > pointer and following it, the pointer reads the data for the wrong CPU. > For pc_cuthread, the new pointer will give the old thread which is > what curthread should return, but the old pointer will give some unrela= ted > thread (whatever the old CPU is running now). > - for counter variables, there is no problem. We don't care whether the > pointer is for the new CPU or the old one, provided the access is atomi= c, > and here I am only considering the case where accesses are natuarally > atomic. (We actually use different access functions for counters so > that things like incrementing counters is atomic.) > Now consider it for wide data. The pointer doesn't change so the multiple > accesses needed for the wide data are at least for the same CPU. This gi= ves > the same atomicity problems as for C pointers. The caller needs to lock. > But PCPU_GET() is supposed to be a general interface. Its atomicity > shouldn't depend on the size of the data. >=20 > % } \ > % __res; \ > % }) For x86-oids, if you use PCPU_GET for pointers, you euther need to brace the block with something that disables preemption, e.g. bind the thread to CPU, or use spinlock, or enter critical section, or be ready to handle possible scheduling. Example of the later would be use of atomic operation on the resulting pointer destination. >=20 > What happens for arches where PCPU_GET() uses a C pointer? I don't see > how this can work for fields that are switched like pc_curthread. Well, > here is what happens in some cases: > - on ia64, PCPU_GET() uses the C pointer pcpu which is a fixed register. > curthread works because it doesn't use PCPU_GET() (it uses a __pure2 > non-volatile asm similarly to i386). curpcb works beause it is not > used. > - sparc64 is similar to ia64 except it gives even more examples of the > special switched fields: pcpu is C pointer in a fixed register; > curpcb is a C pointer in another fixed register; curthread uses a > __pure2 non-volatile asm similarly to ia64. Why is asm used for > curthread on ia64 and sparc64? The asm seems to have no magic, but > just follows the C pointer. Ah, this seems to be just bogus. Old > versions did have magic -- they used a volatile asm and didn't use > __pure2, but they were optimized like the x86 versions 2 years ago. >=20 > So the problem seems to be well understood for the switched fields, and > to not exist for counters. Other cases are hopefully handled by locking. > Here are some that aren't: > - PCPU_GET/SET(switchtime) in kern_resource.c. The accesses are only > proc locked AFAIK. switchtime is uint64_t, so accesses to it are > non-atomic on 32-bit arches. Note that access to switchtime is covered by the process spinlock. Spinlocks disable preemption, so this is fine. > - PCPU_GET/SET(switchtime) in kern_synch.c and sched_*.c. Now the > accesses are thread locked or sched_locked, which had better be enough > (it is all that locks switching pc_curthread too?). Ditto. > - in clock code, there is a lot of thread locking, but this is localized > and not all of the pcpu accesses are covered by it. Apparently, clock > code depends on being called in fast interrupt handle context to give > locking for pcpu. >=20 > PCPU accesses are surprisingly rare except for counters, so there don't > seem to be many problems. >=20 > Most uses of PCP_PTR() are reasonable, since they are in places like > subr_witness.c that should know to lock. I would remove the one in > PCPU_GET(). This would break mainly the switchtime accesses on i386 > and force callers to use PCPU_GET() and know that they need locking. Below is the updated patch, with added assert that offset of pc_curthread is 0. diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c index f88aba7..fe4bcf1 100644 --- a/sys/amd64/amd64/fpu.c +++ b/sys/amd64/amd64/fpu.c @@ -327,7 +327,7 @@ fpuexit(struct thread *td) critical_enter(); if (curthread =3D=3D PCPU_GET(fpcurthread)) { stop_emulating(); - fpusave(PCPU_GET(curpcb)->pcb_save); + fpusave(curpcb->pcb_save); start_emulating(); PCPU_SET(fpcurthread, 0); } @@ -547,7 +547,7 @@ fputrap_x87(void) * wherever they are. */ if (PCPU_GET(fpcurthread) !=3D curthread) { - pcb_save =3D PCPU_GET(curpcb)->pcb_save; + pcb_save =3D curpcb->pcb_save; control =3D pcb_save->sv_env.en_cw; status =3D pcb_save->sv_env.en_sw; } else { @@ -567,7 +567,7 @@ fputrap_sse(void) =20 critical_enter(); if (PCPU_GET(fpcurthread) !=3D curthread) - mxcsr =3D PCPU_GET(curpcb)->pcb_save->sv_env.en_mxcsr; + mxcsr =3D curpcb->pcb_save->sv_env.en_mxcsr; else stmxcsr(&mxcsr); critical_exit(); @@ -609,7 +609,7 @@ fpudna(void) * Record new context early in case frstor causes a trap. */ PCPU_SET(fpcurthread, curthread); - pcb =3D PCPU_GET(curpcb); + pcb =3D curpcb; =20 fpu_clean_state(); =20 @@ -970,7 +970,7 @@ fpu_kern_thread(u_int flags) { struct pcb *pcb; =20 - pcb =3D PCPU_GET(curpcb); + pcb =3D curpcb; KASSERT((curthread->td_pflags & TDP_KTHREAD) !=3D 0, ("Only kthread may use fpu_kern_thread")); KASSERT(pcb->pcb_save =3D=3D get_pcb_user_save_pcb(pcb), @@ -987,5 +987,5 @@ is_fpu_kern_thread(u_int flags) =20 if ((curthread->td_pflags & TDP_KTHREAD) =3D=3D 0) return (0); - return ((PCPU_GET(curpcb)->pcb_flags & PCB_KERNFPU) !=3D 0); + return ((curpcb->pcb_flags & PCB_KERNFPU) !=3D 0); } diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c index 8044fe5..cd3ebc5 100644 --- a/sys/amd64/amd64/machdep.c +++ b/sys/amd64/amd64/machdep.c @@ -996,7 +996,7 @@ exec_setregs(struct thread *td, struct image_params *im= gp, u_long stack) pcb->pcb_dr3 =3D 0; pcb->pcb_dr6 =3D 0; pcb->pcb_dr7 =3D 0; - if (pcb =3D=3D PCPU_GET(curpcb)) { + if (pcb =3D=3D curpcb) { /* * Clear the debug registers on the running * CPU, otherwise they will end up affecting diff --git a/sys/amd64/amd64/trap.c b/sys/amd64/amd64/trap.c index 57d1cc2..d035a7e 100644 --- a/sys/amd64/amd64/trap.c +++ b/sys/amd64/amd64/trap.c @@ -520,9 +520,8 @@ trap(struct trapframe *frame) frame->tf_rip =3D (long)fsbase_load_fault; goto out; } - if (PCPU_GET(curpcb)->pcb_onfault !=3D NULL) { - frame->tf_rip =3D - (long)PCPU_GET(curpcb)->pcb_onfault; + if (curpcb->pcb_onfault !=3D NULL) { + frame->tf_rip =3D (long)curpcb->pcb_onfault; goto out; } break; @@ -708,7 +707,7 @@ trap_pfault(frame, usermode) * it normally, and panic immediately. */ if (!usermode && (td->td_intr_nesting_level !=3D 0 || - PCPU_GET(curpcb)->pcb_onfault =3D=3D NULL)) { + curpcb->pcb_onfault =3D=3D NULL)) { trap_fatal(frame, eva); return (-1); } @@ -764,8 +763,8 @@ trap_pfault(frame, usermode) nogo: if (!usermode) { if (td->td_intr_nesting_level =3D=3D 0 && - PCPU_GET(curpcb)->pcb_onfault !=3D NULL) { - frame->tf_rip =3D (long)PCPU_GET(curpcb)->pcb_onfault; + curpcb->pcb_onfault !=3D NULL) { + frame->tf_rip =3D (long)curpcb->pcb_onfault; return (0); } trap_fatal(frame, eva); diff --git a/sys/amd64/amd64/vm_machdep.c b/sys/amd64/amd64/vm_machdep.c index 103fa0d..070d8c9 100644 --- a/sys/amd64/amd64/vm_machdep.c +++ b/sys/amd64/amd64/vm_machdep.c @@ -90,6 +90,10 @@ static u_int cpu_reset_proxyid; static volatile u_int cpu_reset_proxy_active; #endif =20 +CTASSERT((struct thread **)OFFSETOF_CURTHREAD =3D=3D + &((struct pcpu *)NULL)->pc_curthread); +CTASSERT((struct pcb **)OFFSETOF_CURPCB =3D=3D &((struct pcpu *)NULL)->pc_= curpcb); + struct savefpu * get_pcb_user_save_td(struct thread *td) { diff --git a/sys/amd64/include/pcpu.h b/sys/amd64/include/pcpu.h index d07dbac..5d1fd4d 100644 --- a/sys/amd64/include/pcpu.h +++ b/sys/amd64/include/pcpu.h @@ -216,16 +216,29 @@ extern struct pcpu *pcpup; #define PCPU_PTR(member) __PCPU_PTR(pc_ ## member) #define PCPU_SET(member, val) __PCPU_SET(pc_ ## member, val) =20 +#define OFFSETOF_CURTHREAD 0 static __inline __pure2 struct thread * __curthread(void) { struct thread *td; =20 - __asm("movq %%gs:0,%0" : "=3Dr" (td)); + __asm("movq %%gs:%1,%0" : "=3Dr" (td) + : "m" (*(char *)OFFSETOF_CURTHREAD)); return (td); } #define curthread (__curthread()) =20 +#define OFFSETOF_CURPCB 32 +static __inline __pure2 struct pcb * +__curpcb(void) +{ + struct pcb *pcb; + + __asm("movq %%gs:%1,%0" : "=3Dr" (pcb) : "m" (*(char *)OFFSETOF_CURPCB)); + return (pcb); +} +#define curpcb (__curpcb()) + #define IS_BSP() (PCPU_GET(cpuid) =3D=3D 0) =20 #else /* !lint || defined(__GNUCLIKE_ASM) && defined(__GNUCLIKE___TYPEOF) = */ --ijywFOGgtBfiIjQx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAH/ioACgkQC3+MBN1Mb4g47QCdExFYfgmsb7VN8pWA4w+IeCLe oaYAnixdFtzkLHW0+Fc63F/OLjr+13e2 =LheE -----END PGP SIGNATURE----- --ijywFOGgtBfiIjQx-- From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 19 17:44:07 2012 Return-Path: Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1090D106566C for ; Thu, 19 Jul 2012 17:44:07 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by mx1.freebsd.org (Postfix) with ESMTP id 94C338FC1A for ; Thu, 19 Jul 2012 17:44:06 +0000 (UTC) Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail14.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q6JHi2r1008855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jul 2012 03:44:03 +1000 Date: Fri, 20 Jul 2012 03:44:02 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov In-Reply-To: <20120719123138.GG2676@deviant.kiev.zoral.com.ua> Message-ID: <20120720032018.Q3406@besplex.bde.org> References: <201207172150.q6HLoFvB096742@freefall.freebsd.org> <20120718103210.E834@besplex.bde.org> <20120718035220.GO2676@deviant.kiev.zoral.com.ua> <20120718140523.X1862@besplex.bde.org> <20120718050958.GQ2676@deviant.kiev.zoral.com.ua> <20120718153554.O2195@besplex.bde.org> <20120718081003.GT2676@deviant.kiev.zoral.com.ua> <20120719111846.G780@besplex.bde.org> <20120719123138.GG2676@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Mark Linimon , freebsd-amd64@FreeBSD.org Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 17:44:07 -0000 On Thu, 19 Jul 2012, Konstantin Belousov wrote: > On Thu, Jul 19, 2012 at 01:10:29PM +1000, Bruce Evans wrote: >> On Wed, 18 Jul 2012, Konstantin Belousov wrote: >> >>> On Wed, Jul 18, 2012 at 04:59:38PM +1000, Bruce Evans wrote: >>>> On Wed, 18 Jul 2012, Konstantin Belousov wrote: >>>> Putting the definiton in machine/pcpu.h should avoid changing the >>>> prerequistes for machine/pcb.h. >>>> >>>>> #ifndef _KERNEL >>>>> /* stuff that *used* to be included by user.h, or is now needed */ >>>>> >>>>> Please note the location in pcb.h an not in machine/pcpu.h, where it >>>>> cannot work for technical reasons (struct pcpu is not defined yet). >>>> >>>> Not applicable -- see above. >>> No, this cannot work. machine/pcpu.h defines PCPU_MD_FIELDS which is used >>> to provide md part of the struct pcpu. >> >> I see. Oops. >> >> But this problem is easy to avoid. There are at least the following >> alternatives: >> (1) hard-code the offset, as for curthread. This is ugly, but not too >> hard to maintain. The offset has been 4 * sizeof(struct thread *), >> for more than 10 years, and you can't change this without breaking >> the ABI. > I did this, adding CTASSERTs. See the patch below. Looks good. I had forgotten that CTASSERT() makes this safe. >> To do the same thing for curpcb, provide a PCPU_NONVOLATILE_GET() >> which is the same as PCPU_GET() without the volatile in the asm, >> and #define curpcb as PCPU_NONVOLATILE_GET(curpcb). Or maybe >> start with the inline function used for curthread, and macroize it. >> >> This could be used for curthread too, but I think we want to keep it >> as an inline function since the macro expansions are still horrible. > I do not like this, prefer the inline functions approach. Maybe use even more inlines. I wonder if an inline that is always parsed but rarely used takes longer to compile than a complicated macro that is often but not always expanded (where each expansion gives an asm similar to the inline). >> BTW, can you explain the locking for the pcpu access functions? It seems >> to be quite broken, with the volatile in the asms neither necessary nor >> sufficient. PCPU_PTR() seems to be almost unusable, but it is used. >> ... >> - [curthread and curpcb are special] >> as obviously correctly locked as the above 2. >> - counter variables. Now you want the %fs pointer to change to track >> the CPU. > They are 'locked' by the fact that the increment is atomic regarind > context switches and interrupts, since CPU guarantees that interrupts > only happen on exact instruction boundaries. Also, PCPU_INC() only supports 1, 2 and 4-byte variables on i386. But I increments of int64_t variables using PCPU_PTR() (or DPCPU_PTR()?) aren't safe on i386. >> % } else { \ >> % __res = *__PCPU_PTR(name); \ >> >> __PCPU_PTR() seems to be almost unusable, and this is not one of the >> few cases where it is usable. Here it is used for wide or unusually-sized >> fields where atomic access is especially problematic, yet it does even >> less that the above to give atomicity. First consider using it in all >> cases to replace the above: >> ... >> - PCPU_GET/SET(switchtime) in kern_resource.c. The accesses are only >> proc locked AFAIK. switchtime is uint64_t, so accesses to it are >> non-atomic on 32-bit arches. > Note that access to switchtime is covered by the process spinlock. > Spinlocks disable preemption, so this is fine. I see. It used to use sched locking, but was optimized. > Below is the updated patch, with added assert that offset of pc_curthread > is 0. > diff --git a/sys/amd64/amd64/vm_machdep.c b/sys/amd64/amd64/vm_machdep.c > index 103fa0d..070d8c9 100644 > --- a/sys/amd64/amd64/vm_machdep.c > +++ b/sys/amd64/amd64/vm_machdep.c > @@ -90,6 +90,10 @@ static u_int cpu_reset_proxyid; > static volatile u_int cpu_reset_proxy_active; > #endif > > +CTASSERT((struct thread **)OFFSETOF_CURTHREAD == > + &((struct pcpu *)NULL)->pc_curthread); > +CTASSERT((struct pcb **)OFFSETOF_CURPCB == &((struct pcpu *)NULL)->pc_curpcb); > + Hmm, I was hoping that the CTASSERT() would be in a header, closer to the code. Unfortunately, it can't go very close, for the same reason that we can't just use struct pcpu in machine/pcpu.h. This style seems to be unpopular -- in headers, the only CTASSERTs() are in old disk headers and serial.h. They should use __offsetof() instead of a home made one. Bruce From owner-freebsd-amd64@FreeBSD.ORG Sat Jul 21 17:55:25 2012 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 00CEB106566B for ; Sat, 21 Jul 2012 17:55:25 +0000 (UTC) (envelope-from asido4@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id B414F8FC0A for ; Sat, 21 Jul 2012 17:55:24 +0000 (UTC) Received: by ggnm2 with SMTP id m2so5580196ggn.13 for ; Sat, 21 Jul 2012 10:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pd+dRe38PTVupY3gxLrWK15IkVUS28c06u/Cb0i21uc=; b=H6b2Ye6Hj69jo5L+oHp9mHL2pDsotj7B3rhpnKnKDCYBZag184KuZ1P7qGgJx6bxNn LmjHsZ8MvzQ6vzAHO0qEFzK2UzQhafYsxnvLlB+XxCbxR0MnBtPkRxu37yvshwWwElS5 9b2Wsz9IPzpHfkna6g3F+9sk1Zko+rfq7srb7T/Yd8ChQzuTmlVxy3cDtRaQ6LPQKVZX A1Lwtwh19d07V199rpWWDZ2ki57CGi43sfPuI/G7vygV7m4bYjS//wPXwEPtkgnM8Kxg +do2ypMM68moWNF4mc4rSlvx0zf5I4iiIyb2sNMl92D3WL/0beyYoy+1sfwTSRvZyXQZ wGZA== MIME-Version: 1.0 Received: by 10.50.202.33 with SMTP id kf1mr1247201igc.69.1342893323551; Sat, 21 Jul 2012 10:55:23 -0700 (PDT) Received: by 10.64.106.202 with HTTP; Sat, 21 Jul 2012 10:55:23 -0700 (PDT) Date: Sat, 21 Jul 2012 19:55:23 +0200 Message-ID: From: Arvydas Sidorenko To: freebsd-amd64@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: no such instructions: xsave, xsetbv, xrstor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 17:55:25 -0000 This is the output I get when building 10-CURRENT from HEAD: /usr/src/sys/amd64/amd64/cpu_switch.S: Assembler messages: /usr/src/sys/amd64/amd64/cpu_switch.S:128: Error: no such instruction: `xsave (%r8)' /usr/src/sys/amd64/amd64/cpu_switch.S:504: Error: no such instruction: `xsetbv' /usr/src/sys/amd64/amd64/cpu_switch.S:505: Error: no such instruction: `xrstor (%rbx)' $ uname -a FreeBSD slacker 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: Tue Jun 12 02:52:29 UTC 2012 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 The CPU capabilities should not impact the compilation, but here they're anyways (E8600): $ grep Features /var/run/dmesg.boot | grep -i xsave Features2=0x408e3fd Features2=0x408e3fd Is it problem with assembler? Which on my system is: $ as --version GNU assembler (GNU Binutils) 2.22 Copyright 2011 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-portbld-freebsd9.0'. And classic outdated GCC: $ gcc --version gcc (GCC) 4.2.1 20070831 patched [FreeBSD] Any help is appreciated. From owner-freebsd-amd64@FreeBSD.ORG Sat Jul 21 18:36:55 2012 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B099106566B for ; Sat, 21 Jul 2012 18:36:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 12D4F8FC16 for ; Sat, 21 Jul 2012 18:36:54 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6LIb3sv031413; Sat, 21 Jul 2012 21:37:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q6LIaoJI040375; Sat, 21 Jul 2012 21:36:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6LIaopN040374; Sat, 21 Jul 2012 21:36:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 21 Jul 2012 21:36:50 +0300 From: Konstantin Belousov To: Arvydas Sidorenko Message-ID: <20120721183650.GC2676@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jiG1sp+CfApzbQkA" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-amd64@freebsd.org Subject: Re: no such instructions: xsave, xsetbv, xrstor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 18:36:55 -0000 --jiG1sp+CfApzbQkA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 21, 2012 at 07:55:23PM +0200, Arvydas Sidorenko wrote: > This is the output I get when building 10-CURRENT from HEAD: > /usr/src/sys/amd64/amd64/cpu_switch.S: Assembler messages: > /usr/src/sys/amd64/amd64/cpu_switch.S:128: Error: no such instruction: > `xsave (%r8)' > /usr/src/sys/amd64/amd64/cpu_switch.S:504: Error: no such instruction: `x= setbv' > /usr/src/sys/amd64/amd64/cpu_switch.S:505: Error: no such instruction: > `xrstor (%rbx)' >=20 > $ uname -a > FreeBSD slacker 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: Tue Jun 12 > 02:52:29 UTC 2012 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 >=20 > The CPU capabilities should not impact the compilation, but here > they're anyways (E8600): > $ grep Features /var/run/dmesg.boot | grep -i xsave > Features2=3D0x408e3fd > Features2=3D0x408e3fd >=20 > Is it problem with assembler? Which on my system is: > $ as --version > GNU assembler (GNU Binutils) 2.22 > Copyright 2011 Free Software Foundation, Inc. > This program is free software; you may redistribute it under the terms of > the GNU General Public License version 3 or later. > This program has absolutely no warranty. > This assembler was configured for a target of `x86_64-portbld-freebsd9.0'. >=20 > And classic outdated GCC: > $ gcc --version > gcc (GCC) 4.2.1 20070831 patched [FreeBSD] >=20 > Any help is appreciated. You must follow the UPDATING guide on rebuilding the system, in particular, you shall use buildworld and buildkernel procedure. Assembler in HEAD was patched to support these instructions, and kernel now uses them instead of using manual assembly results. Host CPU features indeed have no relevance to your problem. --jiG1sp+CfApzbQkA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAK9sIACgkQC3+MBN1Mb4hnnwCg9tpQ5AzZTt5ujTh/qQp+FbTi FI0An07amCReHACxey5aUS1ftJ992FSp =u9YM -----END PGP SIGNATURE----- --jiG1sp+CfApzbQkA-- From owner-freebsd-amd64@FreeBSD.ORG Sat Jul 21 17:52:36 2012 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B0F36106564A for ; Sat, 21 Jul 2012 17:52:36 +0000 (UTC) (envelope-from asido4@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6FCA78FC0C for ; Sat, 21 Jul 2012 17:52:36 +0000 (UTC) Received: by ggnm2 with SMTP id m2so5579547ggn.13 for ; Sat, 21 Jul 2012 10:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pd+dRe38PTVupY3gxLrWK15IkVUS28c06u/Cb0i21uc=; b=zigZ/s2xbkh0klmWUSuWapL7Rf9wA+TLzyU+dLvVTxjUcKnkMhyEAMjQNjhFgStkjO /YjtlQA1l7kp25QYAn0f9O1hHQ1L7TUmG6mHDBxBCInypZ5CctNulgrWxJqyqUpACShp kuFhySUQ57WywobTz8lBdVHD/OH8ihAc3JLibPEd7pYg9fY/zqKiq+oxAHDBmkBMdHSX nb22e7nFXy6XHhqldXMsx9ZvEMDy8SyyFijNu2LoIq7Jdlkg10q7DSJtAjKLMzH93iEJ sVYhcPXK2+1O/kLMu9lynoT3oJP0OCKTjRTWIQAuBD776ktc8bQ6sGQU7IKsv5Y5cnII 5OoA== MIME-Version: 1.0 Received: by 10.50.182.232 with SMTP id eh8mr10910916igc.48.1342893150026; Sat, 21 Jul 2012 10:52:30 -0700 (PDT) Received: by 10.64.106.202 with HTTP; Sat, 21 Jul 2012 10:52:29 -0700 (PDT) Date: Sat, 21 Jul 2012 19:52:29 +0200 Message-ID: From: Arvydas Sidorenko To: freebsd-amd64@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Sat, 21 Jul 2012 19:38:38 +0000 Subject: no such instructions: xsave, xsetbv, xrstor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 17:52:36 -0000 This is the output I get when building 10-CURRENT from HEAD: /usr/src/sys/amd64/amd64/cpu_switch.S: Assembler messages: /usr/src/sys/amd64/amd64/cpu_switch.S:128: Error: no such instruction: `xsave (%r8)' /usr/src/sys/amd64/amd64/cpu_switch.S:504: Error: no such instruction: `xsetbv' /usr/src/sys/amd64/amd64/cpu_switch.S:505: Error: no such instruction: `xrstor (%rbx)' $ uname -a FreeBSD slacker 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: Tue Jun 12 02:52:29 UTC 2012 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 The CPU capabilities should not impact the compilation, but here they're anyways (E8600): $ grep Features /var/run/dmesg.boot | grep -i xsave Features2=0x408e3fd Features2=0x408e3fd Is it problem with assembler? Which on my system is: $ as --version GNU assembler (GNU Binutils) 2.22 Copyright 2011 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-portbld-freebsd9.0'. And classic outdated GCC: $ gcc --version gcc (GCC) 4.2.1 20070831 patched [FreeBSD] Any help is appreciated. From owner-freebsd-amd64@FreeBSD.ORG Sat Jul 21 20:06:56 2012 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6142C106564A for ; Sat, 21 Jul 2012 20:06:56 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 245D88FC12 for ; Sat, 21 Jul 2012 20:06:56 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id q6LK6otA079641; Sat, 21 Jul 2012 13:06:50 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q6LK6nHW079640; Sat, 21 Jul 2012 13:06:49 -0700 (PDT) (envelope-from sgk) Date: Sat, 21 Jul 2012 13:06:49 -0700 From: Steve Kargl To: Arvydas Sidorenko Message-ID: <20120721200649.GA79631@troutmask.apl.washington.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-amd64@freebsd.org Subject: Re: no such instructions: xsave, xsetbv, xrstor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 20:06:56 -0000 On Sat, Jul 21, 2012 at 07:52:29PM +0200, Arvydas Sidorenko wrote: > This is the output I get when building 10-CURRENT from HEAD: > /usr/src/sys/amd64/amd64/cpu_switch.S: Assembler messages: > /usr/src/sys/amd64/amd64/cpu_switch.S:128: Error: no such instruction: > `xsave (%r8)' > /usr/src/sys/amd64/amd64/cpu_switch.S:504: Error: no such instruction: `xsetbv' > /usr/src/sys/amd64/amd64/cpu_switch.S:505: Error: no such instruction: > `xrstor (%rbx)' How you building HEAD? -- Steve From owner-freebsd-amd64@FreeBSD.ORG Sat Jul 21 22:05:28 2012 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CDD9106566B for ; Sat, 21 Jul 2012 22:05:28 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id CF8A18FC12 for ; Sat, 21 Jul 2012 22:05:27 +0000 (UTC) Received: by obbun3 with SMTP id un3so9094036obb.13 for ; Sat, 21 Jul 2012 15:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Rb1Mpz0Rnqhufjl1lZjIdw55YOK/CjCJC0Ed38EnDZc=; b=i+RKv1ia6mKid6T87S+TyMEPfNNlzoAPtOd1XhNWfgZJ/EE3MVw1tBYjDqrfIzk91C D87nDBI3XuMVqKOBg78q4N0pzB5jyCkdSV863/hpktsRaWRLF20N9oWdEYeSm5h94WDe snXVWbeCYEtSS1QrXM1hL6DuNxFRIe5Kikmc4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Rb1Mpz0Rnqhufjl1lZjIdw55YOK/CjCJC0Ed38EnDZc=; b=gd+2iirL+ugU/YUIXA9D27qPkuqoPgeIE2aYcZnR/otDV20/iCRoFKMVCWta7hKbhH XSEztFlfARn628YUK5UNtCSYtGgdQ+b0KDpFid8ghJ7d8Vqwf2YGXp5aMxBFIZh6TD1W GZLh+kkn02+yG22IATvFxGUBwxz4Lr2PCgDxP29SHivaPoe2PNEmnisgevxbCpu2LB1z LJv957tZEIeHkOVIVLvC4pP7xOrSTUOR32k3rbYCk4QJBGPZX7OdkjEgvAfOOaqk3Psl 2/ICoww2Pk040EoU2c5zDbT1FSnmyuACxhHd8jhvX948ha2HHs8dvO/O9IJkBvswwqI5 rd8g== MIME-Version: 1.0 Received: by 10.182.164.10 with SMTP id ym10mr13739441obb.75.1342908327379; Sat, 21 Jul 2012 15:05:27 -0700 (PDT) Received: by 10.182.97.164 with HTTP; Sat, 21 Jul 2012 15:05:27 -0700 (PDT) In-Reply-To: References: Date: Sat, 21 Jul 2012 15:05:27 -0700 Message-ID: From: Peter Wemm To: Arvydas Sidorenko Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnI/0NjHoZHDGYZJqoPfXQm2jh0O5+trUPIjQphVJX2P6pt5zQzUNTpEopIhZrWBikFevrx Cc: freebsd-amd64@freebsd.org Subject: Re: no such instructions: xsave, xsetbv, xrstor X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 22:05:28 -0000 On Sat, Jul 21, 2012 at 10:55 AM, Arvydas Sidorenko wrote: > This is the output I get when building 10-CURRENT from HEAD: > /usr/src/sys/amd64/amd64/cpu_switch.S: Assembler messages: > /usr/src/sys/amd64/amd64/cpu_switch.S:128: Error: no such instruction: > `xsave (%r8)' > /usr/src/sys/amd64/amd64/cpu_switch.S:504: Error: no such instruction: `xsetbv' > /usr/src/sys/amd64/amd64/cpu_switch.S:505: Error: no such instruction: > `xrstor (%rbx)' > > $ uname -a > FreeBSD slacker 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: Tue Jun 12 ^^^^^^^^^^^^^^^^^^^^^^ Is that a mistake? We generally only support buildkernel/installkernel type cross-builds from older releases. Or even sometimes older versions of head building later versions. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell