Sun-Spots-Request@RICE.EDU (William LeFebvre) (11/18/87)
SUN-SPOTS DIGEST Tuesday, 17 November 1987 Volume 5 : Issue 60
Today's Topics:
Administrivia
SunOS and Sun 2's
Re: Sun User Group Special Interest Coordinators Wanted
Re: Looking for sendmail.cf file working with three level domain
Re: sun laserwriter help
Re: named pipes, SVID fifos (2)
Re: Help with spurious level N interrupt
vt100tool confusion
Sun-3/50 hardware bug causes segmentation faults in user programs
A puzzle about bcopy()
Sun Education Jan. - June 1988 brochure
Problems with CDC 9720-736
C-Scheme installation to Sun3
Sun vs Apollo and now H.P.
Buying a Sun
----------------------------------------------------------------------
Date: Tue, 17 Nov 87 18:09:19 CST
From: William LeFebvre <phil@Rice.edu>
Subject: Problems with v5n57
Volume 5 issue 57 seems to have uncovered a serious but age-old problem
with the distributed Sun software. Silly me, I dared to send a message
that contained a dot on a line by itself. Many people have complained
about this issue being truncated, even when retrieved from the archive
server. John Gilmore sent me the following explanation:
I'm running SunOS 3.2, and the sendmail.cf that comes with it does not
turn on the "Oi" option, which disables the recognition of "." as a
message terminator on sendmail's standard input. "/bin/rmail" does not
turn on this option when it forks sendmail, either. When I added "Oi"
to sendmail.cf, rmail-ing periods to myself started working. This
should probably be fixed in the Sun software distribution.
Agreed! Meanwhile, what to do about v5n57? The copy currently in the
archives is fixed. If you now request a copy, you will get the whole
thing. But I suspect that this problem is sufficiently widespread to
justify re-sending the entire issue to everyone. If anyone has any strong
objections to this, please send them to "Sun-Spots-Request".
In the future, I will just avoid the problem.
William LeFebvre
Department of Computer Science
Rice University
<phil@Rice.edu>
------------------------------
Date: Sun, 8 Nov 87 17:57:03 PST
From: texsun!sun!path@sun.com (Pat Harding {Product Marketing})
Subject: SunOS and Sun 2's
Responding to Mike Shaddock's 10/28 plea for info on Sun-2 support, I wish
to assure you all that Sun-2 is alive and well. The forthcoming SunOS 3.5
(available Dec/Jan) provides Sun-2 support. The SunOS 4.0 alpha software
is up and running on Sun-2s also. In fact there are no plans for dropping
Sun-2 support. I foresee it extending at a minimum through the SunOS 4.x
series of releases.
Hope this helps.
Pat Harding
Product Manager, SunOS
path@sun.com
------------------------------
Date: Mon, 16 Nov 87 09:21:35 PST
From: weiser.pa@xerox.com
Subject: Re: Sun User Group Special Interest Coordinators Wanted
Sun-Spots recently redistributed my mail about Sun User Group Special
Interest Coordinators (thanks everyone for responding! and more responses
are welcome). Unfortunately I got my Sun mail forwarding address wrong.
Please reach me at: sun!mweiser or weiser.pa@xerox.com
-mark
[[ And please stop sending the responses to Sun-Spots! If you are
interested, please contact Mark directly. Thank you. --wnl ]]
------------------------------
Date: Tue, 3 Nov 87 12:52:00 PST
From: parns!harker@sun.UUCP (Robert Harker, all around good guy)
Subject: Re: Looking for sendmail.cf file working with three level domain
I am assuming that the problem you are having with your sendmail.cf file
is that it is unable to reconize mail directed to your own domain. Here
we run a third level mail domain with our parent or top level domain being
"nsc.com" and our local domain being "parns" with machine addresses being
"machine.parns.nsc.com". The problem we ran into was that the standard
Sun sendmail.cf files tack on the full domain to all addresses, even if
they are local addresses. Then when the mail was delivered, it would get
kicked up to our main mail machine which would then forward it to our
APRAnet forwarder.
With the standard Sun sendmail.cf files, they cannot reconize a top level
domain of the form "part1.part2". In your sendmail.cf file you have two
lines of the form:
DUnsc.com
CUuucp nsc.com com
The first sets your top level domain as "nsc.com", the second creates a
class of aliased top level domains which includes "uucp", "nsc.com", and
"com". The problem is that the Sun semdmail program cannot handle complex
names in classes (ie CU), so it drops the "nsc.com" entry. In your
Sendmail.cf file the testing for local mail with a full domain address (ie
"machine.parns.nsc.com") happens in ruleset 6. But this test is for the
class of top level domains, not the actual top level domain. To fix this
all you need to do is to add two new rules which test for the actual top
level domain. These are actualy just copies of two previous rules with an
"=" removed. To make this change look in ruleset 6 for a line:
R$*<@$*$=D.$=U>$* $1<@$2LOCAL>$5 or full domain name then
add the following lines after this line: # test for domain.universe
directly # $=U should work for nsc.com but dosen't so use $U directly
R$*<@$D.$U>$* $1<@LOCAL>$2 or full domain name
R$*<@$*$=D.$U>$* $1<@$2LOCAL>$4 or full domain name This
fixed the problem for my mail domain.
By the By, I called Sun software support about this and they know about
the problem and say it will be fixed in release 4.0.
Robert Harker, All around good guy.
harker@parns.nsc.com
{sun,decwrl,hplabs}!nsc!parns!harker
------------------------------
Date: Tue, 3 Nov 87 12:06:56 PST
From: parns!harker@sun.UUCP (Robert Harker, all around good guy)
Subject: Re: sun laserwriter help
We have our LaserWriter attached to a diskless Sun 120. The install was
easy, although it took a small trick. The trick is to do the install on
the server as if the LaserWriter was locally installed on the server.
Then when the install is complete you copy the printcap file generated for
the server to the client with the LaserWriter attached, deleting any bogus
entries for other printers. On the client you also link the device that
the Laserwriter is attached to to /dev/lw, ie:
ln /dev/ttyb /dev/lw
The last thing to do is to make sure that the server has an entry for the
LaserWriter that is remote printer entry, not a local printer entry, ie:
lw|ps|postscript|PostScript:\
:lp=:\
:rm=client:\
:rp=lw:\
:sd=/usr/spool/lw:
With these three simple steps, my diskless client was able to drive the
LaserWriter. Note, this assumes that the partition that the LaserWriter
bin and lib files are mounted on the client in the same place as the
server via the NFS(ie /usr/lical/bin, /usr/local/lib/lw. Also note for
other machines to be able use this printer they must be in the clients
/etc/hosts.equiv file.
Lasers Away
Robert Harker, All around good guy.
harker@parns.nsc.com
{sun,decwrl,hplabs}!nsc!parns!harker
------------------------------
Date: 6 Nov 87 18:13:10 GMT
From: arnold@emory.UUCP (Arnold D. Robbins {EUCC})
Subject: Re: named pipes, SVID fifos (1)
SVID compatible fifos are indeed in SunOS from Release 3.2 and later, but
they don't seem to be documented anywhere. The correct program for
creating fifos happens to be /etc/mknod, except Sun hasn't taught it about
fifos yet. [[ "/etc/mknod name p" seems to work for me. --wnl ]]
Here, off the top of my head, is some code to do it:
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
main(argc, argv)
int argc;
char **argv;
{
... check args etc....
if (mknod (argv[1], S_IFIFO | 0666, 0) < 0) {
fprintf (stderr, "%s: ", argv[1]);
perror ("mknod");
exit (1);
}
exit (0);
}
Very simple, although also very non-obvious...
Arnold Robbins
ARPA, CSNET: arnold@emory.ARPA BITNET: arnold@emory
UUCP: { decvax, gatech, }!emory!arnold DOMAIN: arnold@emory.edu (soon)
``csh: just say NO!''
------------------------------
Date: Fri, 6 Nov 87 14:22:57 CST
From: dave@rosevax.rosemount.com (Dave Marquardt)
Subject: Re: named pipes, SVID fifos (2)
Yes, System V FIFOs exist under SunOS 3.4. You need to add a few lines to
the configuration file, and create a new kernel from that configuration
file, and then you're all set. Oh, it might also be a good idea to install
the System V utilities from the tape(s).
options IPCMESSAGE # SystemV IPC Message Facility
options IPCSEMAPHORE # SystemV IPC Semaphore Facility
options IPCSHMEM # SystemV IPC Shared-Memory Facility
-Dave
------------------------------
Date: Fri, 6 Nov 87 17:06:39 PST
From: rusty%velveeta.Berkeley.EDU@berkeley.edu (rusty wright)
Subject: Re: Help with spurious level N interrupt
It could be your software's problem. It's been a while since I've done
any device driver hacking on a multibus sun but I seem to remember that
they used "polling": when a level N interrupt occured the kernel would
sequentially call the device driver interrupt routine for each device
which interrupts at level N and the interrupt routine had the
responsibility to check to see if its device generated the interrupt and
if it did it returned true, otherwise false (and also do its normal
interrupt routine work), whereupon the system wouldn't call any more of
the device interrupt routines. If all of them returned false then you get
the "spurious interrupt" message. Sometimes it may not be obvious (from
your hardware's documentation) what all bits and bit combinations could be
set to inform you that your device generated the interrupt and you could
be returning false when you should be returning true.
------------------------------
Date: 5 Nov 87 22:09:14 GMT
From: Tony E. Davis <tony%linus@mitre-bedford.arpa>
Subject: vt100tool confusion
> From: rtech!llama!sid@sun.com (Sid Shapiro)
> I am looking for a vt100-terminal emulator. I know about vt100tool -
> expensive for 20 or more workstations.
If you're talking about the vt100tool that I know about (it was written
here at MITRE) there must be some confusion. vt100tool is FREE; check the
comp.sources.unix archives, Volume 6.
Tony
Tony Davis
(617) 271-2146
The MITRE Corporation MS A455 Burlington Road Bedford, MA 01730 U.S.A.
tony@linus.b.mitre.org linus!tony tony%linus@mitre-bedford.ARPA
------------------------------
Date: Thu, 5 Nov 87 15:37:45 PST
From: hoptoad!gnu@cgl.ucsf.edu (John Gilmore)
Subject: Sun-3/50 hardware bug causes segmentation faults in user programs
I had a problem running the GNU C compiler wherein it would coredump with
a segmentation fault. If you ran it several times, it would coredump in
different places. It looks like when it loaded a pointer from a struct in
memory, it was getting data from 2 bytes away from where it should've
gotten it. The assembler code was very straightforward though, so I asked
a few people if it was a known problem. Richard Stallman says he had this
problem on a number of Suns at Berkeley, but eventually found one that
never did it, so he just used that one. He also reported that running
under the debugger with a breakpoint set anywhere in that page would cause
the bug to disappear. I tried running on the server, a 3/160, and the
problem did not arise. A friend at Sun confirmed that there *is* a
hardware bug with these symptoms in the Sun-3/50 and that I should call
Customer Support to get it fixed. There are also reportedly software bugs
in releases prior to 3.4 which can cause similar symptoms.
Customer Support did not know of a 3/50 hardware bug involving "bad
pointers crashing user programs" but they have a bug, documented in "Field
Alert #88", which is said to cause EMT traps and segmentation faults.
They were unwilling to send me a copy of the field alert so I could see
whether this is really the problem. They wouldn't say when the bug was
found or what serial numbers or rev levels are affected. But as I
understand it, this is a design bug, not a component failure.
Now, I'm a "time and materials" customer because Sun's service contracts
are too expensive for my taste -- so this costs me money. In fact, it
costs $2500 for Sun to ship me a fixed board on 1-day turnaround, or $2000
for them to come out in a day or two and swap it themselves (cheaper than
install-it-yourself!!!), or $1300 for my Sun to be down for a month while
they get around to fixing it. Sun-3/50's are sufficiently cheap and
depriciating rapidly since they are stuck at 4MB, so I guess I will just
live with the intermittent bug rather than sink $2000 into the system, or
even $1300. Probably the fix is an updated gate array that costs $10 and
plugs into a socket, or a couple of wires that I could solder, but Sun
doesn't offer those options.
If you have 3/50s and are on a service contract, I strongly recommend that
you call Sun to get this fix, since for you it will be free. It can make
a working program look like one with bugs, which is particularly horrid
when you are trying to debug a program.
I'm curious how many other people have seen this kind of problem on their
3/50's, and why it hasn't come up in Sun-Spots before.
John
------------------------------
Date: Wed, 4 Nov 87 14:28:51 PST
From: ultra!wayne@ames.arpa (Wayne Hathaway)
Subject: A puzzle about bcopy()
A puzzlement to me, maybe easy for a Sun expert?
I have written a kernel-resident "networking" package that in loopback
mode provides essentially the capabilities of UNIX-domain sockets. It is
packaged as a regular UNIX driver, accessible via read() and write(),
together with appropriate ioctl()'s for opening and closing connections
and the like. The main difference between it and sockets is that it does
not copy data into or out of the kernel; it uses the kernel bcopy()
routine to move data directly from one process's buffer to the other's.
And this works fine, achieving (again in loopback only) some impressive
transfer rates, like up to 7 megabytes per second on very large buffers
(e.g., 300000 bytes). To repeat and/or summarize: using the "ttcp"
source/sink programs, it can move a gigabyte from one process to another
over a loopback connection at a rate of up to 7 megabytes per second.
Now for the puzzle.
As I was demonstrating this for a co-worker, I mentioned that of course
this was not real "networking" since the data never left the host. In
fact, it was really only measuring the efficiency of the Sun bcopy()
routine, together with the per-transfer overhead of my "networking"
package (which is why it did better with very large buffers, of course).
Anyway, he mentioned that speaking of per-transfer overhead, did I know
how fast bcopy() would move data WITHOUT any overhead, just between
buffers in the same process? No, says I, but hey, that's easy, so about
ten minutes later I had my answer: a VERY puzzling 3.8 megabytes per
second!
After verifying both numbers as much as possible, I decided that the
difference must be in the two bcopy()s, the one in the C library and the
one in the kernel. And sure enough, "disassembling" them both with adb
(we do not have source, sigh) showed a LARGE difference. However, and
here's the real question of this tome, I do not have near enough 680x0
experience to even come close to understanding this further. For example,
if the kernel version is that much better, why not use it in user space?
Well, it does have some calls to "getpgmap" (whatever THAT is!), so ...
It also seems to have a magic lock bit (named "bcopys"): if it gets this
lock, it does a very complicated (and presumably faster) copy, and if it
doesn't get it, it does a simple "movl" loop with "movb" for the
leftovers.
Anyway, can somebody answer: (1) Is it reasonable to expect the kernel
bcopy() to be almost twice as fast, or is my experimental data totally
fubar? (2) What exactly is that kernel routine DOING? (3) Why isn't the
same thing applicable to user space?
Sorry for the length of this, but I HATE puzzles without the answers in
the back of the book!
Wayne Hathaway ultra!wayne@Ames.ARPA
Ultra Network Technologies
2140 Bering drive with a domain server:
San Jose, CA 95131 wayne@Ultra.COM
408-922-0100
------------------------------
Date: Wed, 4 Nov 87 02:36:19 PST
From: texsun!sun!susan@sun.com (Susan Morin)
Subject: Sun Education Jan. - June 1988 brochure
Sun Educational Services has sent out its brochure with course
descriptions and the January - June 1988 schedule. If you haven't received
your copy by November 15, 1987, please contact our toll-free number and we
will mail one out.
within California 800-423-8020
elsewhere in U.S. 800-422-8020
There are two new courses being offered. The first is a 3-day NeWS
Programming class, for those who want to build applications with Sun's new
Network extensible Window System. The second new course is a 5-day Sun-4
Customer Maintenance Training class, for those who must install, configure
and maintain Sun's new RISC-architecture workstation product line.
Our Milpitas facility has doubled in size. We now have 8 classrooms and 8
labs, so we can offer more classes. In addition, we are increasing the
number of offerings of System Administration. It is scheduled twice a
month in our Lexington, MA facility and every week except Memorial Day in
our Milpitas, CA facility.
We have also set up an electronic mail bulletin board so that you can
receive information about new courses as they become available. Send your
Usenet or ARPA address to sun!customer-training or customer-training@sun.com
and we will add you to the bulletin board. You can also use the
customer-training email id to send any questions you may have aobut Sun
Educational Services.
Susan Morin
Course Development Manager
Sun Educational Services
------------------------------
Date: Fri, 6 Nov 87 17:13:45 EST
From: lamont!rgb@columbia.edu
Subject: Problems with CDC 9720-736
I just received my first CDC EMD 9720-736 drive. I've set the sectoring
to the values Sun said they used on the EMD 386 drive. Since the number
of bytes per track is the same I figured this might be a good idea. Diag
comes back and says the drive is off cylinder and not ready. The drive
passes all it's diagnostics. Can anyone help out with the correct switch
settings?
Current setting are:
SWITCH POS SETTING MEANING
A213 1 off 1D
2 off 1D
3 on 2D
4 on 2D
5 off POK
6 on T1
7 on O
8 off N
9 off RT
10 on L
A224 all on Drive 0
Logical address switches all on
1.6Mhz sector clock on
Write Protect/normal on
Sector switches 2^0 2^5 2^9 on
Bob Bookbinder
lamont!rgb
UUCP: {ihnp4, decvax, seismo} philabs!lamont!rgb
ARPA: lamont!rgb@columbia.edu
------------------------------
Date: 5 Nov 87 02:48:48 GMT
From: kddlab!secisl.seclab.junet!tau@uunet.uu.net ("Yatchan" TAUCHI)
Subject: C-Scheme installation to Sun3
I will install C-Scheme to Sun3 (SunOS Rel.3.2). C-Scheme tape for
VAX/UNIX-4.{1,2}BSD and HP/HP-UX is available, but I do not know which is
easier to install to my Sun3. Because I have no experience to install any
software to VAX/UNIX-4.2BSD and to use HP/HP-UX.
If you did install C-Scheme to Sun3 or if you know which is easier to
install to Sun3, please let me know.
Yasuyuki TAUCHI, SECOM IS-Lab, Tokyo, JAPAN
Net: tau%seclab.junet@uunet.UU.NET
UUCP: ...!seismo!kddlab!titcca!secisl!tau
------------------------------
Date: Wed, 4 Nov 87 12:19:28 GMT
From: Dr R M Damerell (RHBNC) <damerell@nss.cs.ucl.ac.uk>
Subject: Sun vs Apollo and now H.P.
Many thanks to everybody who answered my question on this topic. I tried
to at least acknowledge all messages received, but there seems to be an
unreliable mailer somewhere...
One reply said "you ought to consider Hewlett-Packard as an alternative".
So I approached H-P sales, who offered what seems to be a very attractive
deal on maintenance. (and their hardware seems comparable in price with
Sun). Please does anybody wish to tell me their experience with H-P?
Well, I suppose this really ought to go to a H-P users list; but I cannot
find one.
Thank you,
Mark
------------------------------
Date: Thu, 05 Nov 87 08:22:34 -0800
From: Amnon Meyers <meyers%cip.uci.edu@cip.uci.edu>
Subject: Buying a Sun
I'm new to the Sun-Spots bboard, and have recently been looking at
purchasing a Sun for home use.
The cost for a configuration including Sun 3/60, 150 Mb disk, tape drive
and 4Mb extra memory is on the order of $15,000, which is prohibitive,
considering the expected costs of repair and maintenance down the line.
If anyone has used Suns for sale, or knows where ads can be found for
these, I'd appreciate it.
If anyone has suggestions for reducing the initial cost, (eg, with third
party equipment), I'd appreciate that also.
Please reply directly to: meyers@ics.uci.edu.
Amnon Meyers
ICS Department
UCI
Irvine, CA 92717
(714)856-4840
------------------------------
End of SUN-Spots Digest
***********************