Sun-Spots-Request@RICE.EDU.UUCP (05/12/87)
SUN-SPOTS DIGEST Monday, 11 May 1987 Volume 5 : Issue 13
Today's Topics:
Re: Warning: IPC board
Re: Generating Sun2 binaries on a Sun3? (2)
SDI game for Sun workstations
Re: 3/75 SCSI Controller
Drive Types
Bug in SUN 3.2, 3.3 machdep.c (or movc.s) "panic: memall intrans|want"
SUN OS 3.[23] kernel panics with "memall intrans|want"
Re: multi-player games on sun 3/50s
UNIX directory browser for free (almost)
Re: Speech I/O on Sun 3/50?
Color hardcopy devices?
performance query?
calendar for suntools?
SunCore?
PC-NFS and Ethernet interfaces?
swap space allocation?
NFS for VAX/VMS; TCP/IP ditto.?
Read error from network?
------------------------------------------------------------------------
Date: Wed, 6 May 87 11:52:51 EDT
From: sunrock!wilsun!brian@sun.com (Brian Wilson)
Subject: Re: Warning: IPC board
Regarding Robert Nagler's comments about the Multi-Access licensing of
SunIPC software:
The descriptions in the price list (April 6, 1987) seem pretty clear -
see page 33:
"Single user version for dedicated MS-DOS users, Multi-access version
for occasional MS-DOS capability shared over the network."
Also, the order numbers for these versions are listed under the headings
"Single User, Local Access" and "Multi Access over Ethernet."
Do you think this needs further clarification?
Brian Wilson
Sun Microsystems - Tech Support - Rochester NY
------------------------------
Date: Wed, 06 May 87 11:42:53 -0700
From: ehrhart@spam.istc.sri.com (Tim Ehrhart)
Subject: Re: Generating Sun2 binaries on a Sun3? (1)
Matt,
First I would like to be sure we're talking apples and apples not
apples and oranges. When you say Sun"x" where x = {1,2,3} it refers
to hardware, that is a Sun2 has a 68010 and a Sun3 has a 68020.
When you say "number"."x" where number = {1,2,3} and x = {0,1,2,3,4,..}
it refers to Sun's operating system version, for example 2.0 was the
first Sun operating system with NFS and 3.3 is the latest version I
now am running.
Now that the ground rules are established here's who plays with what:
3.x will run on Sun3 and Sun2 (and I think even Sun1).
2.x will run only on Sun2 and Sun1.
1.x will run only on Sun2 and Sun1.
Here's a truth table of who plays who's executables: (excluding Sun1's)
Target HW/SW
|---------------------------------------------------------
| | Sun3/3.x | Sun2/3.x | Sun2/2.x | Sun2/1.x |
|---------------------------------------------------------
|---------------------------------------------------------
Source | Sun3/3.x | yes | no | no | no |
HW/SW |---------------------------------------------------------
| Sun2/3.x | yes | yes | NO | NO |
|---------------------------------------------------------
| Sun2/2.x | yes | yes | yes | depends |
|---------------------------------------------------------
| Sun2/1.x | probably | probably | yes | yes |
|---------------------------------------------------------
(where depends = no NFS or YP conflicts or requirements)
(where probably = network access would probably fail)
The main point here is that any Sun2 executable created with 3.x will
NOT run on a Sun2 running 2.x because the a.out(5) format changed from
2.x to 3.x. That is why Sun2/3.x executables are rendered useless under
2.x. So even though you have 68010 instructions in the executable, the
a.out struct at the beginning of the executable is different.
There is also the issue of how to create a Sun2/3.x executable on a
Sun3/3.x box. Both the compiler and the assembler have options to crank
out 68010 executables (albeit the option to cc(1) is pretty much
undocumented). Where most folks get burned is in the linking phase.
They are normally on a Sun3 and ld(1) has no options for knowing what
kind of executable to make, so by default /lib and /usr/lib contain
(or point) to 68020 libraries. So even if you compile all your own
source as 68010, but link with 68020 libs, the executable becomes a
68020 executable!! How to prevent this is to change your load lines
to include (if necessary) absolute library names: (This pretty assumes
you have a dual architecture file server, or can NFS mount libs from a
Sun2/3.x server)
Wrong: cc -mc68010 -O -c myprog.c
cc -mc68010 myprog.o -lm -o myprog
Right: cc -mc68010 -O -c myprog.c
cc -mc68010 myprog.o /usr.MC68010/lib/libm.a -o myprog
I hope this clarifies the issue instead of making it more confusing
than it already is. The information I presented is only my findings
after much research. If there are any inconsistencies I would appre-
ciate hearing from other folks.
Tim Ehrhart SRI International Menlo Park, CA 94025
--------
------------------------------
Date: 8 May 1987 1108-PDT (Friday)
From: @nprdc.arpa:lim@dewey (Bill Lim)
Subject: Re: Generating Sun2 binaries on a Sun3? (2)
This is what I did to get sun2 binaries out of our sun3:
It requires two changes. The library /lib/libc.a needs to be
68010 object code. You can get this from the Sun-2s. (There are
some front end objects like Fcrt.o, etc. which must also be
68010 objects, but it seems that the Sun-3s already have them
as 68010, strange.)
Now, for part two. You must specifiy the undocumented -m68010
switch when compiling object modules. You can simply stick this
in make's CFLAGS macro: CFLAGS = -m68010 ....
The switch is not required during the linking process. The
linker, ld, determines what the final target CPU binary should
be by inquiring to a /lib/libc.a object module called
is68020.o. If this is false, then the target binary CPU type is
68010. (This, of course, gets overridden if any object modules
are not all 68010.)
Now, it is problably possible to make this totally transparent
(i.e. not having to specify -m68010), by changing the compilier
cc, ccom, etc, and setting the files /bin/mc68010 and
/bin/mc68020 to true and false, respectively. But, the possible
side effects from this are too great since the scope of the
changes goes beyon the compiler environment. (And then again,
changing the compiler executables may not accomplish anything
anyway.)
Bill Lim
NPRDC/AIM Artificial Intelligence Group
San Diego, CA. 92152
VOICE: 619 225 6434
APRA: lim@nprdc.apra
UUCP: ihnp4 \
akgua \
decvax >---- !sdcsvax!sdics!nprdc!lim
dcdwest /
ucbvax /
------------------------------
Date: Fri, 8 May 87 23:11:39 EDT
From: mark@mimsy.umd.edu (Mark Weiser)
Subject: SDI game for Sun workstations
I have written a game, called SDI, for Suns. I believe, but have not
actually checked, that it uses close to every feature in SunView,
plus some new ones I added. It is available, compressed, for anonymous
ftp on mimsy.umd.edu in file sdi.shar.Z. It will also be available
on the Sun User Group tape, coming soon.
It has been tested by various groups around the net, and seems robust.
The major problem seems to be that it is addictive. Don't ftp it if
you have a project due soon.
Enjoy.
-mark
-----------
Spoken: Mark Weiser ARPA: mark@mimsy.umd.edu Phone: +1-301-454-7817
After May 15, 1987: weiser@parcvax.xerox.com
------------------------------
Date: Wed, 6 May 87 14:04:34 MDT
From: paul%manjusri.colorado.edu@relay.cs.net (Paul K. Harter)
Subject: Re: 3/75 SCSI Controller
in sunspots v5 n11, ROODE@bionet-20.arpa (David Roode) asks about
SCSI adaptors in brand-X memory. I just happened to see such
a card recently announced by HSI (408) 268-2078. They claimed:
VME memory with SCSI connectors
You might try them.
paul
paul@boulder.colorado.edu
------------------------------
Date: Thu, 7 May 87 00:02:53 PDT
From: cgl.ucsf.edu!hoptoad.UUCP!cfcl!rdm@sun.UUCP (Rich Morin)
Subject: Drive Types
The bottom line on drive types, compliments of Mike Persichetty of Sun
(mike@persius.sun.com):
I sent this out a few weeks ago. I don't see anything proprietary, since
one could always work backwards from the Sun switch settings on the drive
to figure out bytes/sector. Drive type can be found in the source for diag.
Hope this explaination helps.
One thing I did not mention is that if you format using other, and you
re-enter diag, you must still use other to define the drive parameters.
Otherwise, you will be unable to read the label, etc.
Subject: mixing disc drives
This was in answer to someone's question concerning mixing of disc drives
on a single controller. The original question was about mixing a 380 and
a 130 meg disc on a single controller. Also asked were rules concerning
mixing any drives. It may not make sense to many, delete as you desire.
There is nothing wrong with the configuration mentioned (380 + 130). There
are no written guidelines that I know of for mixing drives. Problems that
can be encountered are 1) controller I/O speed and 2) drive type. The
first problem can be overcome by simply using a controller with a faster
speed, ie. use a 451 for both fast and slow SMD discs. The second problem
is more complex, but can also be overcome, if drive type is understood.
The source for diag (diag.c) defines drive type for all SMD discs used
by Sun. The Xylogics 450/451 can only handle 4 drive types (0-3). When
Sun introduced its newer disc drives (2361 for example), all usable drive
types had been defined. So, there are now some discs that share the same
drive type number, yet they are actually different drives, different
meaning the geometry (Cylinders, heads, sectors). This table shows
geometry and drive type.
ncyl acyl type heads byte/sec drive
587 2 1 7 621 Fujitsu-M2312K
821 2 2 10 621 Fujitsu-M2284/M2322
840 2 0 20 595 Fujitsu-M2351 Eagle
821 2 3 10 600 Fujitsu-M2333
840 2 3 20 600 Fujitsu-M2361 Eagle
1147 2 1 10 613 CDC EMD 9720
1022 2 3 16 Fujitsu-M2294
821 2 2 10 CDC-9730-160
1022 2 3 16 Ampex-Capricorn
So, because the CDC EMD 9720 (280mb) and the Fujitsu M2312 (84mb) have
the same drive type, and have different geometries, they cannot be used
on the same controller, unless you choose "other" and assign a drive type
other than 1 to either of the drives. The same holds true for mixing a
Fujitsu M2333 (280mb), a Fujitsu M2361 (475mb), a Fujitsu M2294 (280mb),
and a Ampex-Capricorn on the same controller (the M2294 and Ampex can
be used together, they have the same geometry).
How does the system know the drive type? It is part of the format laid
down on the drive. So, if you must mix different drives, you must choose
your drive type carefully when you initialize the system with diag. Also,
you must remember that if you format a drive using other, you should not
try to use the same drive on another system, unless you reformat it as
the standard drive type. This will avoid future problems if another disc
is added to the system.
------------------------------
Date: 8 May 87 06:30:41 GMT
From: harvard!harvisr!endor.harvard.edu!dudek@seismo.css.gov (Glen Dudek)
Subject: Bug in SUN 3.2, 3.3 machdep.c (or movc.s) "panic: memall intrans|want"
Subject: SUN OS 3.[23] kernel panics with "memall intrans|want"
Index: .../sys/sun3/machdep.c SUN OS 3.2, 3.3
Description:
When booting a SUN kernel configured with MAXUSERs more than about
12 on a SUN-3 with at least 8 megabytes of memory, the kernel will
panic during startup with a "panic: memall intrans|want" (or perhaps
trap and die).
Repeat-By:
Configure a SUN 3.2 or 3.3 kernel with MAXUSERs set to 16. Find
a SUN-3 with at least 8 megabytes of memory. Boot your new kernel.
Watch it crash and burn.
Fix:
The problem is that all the kernel tables which are allocated
in startup() are zeroed with one call to bzero(). bzero() is
implemented with a loop using the 68000-family "dbra"
instruction, which decrements a signed 16-bit counter and
branches if the counter is not zero. Since the counter is
tracking longs, bzero() can zero at most 2^17 bytes per call
(actually, 2^17+3, before I hear from Guy). Unfortunately, the
size of these tables can grow beyond this limit, and the call
to bzero() will not actually zero all the tables. The last
table allocated is the coremap, and the "panic: memall
intrans|want" occurs when allegedly free kernel memory is
allocated, but found to have certain control bits set when
removed from the coremap free list.
The possible fixes, of course, are to change bzero() so it can
zero out a larger chunk of memory at a time, or to change startup()
so it calls bzero() multiple times if necessary. We felt that
one C change affecting one routine was better than one assembly
change affecting many routines (besides, we didn't want to learn
68000 assembly any more than we had to :-).)
Workaround:
Well, if you have source, apply the diffs below to
".../sys/sun3/machdep.c". Otherwise, don't configure a big
kernel on a machine with enough memory to tickle the bug.
Diffs follow:
*** /tmp/,RCSt1a00142 Fri May 8 02:12:37 1987
--- machdep.c Fri May 8 02:06:37 1987
***************
*** 576,582 ****
--- 576,602 ----
range = btoc(v) - (firstaddr + btop(KERNELBASE));
i = firstaddr + btop(KERNELBASE);
mapin(pte, i, mapaddr, range, PG_V | PG_KW);
+ #ifndef ORIGINAL
+ /* We can't bzero more than 2^15 (0x8000) longs at a time, so call bzero
+ * as many times as we have to to get the job done - gd, njh 5/8/87
+ */
+ {
+ /* Maximum pages we can zero at once - actually, we can do a few more,
+ * but close enough for goverment work
+ */
+ #define MAXZEROPAGE (btop(0x10000))
+ unsigned j, zend;
+
+ zend = i + range - (MAXZEROPAGE - 1);
+ for (j = i; j < zend; j += MAXZEROPAGE)
+ bzero(ptob(j), (u_int)ptob(MAXZEROPAGE));
+
+ if (j != i+range)
+ bzero(ptob(j), (u_int)ptob(i+range-j));
+ }
+ #else /* ORIGINAL */
bzero(ptob(i), (u_int)range * NBPG);
+ #endif /* ORIGINAL */
mapaddr = mapaddr + range;
/*
------------------------
Glen Dudek, Nike Horton
System Managers Emeritus
Aiken Computation Lab
Harvard University
------------------------------
Date: Wed, 6 May 87 00:41:05 pdt
From: oster%lapis.Berkeley.EDU@berkeley.edu (David Phillip Oster)
Subject: Re: multi-player games on sun 3/50s
We have a bare bones version of Mazewar that runs under X.
------------------------------
Date: Mon, 11 May 87 14:41:29 -0700
From: rlb@riacs.edu (Bob Brown)
Subject: UNIX directory browser for free (almost)
I have written a directory browser that works like SFGetFile on the Mac,
and now routinely incorporate it into applications I write for the Sun.
I have packaged the routines as a saparate application that lets you
browse a UNIX directory tree and select a file whose full pathname is
then copied to the Sun shelf. It is useful for whenever you need a full
pathname in a window or program (like Frame Technology's Maker) and that
window or program has the ability to yank text from the shelf.
Before sending this out to a USENET sources group, I'd like to try a
smaller distribution. I had exchanged some notes with Vicky Riffle
about setting up an anonymous FTP on a Rice machine for sources and she
agreed, but due to the experimental nature of this code, I've decided to
keep it closer to home. Though our community needs a central anonymous
FTP host for archiving freeware, I'd rather see it established with
sounder (or better tested) stuff than this.
I'd like a few people to grab the code and try it out and feed back some
comments and then I'll more widely distribute it. You can get the code
from
host: icarus.riacs.edu (128.102.8.1)
login: anonymous
file: pub/getfile.shar
Bob Brown
RIACS/NASA Ames
------------------------------
Date: 7 May 87 20:45:24 GMT
From: ut-sally!unniks@seismo.css.gov (C. Unnikrishnan)
Subject: Re: Speech I/O on Sun 3/50?
I know from using one that Votan makes such a combination
compatible with Sun hardware. I donot have addresses etc,
but will be glad to dig them up if you can't reach them.
unni
--
C. Unnikrishnan
unniks@sally.UTEXAS.EDU ##Arpa Internet
unniks@ut-sally.UUCP or {ihnp4,seismo,ucbvax,gatech,..}!ut-sally!unniks ##UUCP
------------------------------
Date: Fri, 8 May 87 18:10 EDT
From: BSD%PSUVM.BITNET@wiscvm.wisc.edu (Scott Dickson)
Subject: Color hardcopy devices?
We are looking into various color hardcopy devices for our Suns and I was
wondering if anyone had recommendations. Has anyone had experience with
Shinko color hardcopy, Seiko, or the Tektronix 4296(?) devices? What sort of
interface for the user is there to the device? How much does it cost to
purchase and to maintain? Reliability?
Are there other suggestions? What about accessing the device via the ethernet?
Please reply by mail, and I will summarize.
--Scott Dickson
BSD@PSUVM.BITNET
------------------------------
Date: 6 May 1987 17:39:20 BST
From: uucp%ux63.bath.ac.uk@cs.ucl.ac.u (James Davenport)
Subject: performance query?
We are contemplating the following system, and I would be grateful
for people's comments on its potential performance.
1 3/280 with 16M main memory 3G disc
serving up to 30 networked-in users (edit/compile/trivial run)
8 3/50 discless
each serving one 'serious' researcher.
Does anyone have any good performance feelings for this configuration.
Can a 3/280 serve 30 users at all? Can it do so and be a file server??
Reply to me (jhd%uk.ac.bath.maths@ucl-cs.arpa or jhd1%camphx%caga@ucl-cs.arpa)
and I will sumaarise to the net.
Thanks, James Davenport
------------------------------
Date: 6 May 87 23:09:29 GMT
From: mkhaw@teknowledge-vaxc.arpa (Michael Khaw)
Subject: calendar for suntools?
Is there a calendar tool that runs under suntools? Someone here has
asked for a suntools program that will let them see a facsimile of a
real calendar under suntools: I suspect that includes the ability to
"flip pages" on the calendar. The standard "cal" program is not what
they're looking for.
Please note that we are not looking for the "month" program posted
to mod.sources. What we're after is an iconic, direct-manipulation-
via-mouse type of calendar rather than a text-based "visual" calendar.
Thanks,
Mike Khaw
--
internet: mkhaw@teknowledge-vaxc.arpa
usenet: {hplabs|sun|ucbvax|decwrl|sri-unix}!mkhaw%teknowledge-vaxc.arpa
USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
------------------------------
Date: Wed, 6 May 87 09:34:03 pdt
From: ssc-vax!ssc-bee!thornton@beaver.cs.washington.edu (Ken Thornton)
Subject: SunCore?
I just started using a Sun 3/50M for research (I later plan to move to a
3/XXC to display shaded or colored images) and would like to hear about
peoples experiences with SunCore.
SunCore seems ideal for me because I wish to display previously defined
complete and valid solids represented in face, vertex, and edge format.
I do have a few questions though:
1) The SunCore manual says that hidden surface removal is only supported
for color or gray level displays. Why?
2) I only need to display single objects, but wish to include shadows. The
shader for SunCore does not support shadows (according to the manual).
Is there any way to modify the ray-tracer?
3) Similarly, I believe only a single light source is supported. How might
I add support for multiple light sources?
4) For those of you able to display shaded pictures, how does the rendering
time of the SunCore shader compare to an equivalent shader not run
using SunCore, but on the same machine?
E-mail replies are welcome. I will post a summary if desirable.
Ken
--
/\
/\/ \/\
/ / /\/ \ Ken Thornton {decvax,ihnp4}!uw-beaver!ssc-vax!ssc-bee!thornton
/ / / \ \
------------------------------
Date: Thu, 7 May 87 11:17:49 edt
From: a_lie%vax.runit.unit.uninett@tor.nta.no (Anund Lie)
Subject: PC-NFS and Ethernet interfaces?
I understand PC-NFS as delivered by Sun only supports the 3Com 3C501
Ethernet interface. How dependent on this interface is PC-NFS really?
Is it possible to swap the Ethernet driver part of PC-NFS for a driver
(for instance from some PC TCP/IP package) for another Ethernet card
(possibly by writing a small amount of code acting as "glue")?
Anund Lie
Norwegian Institute of Technology
a_lie%vax.runit.unit.uninett@nta-vax.arpa
------------------------------
Date: Thu, 7 May 87 11:17:49 edt
From: mike@thumper.bellcore.com (Mike Caplinger)
Subject: swap space allocation?
I asked this question a long time ago, but no one seemed to know the
answer. What does the "wasted" number in an /etc/pstat -s mean?
For example, on my Sun-3/75 with standard-sized swap partition, I
get output from pstat -s of
9832k used (1944k text), 6662k free, 3568k wasted, 0k missing
max process allocable = 6128k
avail: 11*512k 2*256k 1*128k 1*64k 4*32k 5*16k 118*1k
The "3568k wasted" worries me, since I frequently run out of swap
space on this machine.
In a related question, since 4.0 will supposedly do away with ND
swap partitions, is swapping in general going to be revamped?
It's kind of a pain to have to have separate swap partitions.
On the Apollo (you guys knew I was going to say something like
this, right? :-) the swap file is just an ordinary file like any
other. Can anybody at Sun describe what's going to happen to
swap partition handling?
(A question: if one just swaps to a vanilla Unix file, is the overhead
of chasing block pointers a problem?)
Mike Caplinger
mike@bellcore.com
{decvax,ihnp4}!thumper!mike
disclaimer: Nothing I say represents official policy of Bell Communications
Research, nor is it an endorsement of any single product. Obviously.
------------------------------
Date: Fri 8 May 87 12:56:09 N
From: MANSFIEL%EMBL.BITNET@wiscvm.wisc.edu (Niall Mansfiel)
Subject: NFS for VAX/VMS; TCP/IP ditto.?
We have a brace of Suns (bliss, bliss!) which we have to
connect to a brace of VAXes running VMS (vomit, vomit!), and
a few other odd things to connect to both.
We need
NFS } for VMS on the Vax
TCP/IP }
Does anybody know where we can get these things, how much
they cost, and whether they are wonderful or just boxes of
dung?
Thanks for any help,
Niall
------------------------------
Date: 9 May 87 00:44:27 GMT
From: bcsaic!paula@june.cs.washington.edu (Paul Allen)
Subject: Read error from network?
We have a network with 28 Suns, a couple VAXen, and assorted PC's,
Symbolics, and other ethernet devices. One of the Suns (duckabush) is a
3/280 with two 575Mb drives and six diskless clients. Except for my
administrative chores, nobody ever logs in on duckabush. Lately (say,
for the last week or so) I have noticed the following strange behavior:
When duckabush has had no logins for a while, an attempt to rsh to
duckabush gets the response:
read error from network: connection reset by peer
Connection closed.
It doesn't appear to matter which host I try to rsh from. After the
initial failure, subsequent attempts to rsh to duckabush from any Sun
simply hang until they time out. However, rsh'ing to the Ultrix VAX and
then rsh'ing to duckabush will always work. Furthermore, once I have
logged into duckabush from the VAX, subsequent rsh attempts from any Sun
always succeed. The Suns are running 3.2. The VAX is running Ultrix
1.2. One thing that may be significant is the fact that perhaps a half
dozen times over the last month or so, duckabush has reported something
like:
duplicate ip address from: 8:0:28:1:5:e
Our ethernet spans four buildings and is used by many organizations. I
have thus far been unable to identify the offending device.
Has anyone seen this rsh behavior before? Can anyone suggest a way to
approach the problem?
Paul Allen
Boeing Advanced Technology Center
...uw-beaver!ssc-vax!bcsaic!paula
paula@boeing.com
(206) 865-3297
------------------------------
End of SUN-Spots Digest
***********************