freebsd-sparc-digest V5 #218
owner-freebsd...@freebsd.org
freebsd-sparc-digest Friday, January 17 2003 Volume 05 : Number 218
In this issue:
ahc driver and vinum work on Ultra10
sparc64/47143: OFW console does not implement ALT_BREAK_TO_DEBUGGER
Re: panic: trap: fast data access mmu miss
Re: assembler error in XFree86 snapshot
portupgrade on sparc64
Re: portupgrade on sparc64
Re: portupgrade on sparc64
Re: portupgrade on sparc64
Ultra 10 won't boot after install
XFree86 and syscons support
Re: Sparc64 floating point questions
Re: Sparc64 floating point questions
----------------------------------------------------------------------
Date: Thu, 16 Jan 2003 10:28:29 +0100 (CET)
From: Harti Brandt <bra...@fokus.gmd.de>
Subject: ahc driver and vinum work on Ultra10
Hi all,
the release notes for 5.0 say, that support for ahc(4) is coming really
soon now. It appears, that an adaptec 29160N is just working out of the
box if you put the ahc driver into your kernel config (see dmesg below).
You just cannot boot from it (because it has no OF code). So its probably
a good idea to just remove that 'coming real soon' from the hardware list.
It may also make sense to enable building vinum. I reported back in
december, that I found RAID0 and RAID1 to work, and there was another
report on this a couple of days ago. The following patch will do that:
harti
Index: Makefile
===================================================================
RCS file: /home/cvs/freebsd/src/sys/modules/Makefile,v
retrieving revision 1.298
diff -r1.298 Makefile
274c274,275
< SUBDIR+=hme
- ---
> SUBDIR+=hme \
> vinum
kernel: Copyright (c) 1992-2003 The FreeBSD Project.
kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
kernel: The Regents of the University of California. All rights reserved.
kernel: FreeBSD 5.0-CURRENT #3: Tue Jan 7 18:15:41 CET 2003
kernel: ro...@catssrv.fokus.gmd.de:/opt/obj/usr/src/sys/CATSSRV
kernel: Preloaded elf kernel "/boot/kernel/kernel" at 0xc05d6000.
kernel: Preloaded elf module "/boot/kernel/random.ko" at 0xc05d6170.
kernel: Preloaded elf module "/boot/kernel/if_hme.ko" at 0xc05d6240.
kernel: Preloaded elf module "/boot/kernel/miibus.ko" at 0xc05d6310.
kernel: Timecounter "tick" frequency 333000000 Hz
kernel: cpu0: Sun Microsystems UltraSparc-IIi Processor (333.00 MHz CPU)
kernel: Model: SUNW,Ultra-5_10
kernel: Initializing GEOMetry subsystem
kernel: nexus0: <OpenFirmware Nexus device>
kernel: pcib0: <U2P UPA-PCI bridge> on nexus0
kernel: pcib0: Sabre, impl 0, version 0, ign 0x7c0
kernel: DVMA map: 0xc0000000 to 0xc1ffffff
kernel: pci0: <PCI bus> on pcib0
kernel: pcib1: <APB PCI-PCI bridge> at device 1.0 on pci0
kernel: pci1: <PCI bus> on pcib1
kernel: ahc0: <Adaptec 29160N Ultra160 SCSI adapter> port 0x400-0x4ff mem 0x2000-0x2fff irq 16 at device 1.0 on pci1
kernel: aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
[SNIP]
kernel: Waiting 15 seconds for SCSI devices to settle
kernel: da0 at ahc0 bus 0 target 1 lun 0
kernel: da0: <IBM DDYS-T18350M SA5A> Fixed Direct Access SCSI-3 device
kernel: da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled
kernel: da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C)
- --
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
bra...@fokus.gmd.de, bra...@fokus.fhg.de
------------------------------
Date: Thu, 16 Jan 2003 13:44:26 +0100 (CET)
From: Hartmut Brandt <bra...@fokus.gmd.de>
Subject: sparc64/47143: OFW console does not implement ALT_BREAK_TO_DEBUGGER
>Number: 47143
>Category: sparc64
>Synopsis: OFW console does not implement ALT_BREAK_TO_DEBUGGER
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-sparc
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Thu Jan 16 04:50:03 PST 2003
>Closed-Date:
>Last-Modified:
>Originator: Hartmut Brandt
>Release: FreeBSD 5.0-CURRENT sparc64
>Organization:
FhI Fokus
>Environment:
System: FreeBSD catssrv.fokus.gmd.de 5.0-CURRENT FreeBSD 5.0-CURRENT #2: Thu Jan 16 13:19:01 CET 2003 h...@catssrv.fokus.gmd.de:/opt/obj/usr/src/sys/CATSSRV sparc64
>Description:
The kernel option ALT_BREAK_TO_DEBUGGER does not work with the open firmware
console on sparc (and probably other platforms that use ofw).
>How-To-Repeat:
Compile a kernel with 'options ALT_BREAK_TO_DEBUGGER' and 'options DDB',
reboot and try \r~^B. Observe, that the debugger is not called.
>Fix:
The following patch implements the flag in ofw_console.c.
Index: ofw_console.c
===================================================================
RCS file: /home/cvs/freebsd/src/sys/dev/ofw/ofw_console.c,v
retrieving revision 1.7
diff -c -r1.7 ofw_console.c
*** ofw_console.c 18 Nov 2002 06:19:12 -0000 1.7
- --- ofw_console.c 16 Jan 2003 12:39:41 -0000
***************
*** 28,33 ****
- --- 28,36 ----
"$FreeBSD: src/sys/dev/ofw/ofw_console.c,v 1.7 2002/11/18 06:19:12 jake Exp $";
#endif /* not lint */
+ #include "opt_ddb.h"
+ #include "opt_comconsole.h"
+
#include <sys/param.h>
#include <sys/kernel.h>
#include <sys/systm.h>
***************
*** 39,44 ****
- --- 42,49 ----
#include <dev/ofw/openfirm.h>
+ #include <ddb/ddb.h>
+
#define OFW_POLL_HZ 4
static d_open_t ofw_dev_open;
***************
*** 68,73 ****
- --- 73,82 ----
static struct callout_handle ofw_timeouthandle
= CALLOUT_HANDLE_INITIALIZER(&ofw_timeouthandle);
+ #if defined(DDB) && defined(ALT_BREAK_TO_DEBUGGER)
+ static int alt_break_state;
+ #endif
+
static void ofw_tty_start(struct tty *);
static int ofw_tty_param(struct tty *, struct termios *);
static void ofw_tty_stop(struct tty *, int);
***************
*** 295,300 ****
- --- 304,314 ----
}
}
+ #if defined(DDB) && defined(ALT_BREAK_TO_DEBUGGER)
+ if (db_alt_break(ch, &alt_break_state))
+ breakpoint();
+ #endif
+
return (ch);
}
***************
*** 304,309 ****
- --- 318,327 ----
unsigned char ch;
if (OF_read(stdin, &ch, 1) > 0) {
+ #if defined(DDB) && defined(ALT_BREAK_TO_DEBUGGER)
+ if (db_alt_break(ch, &alt_break_state))
+ breakpoint();
+ #endif
return (ch);
}
>Release-Note:
>Audit-Trail:
>Unformatted:
------------------------------
Date: Thu, 16 Jan 2003 21:36:55 +0100 (CET)
From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <grou...@free.fr>
Subject: Re: panic: trap: fast data access mmu miss
On Tue, 14 Jan 2003, Thomas Moestl wrote:
> On Tue, 2003/01/14 at 21:30:36 +0100, G=E9rard Roudier wrote:
[...]
> > > I think I've already ruled out most causes; I'm suspecting that
> > > malloc() might be failing due to massive use of M_NOWAIT in the
> > > related code.
> >
> > If less than 20K of memory is massive allocation, then your mail may we=
ll
> > come from twenty years ago IT age and I can only be dreaming at the
> > moment. :-)
> >
> > The driver fails during initialisation after having allocated less than
> > 20K in PAGE size chunk for the controller and probably less than 2 PAGE=
S
> > if PAGE size is large.
>
> I was not refering to sym alone. The IOMMU code itself also uses
> M_NOWAIT to allocate DVMA memory and resource descriptors, and it's
> not unlikely that previosly intialized drivers have used it and
> drained the pool. The last round of updates increased the number of
> allocations the IOMMU code does, hence this suspicion (it turns out
> to be rather unlikely after reading some more allocator code though :)
Thanks for the clarification.
I just have some general comments about: :)
Most (almost all) resources allocated at drivers/modules initialisation
are never freeed. As a result, these resources should be available at the
moment they are requested and waiting or not for availability will not add
any magic that can prevent from shortage, in my opinion.
Speaking about sym, it tries to recover from resource shortage after
initialisation and should succeed most of the time. I just don't want the
driver to allocate everything at initialisation since this can be hudge
wastage in average. And yes, the driver will also use NOWAIT option after
initialisation, since waiting for resources would either need complex
synchronisation or would break IO ordering requirements.
Note that we could allocate the needed resources and no more in SIMs if
FreeBSD/CAM provided the slave_alloc()/slave_configure()/slave_destroy()
semantic as in Linux 2.5. May-be Justin should consider this to be
implemented in CAM. :)
And on the other hand, SIMs could wait for resources during initialisation
if aggressive parallelism that may lead to resource shortage occurs on
kernel boot, since there is generally no ordering requirements during
initialisation step.
G=E9rard.
------------------------------
Date: Thu, 16 Jan 2003 21:17:28 +0100
From: Thomas Moestl <tmo...@gmx.net>
Subject: Re: assembler error in XFree86 snapshot
On Wed, 2003/01/15 at 23:24:48 -0800, Kris Kennaway wrote:
> I'm trying to compile anholt's XFree86 4.2.99 snapshot on sparc, and I
> get the following error message:
>
> cc -c -O -pipe -ansi -Dasm=__asm -Wall -Wpointer-arith -Wundef -I/usr/tmp/XFree86-4-libraries-devel/work/xc -I/usr/tmp/XFree86-4-libraries-devel/work/xc/exports/include -DCSRG_BASED -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -D_THREAD_SAFE -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI -DMALLOC_0_RETURNS_NULL XRes.c
> {standard input}: Assembler messages:
> {standard input}:667: Error: relocation overflow
> *** Error code 1
>
> line 667 of the .s file is:
>
> > .LL86:
> > umul %o0, 4294967295, %o0
This is a arguably a gcc bug. All (13-bit) immediate operands are
sign-extended, even those to instructions which operate on unsigned
values, so umul can handle a range of very small and a range of very
large operands. gcc correctly recognizes that it can use an immediate
here; however, it chooses to output it as an unsigned number and does
not sign-extended it from 32 to 64 bit.
All sign extensions for instructions are made to the full 64 bit
however (even if umul only happens to use 32 of those), so when the
assembler checks whether a value is representable as an immediate, it
will check that the 64-bit sign extension of the immediate creates
the desired value (in sparc64 mode), i.e. it doesn't ignore the upper
32 bits even if a particular instruction does not use them.
One solution is to generate negative literals for immediates if we
mean them to be sign-extended (which gcc does already for some other
instructions). The attached patch implements this, I'm not sure it
uses the best possible way to do this though, and it also needs a bit
more testing.
- Thomas
- --
Thomas Moestl <tmo...@gmx.net> http://www.tu-bs.de/~y0015675/
<t...@FreeBSD.org> http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
Index: config/sparc/sparc.c
===================================================================
RCS file: /ncvs/src/contrib/gcc/config/sparc/sparc.c,v
retrieving revision 1.1.1.9
diff -u -r1.1.1.9 sparc.c
- --- config/sparc/sparc.c 10 Oct 2002 04:40:04 -0000 1.1.1.9
+++ config/sparc/sparc.c 16 Jan 2003 18:09:06 -0000
@@ -6462,6 +6462,22 @@
output_address (XEXP (x, 0));
return;
+ case 's':
+ {
+ /* Print a sign-extended 32-bit value. */
+ HOST_WIDE_INT xi;
+ int i;
+ if (GET_CODE(x) == CONST_INT)
+ xi = INTVAL (x);
+ else if (GET_CODE(x) == CONST_DOUBLE)
+ xi = CONST_DOUBLE_LOW (x);
+ else
+ output_operand_lossage ("invalid %%s operand");
+ i = trunc_int_for_mode (xi, SImode);
+ fprintf (file, "%d", i);
+ return;
+ }
+
case 0:
/* Do nothing special. */
break;
Index: config/sparc/sparc.md
===================================================================
RCS file: /ncvs/src/contrib/gcc/config/sparc/sparc.md,v
retrieving revision 1.1.1.8
diff -u -r1.1.1.8 sparc.md
- --- config/sparc/sparc.md 10 Oct 2002 04:40:08 -0000 1.1.1.8
+++ config/sparc/sparc.md 16 Jan 2003 17:09:36 -0000
@@ -6120,7 +6120,7 @@
"TARGET_HARD_MUL32"
"*
{
- - return TARGET_SPARCLET ? \"umuld\\t%1, %2, %L0\" : \"umul\\t%1, %2, %L0\\n\\trd\\t%%y, %H0\";
+ return TARGET_SPARCLET ? \"umuld\\t%1, %s2, %L0\" : \"umul\\t%1, %s2, %L0\\n\\trd\\t%%y, %H0\";
}"
[(set (attr "type")
(if_then_else (eq_attr "isa" "sparclet")
@@ -6134,7 +6134,7 @@
(mult:DI (zero_extend:DI (match_operand:SI 1 "register_operand" "r"))
(match_operand:SI 2 "uns_small_int" "")))]
"TARGET_DEPRECATED_V8_INSNS && TARGET_ARCH64"
- - "umul\\t%1, %2, %0"
+ "umul\\t%1, %s2, %0"
[(set_attr "type" "imul")])
;; XXX
@@ -6145,8 +6145,8 @@
(clobber (match_scratch:SI 3 "=X,h"))]
"TARGET_V8PLUS"
"@
- - umul\\t%1, %2, %L0\\n\\tsrlx\\t%L0, 32, %H0
- - umul\\t%1, %2, %3\\n\\tsrlx\\t%3, 32, %H0\\n\\tmov\\t%3, %L0"
+ umul\\t%1, %s2, %L0\\n\\tsrlx\\t%L0, 32, %H0
+ umul\\t%1, %s2, %3\\n\\tsrlx\\t%3, 32, %H0\\n\\tmov\\t%3, %L0"
[(set_attr "type" "multi")
(set_attr "length" "2,3")])
------------------------------
Date: Thu, 16 Jan 2003 16:14:44 -0500
From: Garance A Drosihn <dro...@rpi.edu>
Subject: portupgrade on sparc64
Now that a cvsup binary is available, I'm trying to compile more
ports on my sparc64 test machine. While I'm able to compile ruby
and portupgrade, the portupgrade program doesn't seem to be working
right for me. I keep getting results such as:
(22) /usr/local/sbin/portinstall -Rr trafshow
** No such installed package nor such port called 'trafshow' is found.
Do others see the same behavior with portupgrade under sparc64?
- --
Garance Alistair Drosehn = g...@gilead.netel.rpi.edu
Senior Systems Programmer or g...@freebsd.org
Rensselaer Polytechnic Institute or dro...@rpi.edu
------------------------------
Date: Thu, 16 Jan 2003 13:17:19 -0800
From: Kris Kennaway <kr...@obsecurity.org>
Subject: Re: portupgrade on sparc64
- --jI8keyz6grp/JLjh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Jan 16, 2003 at 04:14:44PM -0500, Garance A Drosihn wrote:
> Now that a cvsup binary is available, I'm trying to compile more
> ports on my sparc64 test machine. While I'm able to compile ruby
> and portupgrade, the portupgrade program doesn't seem to be working
> right for me. I keep getting results such as:
>=20
> (22) /usr/local/sbin/portinstall -Rr trafshow
> ** No such installed package nor such port called 'trafshow' is found.
>=20
> Do others see the same behavior with portupgrade under sparc64?
Are you using ruby 1.6 or 1.8? The former doesn't work on sparc64 (et
al), and the default was recently changed to 1.8.
Kris
- --jI8keyz6grp/JLjh
Content-Type: application/pgp-signature
Content-Disposition: inline
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE+JyFeWry0BWjoQKURArIMAKC1n2+xqJjKkkm3T0i7lHwIJzu1BwCg1XFb
bk4TLClDZKMmUg48TF/aURU=
=PmFV
- -----END PGP SIGNATURE-----
- --jI8keyz6grp/JLjh--
------------------------------
Date: Thu, 16 Jan 2003 17:32:29 -0500
From: Garance A Drosihn <dro...@rpi.edu>
Subject: Re: portupgrade on sparc64
At 1:17 PM -0800 1/16/03, Kris Kennaway wrote:
>On Thu, Jan 16, 2003 at 04:14:44PM -0500, Garance A Drosihn wrote:
> > While I'm able to compile ruby and portupgrade, the portupgrade
> > program doesn't seem to be working right for me.
>
>Are you using ruby 1.6 or 1.8? The former doesn't work on sparc64
>(et al), and the default was recently changed to 1.8.
"Both", sort of.
I was starting with a fresh system, so I did a
cd /usr/ports/lang/ruby
make && make install && make clean
cd /usr/ports/sysutils/portupgrade
make && make install && make clean
The first set did install 1.6, but it's there as ruby16. The
second set did not find /usr/local/bin/ruby, so it first built
ruby-devel.
So after all that, ruby -v tells me:
ruby 1.8.0 (2003-01-11) [sparc64-freebsd5]
I just deinstalled ruby, and I still have the problem.
I deinstalled portupgrade and reinstalled it, and still have
the problem. It might be some other things I'm doing. I'll
try a few other changes.
- --
Garance Alistair Drosehn = g...@gilead.netel.rpi.edu
Senior Systems Programmer or g...@freebsd.org
Rensselaer Polytechnic Institute or dro...@rpi.edu
------------------------------
Date: Thu, 16 Jan 2003 14:37:51 -0800
From: Kris Kennaway <kr...@obsecurity.org>
Subject: Re: portupgrade on sparc64
- --T4sUOijqQbZv57TR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Thu, Jan 16, 2003 at 05:32:29PM -0500, Garance A Drosihn wrote:
> I just deinstalled ruby, and I still have the problem.
> I deinstalled portupgrade and reinstalled it, and still have
> the problem. It might be some other things I'm doing. I'll
> try a few other changes.
Talking to knu once you've done this might be the best idea.
Kris
- --T4sUOijqQbZv57TR
Content-Type: application/pgp-signature
Content-Disposition: inline
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE+JzQ+Wry0BWjoQKURAifSAJ9QevakWGuhe6OEoUd69CO/93jAgQCg/g0l
sxO7u0Tx0yJcBmcd/DeAseE=
=6XYj
- -----END PGP SIGNATURE-----
- --T4sUOijqQbZv57TR--
------------------------------
Date: Thu, 16 Jan 2003 15:11:03 -0800
From: Brooks Davis <bro...@one-eyed-alien.net>
Subject: Ultra 10 won't boot after install
- --tThc/1wpZn/ma/RB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
I've got an ultra 10 that I'm trying to get up and running with 5.0.
I've triedthe RC1 mini ISO as well as both the mini and regular RC3
ISOs. I make it through install sucessfully (though it failed to sync
103 buffers this last time), but when I try to boot from the ok prompt I
get the output at the end of this message. I'm stumped. Any
suggestions of things to check or try would be helpful.
Thanks,
Brooks
ok boot
Resetting ...=20
Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 300MHz), No Keyboard
OpenBoot 3.11, 128 MB memory installed, Serial #9478304.
Ethernet address 8:0:20:90:a0:a0, Host ID: 8090a0a0.
Rebooting with command: boot =20
Boot device: disk:b File and args:=20
Evaluating: boot
Can't open boot device
Boot device: disk:b File and args:=20
Evaluating: boot
Can't open boot device
ok boot disk:a
Boot device: /pci@1f,0/pci@1,1/ide@3/disk@0,0:a File and args:=20
Can't open boot device
ok boot disk
Boot device: /pci@1f,0/pci@1,1/ide@3/disk@0,0 File and args:=20
Can't open boot device
ok=20
- --tThc/1wpZn/ma/RB
Content-Type: application/pgp-signature
Content-Disposition: inline
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE+JzwEXY6L6fI4GtQRAvPNAJ4+mVwAAWafkJgVOfGlJQQdAGZx+gCfdHBn
t91wv/U5yVyDBtzXRRqCAxI=
=PjbI
- -----END PGP SIGNATURE-----
- --tThc/1wpZn/ma/RB--
------------------------------
Date: Thu, 16 Jan 2003 15:47:02 -0800
From: Kris Kennaway <kr...@obsecurity.org>
Subject: XFree86 and syscons support
- --qDbXVdCdHGoSgWSk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
I managed to get XFree86 to compile on sparc64, however it fails to
run due to the lack of console support on FreeBSD/sparc64. Is anyone
working on this?
Kris
- --qDbXVdCdHGoSgWSk
Content-Type: application/pgp-signature
Content-Disposition: inline
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE+J0R1Wry0BWjoQKURAvyxAJ9MRrvLS5nAaDbY4afXcQMIziIQhACfVd/W
d6DWUXItOBCkvPk2/BkT8CQ=
=wz8H
- -----END PGP SIGNATURE-----
- --qDbXVdCdHGoSgWSk--
------------------------------
Date: Thu, 16 Jan 2003 18:16:00 -0800 (PST)
From: John Polstra <j...@polstra.com>
Subject: Re: Sparc64 floating point questions
In article <2003011502...@crow.dom2ip.de>,
Thomas Moestl <tmo...@gmx.net> wrote:
>
> Oh, I should have mentioned that %fprs is a bit special; the kernel
> uses the FEF bit to test whether floating point support is enabled for
> the process, and will only save the state across context switches in
> that case. It will also lazily restore the context, i.e. it will
> disable the FEF bit and reload the registers only when the process
> uses floating point operations for the next time (which triggers an
> exception in that case).
> That means that %fprs must be restored first, otherwise this might
> clear FEF and cause stale values to be reloaded later.
> In fact, you do not need to save it at all; the only other bits in
> that register are the DU (upper fp register file half dirty) and DL
> (lower half dirty) bits, which are automatically maintained.
> For performance, it would probably be best to always just set the FEF
> bit before reloading the other registers (this is not required
> though), like:
>
> wr %g0, FPRS_FEF, %fprs
I'm a little bit confused about this. Won't the instruction above
clear the DU and DL bits? And isn't that a bad thing to do? It
seems like the state maintained in those bits is per-process rather
than per-thread.
John
- --
John Polstra
John D. Polstra & Co., Inc. Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
------------------------------
Date: Fri, 17 Jan 2003 14:30:55 +0100
From: Thomas Moestl <tmo...@gmx.net>
Subject: Re: Sparc64 floating point questions
On Thu, 2003/01/16 at 18:16:00 -0800, John Polstra wrote:
> In article <2003011502...@crow.dom2ip.de>,
> Thomas Moestl <tmo...@gmx.net> wrote:
> >
> > Oh, I should have mentioned that %fprs is a bit special; the kernel
> > uses the FEF bit to test whether floating point support is enabled for
> > the process, and will only save the state across context switches in
> > that case. It will also lazily restore the context, i.e. it will
> > disable the FEF bit and reload the registers only when the process
> > uses floating point operations for the next time (which triggers an
> > exception in that case).
> > That means that %fprs must be restored first, otherwise this might
> > clear FEF and cause stale values to be reloaded later.
> > In fact, you do not need to save it at all; the only other bits in
> > that register are the DU (upper fp register file half dirty) and DL
> > (lower half dirty) bits, which are automatically maintained.
> > For performance, it would probably be best to always just set the FEF
> > bit before reloading the other registers (this is not required
> > though), like:
> >
> > wr %g0, FPRS_FEF, %fprs
>
> I'm a little bit confused about this. Won't the instruction above
> clear the DU and DL bits?
Yes.
> And isn't that a bad thing to do? It seems like the state
> maintained in those bits is per-process rather than per-thread.
Since you are going to write to all fp registers anyway, both will get
set automatically. These bits are not used by the hardware and exist
only to allow software to skip saving unused registers. The kernel
does not currently make use of them. However, if it (or a userland
thread manager) did, and a switch was to take place before all
registers were restored, the missing dirty bits would indicate that
the yet unaccessed parts of the registers need not be saved, which
does not matter at all since their old values will not be used any
more.
The kernel itself does never clear DU and DL, so it is possible to use
them in user land to skip unnecessary saving (and unneccesary
reloading if one of the halves was not accessed at all); in this case
it would be necessary to clear the bits explicitely after reloading.
Both will however get set currently each time the fp registers are
restored after a (kernel) context switch, so this does probably not
really pay off. Also, things would break if the kernel started to use
them for saving decisions.
Setting FEF explicitely before reloading makes sure that a fp state
that was saved on a previous context switch and that might not have
been restored yet will not be restored due to the following register
accesses. Since all registers will be overwritten anyway, this would
just eat cycles unnecessarily.
- Thomas
- --
Thomas Moestl <tmo...@gmx.net> http://www.tu-bs.de/~y0015675/
<t...@FreeBSD.org> http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
------------------------------
End of freebsd-sparc-digest V5 #218
***********************************
To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-sparc-digest in the body of the message