Sun-Spots-Request@RICE.EDU.UUCP (06/27/86)
SUN-SPOTS DIGEST Thursday, 26 June 1986 Volume 4 : Issue 19
Today's Topics:
UNDUMP for TeX for SUN3
Bug with cc optimizer under 3.0 (long)
Mount deadlocks
Problems with SunView (long)
"lies" in Sun documentation
One SUN supporting 40 students
12MHz vs. 16MHz 68881 comparison?
MDQS on Sun 3.0?
Adding an Eagle-and-a-half to a Sun?
Sunview?
SL on Sun3?
Maintaining multiple objects on mixed Sun systems?
Request for Visual Calculator?
3.0 lockscreen/kernel bug?
Benchmarks and info on file servers?
NFS hanging...yow?
SCSI disks & SCSI ports?
------------------------------------------------------------------------
Date: Sat, 21 Jun 86 11:45:24 EDT
From: Barry Shein <bzs%bu-cs.bu.edu@CSNET-RELAY.ARPA>
Subject: UNDUMP for TeX for SUN3
I fixed undump to rebuild TeX on a SUN3/Release 3.0 a long time
ago, if you need it just ask (if someone wants to volunteer a
good place to put it for anonymous ftp that would be good too.)
-Barry Shein, Boston University
-----------------------------
Date: Mon, 23 Jun 86 16:43:37 PDT
From: sdcarl!jay@ucbvax.Berkeley.EDU (Jay Tobias)
Subject: bug with cc optimizer under 3.0
The following is in respone to the bug reported with the cc optimizer
under Sun Release 3.0. We have this version of the operating system
running on a Sun2/170.
Of interest here is the declaration of the variable r2 as a register
pointer to a character. The C source is followed by assembly source,
produced by the -S option to cc, for the unoptimized and the optimized
versions in that order. Note that in the optimized version the line
that both declares and intitializes r2 is incorrectly implemented.
In particular the initialization is never performed!
To see this, observe that data register d6 is used as the register
for variable 'r2'. Notice that a little below label 'L14:',
after the pointer arithmetic is performed with variables 'p'
and 'i', variable 'r2' is assigned to by the 'movb' instruction.
Now look at the same region for the optimized code. This appears
several lines after the label '_main:'. There is no
assignment to data register d6 and therefore no initialization of
variable 'r2'. Thus when the second conditional is executed,
it fails and variable 'r1' maintains the value of 0.
This report is going to both sunspots and the Sun Microsystems
e-mail bug reporting site.
C source
========
main() {
int i = 0;
char *p = " ";
register r1 = 0;
register char r2 = *(p+i);
if(r2 == 'x')
r1 = r1 - 1;
else if(r2 == ' ')
r1 = 1;
printf("%d\n", r1);
}
Assembly source (from cc -S)
============================
LL0:
.data
.text
|#PROC# 04
.globl _main
_main:
link a6,#0
addl #-LF12,sp
moveml #LS12,sp@
clrl a6@(-0x4)
.data1
L14:
.ascii " \0"
.text
movl #L14,a6@(-0x8)
moveq #0,d7
movl a6@(-0x8),a0
addl a6@(-0x4),a0
movb a0@,d6
cmpb #0x78,d6
jne L15
movl d7,d0
subql #0x1,d0
movl d0,d7
jra L16
L15:
cmpb #0x20,d6
jne L17
moveq #0x1,d7
L17:
L16:
.data1
L19:
.ascii "%d\12\0"
.text
movl d7,sp@-
pea L19
jbsr _printf
addqw #0x8,sp
LE12:
moveml a6@(-0x10),#0xc0
unlk a6
rts
LF12 = 16
LS12 = 0xc0
LFF12 = 8
LSS12 = 0x0
LP12 = 0x10
.data
Assembly source (from cc -O -S)
===============================
.data
.text
LL0:
|#PROC# 04
.data1
L14:
.ascii " \0"
.data1
L19:
.ascii "%d\12\0"
LF12 = 16
LS12 = 192
LFF12 = 8
LSS12 = 0
LP12 = 16
.data
.text
.globl _main
_main:
link a6,#-16
moveml #192,sp@
clrl a6@(-4)
movl #L14,a6@(-8)
moveq #0,d7
movl #L14,a0
addl a6@(-4),a0
cmpb #120,a0@
jne L15
subql #1,d7
jra L16
L15:
cmpb #32,d6
jne L16
moveq #1,d7
L16:
movl d7,sp@-
pea L19
jbsr _printf
addqw #8,sp
moveml a6@(-16),#192
unlk a6
rts
Jay Tobias
University of California, San Diego
Center for Music Experiment Q-037
La Jolla, Ca. 92093
619-452-4383
{ucbvax,ihnp4,akgua,hplabs,sdcsvax}!sdcarl!jay
-----------------------------
Date: Wed, 25 Jun 86 10:13:53 PDT
From: John Bruner <jdb@s1-c.arpa>
Subject: Mount deadlocks
Another problem Sun UNIX has with mounts occurs in "/etc/rc.boot".
This file disobeys the rule that no changes be made to a corrupted
filesystem until it is cleaned. Specifically, zeroing "/etc/mtab",
adding an entry for "/", and mounting "/pub" is a no-no if the root
hasn't been salvaged yet.
Recently one of the nd root filesystems here was corrupted, and the
damage included "/etc/mtab" and "/etc/rmtab". I was unable to boot
the machine to single-user because it panic()ed as soon as these
commands in "rc.boot" tried to touch the corrupted inodes.
Fortunately this was an nd root, so I was able to fix it via the
"ndl" device on the fileserver.
Since then I've rewritten my "rc.boot" file to read:
> #
> # Sun breaks all of the rules with this file, which is executed prior to
> # single-user mode. In their version, if the root filesystem is corrupted
> # in such a way that "/etc/mtab" is garbage, it may not be possible to
> # boot UNIX at all! To avoid this problem, we must perform an fsck on the
> # root prior to making any changes there. Fortunately this is reasonably
> # fast.
> #
> # Since "/bin" isn't on the root, the set of available commands is very
> # limited until we have verified the root and can start mounting things.
> #
> # Note: the variable "root" must be set to the name of the (cooked) root
> # device. For discless nodes this is "/dev/nd0"; for file servers with
> # Xylogics controllers it is "/dev/xy0a". We can't figure it out
> # automatically because the tools in "/bin" (e.g. "grep") aren't available.
> #
> root=/dev/nd0
> hostname=pathfinder
> #
> if [ ! -f /fastboot ]
> then
> /etc/fsck -p $root > /dev/console
> if [ $? = 4 ]
> then
> /etc/reboot -q -n
> fi
> fi
> > /etc/mtab
> /etc/mount -f /
> /etc/mount /pub
> /bin/hostname $hostname
> /etc/ifconfig ec0 $hostname -trailers up
> /etc/ifconfig ie0 $hostname -trailers up
> /etc/ifconfig le0 $hostname -trailers up
> /etc/umount -at nfs
> sync
[I think a better solution would be a path to single-user which avoids
"rc.boot" entirely.]
BTW, ever since we switched to 3.0FCS we've been having frequent crashes
in "ifree". "fsck" refuses to recover these because the link count in
some inode is too small (i.e. there are more links than the inode
indicates). Usually one of the links is "/etc/mtab" or "/etc/rmtab".
Without source code I've been unable to figure out what is happening.
This does not happen in Sun 2.0 or on our NFS VAXes (where I do have
source code). Has anyone else experienced this problem?
--
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: Wed, 25 Jun 86 16:36:56 -0500
From: Christopher Byrnes <cb@mitre-bedford.ARPA>
Subject: Problems with SunView
I've been using SunView 3.0 on our Sun 3's to create a prototype Ada
programming environment. Besides using SunView to provide a nice
window interface to a user, I'm trying to use existing UNIX tools
(such as the Verdix VADS Ada system and the Emacs editor) as part of
this environment. I've noticed some problems when trying to write C
code which uses SunView and I wonder if anyone else out there has
noticed these problems and has developed good work-arounds.
The Sun RPC documentation is vague as to whether you can split a RPC
"program" and its associated "procedures" among different UNIX
processes. I had hoped to assign one RPC program number to a major
function, with the different procedure numbers further defining the
particular option for that program. Different procedures could be in
different UNIX processes. That doesn't seem to work, I wound up
having to make sure that all the RPC procedure handlers for a
particular RPC program are in the same UNIX process. Did I miss
something in the documentation?
Mixing RPC handlers and SunView in the same program can cause LOTS
of problems. I want to use RPCs (and not the regular notifier)
because I felt that RPC had a better data transfer method than the
selection service in SunView (when your not passing just text around).
SunView often wound up confused over which UNIX file descriptors it was
or was not suppose to be checking with "select()". I eventually got
around this problem by using "notify_no_dispatch()" inside the RPC
handlers to temporarily turn the notifier off.
The standard RPC function to encode/decode C "int" values doesn't
seem to work right. The value seems to be encoded into a 4-byte value
O.K., but decoding seem to swallow up more than 4 bytes (resulting in
the wrong number passed as an XDR value). I wrote my own decoder
eventually. Have others noticed this?
The SunView text window documentation is very confused over the
difference between a position number (usually an "int") in the
contents of a text window versus a position pointer (usually a "char
*"). Some functions call for one argument type, while others call
for the other. Trying to mix the two types of "textsw" function calls
is awkwards, the interface should either be consist or define
additional functions which duplicate actions for either type or
argument. In addition, such functions will claim that they want one
type when in reality that work only when the other argument type is
used. Using "textsw" takes a lot or trial and error!
The "wait3" interposer does not work, when I try defining such an
interposer SunView dies (dumping core) on some internal call after my
interposer returns control. I worked around this by redefining the
"wait3" handler to be my old interposer, which then called the default
"wait3" handler (which I saved). Is there something special about
"wait3" interposers which makes them different from the others?
Once you start a window destruction request (such as a mouse click
on the appropriate option of the frame's menu), SunView seems to treat
the destroy operation as an atomic operation. For example, one thing
I'd like to do when running a pre-existing program (such as Verdix's
Ada debugger), is to send the "quit" characters to the program so the
program shuts down cleanly before the window containing it goes away.
I had planned to send (via some artificial input events) the keystroke
characters necessary to do this and have the notifier send them before
the destroy takes place. This doesn't work, neither a destroy
interposer nor a new destroy handler nor NOTIFY_IMMEDIATE options
would force those characters to the UNIX program before the TTY window
containing the program was destroyed. I got around this by posting
the necessary keystrokes with the notifier and then having the destroy
interposer ignore (reject) the destroy request. The keystrokes get
sent to the UNIX program, which eventually kills off the associated
UNIX process, which automaticaly generates another destroy request to
the notifier, which this time accepts the destroy request and finally
kills the window. Hardly an elegant solution!
The "menu" pointer is not being returned properly, especially for
the main menu associated with a frame. The example in the back of
Section 11 of "The SunView Programmer's Manual" (which is on menus)
indicates that the "menu *" can be returned. Yet where ever I try to
request this menu pointer through "window_get()" (either before of
after the call to "window_main_loop()"), I always get a zero returned.
As you might guess, passing a zero as a "menu" to any of the menu
functions will cause SunView to dump core. Is that example at the end
of Chapter 11 wrong, or are we allowed to access (and eventually
change) predefined window menus?
I couldn't find a way to get at the "accelerator" actions which are
predefined. For example, I'd like to prevent users from resizing some
windows as some canned programs assume full use of the screen and
cannot be adapted to Sun's conventions (easily). Assuming the above
menu pointer problem is solved and I can disable the "resize" option,
will that prevent people from using <Control> and the middle mouse
button from resizing the window behind my back?
The TTY window type doesn't allow the caller to learn the UNIX
process number for the program which was started up. Knowledge of
this process number is important if you want to set up a "wait3"
handler. In my case if the process dies of its own accord I do
something different than if the process is being killed as a result of
a window destroy request (see the above comments on having to send
keystrokes to the program to allow a clean shut down). Currently I
spawn off a new UNIX process to act as manager to the newly created
window, and I assume that the process number of the UNIX program which
will be running in the TTY window is one more than the process number
of the manager function I just spawned. This is a dangerous
assumption (suppose something else gets "forked()" in between), the
TTY window should have the associated process number as an attribute.
A larger concern is the lack of a good match between all of the UNIX
concepts and all of the SunView concepts. For example, I'd like to
treat Sun windows as first-class citizens, so UNIX program could
direct their stdout to a named window just like stdout can be directed
to a file. Wouldn't it be nice if a complex UNIX "pipe" structure
could be set up which allowed you to view the text which was being
passed along the pipe? Currently it takes a lot of C programming in
order to do these sorts of things. Other windowing systems implement
the concept of a "stream" which can be read and written to at either
end by different processes (Emacs and various lisp machines are
examples). SunView could use such a higher-level of abstraction.
(* many of these words are copyrighted) Christopher Byrnes
(all of these words are my opinion The MITRE Corporation
and my not reflect my employer's Burlington Road
policies) M/S A425
Bedford, Mass. 01730
cb@Mitre-Bedford.ARPA
...!decvax!linus!mbunix!cb.UUCP
-----------------------------
Date: Fri, 20 Jun 86 11:22:38 EDT
From: cjh@CCA.CCA.COM (Chip Hitchcock)
Subject: "lies" in Sun documentation
re your upward-compatibility problem with sun{tools,view}, this is hardly the
only case where the documentation doesn't seem to have been checked by anyone
responsible for code. A lesser example is nroff under Sun 2.x; the manual
claims you can stack up to 6 "environments", but nroff barfs if you try more
than three (the standard under 4.2 BSD). (This is trivial to find if anyone
actually checks---it can be demonstrated by nroffing a file containing 6
characters: ".ev 3<cr>") When I called Sun to complain (our in-house macros,
developed on a VAX w/ source license, require more environments) they
tail-chased for a couple of days, then said they'd change the documentation
instead of the code.
-----------------------------
From: lll-crg!caip!harvard!pixel!pixdoc!fbp@lll-tis-b.ARPA
Date: Tue, 24 Jun 86 09:31:39 edt
Subject: One SUN supporting 40 students
Q: What would it take to get a Sun workstation to support 40 students...
A: A MIRICLE !
Sorry to be snyde, but the Sun isn't built for that kind of work.
Unix isn't either. If you can find a way to hook everyone in (MUX)
and they all ask to compile or use 'vi', the system will thrash
for a long time. On the ofhter hand if everyone pecks away in 'ed'
and rarely do anything else it might be ok.
Rick
-----------------------------
Date: Thu, 19 Jun 86 06:39:18 edt
From: allegra!mp@seismo.CSS.GOV
Subject: 12MHz vs. 16MHz 68881 comparison?
Has anyone who has both "old" and "new" Sun-3's done any timings to see
how much faster the system can do floating point with the 16MHz 68881?
We have only the "old" 12MHz versions, and we're contemplating buying upgraded
boards if it looks worthwhile.
Mark Plotnick
allegra!mp
-----------------------------
Date: Sat, 21 Jun 86 11:43:28 PDT
From: Dave Truesdell <davet%smaug@rand-unix.ARPA>
Subject: MDQS on Sun 3.0?
> Has anyone gotten BRL's `MDQS' spooling system working under version 3.0?
> Some of our users have reported that the "netsend" routine stopped working
> when they started running 3.0.
The Sun-3/75 I'm sending this from uses MDQS to spool all its printing
to our vaxen. The only problems I had with netsend, was with how data
was stuffed into the (I think) "rawreq" structures. Other than that
(and a couple of NULL pointer problems) it's been working fine, for
a couple of months.
If anyone's intersted, get in contact with me, and I'll dig up what we
changed.
David A. Truesdell
ARPAnet:
davet@rand-unix
UUCP/usenet:
{hermix,hollywood,litvax,trwrb,vortex}!randvax!davet
-----------------------------
Date: Fri, 20 Jun 86 13:15:12 edt
From: seismo!allegra!phri!roy@sally.utexas.edu (Roy Smith)
Subject: Adding an Eagle-and-a-half to a Sun?
We just got 2 3/180 file servers, each with a single Eagle. With
25 Mbytes wasted per client for root and swap and 8 clients each, we're
already in the market for more disks.
Solution #1 is to buy an expansion 380 Mbyte drive from Sun
directly. Even with the fairly substantial educational discount we get,
that's seems like a poor way to go.
Solution #2 is to get an Eagle from a third party. What problems
will I have doing this? Sun has some funny cable bulkhead arrangement;
this probably means I'll have to buy the vanilla Eagle from Joe's Deli and
Disk Empourium and then go back to Sun to get the cable sets. Yes?
What about the new 600 Mbytes Eagles? Does anybody have experience
adding one of them to a 3/180 with a plain Eagle? Can I expect them to
have the same (amazing) service record? Will there be any software
problems with having 2 different size drives on the same controller? Is it
simply a matter of telling the format/label/diag program the right number
of cylinders for each spindle?
Of course, there *are* other disks besides the Eagle. Everything
I've heard and read, however, has convinced me that there really isn't any
point considering them. Anybody care to refute this?
-----------------------------
Date: Mon, 23 Jun 86 17:59:39 -0100
From: Richard Tobin <seismo!mcvax!aiva.ed.ac.uk!richard@SALLY.UTEXAS.EDU>
Subject: Sunview?
I'm trying to convert a program I wrote under rel.2 sunwindows/suntools to
rel.3 sunview. (I can't even compile my release 2 version, contrary to the
claim in the sunview programmer's guide, because at least some #include files,
such as ttysw_impl.h, don't exist.)
The notifier/agent paradigm looks nice, and is just the sort of thing I need.
Unfortunately, several essential features are either missing or undocumented.
I called sun uk technical support; they're going to call back when they've
read the manuals. In the meantime, can anyone help with these problems:
Almost all the tty subwindow documentation is gone. Does this mean that
functions like ttysw_input and ttysw_esc_extend are no longer supported?
Or is the documentation just incomplete?
I can't find any reference to tool_layoutsubwindows. I would have expected
there to be an attribute (perhaps FRAME_LAYOUT_PROC) to provide the same
functionality, but I can't find any mention of one. I tried using
tool_layoutsubwindows as before, and my routine gets called, but the
program then loops calling ttysw_prioritizer recursively... Anyone know
what to do?
Thanks in advance,
Richard Tobin, JANET: R.Tobin@uk.ac.edinburgh
AI Applications Institute, ARPA: R.Tobin@uk.ac.edinburgh@ucl-cs.arpa
Edinburgh University. UUCP: ...!ukc!edinburgh.ac.uk!R.Tobin
-----------------------------
Date: Thu, 19 Jun 86 18:33:09 EDT
From: lrj@tcgould.tn.cornell.edu (Lewis R. Jansen)
Subject: SL on Sun3?
I am trying to bring SL (Serial Line IP) up on a Sun 3/52 running
Sun Unix 3.0. When i make a kernel with the mods, the sun seems to behave
alright, but when i bring up Suntools, and type a character into a window,
i get this error : 'ws_read_indev length error 1', whiel everything else
seems alright...
The other end of the ttyline (which is what SL uses) is connected to a
VAX 11/750 with 4.2 BSD which already has SL running. I JUST got SL from
seismo.arpa, so it is definitely the 'latest' version.
Anyone have any ideas? The reaspn i'm using SL is because we don't have
everything for our ethernet yet... we're waiting for delnis & taps from
DEC...
-- lewis r. jansen, lrj@lasspvax.tn.cornell.edu
-----------------------------
Date: 5 Jun 86 12:35 EST
From: montnaro%chenengo.tcpip@ge-crd.arpa
Subject: Maintaining multiple objects on mixed Sun systems?
(Pardon me if this topic has been discussed already. We have been
disconnected from Sun-Spots for awhile.)
One problem that all the recent advances in Sun hardware and software has
created is the need to maintain multiple versions of tools and libraries on
a single server node. I am aware of three distinct hardware/software
categories. There are probably other (minor) categories. With the growing
availability of NFS for a number of computers, the situation is not likely
to improve.
Sun-2 hardware running Sun Unix 2.x
Sun-2 hardware running Sun Unix 3.x
Sun-3 hardware running Sun Unix 3.x
Our site has Suns which fall into all three categories. Some third party
software, such as the Template graphics package and GNU Emacs, are centrally
located in order to minimize disk space gobbling. In order to try and not
duplicate the source code three times and still have make work properly, I
am trying the following (for Template - GNU Emacs will probably take
something more complex):
1. Under each source code directory (SRC), create 68010-2, 68010-3, and
68020 subdirectories, as necessary.
2. In the new directories, create symbolic links for all source files,
makefiles, necessary directories relative to them, etc.
3. Add the following new targets to the makefile in the SRC directory:
# The driver target is the first target in the Makefile.
driver :
if [ ! -f /bin/sun2 ]; then \
(cd 68010-2 ; make sun2_2); \
elif sun2; then \
(cd 68010-3 ; make sun2_3); \
else \
(cd 68020 ; make sun3_3); \
fi
sun3_3 :
<actions for Sun-3 running rev 3>
sun2_2 :
<actions for Sun-2 running rev 2>
sun2_3 :
<actions for Sun-3 running rev 3>
Execution of "make" from SRC will cd to the appropriate machine-specific
directory and make a single target.
This system is obviously very kludged. For instance, it is really only
useful for directories where one true target is of interest. It also
requires you to access the directory from all the different types of
machines on which the software runs.
Can anyone suggest a cleaner way to do this? Perhaps there is a Sun
Microsystems software developer out there who reads this list and can give
some hints based on past experience. Any and all suggestions are
appreciated. I will summarize the responses I get if there appears to be
much interest.
Thanks,
==========
Skip Montanaro
ARPA: montanaro@ge-crd.arpa
US Mail: General Electric Company
Corporate Research and Development
P.O. Box 8
Bldg KW, Room C210
Schenectady, NY 12304
Phone: 518-387-7312
==========
-----------------------------
Date: Tue, 24 Jun 86 21:26:08 PDT
From: John S. Watson <nike!watson@lll-tis-b.ARPA>
Subject: Request for Visual Calculator?
Does anyone have a visual, window based calculator-tool for the Sun Workstion?
There are many time when I am at my Sun and I need to do a quick calculation.
The Unix bc and dc are alright, but sometimes I would like something more visual
and mouse oriented. I looking for something like the demo on Apollo
workstations; it would be alright if it had more functions though.
Thanks in Advance,
John S. Watson
NASA Ames Research Center
ARPA: watson@titan.arc.nasa.gov
UUCP: nike!watson
-----------------------------
Date: Thu, 26 Jun 86 14:25:54 EDT
From: Steve D. Miller <steve@mimsy.umd.edu>
Subject: 3.0 lockscreen/kernel bug?
It seems that in vanilla Sun 3.0, running lockscreen in suntools
and then pressing the left, then the right (pressing right button
is perhaps not necessary) mouse buttons will crash the kernel in
win_send_one. Somehow, it is trying to access an invalid address;
win_send_one is in sunwindowdev/win.c, and the place it dies is
after the debug printf for LOC_TRAJECTORY, and before the printf
for "vuid"...probably in the first expansion of the win_getinputcodebit
macro, but I'm not 100% positive.
I'm running with click_to_type enabled for SunView; I haven't
tried to crash it with that off, but I can crash it consistently
with the mouse clicks above.
Has anyone else stumbled across this, and perhaps even stumbled
across a fix? No sense reinventing the wheel if I can avoid it...
-Steve
Spoken: Steve Miller ARPA: steve@mimsy.umd.edu Phone: +1-301-454-4251
CSNet: steve@umcp-cs UUCP: {seismo,allegra}!umcp-cs!steve
USPS: Computer Science Dept., University of Maryland, College Park, MD 20742
-----------------------------
Date: Tue, 24 Jun 86 02:44:28 cdt
From: usl!jew@SALLY.UTEXAS.EDU (James E. Wilson)
Subject: Benchmarks and info on file servers
I am looking for bibliography and references to materials pertaining to
benchmarks and information on file servers. I have particular interest
in materials relating to the Sun NFS or Apollo Domain systems, but any
similar references and pointers to information would be most useful.
Anything you can possibly send by E-mail or snail mail would be appreciated.
Thank you.
Jim Wilson
US Mail: USL P.O. Box 45147, Lafayette, LA 70504; tel. (318)231-6423
UUCP: {ut-sally, akgua}!usl!jew ARPA: usl!jew@ut-sally
-----------------------------
Date: Tue, 24 Jun 86 15:42:19 PDT
From: gerolima@Ford-wdl1.ARPA (Mark Gerolimatos)
Subject: NFS hanging...yow?
For weeks, I read all the scare stories about NFS mounts hanging.
The biggest fear was a Sun III sucking off of a Sun II. I can tell
you now that that is not much of a problem, as long as there aren't
too many Sun III's mounting the Sun II file system.
What I've been having problems with is
1)Sun II (version 2.0, not 2.2) sucking off of a Sun III (version 3.0,
as opposed to 3.2). I can get a listing of a directory fine, but a global
grep, make, etc hangs. Quite often, the only way out is to reboot the
machine (when this happens in console mode).
2)Sun III's mounting off of a sick Sun III. In this case, we mounted a
3.0 system NFS SOFT (not hard, soft) on our 3.0 system. When the serving
system went down (we were experimenting with level 1 trancievers on a Sun III,
a futile, failed, but noble experiment), the client machine hung. Correct
me if I'm wrong, but a soft mount should fail, and not hang. Right?
(Note: Sun III soft mounts from Sun II's do indeed time out)
P.S. Trick questions: how do you do ttysw_{in,out}put(), or WIN_ATTR_LIST in
Sunview? *sigh*
"For almost a quarter of a century..."
"...Change Baby, Don't Worry!... Mark Gerolimatos
...Welcome! Welcome!... ARPA: gerolima@ford-wdl1.arpa
...Change Baby, Don't Worry!... UUCP: {sun,fortune}!wdl1!gerolima
...Box! Box! Box! Box!... AT&T: (415) 852-4105
...Now, We Say Good-Bye... Mail: c/o Ford Aerospace
...Welcome to the GALATT... 3939 Fabian Way
...G-A-L-A-T-T We're GALATT..." Palo Alto CA 94306
-English phrases from a Japanese song Mail Stop X20
-----------------------------
Date: 25 Jun 86 03:58:00 PDT (Wed)
From: vis!greg@nosc.ARPA
Subject: SCSI disks & SCSI ports?
I'm an independent consultant with a SUN-2/50 with SCSI disk
and tape. I'm shopping for a second SCSI disk. I'd like to
get one with more than 71Mbytes if possible, but havn't found
a supplier. I'd be interested in hearing from anyone who's
found and successfully installed third-party SCSI disks. I'll
summarize the responses I get.
I'm also interested in getting a few more ports. Does anyone
have any experence adding third party SCSI ports to SUNs?
Again, I'll summarize any responses.
Thanks,
_Greg
J. Greg Davidson Virtual Infinity Systems
+1 (619) 452-8059 6231 Branting St; San Diego, CA 92122 USA
greg@vis.uucp ucbvax--| telesoft--|
davidson@sdcsvax.uucp decvax--+--sdcsvax--+--vis
davidson@sdcsvax.ucsd.edu ihnp4--| noscvax--|
-----------------------------
End of SUN-Spots Digest
***********************