Sun-Spots-Request@RICE.EDU (William LeFebvre) (07/01/88)
SUN-SPOTS DIGEST Thursday, 30 June 1988 Volume 6 : Issue 128
Today's Topics:
Re: pointers to Clearpoint (Helios actually)
Re: looking for comments on the 15-pin ethernet connectors
Re: bind: address already in use
Re: Sun 4 cc(1) bug
What "real" glare filters do
Deliver mail to receiver's login directory
timed doesn't work
Possible problem with several Interphase controllers on a Sun-4/280
need advice diagnosing system or hardware problem
Support for GP boards?
OS 4.0 on Multibus?
Send contributions to: sun-spots@rice.edu
Send subscription add/delete requests to: sun-spots-request@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@rice.edu" or mail the word "help" to the same address
for more information.
----------------------------------------------------------------------
Date: Tue, 21 Jun 88 19:43:08 EST
From: kimery@helicon.math.purdue.edu (Sam Kimery)
Subject: Re: pointers to Clearpoint (Helios actually)
> (Joel Conklin writes):
>Helios Systems also sells memory for the entire SUN product line....
Helios also isn't shipping ANY 3/260 memory. I have several pieces "on
order" that have been promised to ship on "Friday" for 2 months now!
(guess I should pin down which Friday rather than assume :-)) The rather
obnoxious thing about the delay is that I was assured that the boards were
shipping when I ordered in March. Buyer beware.
Sam Kimery - System Admin. - Math Department Purdue University
UUCP: !{decwrl,gatech,ucbvax,ihnp4}!purdue!kimery
ARPA: kimery@purdue.edu BELL: 317-494-6055
------------------------------
Date: Mon, 20 Jun 88 11:16 CDT
From: David F. Dow <dow@MCC.COM>
Subject: Re: looking for comments on the 15-pin ethernet connectors
[[ This was forwarded from a reader of the "tcp-ip" ARPANet list. --wnl ]]
Since everyone is knocking this one around, let me insert my pet peeve.
On Sun's 3/160 and 3/260 machines (and perhaps others) have you noticed
what is right next to the fickle slide lock? THE RESET BUTTON! I don't
care to think how many times our servers have gone off the air from the
slide connector falling out, soon followed by a crash of the system from
hitting the reset button while trying to replace it. grrrrr.
Regards,
-- David F. Dow
------------------------------
Date: Wed, 22 Jun 88 09:30:25 CDT
From: "Matt Crawford" <matt@oddjob.uchicago.edu>
Phone: +1 312 702 8207
Subject: Re: bind: address already in use
Reference: v6n118 and others
Stephen Roznowski writes:
> Daemons like SMTP (sendmail) initially listen on port 25; when a connect
> request comes in, it forks a copy of itself and rebinds to the first
> available port less than 1023 (a priviliged port).
This is not correct. Sendmail listens on port 25 by creating a socket and
binding it to port 25. (This is the step that fails if you start a second
sendmail daemon.) The remote end is still unspecified. When a connection
comes in a new socket is created whose local end is still on port 25, but
whose remote end is now bound to the address and port of the mail sending
daemon. Sendmail forks and the child closes the listening socket while
the parent closes the new socket.
To digress a little, a TCP connection is identified by { local addr, local
port, remote addr, remote port }. If your system is receiving two
messages from the same host at the same time, then you have two
connections which are identical in the first three of these four
parameters.
If you try to start a second copy of a TCP server, the new copy will fail
to bind to the reserved port (e.g., 25 for sendmail). If, however, you
start a second copy of an RPC server, the new copy will cancel the old
one's registration with the port mapper. All requests will then go to the
new copy and the old one will be idle.
Matt Crawford
------------------------------
Date: Wed, 22 Jun 88 10:31:06 edt
From: mp@allegra.att.com
Subject: Re: Sun 4 cc(1) bug
I tried the program on a few systems here (Sys4-3.2L, -3.2, and 4.0), and
it looks like a bug in the C compiler in Sys4-3.2 and beyond. It works
fine on a Sys4-3.2L system here. The problem sems to be that the floating
point value isn't being converted into a double before being passed to
makereal(). Changing the call to be
value=makereal((double)f);
produces the necessary conversion code.
Mark Plotnick
allegra!mp
------------------------------
Date: Wed, 22 Jun 88 9:56:25 EDT
From: Bernie Cosell <cosell@wilma.bbn.com>
Subject: What "real" glare filters do
The real glare filters (as opposed to the ersatz menagerie of screens and
micro-venetian-blinds and other junk that masquerade as glare screens)
have a circular polarizer. I don't understand the stuff, but what it does
is polarize light as it goes through it AND rotates the polarization axis
90 degrees. Thus, incident light goes through the filter, is polaraized
and rotated, bounces off the screen, but is now cross polarized and so
BLOCKS the light as it reflects back... bingo no glare. After many
frustrating run-ins with the pretenders to the name, I bought myself one
(no hope of geting my company to pay for the thing, no matter how useful
it seemed to be) and it was *wonderful*. (this was for a terminal with a
screen 1/2 the size of a 19" SUN, and the thing cost around $120). They
also have an antiglare coating on the front surface (just like
photographic lens) to cut down front-surface glare.
I don't know about the radiation stuff -- I'd bet that it is mostly
spurious. A reaction to the "VDT's cause <thisorthat>" hysteria that
lurks about (I'm sure you can also buy "anti-unintended-acceleration kits"
for Audis from enterprising marketers :-))
__
/ ) Bernie Cosell
/--< _ __ __ o _ BBN Labs, Cambridge, MA 02238
/___/_(<_/ (_/) )_(_(<_ cosell@bbn.com
------------------------------
Date: Wed, 22 Jun 88 10:34:19 EDT
From: jas@proteon.com (John A. Shriver)
Subject: Deliver mail to receiver's login directory
Mail is delivered to /usr/spool/mail so that /bin/mail does not have to
run setuid to root. Of course, it seems that everyone runs it that way,
anyways, which in most versions of Unix has been a pathetic security hole.
Note that /usr/spool/mail is world-writeable, so /bin/mail would not need
to be setuid root. (Which has the down side that anyone on the machine
can delete your mail.)
If you deliver mail to a user's home directory, you probably will have
/bin/mail need to be setuid root. (We avoided this on a V7 Unix
system here where mail went to home directories by having the mailer
run set-group-id to mailer, and the user's incoming mail box had to be
group mailer, and their home directory had to have world serach [x]
privilege. However, it was Very easy for a user to mess this up and
not get mail.)
Also, the use of /usr/spool/mail may also have something to do with the
rather feeble interlock on updating mailboxes simultaneously. (It does
not use flock().)
[[ It does not use flock because flock didn't exist when /bin/mail was
first written. In fact, flock is a recent addition to BSD and SunOS. The
old-style locking scheme is hardly "feeble". When done correctly, it
worked rather well (of course, this was before the days of the Network
File System). --wnl ]]
------------------------------
Date: 21 Jun 88 22:31:34 GMT
From: Karl Berry. <umb!karl@husc6.harvard.edu>
Subject: timed doesn't work
What else has to be done to invoke the time daemon besides saying
`/usr/etc/in.timed' to the shell?
(And/or putting it in one of the /etc/rc files.) This is on a Sun 3/140
running 3.4. When I do that, it gives me eight characters of garbage
followed by the hostname, as in
&ia red
(with no newline afterwards). When I tried to compile the Vax timed (which
supposedly has support for the 68000), I ran into many undefined TSP_???
constants, thus concluded that approach wouldn't work.
Any help?
Karl. karl@umb.edu ...!harvard!umb!karl
------------------------------
Date: Wed, 22 Jun 88 01:33:56 +0200
From: Per Westerlund <perw@holtec.se>
Subject: Possible problem with several Interphase controllers on a Sun-4/280
FYI, if You are going to use more than one Interphase controller on a
Sun-4/260 or Sun-4/280, one Phoenix and one V/TAPE for instance, make sure
that the revision level on the CPU board is 12 or more. On boards with
lower revision levels than 12, the VME spec. is violated slightly, but
enough. Symptom: VME timeouts (and system crashes) when more than one
controller is used "simultaneously".
Per Westerlund
P.S. I am using OS 4.0
------------------------------
Date: Tue, 21 Jun 88 22:08:28 PDT
From: haynes@ucscc.ucsc.edu (99700000)
Subject: need advice diagnosing system or hardware problem
We have a 3/280 running 3.5, no workstations, 32 RS232 ports, Ethernet.
Occasionally the machine slows to a crawl, fails to echo input characters
on terminals and console, suggestive of an extremely high interrupt load
sucking up all available cpu time. However we can ping it from another
machine and response to ping is entirely normal.
The last time this happened we looked at the port selector and did not
find any lines showing lots of activity as might happen with a noisy line.
Then we disconnected the Ethernet transceiver cable. There was no
immediate improvement, but a few minutes later the machine got well, and
stayed that way when we put the cable back on. During the bad time we
could (with some effort) get commands typed in to run things like ps and
vmstat, and didn't see anything unusual that way, except that in vmstat
the 'de' column consistently showed something like 73.
Can anyone suggest what we should be looking at to try to isolate the
problem?
------------------------------
Date: Tue, 21 Jun 88 14:31:01 CDT
From: Mark Hall <foo@Rice.edu>
Subject: Support for GP boards?
Does Sun support their graphics processor (GP) at any but the lowest level?
The GP and GP+ boards have a lot of power for doing 3D viewing in
hardware. If you don't believe it, run the demo programs for the GP.
Nice! So you want to write similar applications? You seem to be out of
luck.
The "Software Interface for the Sun Graphics Processor" manual lists
several programming levels:
1) SunCore - An ACM Standard from 1979 that was never approved
and has lots of overhead. Sun's demo programs don't
use this, probably because the overhead would make
the board look too slow.
2) SunCGI - 2D package that doesn't use the power of the GP
3) Pixrects and Pixwins - ditto 2 above
4) Command Interface Level - the lowest level without writing
your own microcode
The 1 and 4 above are the only 3D levels. 4 would be the level of choice
since speed is (almost) always the concern for this kind of polygon-based
graphics. Sun provides two example packages that are built on top of this
level, DEV_GP1 and the VIEWPORT package. Sun's GP demos use these.
There are two major problems: the packages are unsupported and don't seem
to work. Sun's "shader" demo sometimes collides with the window system
("window lock broken" error message) or goes into a busy wait state
somewhere (CPU is pegged, once until SIGXCPU was sent to the process).
Here are some comments from the source to the GFXLIB for the GP:
* We trust the window system to reliably change the clip ID to indicate
* a window change. Most of the time this works, but the scheme is not
* foolproof.
*
* The GP1 has a bug which causes buffers full of large polygons to affect
* other graphics on the screen. If this is ever fixed, the polygon scheme
* might have to be changed. No attempt is made to shuffle polygon edges
* to a new buffer if the current buffer is overflowed. This might be a
* good idea in the future (as long as I don't have to do it).
Did the (hardware?) bug ever get fixed? What happens if the buffer does
overflow?
Has anyone fixed the DEV_GP1 stuff? Does anyone have any similar package
to drive the GP? Any help would be greatly appreciated.
- Mark Hall
foo@rice.edu
------------------------------
Date: Tue, 21 Jun 88 12:11:40 PDT
From: nosun!cvedc!opus!markh@sun.com (Mark Holm)
Subject: OS 4.0 on Multibus?
We recently received OS 4.0 from Sun to go on the Sun supported systems
that we have in the shop. Unfortunatly those machines are under rather
heavy use right now. So in an effort to prepare for the future I decided
to build a second set of system disks on my system, a CV 3311 (Sun 2/120
equivelant, all Sun boards - different cabinet), to move to the Sun 2/160
later. The problem that I ran into was that each of the different kernal
types (Munix, mini-root, and Generic) all panic when you try and run them
on this type of machine.
This machine has 4Mbytes of ram and a Sun boot prom Revision NA. Each
kernal panics at the same point. After answering all the startup questions
as stated (vaguely) in the manual, each kernal panics after declaring the
dump device. The trap address and traceback messages are exactly the same
for each one for example on Munix:
dump on ns0b fstype spec
:
trap address 0x8,pid 1,pc=470e,sr=2004,stkfmt 8,context 0
Bus Error Reg98<VALID,PROTERR>
access .... (ommitted for brevity)
traceback ... (ditto)
End traceback
Panic: Bus error
I tried this on 2 different 3311's and got the same results. Then in
desperation, I begged the use of the 2/160 for a day and loaded the disk
there. Everthing worked fine. I built a SDST120 kernal from the config
files and tried it again on my machine with both the rebuilt kernal and
the Generic one and again got the same results.
My questions are:
1. Has anybody else succeeded in getting 4.0 up on an 010 multibus machine??
2. Is there a rom revision level requirment for 010 machines that the manuals
failed to mention??
I asked these same questions of the Sun hotline but so far my request
seems to have been swallowed by a black hole even though I cross
referenced it to our machine with a service contract. The local Sun guys
have been sympathetic but they don't have any multibus machines to check
against.
Any suggestions or comments would be gratefully accepted.
[[ Aftger Mr. Holm sent this message, he received a response from hotline
and forwarded it to Sun-Spots. Here it is: --wnl ]]
> Yes, 4.0 does run on multibus systems (albeit slower than 3.x). What
> you are running into here is, I think, a hardware problem. If you check
> the part number on your CPU. If it is 501-1007, jumper J701 must be
> in. We have had a couple of customers already run into this. If you
> don't know where to find the part number for the CPU or whether jumper
> J701 is in or out, I would suggest placing a hardware call as I haven't
> the faintest idea on how to check either (I'm just a software dweeb ;-)).
> If this isn't the case, please let me know, and we can see what else might
> be wrong.
>
> Allan McKillop
> Sun Microsystems, Inc.
> Technical Support Engineer
> Internet: allan@sun.COM
> UUCP: ...!sun!allan
Mark Holm ..tektronix!ogcvax!cvedc!mholm
Computervision ..sun!cvbnet!cvedc!mholm
14952 NW Greenbrier Parkway Phone (503)645-2410
Beaverton, Oregon 97006 FAX (503)645-4734
------------------------------
End of SUN-Spots Digest
***********************