Sun-Spots-Request@RICE.EDU.UUCP (07/25/86)
SUN-SPOTS DIGEST Friday, 25 July 1986 Volume 4 : Issue 23
Today's Topics:
Wrong compilation of OP= operators
RCS on Suns
RCS on SUNs and vt100 emulator
Graphics editor && vt100 emulator
revarp creates garbage route
tftpboot problems
"arp problem" really /etc/hosts botch
SUNs Tie for First in World Computer Chess Championships
SuperEagle, Xylogics 451, Sun 2 with Release 3?
Adding disks/tape hardware to sun3?
Help with Sun 2/120 grafix?
Suntools and HUP signal oddity?
New fonts for Laser Writer?
------------------------------------------------------------------------
Date: Mon, 21 Jul 86 22:11:07 CDT
From: David Chase <rbbb@titan.rice.edu>
Subject: Wrong compilation of OP= operators
Mail about this is also cropping up on info-c, but I was made aware of
this about a week ago by Scott Comer (also at Rice). This bug is not
confined to Suns; it has also been observed on Vaxes running BSD Unix and
on a Pyramid.
In many situations, the two statements
1) a = a OP b;
and
2) a OP= b;
are NOT equivalent. For example, if "a" and "b" are floats, 1) performs
the addition in double precision (as it should) and 2) does it in single
precision. This problem shows up in other type conversions; I haven't
really explored it yet, but I expect a much fuller discussion soon on
info-c. (Of course, on info-c one can expect a full discussion of
EVERYTHING. The wheat-to-chaff ratio is much much lower). I leave it to
a compiler guru at Sun to discover all the instances of this bug.
In case you are wondering, K&R says (p. 191):
The behavior of an expression of the form E1 op= E2 may be inferred by
taking it as equivalent to E1 = E1 op (E2); however, E1 is evaluated
only once.
David
-----------------------------
Date: Sat, 19 Jul 86 01:26:20 PDT
From: guy@SUN.COM (Guy Harris)
Subject: RCS on Suns
> Has anyone out there been successful in geting rcs to run on a Sun?
> We're using Sun 2's running Version 3.0 and would like to use rcs to
> manage our source code. Unfortunately, the port seems to involve much
> more than just moving the sources and remaking, as the rcs code seems
> to be machine dependent.
> Have any of you done this successfully?
Yes. The RCS code is "machine-dependent" in that
1) it assumes pointers and integers are the same size (yes,
*another* in a long series of such programs); this isn't
a problem on Suns, but is a problem on a number of other
machines
2) it assumes that you really don't have to be all that
careful to avoid dereferencing null pointers
These aren't really machine dependencies, they're just incorrect C. The
only "machine-dependency" in the RCS code is the bit that determines the
default comment character for assembly-language files.
I had to get RCS running on a machine that had 16-bit "int"s, 32 bit
pointers, and no access to location 0 in user mode; I have fixes to the
4.2BSD version of RCS to do this (the resulting version can also be
configured to run on System III and System V as well).
Of course, RCS also requires a modified version of "diff" and "diff3".
You're on your own there; the 4.2BSD version of RCS comes with modified
versions of the 4.1BSD "diff" and "diff3", and I no longer have what changes
were needed (if any) to make them acknowledge that null pointers are not to
be dereferenced. I remember them having a number of type-correctness
problems with pointers and integers (which cause things to blow up if
pointers and integers aren't the same size - or if you have a 68K machine
that puts the return value of integer-valued functions into D0 and of
pointer-valued functions into A0), but I don't think there are any null
pointer dereferences.
The 4.3BSD versions of "diff" and "diff3" have the requisite features as
well, so no modifications to "diff" or "diff3" are required if you have
those versions of "diff".
FYI, the 3.0 "make", being based on the System V "make", knows about SCCS
(and it has been taught about the SCCS subdirectory convention used by the
"sccs" front end, so it can use "SCCS/s.foo.c" to make "foo.c" or "foo.o"),
and can get the Makefile from SCCS. It does not know about RCS; you may be
able to teach it, but it won't be able to automatically "co" the "Makefile".
Of course, if you have RCS source, you have a UNIX source license (since you
have the source to "rdiff" and "rdiff3", both based on AT&T licensed code),
so you may have enough source to whip up a version of "make" that can handle
RCS as well.
-----------------------------
Date: Wed, 23 Jul 86 10:36:14 cdt
From: franklin%pp@mcc.arpa (Maurice T. Franklin)
Subject: RCS on SUNs and vt100 emulator
In article <1986.07.18.11.24.52.965.05906@iapetus.rice> Sun-Spots@Rice.edu writes:
>-----------------------------
>
>Date: Fri, 11 Jul 86 15:53:45 EDT
>From: penny@CCA.CCA.COM (Penny Rheingans)
>Subject: RCS on Suns
>
>Has anyone out there been successful in geting rcs to run on a Sun?
>We're using Sun 2's running Version 3.0 and would like to use rcs to
>manage our source code. Unfortunately, the port seems to involve much
>more than just moving the sources and remaking, as the rcs code seems
>to be machine dependent.
>
>Have any of you done this successfully?
>
>Penny Rheingans
>
>penny @ cca.cca.com
>
We have installed rcs on Sun-2's running Version 2.0 with success. Only a
minor change in the sources was necessary. I used Sequent sources, but
I'm sure Vax sources would work with similar fixes. If anybody wants the
fixes, let me know.
However, Sun-3's, running Version 3.0, are another story. Has anybody out
there succeeded at this?? I have the same sources that I got to work on
a Sun-2 on the Sun-3. But, when you run 'ci' and it runs 'rdiff', rdiff
goes into an infinite loop. I have isolated the loop to a for loop in
diffreg.c, if anybody's interested. I tried the Sun-2 binary of rdiff on
the 3 and still got an infinite loop. Thus, the bug is not in the Sun-3
compiler, but in the kernal (I think).
>-----------------------------
>
>Date: Mon, 14 Jul 86 22:40 EDT
>From: HUDGENS%FSU.MFENET@LLL-MFE.ARPA
>Subject: vt100 emulator
>
> Are you aware of any information about the availability of a
>'vt100-window' for a Sun workstation, which correctly emulates the
>characteristics of a vt100? We currently do a lot of work on a Vax from
>a Sun-2, and must edit in line mode, with the terminal set as 'unknown'.
>We have two choices: one is to develop a 'vt100-window' for the Sun, and
>the other is to find some software for the VAX that will emulate the Sun.
> Any responses would be appreciated.
> Jim Hudgens
>
A vt100tool has just recently been posted to mod.sources. I haven't tried
it yet, but I expect it will fit your bill.
My only question is: If you have Suns, then you must have a termcap for type
'sun' in your Sun's /etc/termcap. If you simply copy the sun entry to your
Vax's /etc/termcap and specify TERM = sun in your .login, then that should
do it. (Note, however, that you can't change the size of a sun window from
the default size if you're going to use it for rlogins.)
Maurice T. Franklin, System Administration
Parallel Processing, MCC
ARPA Internet: franklin@mcc.arpa
UUCP: {gatech,ihnp4,seismo,ucbvax}!sally!im4u!milano!mcc-pp!franklin
-----------------------------
Date: Sun, 20 Jul 86 19:23:33 PDT
From: dcmartin@ingres.berkeley.edu (David C. Martin)
Subject: graphics editor && vt100 emulator
Well, by the time this letter gets out most of you will have seen the
posting in mod.sources about vt100tool. If you haven't seen it check
your back postings.
As for a Graphics diagram editor, Gremlin is available from UC Berkeley
on their CAD Tools Distribution tape. You have to have a AT&T DMD license
to get the fonts. It can be used to generate diagrams (e.g. schematics)
which can be merged into troff documents.
dcm
-----
David C. Martin
-----
University of California at Berkeley
College of Engineering
Electronics Research Lab
434 Evans Hall
Berkeley, CA 94720
-----
arpa: dcmartin@ingres.Berkeley.EDU home: 2441 Haste St #37
uucp: {ihnp4,decvax}!ucbvax!dcmartin Berkeley, CA 94704
at&t: 415/642-3560 (O) - 415/843-6470 (H)
-----------------------------
Date: Tue, 22 Jul 86 12:54:29 PDT
From: John Bruner <jdb@s1-c.arpa>
Subject: revarp creates garbage route
On a discless client it is necessary for the kernel to configure the
Ethernet interface in order to start up the 'nd' pseudo-device
driver (for the root and swap devices). In order to configure the
interface it is necessary to determine its Internet address. This
is accomplished by broadcasting a reverse ARP request and waiting
for a response containing the client's address.
In order to initialize the interface so that the revarp broadcast
can be sent, the interface is assigned a temporary address whose
"network" number is INADDR_ANY (0) and whose host number is derived
from the machine ID. When the real Internet address is determined
the address of the interface is changed.
Whenever an interface's address is changed, an network route is
installed. Thus, when the temporary address is assigned, a route
is created. Since the "network" number is zero, this turns out to
be a default route.
Normally, when an interface address is changed, the old route (based
upon the old address) will be removed, the address will be changed,
and a new route will be installed. However, revarp_myaddr() [in
"netinet/if_ether.c"] uses "ifp->if_addr" (indirectly through the
pointer "sin") to hold the temporary and final interface addresses
which it passes as arguments to if_setaddr(). By doing so, it
clobbers the current (temporary) address in the "ifnet" structure
before it calls if_setaddr() to establish the new one. Thus, instead
of removing the garbage route associated with the temporary address,
if_setaddr() [actually set_if_addr()] tries to remove a (nonexistant)
route corresponding to the "real" address. (It subsequently installs
the correct network route.)
The left-over garbage route, since it is a default route, interferes
with other default routes. In our environment, all non-local traffic
is routed through two default gateways (VAXes connected to IMPs).
The garbage route causes all non-local traffic to be misdirected
to the bit bucket. [Perhaps "routed" deals with this? We don't
use "routed" because our routes are very simple and it is a pig.]
I fixed this problem in our kernel by changing the pointer "sin"
in revarp_myaddr() to a structure and initialized sin.sin_family
to AF_INET. I changed all references to sin->sin_addr to
sin.sin_addr and changed (struct sockaddr *)sin to
(struct sockaddr *)&sin. [License restrictions prevent me from
including the code here.]
Prior to our acquisition of kernel sources, I "fixed" this by
executing the file "/usr/etc/rc.route" from "rc.local" after
"/usr" is mounted. That file contains:
> #! /bin/sh
> #
> # Set up the default routing. Get rid of any existing default routes
> # which use network 0. This is necessary because of a bug in Sun 3.0
> # that sets up a garbage default route (which prevents legitimate
> # default routes from working).
> #
> PATH=/bin:/usr/bin:/usr/ucb:/etc:/usr/etc export PATH
> SEDCMD='/^\(default\) *\(0[^ ]*\).*/s;;/usr/etc/route delete \1 \2;p'
>
> netstat -r -n | sed -n -e "$SEDCMD" | sh 2>&1
>
> route add default 128.15.0.2 1
> route add default 128.15.0.3 2
--
John Bruner (S-1 Project, Lawrence Livermore National Laboratory)
MILNET: jdb@mordor [jdb@s1-c.ARPA] (415) 422-0758
UUCP: ...!ucbvax!decwrl!mordor!jdb ...!seismo!mordor!jdb
-----------------------------
Date: 23 Jul 86 15:08:11 EDT
From: Charles <MCGREW@RED.RUTGERS.EDU>
Subject: tftpboot problems
Regarding the 'tftpboot' problem with clients, I think the problem
is that the client that's booting doesn't have itself in its own host
table. If the client's name isn't in its local host table (the one
that it keeps in its own /etc/hosts), then when booting (before yp is
running), the 'hostname' call in the ifconfig will return the correct
hostname, ifconfig will look it up in the /etc/hosts table, not find
it, and ifconfig will assume its an address, with the noted chaos.
We've found here that putting the host name in its own host table
does the trick. [For those who don't manage a file server, this
sounds like base stupidity to not have the host table in the client's
host table. However, with the 'copy_client' utility, its actually a
natural mistake to make -- having made the mistake myself.]
Charles
-------
-----------------------------
Date: Sat, 19 Jul 86 11:40:21 PDT
From: glenn@SUN.COM (Glenn C. Skinner)
Subject: "arp problem" really /etc/hosts botch
With respect to Roy Smith's (supposed) arp problems, dredge@zotz.STANFORD.EDU
(Michael Eldredge) writes:
> ...
> The problem is in 'ifconfig'. Sun's version seems to have a really bad
> heuristic for deciding if a word is an ether address, an ip address or
> a hostname. The three are very different, and very easy to tell apart:
> ether: 8:0:20:1:ff:f5
> ip: 36.2.0.81
> host: bbc
>
> Certainly if you look at our hostnames, it is obvious where the problem
> lies. The only host with problems is 'bbc'. The first character is
> (looks like) a hex digit.
>
> ifconfig is usually used to set the ip address, but if given an ether
> address, it will override the kernel's idea of what the ether address
> is. So in our case: 'bbc' was taken to be 'bbc:0:0:0:0:0'. It
> would send out TFTP request with a return ether of 'bc:0:0:0:0:0'
> (0xbbc gets truncated to the low order byte of 0xbc'), the server
> sends it back, but of course the hardware is listening on its
> real ether address and never sees the responce.
>
> The fix, until sun fixes it is (well a fix is, or my fix is) to make sure
> that 'ifconfig' never gets confused. This can be done by always giving
> it the ip address. To automate this, I have changed '/etc/rc.boot' to:
>
> #
> # @(#)rc.boot 1.1 85/12/18 SMI
> #
> # Executed once at boot time
> #
> hostname=bbc
>add: ipadder=`ypmatch $hostname hosts | sed 's/[ ][ ]*.*$//'
> > /etc/mtab
> /etc/mount -f /
> /etc/mount /pub
> /bin/hostname $hostname
>mod: /etc/ifconfig ec0 $ipadder -trailers up
>mod: /etc/ifconfig ie0 $ipadder -trailers up
>mod: /etc/ifconfig le0 $ipadder -trailers up
> /etc/umount -at nfs
> sync
>
> Michael Eldredge
> dredge@zotz.stanford.edu
This explanation starts to zero in on the true cause of the problem, but
doesn't quite hit it. It also contains a slight misconception about the
way ifconfig operates.
The true explanation (excerpted from my reply to Roy Smith) is as follows.
It sounds very much like you don't have the affected machines'
/etc/hosts files set up correctly.
At boot time, yp isn't yet up and running. This means that
host name lookups have no recourse but to use the /etc/hosts
file. The first time this becomes important is when /etc/ifconfig
runs to set up the Ethernet interface. The command is of the
form:
/etc/ifconfig ie0 $hostname
Since the hostname here is (e.g.) "alanine", the command is
effectively
/etc/ifconfig ie0 alanine
Ifconfig proceeds to try to turn "alanine" into an IP address by
looking it up in /etc/hosts. This lookup fails, which causes
ifconfig to fall back to its last resort -- interpreting its
argument string as a raw Ethernet address. Due to some rather
shoddy coding in ifconfig (which I've fixed for future releases),
the leading 'a' in "alanine" turns into the Ethernet address
a:0:0:0:0:0. After all, 'a' is a hex digit...
Thus, the observed symptoms. The cure is to make sure that each
machine has an entry for itself in its /etc/hosts file. As you
can probably imagine, this bug had us tearing our hair out the
first time it surfaced (on an internal machine named "cetra").
A bit more explanation about ifconfig. It tries first to interpret its
argument as a hostname, then as an IP address, and finally, if all else
fails, as an Ethernet address. Thus, the crux of the problem is determining
what kind of an address the supplied argument really is. The "really bad
heuristic" and "rather shoddy coding" referred to above come straight from
the 4.2bsd version of ifconfig. The problem is a sscanf call that doesn't
care how much of its subject string it matches. The fix I referred to is
simply to insist that the purported Ethernet address occupy the entire
argument string, not the initial prefix that the old scanf call was willing
to match.
The patch to /etc/boot suggested above is unnecessary; the right way to
avoid the problem is to make sure /etc/hosts is correct. (Note that it's
unnecessary to list all hosts in it; only the loopback entry and the entry
for the host itself are required.) In fact, it's hard to see how the patch
could work, since ypmatch can't be expected to work until the domain name
has been set and ypbind run, neither of which occur until /etc/rc.local
runs (after rc.boot has completed).
-- Glenn Skinner, SMI
-----------------------------
Date: Thu, 17 Jul 86 14:20:09 pdt
From: ubc-vision!alberta!jonathan@uw-beaver.arpa
Subject: SUNs Tie for First in World Computer Chess Championships
20 Suns Tie for First
in World Computer Chess Championships
The program Sun Phoenix, running on 20 Sun 3/75s, fin-
ished in a 4-way tie for first place in the World Computer
Chess Championships in Cologne, West Germany, June 11-16.
The other three winners were 1983-1986 World Champion Cray
Blitz (running on a Cray XMP-48), Hitech (64 specially
designed VLSI chips front-ended by a Sun), and Bebe (spe-
cially designed bit-slice hardware). There were too many
programs for a playoff, so a tiebreaking system was used
(adding the scores obtained by each program's opponents).
On this basis, Cray Blitz repeated as champion.
The chess program Phoenix is authored by Jonathan
Schaeffer and Marius Olafsson from the University of Alberta
in Edmonton, Canada. The program has performed well in pre-
vious computer chess tournaments, but has always suffered
from lack of computing horsepower. For the tournament, SMI
agreed to make available 20 Suns 3/75s at their Mountain
View offices. The increase in computing resourses allowed
Phoenix to have the best result in its 5 year career.
Phoenix is actually 2 programs. Ten computers are used
to play positional chess, typically being able to search
ahead a minimum of 7 half moves (one move by one player) in
a position. The other 10 are used to look for tactical win-
ning and losing lines of play, usually searching an extra 2
half moves beyond the positional program. Each program gets
a 6-fold speedup using 10 computers compared to the single
processor case.
The processes communicate using the Virtual Tree
Machine (VTM) software (an old version is available on the
Sun Users Group Tape). VTM provides high-level routines for
handling connection establishment, connection initializa-
tion, exchange of messages, interrupt handling, as well as
information on the configuration and layout of the virtual
machine being used.
The next world championship is not until 1989. Perhaps
by then we will have better algorithms for using many more
Suns profitably.
-----------------------------
Date: Fri, 18 Jul 86 11:47:48 GMT
From: Paul Cooper <mcvax!stl!pac@seismo.CSS.GOV>
Subject: SuperEagle, Xylogics 451, Sun 2 with Release 3?
Earlier this year there was some discussion on the net concerning
attaching a super eagle and a Xylogics 451 controller to a Sun 2. We
have now got to the point were we need a big disk and are considering
this option. I'd like to hear of anyone's experiences since then and
any problems that release 3 has caused. Finally what do we need to
know in order to install the 451 (eg. switch settings, configuration,
etc.)?
--
-- Paul Cooper (...!mcvax!ukc!stc!stl!pac)
(pac@stl.stc.co.uk)
-----------------------------
Date: Mon, 21 Jul 86 10:48:18 edt
From: savax!dove@dspvax.MIT.EDU (dove)
Subject: Adding disks/tape hardware to sun3?
I am interested in buying basic sun3's and adding disk and tape from
third party vendors. Please send me your experiences with this (via mail).
Especially with respect to hardware/software integration and
maintenance/support issues.
-----------------------------
Date: Mon, 21 Jul 86 14:09:39 gmt
From: Maintenance Crew <maint%cstvax.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Subject: Help with Sun 2/120 grafix?
Here at Edinburgh University we have a Sun 2/120 with the colour
grafix controller. To this we have a Mitsibushi C3479 monitor connected.
The problem we're having is getting them to sync together. The
specification for the Mitsibushi gives a horizontal scan freq of 15.5-24kHz
now the Suns sync signal from what I've seen on a scope is about 15.3kHz.
I have a technical manual for the Mitsibushi and have been playing around
with various values of resistors in the horizontal deflection circuit to try
and alter the timing, but with no joy so far!! Is there anybody out there
who has had similar problems? or can you reccomend another suitable Monitor.
Thanks in advance.
Please e-mail me at above address.
Or if you can give us a ring (+44 31 667 1081 ext2787)
Cheers Mike and the Crew.
-----------------------------
Date: Mon, 21 Jul 86 21:52:18 CDT
From: David Chase <rbbb@titan.rice.edu>
Subject: Suntools and HUP signal oddity?
I'm not really sure what is happening here, but I don't think it is right.
I'll just relate what happened and some gullible soul out there can
recreate this for themselves.
(While running release 3.0 on a Sun 3) I wanted to shut down Suntools and
log out in a hurry (i.e, type a command and leave, and let the computer do
the rote work). So, I killed my root csh process (the one attached to the
console) with a HUP signal. If it matters, I did this in the CONSOLE
window. I saw a little message about resetting the pgrp, the window went
away, and the "login: " prompt appeared. Of course, nothing I typed did
anything, until I moved the mouse (yes, it was still moving) over to
another window (yes, it was still open), and typed in it. Eventually, I
typed "su" and a password, and rebooted the machine, but before I did that
I opened up the clock and generally discovered that many things still
seemed to work.
Now, I think what SHOULD have happened is that all that stuff should have
been blown away and the console made ready for someone else to login. I
suppose that someone can trot out the Guilt Squad to tell me that what I
did was highly irregular and completely exceptional, but you CAN catch a
HUP signal and do something sensible. (I just had to mention the Guilt
Squad. They are still very much alive. Does anyone else remember W.
Kahan's IEEE floating point talks, and how it is all really Seymour Cray's
fault?)
David
-----------------------------
Date: Wed, 23 Jul 86 16:05:47 SET
From: FHCAA03%BLEKUL11.BITNET@WISCVM.ARPA
Subject: New fonts for Laser Writer?
Does anyone have experience in implementing new fonts for the Sun Laser
Writer?
There exist in /usr/lib/font a number of font definitions for use by
troff, but they cannot be used with ptroff or pscat : these need the
corresponding conversion tables in /usr/local/lib/lw/troff.font/*.ct .
The only conversion tables we have are the 'Times' and 'Helvetica' ones
(as supplied with the PostScript software).
I would like to know if somebody has written definitions for other fonts
(.afm and/or .map files) and if they are willing to send them over
the network. Any comments/suggestions/problems in this area are also
welcome.
Please reply to the Bitnet address:
FHCAA03@BLEKUL11.BITNET
Vital Debroey
K. U. L. , Chem. Eng. Dept.
de Croylaan 2
B - 3030 Heverlee (Belgium)
-----------------------------
End of SUN-Spots Digest
***********************