Sun-Spots Digest, v6n95
William LeFebvre
Sun-Spots-Request at RICE.EDU
Mon May 23 02:48:25 AEST 1988
SUN-SPOTS DIGEST Saturday, 21 May 1988 Volume 6 : Issue 95
Today's Topics:
Re: Suns lose track of the console (2)
Re: SLIP on Sun-OS 4.0 - don't hold your breath
Re: apl for suns
rlogin window size bug
silly behaviour of dbx(tool)
Fixing Client Boot Failures
File system reorganization under 4.0
Shared memory references?
PSImail for Suns?
Dual-porting on Xy451?
/tmp on a NFS server?
text: table is full?
Query on 386 machines
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: Wed, 18 May 88 14:21:00 EDT
From: mcgrew at topaz.rutgers.edu (Charles)
Subject: Re: Suns lose track of the console (1)
Reference: v6n89
Robert Drzyzgula writes:
> Does anyone know why Suns lose track of thier console? ... The
> Sun will not respond to any terminal input, *even break*!
We've seen this problem on our suns from time to time (though we run a
hacked 3.2). What happens is the getty becomes disassiated with the 'a'
port somehow, so input from the terminal goes nowhere. Coming in over the
network and killing the getty (so a new one spawns) clears the problem.
Charles
------------------------------
Date: Wed, 18 May 88 11:52:15 PDT
From: Brent Chapman <capmkt!brent at cogsci.berkeley.edu>
Subject: Re: Suns lose track of the console (2)
Reference: v6n89
I ran in to a similar-sounding problem several releases back. The
solution turned out to be very simple: delete /dev/kbd, /dev/mouse, and
/dev/fb. These are the devices that control the keyboard, mouse, and
frame buffer on a workstation. If you're using a terminal for your
console, you don't have any of these; by deleting them, you avoid certain
SunOS bugs that cause them to be used when they shouldn't be... That
might solve your problem.
-Brent
Brent Chapman Capital Market Technology, Inc.
Senior Programmer/Analyst 1995 University Ave., Suite 390
brent at capmkt.com Berkeley, CA 94704
{lll-tis,uunet}!capmkt!brent Phone: 415/540-6400
------------------------------
Date: Wed, 18 May 88 12:07:39 PDT
From: Brent Chapman <capmkt!brent at cogsci.berkeley.edu>
Subject: Re: SLIP on Sun-OS 4.0 - don't hold your breath
Reference: v6n89
Ted Nolan (ted at braggvax.arpa) writes:
# Well, I suspect there will be a SLIP for 4.0 shortly after it goes out the
# door. I say this because we have just gotten PCNFS 3.0 and it supports
# SLIP. Sun has included dialup SLIP for the Sun as part of the server
# utilities disk, and I can't see them saying that they won't provide it for
# SunOS 4.0 given it's now officially part of one of their products.
I'm not so sure of this. In the "Sun Unbundled Software Availability"
table that was a part of the "When Should I Upgrade to SunOS 4.0?" letter
that I (and presumably all other support contract primary contacts) got,
PC-NFS 3.0 (which I received as an upgrade last week) is available in a
binary-compatible form for SunOS 4.0 right now, _but_ there is a footnote
that says "Availability of PC-NFS support for serial lines [SLIP] under
SunOS 4.0 to be announced at a later date.". There is no date listed for
"full functionality under 4.0" for PC-NFS 3.0. There is something
labelled simply "PC-NFS" (do they mean a version newer than 3.0?) that the
chart says will never run under SunOS 3.x, and which has a "full
functionality under 4.0" date of "TBA".
In other words, Sun has _not_ committed itself to supporting SLIP under
SunOS 4.0. They have said they would announce the _availability_ of it
later; they might very well announce that it won't be available. I
certainly hope not. In any case, who wants to buy PC-NFS just to get SLIP
for UNIX to UNIX use?
I'm curious about several things:
How many people/organizations/whatever _use_ SLIP on their Suns?
For how many machines?
Over dialup lines?
How many _would_ use SLIP if it were a part of the SunOS release?
For how many machines?
Over dialup lines?
How many would pay for SLIP as an unbundled product from Sun?
How much would you pay?
-Brent
Brent Chapman Capital Market Technology, Inc.
Senior Programmer/Analyst 1995 University Ave., Suite 390
brent at capmkt.com Berkeley, CA 94704
{lll-tis,uunet}!capmkt!brent Phone: 415/540-6400
------------------------------
Date: Thu, 19 May 88 09:15:37 EDT
From: ted at braggvax.arpa
Subject: Re: apl for suns
There is a version of APL on the 4.2 and 4.3BSD distribution tapes. It's
for PDPs and vaxen, but I suspect it would run on Suns with some work.
I'm not sure about the legal status, but I suspect you don't need a Unix
src liscense.
Ted Nolan
ted at braggvax.arpa
Here's the contact information from the README:
Title: APL
Authors: John D. Bruner
Lawrence Livermore Laboratory
P.O. Box 808, L-276
Livermore, CA 94550
(415) 422-0758
Prof. Anthony P. Reeves
Cornell University, Phillips Hall
Ithaca, NY 14853
(607) 256-4296
Description:
This is Purdue/EE's APL, which runs on both PDP-11's and VAX-11/780's.
This APL originally was written by Ken Thompson at Bell. It went to
Yale for a while, and came to Purdue via a Chicago distribution in (I
think) 1976. Jim Besemer (now with Tektronix in Oregon) made many
of the extensions to the original V6 PDP-11 version, including
quad I/O functions, the state indicator, internal label processing,
and a number of primitive functions. I began support of APL when
Jim left in 1978 and have been handling it since then.
The driving force behind all of the development and maintenance of APL
at Purdue has been my major professor, Dr. Anthony P. Reeves. Please
forward bugs/comments/suggestions to Dr. Reeves or to me (UUCP site
"pur-ee", login names "reeves" and "bruner").
------------------------------
Date: Thu, 19 May 88 11:43:11 CDT
From: William LeFebvre <phil at rice.edu>
Subject: rlogin window size bug
I have noticed this bug on release 3.2 and 3.5. I currently have no
way to check 3.5.1. Sun has been notified of this bug (I sent the message
at least, but I haven't gotten an acknowledgement yet).
Problem:
In a SunView shelltool, an rlogin session does not correctly
propagate window widths in excess of 127 columns.
Repeat-by:
When running suntools, start up a shelltool. rlogin to your
favorite host (you can even rlogin to yourself). Type
"stty everything" and look at the number of columns.
Move the window all the way to the left. Stretch the window
all the way to the right (making it as wide as the screen will
allow). Type "stty everything" again. The number will be
completely unreasonable: something above 65000. At this point,
termcap will start returning "0" for the "co" capability. This
renders some termcap/curses based programs useless.
Conjecture:
It is a fact that the tty driver under SunOS stores the width
and length in full-sized ints. Look at "struct ttysize". I
suspect (based on the definition of a "struct winsize") that
rlogin propagates this information in an unsigned short. If
this is true, it could be that the receiving end forgot it was
unsigned.
Suggested-fix:
Requires source that I don't have access to.
Submitted-by:
William LeFebvre
Department of Computer Science
Rice University
<phil at Rice.edu>
------------------------------
Date: Thu, 19 May 88 05:15 EDT
From: DAVIS at scrvx2.sdr.slb.com
Subject: silly behaviour of dbx(tool)
The following was reported by a user here. I'd like to know if anyone else
has any comments or ideas before I make a fool of myself with our local
sun office.... Of course, `void' is a keyword in C, but then our user was
debugging Fortran :-)
In the program below dbx (tool) gets void as a static real of dimension
[3,101] instead of being a real variable [2,100].
integer i,j
parameter (i = 100)
real*4 vg(0:i,2), void(0:i,2)
do 10 j=1,i
vg(j,1)=10
vg(j,2)=20
void(j,1)=11
void(j,2)=22
10 continue
end
If I try to print void then I get "syntax error". The variable vg is
handled correctly.
The problem seems to be the name of the variable 'void'. If I change it to
svoid as below,
integer i,j
parameter (i = 100)
real*4 vg(0:i,2), svoid(0:i,2)
do 10 j=1,i
vg(j,1)=10
vg(j,2)=20
svoid(j,1)=11
svoid(j,2)=22
10 continue
end
In this case if I ask whatis svoid then I get the correct answer and can
print the contents of the array. The bug seems to be associated with the
variable name void. In this second case if I ask whatis void then the
answer is
fortran print decl
the same answer if I ask what is real, complex or char.
------------------------------
Date: Wed, 18 May 88 11:16:17 EDT
From: umix!lokkur!scs at rutgers.edu (Steve Simmons)
Subject: Fixing Client Boot Failures
We have an irregular failure with clients hanging during the boot process.
It's not clear *why* they fail, but fixing it is easy. The cause is
always the device files getting scrambled. The fix:
Mount the client partition on the server. Remove all of the entries in
/dev except MAKEDEV. In the client /dev, give the command MAKEDEV std
pty0 pty1 pty2 win[I forget]. This will rebuild the entire /dev
directory for you. The client will then (usually) come up fine.
On less frequent occasions the entire client root partition is scrambled.
These things usually happen in bunches -- 3 to 10 in a cluster. Then
things will be fine for months. We make no changes to the nd.local files,
and are running 8-9 clients per server under 3.4. It's been happening
since 3.0, tho. Anyone seen similar problems?
Steve Simmons
UNIX Systems Mgr, Schlumberger CAD/CAM
scs at applga.uucp
------------------------------
Date: Tue, 17 May 88 09:57:54 BST
From: Ian Phillipps <mcvax!camcon!igp at uunet.uu.net>
Subject: File system reorganization under 4.0
Reference: v6n77
> Many readers of this list may have heard of the upcoming release of a
> major SUN operating system titled 4.0 -- but many may not have heard about
> the many fundamental changes in Unix that are coming along with it.
> Also, /bin no longer exists! Its contents live in /usr/bin. Also,
> /lib no longer exists. Its contents have been moved to /usr/lib.
IS THIS A SPOOF? What about all those scripts that start "#!/bin/csh" What
about all the shell scripts and makefiles which call up /bin/sh
explicitly? Broken, every one! [[ Not necessarily... --wnl ]]
> Executables from /etc are in /usr/etc. Also, /usr is to be mounted
> read-only.
Now you ARE joking. Aren't you? Where do user files go?
> Executables from the root directory reside in /single.
> Comments anyone?
I can see a few symbolic links appearing if this is really true.
[[ According to earlier discussion in Sun-Spots, /bin will be a symlink to
/usr/bin, and similarly for /lib. --wnl ]]
UUCP: ...!ukc!camcon!igp | Cambridge Consultants Ltd | Ian Phillipps
or: igp at camcon.uucp | Science Park, Milton Road |-----------------
Phone: +44 223 358855 | Cambridge CB4 4DW, England |
------------------------------
Date: Wed, 18 May 88 17:45:54 edt
From: mlijews at nswc-wo.arpa
Subject: Shared memory references?
Does anyone have some good references for using the System V shared memory
stuff. I am contemplating a project which could make good use of these
goodies and would appreciate any references you could give, be they
programs you've written, books or articles. Thanks.
Mike Lijewski (mlijews at nswc-wo.arpa)
Applied Math Branch
NSWC
Silver Spring, MD 20903
------------------------------
Date: Thu, 19 May 88 05:08 EDT
From: DAVIS at scrvx2.sdr.slb.com
Subject: PSImail for Suns?
I have heard rumours that someone has written a version of DEC's PSI
(packet switch interface) mailer for Suns. Does anyone now anything about
this ? We are connected to an internal net composed chiefly of VAXen, and
currently have to run all our mail out through an Exos/PMDF gateway on one
of our own VAXen. To be able to send and recieve PSI mail (as all of our
net traffic is that comes from elsewhere) directly on the Suns would be
wonderful, and we could then concentrate on using the OSI and X25/X29
software we already have...
------------------------------
Date: Thu, 19 May 88 15:03:13 +0300
From: leonid at TAURUS.BITNET
Subject: Dual-porting on Xy451?
Has anyone out there tried to connect dual ported SMD disks (e.g. 2361) to
two different 451's on two SUNs ? Sun people claim this is impossible on
the device driver level, but it seems something worth a try.
[ I known BSD file system doesn't support dual-porting, but mounting read
only a dual-ported filesystem works find on BSB ]
Leonid
------------------------------
Date: Thu, 19 May 88 09:49:21 EDT
From: Peter Marshall <peter at hadrian.uwo.ca>
Subject: /tmp on a NFS server?
We have a pair of SUN 3/60s each with a 144MB SCSI drive. We have the
file systems cross mounted (/usr/src/usr.local on one machine, /usr/ucb on
the other etc.) to save space and still give each machine local paging and
swapping space. We made a change recently to one of the machines by
making /tmp (in the "a" partition) a link to /usr/tmp where /usr was
mounted from the other machine. Suddenly after an hour of use or so I
started getting messages from commandtool windows about problems with the
disk structure with a diagnosis that it was probably full. The only way
to continue was to turn off scrolling in the window. Periodically
mailtool would hang up in a disk wait state.
We tried a number of things to correct this problem (like increasing the
amount of free space on the disks) but the problem persisted. When we hit
upon putting /tmp back on the local disk everything worked just fine
again. (The timing relationship between moving /tmp and the problems with
the screen programs was not as obvious at the time!)
Has anyone else seen symptoms like this? Is there something about /tmp
files that means that they cannot wait for an NFS server to fire up before
giving up? Is this going to be a problem with (future) diskless clients
that we might add (that will not use ND)?
We currently get a fair number (4 or 5 times a day) of
NFS server hadrian not responding still trying
NFS server hadrian ok
messages, often when "hadrian" is doing very little. There is very little
pause between the messages. Is this normal or related to the above
problem?
Peter Marshall, Data Com. Manager, NSC 220, CCS, Univ. of Western Ontario
519-661-2151 peter at hadrian.uwo.ca peter at julian.uucp pm at uwovax.bitnet
------------------------------
Date: Thu, 19 May 88 10:48:04 EDT
From: ufnmr!ufnmr_1!gareth at bikini (Gareth J. Barker)
Subject: text: table is full?
Can someone please tell me what the 'text' in the 'text: table is full'
message is. Is the size of the table definable in the kernel
configuration files, and what trade-offs are involved in increasing it??
Thanks for any help,
Gareth J. Barker,
University of Florida,
Department of Radiology.
BITNET : GJBARKER at UFFSC.BITNET
INTERNET : ufnmr!gareth at BIKINI.CIS.UFL.EDU
UUCP : ...gatech!uflorida!ufnmr!gareth
------------------------------
Date: Thu, 19 May 88 14:31 +1000
From: Robert Smart <munnari!ditmelb.oz.au!SMART at uunet.uu.net>
Subject: Query on 386 machines
Do the new Sun 386 machines support the sunlink protocols? For sunlink
X.25 this requires that the serial ports be capable of handling
synchronous communications.
Bob Smart, CSIRO Division of Information Technology, Australia
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list