Sun-Spots Digest, v6n196
William LeFebvre
Sun-Spots-Request at RICE.EDU
Thu Aug 25 03:58:56 AEST 1988
SUN-SPOTS DIGEST Tuesday, 23 August 1988 Volume 6 : Issue 196
Today's Topics:
Re: SIGIOT?
Re: Format of a ".o" file
Other network mailing lists and marginal topics
Minor changes to contool, this time for version 1.1
A good word for PC-NFS
Speeding up dumps over the network
7053 performance - observations
SunOS 4.r0 and SCSI disks on a 3/60
compiler error: out of string space
Need help with SunOS4.0 tape driver
Need working printcap entries
slip on SunOS4.0?
Interleaf macintosh <=====> sun?
Send contributions to: sun-spots at rice.edu
Send subscription add/delete requests to: sun-spots-request at rice.edu
Bitnet readers can subscribe directly with the CMS command:
TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name
Recent backissues are available via anonymous FTP from "titan.rice.edu".
For volume X, issue Y, "get sun-spots/vXnY". They are also accessible
through the archive server: mail the request "send sun-spots vXnY" to
"archive-server at rice.edu" or mail the word "help" to the same address
for more information.
----------------------------------------------------------------------
Date: Fri, 19 Aug 88 09:13:26 EDT
From: csrobe at work1.icase.edu (Charles S. [Chip] Roberson)
Subject: Re: SIGIOT?
Allan Adler asks how he could see a SIGIOT on a Sun 3 if Sun says it is
not generated on a Sun.
I saw the same thing a while back when I was running Kahan's Floating
Point Test "Paranoia" on our Sun 3/180 with FPA. It seems that when
Paranoia was trying to determine the radix it was executing:
w = 1.0;
do {
w = w + w;
y = w + 1.0;
z = y - w;
y = z - 1.0;
} while ( -1.0 + FABS(y) < 0.0 );
which wouldn't stop until w was so large that a float couldn't fully
represent w + 1.0;
When I ran this code using software floating point calculations or with an
MC68881 it worked just fine. However, when I ran it with the Sun fpa I
would get an SIGIOT (Integer Overflow) trap. The difference is that the
Weitek chip set was raising the SIGIOT from the fpa, while the MC68881 and
software implementations just let the bits get lost. In my case, I just
had to remove the signal catcher setup call:
signal(SIGFPE, sigfpe);
Hope this helps,
-chip
Charles S. Roberson ARPANET: csrobe at icase.edu
ICASE csrobe@[128.239.1.30] (cs.wm.edu)
MS 132C BITNET: $csrobe at wmmvs.bitnet
NASA Langley Rsch. Ctr. UUCP: ...!uunet!pyrdc!gmu90x!wmcs!csrobe
Hampton, VA 23665-5225 Phone: (804) 865-4090
------------------------------
Date: Thu, 18 Aug 88 11:16:31 PDT
From: SJ.ATE.SLB.COM!greg at spar.slb.com
Subject: Re: Format of a ".o" file
>I would like to be able to look at .o files on a SUN3 and figure out how
>they are put together...
The man page for "a.out" goes into gory detail about the construction of a
".o" file. (A .o file is simply an a.out file which has not had all of
its external references resolved.) It is in section 5 of the manual.
I was successful in writing a program to display the various sections of
an "a.out" file from this information. The header file "a.out.h" contains
macros to get you to specific portions of the file, as well as definitions
for the data structures.
Greg Wageman greg%sentry at spar.slb.com
Schlumberger Technologies
1601 Technology Drive
San Jose, CA 95110
------------------------------
Date: Tue, 23 Aug 88 12:11:56 CDT
From: William LeFebvre <phil at Rice.edu>
Subject: Other network mailing lists and marginal topics
One of my responsibilities as moderator is to make sure that the messages
distributed to the list stay focused on the main topic: Sun workstations.
As I pointed out a few weeks ago, there are several topic areas that are
"tangential" to the main topic, but are still marginal. Fortunately, this
isn't the only Inetrnet network mailing list, and there are others that
may be more suitable for some of the marginal topics that show up here. I
will list these groups later in this message. In each case, submissions
(messages intended for the entire group's readership) and only submissions
should be mailed to the address listed. If you are interested in having
your mail address on the distribution list, then mail your request to the
"request" address. The request address for list "list at machine" is always
"list-request at machine". For example, to join info-c, one would mail a
request to "info-c-request at brl.arpa".
Here is the list:
INFO-C at BRL.ARPA Discussion of the C programming langauge
Gatewayed with the Usenet list "comp.lang.c"
INFO-POSTSCRIPT at SUSHI.STANFORD.EDU
INFOPS at STANFORD (BITNET)
Discussion of the PostScript langauge and related
topics. Bitnet requests should be mailed to the
address "INFOPSR at STANFORD".
INFO-UNIX at BRL.ARPA Question/Answer forum for "novice" Unix users and
administrators. Also sometimes used for discussion
of Unix on small (micro) computers.
LASER-LOVERS at BRILLIG.UMD.EDU
Discussion of laser printer hardware, software,
and fonts.
NeWS-makers at BRILLIG.UMD.EDU
...!seismo!mimsy!NeWS-makers (uucp)
Discussion of the Network/extensible Window
System (NeWS).
nfs at TMC.EDU Discussion about NFS, mostly oriented toward
PC-NFS, MAC-NFS, etc.
SERVERS%UCF1VM.BITNET at CUNYVM.CUNY.EDU
Discussion of network (primarily BitNet) and
inter-network file servers.
UNIX-WIZARDS at BRL.ARPA Distribution list for people maintaining machines
running the Unix operating system. Intended to
be technical (simple or "novice" questions should
be sent to "Info-Unix").
WorkS at RUTGERS.EDU Discussion of personal workstation computers, such
as the Sun, Apollo, Silicon Graphics, AT&T.
A list that contains more detailed information about these groups is
available in the archives. It is filed under "sun-spots" with the name
"other-lists" and is only 7553 bytes long. It can be retrieved via
anonymous FTP from the host "titan.rice.edu" or via the archive server
with the request "send sun-spots other-lists". For more information about
the archive server, send a mail message containing the word "help" to the
address "archive-server at rice.edu".
William LeFebvre
------------------------------
Date: Thu, 4 Aug 88 10:46:35 EDT
From: Matt Landau <mlandau at diamond.bbn.com>
Subject: Minor changes to contool, this time for version 1.1
Here's a set of diffs implementing my changes to contool (addition of a
"Become Console" menu item, rearragement of the menus) for release 1.1 of
contool.
- Matt -
[[ Stored in the archives under "sun-source" as "contool.diff" and it is
6445 bytes long. Use the request "send sun-source contool.diff". --wnl ]]
------------------------------
Date: Thu, 18 Aug 88 11:34:41 PDT
From: ultra!norm at ames.arc.nasa.gov (Norm Finn)
Subject: A good word for PC-NFS
I hadda speak up after some of the recent comments about how awful PC-NFS
is. We've got a 3/280 server, 10 3/50 and 3/160 clients, and about 15
PC/ATs and clones running PC-NFS, mostly connected via thin Ethernet. WE
LOVE IT. Our CAE software runs (limps? 640K ain't much) on the PCs with
all the data bases on the Sun, allowing the users to run on any available
PC, while giving us painless and comprehensive back-ups of the data via
the Sun's tape drive. We plot schematics from the PCs via the Sun either
using our TI laser printer in HP plotter emulation mode, or simply
queueing up stuff for the pen plotter. Every lab bench has a couple of
PCs on the net, many with only a single floppy; after booting, they use
the NFS disk(s) for everything. The latest software is released to the
Sun, and it's immediately available to all stations. We don't really
exercise file security or accounting; everybody's in the same group. I'm
sure it has bugs, but it's working wonders in our shop.
Norm Finn
ultra!norm at ames.arc.nasa.gov
Ultra Network Technologies
2140 Bering Dr.
San Jose, CA 95131
(408) 922-0100
------------------------------
Date: Fri, 19 Aug 88 10:49:25 EDT
From: zwicky at pterodactyl.cis.ohio-state.edu (Elizabeth D. Zwicky)
Subject: Speeding up dumps over the network
Reference: v6n189
About speeding up dumps over the network: rmt uses the least efficient
possible method (read a block, send a block, write a block to tape, send
back acknowledgement, start over). This makes it highly sensitive to
network delay. Our measurements:
Time to back up server to its own tape drive: 30 min.
Time to back up server to tape drive on same local network: 90 min.
Time to back up server to tape drive across fiber ring (this involves
getting to the ring, going over it, and getting off it
again): 11 *hours*.
Anything you can do to speed up your network will have a major effect.
One of the programmers here, Paul Placeway, is currently hacking on dump
and rmt. So far, he has managed to double the speed of each, and he hasn't
really worked that hard on rmt. When he finishes, he will be posting the
diffs. All the pieces are compatible with old versions; if you don't mind
losing the speedup, an old rmt can talk to a new rmt. The new dump works
with standard restore (although you need to specify the blocking factor).
The main drawback of the new versions is that they suck up resources; you
can really load your machine and your network with them. On the other
hand, you shouldn't be doing dumps during times when usage is high anyway.
Elizabeth Zwicky (zwicky at cis.ohio-state.edu)
------------------------------
Date: Thu, 18 Aug 88 16:49:58 BST
From: mcvax!ritd.co.uk!mr at uunet.uu.net
Subject: 7053 performance - observations
Just a few short observations: I have been running 7053's in-house for a
few months now. The one I watch most is my desktop's server, a 3/280-16
running 4.0. I regularly find it max'ing out at 50+ tps (according to
iostat) on a Fujitsu 2344 (67 sectors/track). Often runs (when busy, of
course) at 40-50tps. This is much higher than I am used to with
XY451+Eagle.
Either I am running lucky (fat chance) or the 7053/753 'aint so bad as
some have painted it. I feel a lot happier being able to plug my
controller *straight in* and have the system understand it. I have the
luxury of trading off convenience/safety with a few <insert local
currency> or maybe a little performance.
Here's my favourite hick "bench mark": run 'tar cf /dev/null /xyz' and
watch iostat. The above machine gave me ~55tps, a 3/180+XY451 gave
me ~30tps. OK, not a straight comparison, but lifes not fair anyway.
Martin Reed, Racal Imaging Systems Ltd
uucp: mr at ritd.co.uk,{mcvax!ukc!ritd,sun!sunuk!brains}!mr
Global String: +44 252 622144
Paper: 309 Fleet Road, Fleet, Hants, England, GU13 8BU
------------------------------
Date: Fri, 19 Aug 88 16:49:21 EST
From: munnari!cad.oz.au!skea at uunet.uu.net (Alan Skea)
Subject: SunOS 4.r0 and SCSI disks on a 3/60
Recently we tried to upgrade our 3/60 from 3.4 to 4.0. We have some
Toshiba MK156FB disks attached to our 3/60's and have some problems with
them (every now and then they stop responding to our suns. The activity
light comes on and stays on and we have to reboot to clear it. Only
happens during writes). Anyway, we thought that upgrading to 4.0 with its
"better support for third party disks and a special new format program"
would be a step in the right direction.
Well, we were wrong. The new format program does very little more that
the old diag program. They claimed that disk parameters could now be put
into a file which is consulted when format is run. This is true but it
does not go far enough. All the controller paramaters are still hardwired
into the program and there is a very limited selection of controllers that
are supported.
The 4.0 boot program and the 4.0 SCSI drivers are also a bit buggered.
The first time 4.0 tries to access our disks, the access fails (probably a
mode-select command with garbage parameters or something). Subsequent
accesses succeed. We discovered this by ether-booting a 3/60 from a 3/160
(which can run 4.0 without problems) and trying to mount the Toshiba disk
file systems. The first attempt failed, but the second attempt succeeded.
Subsequent use of the disk gave no trouble.
Trying to boot from these disk fails as soon as something tries to access
the disk - the first failure is fatal. The roms have no trouble bringing
boot off the disk, but boot cannot bring in vmunix. We tried
ether-booting unix with the -a flag, and telling it that the root
partition was on the disk. Vmunix gets a fair way through the boot and
then fails when it tries to access the disk.
At this point we gave up. Surely there are few enough SCSI commands that
the boot sequence can be put in a file somewhere and boot and vmunix can
be rebuilt to understand the appropriate sequence for the disk (determined
by the Inquiry command or something)
We are now back running SunOS 3.4 where things mostly work.
Alan Skea.
yway.
Elizabeth Zwicky (zwicky at cis.ohio-state.edu)
------------------------------
Date: 18 Aug 88 16:05:31 GMT
From: unido!pbinfo!michael at uunet.uu.net (Michael Schmidt)
Subject: compiler error: out of string space
Translating a large source file with 'cc' under SUNOS 3.4, I get an
"compiler error: out of temporary string space". How can I give it more
string space? I CANNOT make the source file smaller, since it is
generated.
Michael Schmidt, Universitaet-GH Paderborn, FB 17, Warburger Str.100,
D-4790 Paderborn, West Germany
Mail: michael at pbinfo.UUCP or michael%pbinfo at uunet.uu.net
------------------------------
Date: Thu, 18 Aug 88 14:34:09 EDT
From: Bill Arbaugh <arbaugh at hqda-ai.arpa>
Subject: Need help with SunOS4.0 tape driver
I believe that there is a problem with the tape driver in SunOS 4.0.
Specifically, I'm running a 3/160 with a Xylogics 472 controller to a
Kennedy model 9300 (Not Dual Density). I'm getting xt hard errors from
suninstall and the various commands that access the tape drive while using
the miniunix. I've called numerous people from sun (local and national)
under our maintenace and have been told by both "Yeah its probably a
driver problem, but we don't have a Kennedy to test on so....unless you
want to pay us to fix it you're on your own." The current system runs
fine under 3.4 so I know its not a problem between by drive and the
controller. I've thought about using portions of the 3.4 driver but I'm
not sure how much Sun has changed things in that department. Anybody
help??
Bill Arbaugh Phone: (202) 694-6900
UUCP: *!uunet!cos!hqda-ai!arbaugh ARPA: arbaugh at hqda-ai.arpa
------------------------------
Date: 18 Aug 88 21:40:46 GMT
From: kramerj at ucs.orst.edu (Jack Kramer - OSU Gene Res)
Subject: Need working printcap entries
I need robust working printcap entries for the following printers:
HP laserjet
HP laserjet II
Epson FX (85 and 286)
IBM Proprinter
If any one has these could you please mail to me.
thanks
------------------------------
Date: Thu, 18 Aug 88 12:41:28 -0800
From: jar at jessica.stanford.edu
Subject: slip on SunOS4.0?
Has anyone installed SLIP code on a SunOS 4.0 system? If so, was the
archived slip code on titan.rice.edu (slip.shar) used?
Looking at that slip.shar, it is for generic 4.2 and Suns running 3.x.
Since there doesn't seem to be any documented support in the SunOS 4.0
distribution I was hoping to use this code.
If possible, please reply to jar at jessica.stanford.edu.
thanks,
Janine Roeth
Academic Information Resources
Stanford University
------------------------------
Date: 18 Aug 88 21:49:08 GMT
From: oliveb!stpstn!aad at ames.arc.nasa.gov (Anthony A. Datri)
Subject: Interleaf macintosh <=====> sun?
I'm facing the possibility of having to transfer Interleaf files back and
forth between Suns (2 and 3 running 3.2) and a Macintosh, primarily
Interleaf files created on a Mac to the Sun for use in Interleaf. The
manuals only speak of importing foreign documents. Any experiences? I
wouldn't bother anyone with this, but I know that there is a concept of
data and resource forks, and since I don't have a Mac Interleaf file yet
to experiment with......
TIA, of course.
Anthony A. Datri,SysAdmin,StepstoneCorporation,stpstn!aad
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list