Sun-Spots-Request@Rice.edu (William LeFebvre) (09/13/88)
SUN-SPOTS DIGEST Friday, 9 September 1988 Volume 6 : Issue 222
Today's Topics:
Re: Sun 4/110 surprises (2)
Re: Gnu Emacs under 4.0
Re: wanted: Mac NFS
SUNOS vs Ultrix S/W Support prices
tftpboot on clients can cause packet storm
SL/IP is broken if used with ALM-2's
Problems with fork() and wait()
Problems with Sun-TOPS and Sunlink-X.25 (X.29)
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: Wed, 7 Sep 88 16:54:49 PDT
From: "John D. Polstra" <cfj!polstra!jdp@uunet.uu.net>
Subject: Re: Sun 4/110 surprises (1)
Reference: v6n217
Paul O'Neill <pvo3366@neptune.oce.orst.edu> writes:
>I've never used TeX.
>I'm surprised a formatting package uses floating-point, but I'll bet
>that's what's happening. Solution--order an FPU.
TeX does not use floating-point. It uses its own home-grown arithmetic
routines, which are built entirely upon integer operations.
Floating-point was avoided in order to achieve what Knuth felt was an
extremely important goal: that all calculations should come out the same
down to the last bit, no matter what hardware TeX was running on.
John Polstra (jdp@polstra.uucp)
------------------------------
Date: Thu, 8 Sep 88 00:20:43 EDT
From: attcan!utzoo!henry@uunet.uu.net
Subject: Re: Sun 4/110 surprises (2)
>... to answer Jeff's system-time question. There are no compile time
>floating-point options on sun4's. The FPU is assumed to be there. If
>it's not, then the *KERNEL*, not linked library stuff, emulates the FPU.
This is in fact a requirement of the architecture: the FPU is supposed to
act as if it's there even if it's not, so to speak. This is an enormous
win from the software end, and I'm sure Sun has had enough headaches
supporting all the various permutations of floating-point hardware on the
Sun 3 to like this, but it does tend to kind of hurt performance when the
hardware isn't there. Unless great care has been taken, trap plus switch
into kernel plus etc. will be a good deal slower than simply calling a
library function to do a floating-point operation.
If you have sources for the stuff, you might look to see if Sun has
implemented a simple optimization that roughly doubled emulated floating-
point performance on the pdp11 in vaguely similar circumstances: before
returning to the user program after emulating an instruction, look to see
if the *next* instruction will also require emulation. This saves working
your way out of the kernel and the trap only to dive right back in on the
very next instruction.
Henry Spencer at U of Toronto Zoology
uunet!attcan!utzoo!henry henry@zoo.toronto.edu
------------------------------
Date: 7 Sep 88 18:52:50 GMT
From: umix!oxtrap!rich@uunet.uu.net (K. Richard Magill)
Subject: Re: Gnu Emacs under 4.0
Reference: v6n203
>From: Paul Hudson <mcvax!moncam!paul@uunet.uu.net>
>
>Emacs won't compile under 4.0 if you've installed the fixes to the X11
>stuff.
Gnu emacs 18.51 + dana's patches worked for me as did a pre-release 18.52.
------------------------------
Date: 7 Sep 88 22:24:22 GMT
From: bambam!hjp@uunet.uu.net (Howard J. Postley)
Subject: Re: wanted: Mac NFS
Thanks to everyone who responded to my query. The general consensus is
that MacNFS does not exist. There are several ways to make a Mac live on
an NFS network, but none is wonderful. The best one seems to be to run
TOPS on a Sun or Pyramid as a gateway. This works, although it is
something of a kludge. TOPS/PC-NFS as a combined product is due in 1Q89.
The Kinetics/Cayman stuff is fine, except that you are stuck at LocalTalk
speed. Kinetics now has ethernet boards for the Mac II and Mac SE but the
software is the pits. Oh well, I guess I'm stuck 'til Jan...
Here are the responses that I received:
__________
I haven't heard of a real NFS for the Mac, yet. Depending on your needs,
you might possibly be satisfied with CAP, which runs on most BSD Unix
boxes and provides an AppleShare-compatible file server called "aufs". We
use it here, a bit... I have a 15-meg library of Mac public-domain and
shareware software sitting on our Sun 3/280 fileserver. To the Mac, it
looks just like an AppleShare volume with a "Net devil" icon. I use a
second "aufs" volume to transfer text files back and forth between my Mac
and my Sun 3/60 workstation. A bit of tweaking is necessary to compensate
between the Mac's end-of-line convention (CR) and that of Unix (NL), but
it's not onerous.
CAP is cheap... $0.00 if you can get it via FTP or from a friend. It
requires the use of the KIP gateway code in the K-box, or the new
KIP-equivalent from Kinetics.
__________
Cayman has a box dubbed GatorBox, which is an AppleTalk-TCP/IP gateway
which will also gateway AFP and NFS back and forth.
__________
Cayman Systems is now shipping their Gator Box, an Ethernet/Appletalk
gateway that acts as a Kinetics clone and also allows you to mount NFS
volumes as AppleShare volumes. Be warned that in version 1.0 the
NFS/AppleShare behavior is very buggy, with fixes promised in version 1.1
(due out in anywhere between two weeks and two months). The rest of the
box's functionality, the usual MacIP stuff, seems just fine. Version 2.0,
due out first quarter '89, promises to support cross system email and
printing.
Their support staff certainly seem to know the product, and sound like
part of the development team. They've been very good about returning
phone calls, and are very grateful for bug reports.
Write to them at
Cayman Systems
One Kendall Square, Building 600
Cambridge, Massachusetts 02139
__________
While I was in UniForum at the begining of the month, I saw a product by
Cayman Systems that allowed you to do what you need. NFS volumes will
look as AppleShare volumes on your desktop.
I am not recomending this, neither I am against it.
You can contact them at
(617) 494-1999
--
Howard Postley usenet: uunet!bambam!hjp
On Word phone: +1 213 399 7733
snail: 2434 Main St; Santa Monica, CA 90405
------------------------------
Date: 7 Sep 88 19:24:45 GMT
From: animal@ernie.necam.com (Alan R. Silverman)
Subject: SUNOS vs Ultrix S/W Support prices
I just finished reading an article where someone flamed Sun for having a
not so large support group and exceptionally high prices verses the Dec
end.
THIS IS INSANE!
First of all, let's talk response!
Sun- I call in a problem. The call is usually returned within an hour or
so. The engineer calling me back will ALWAYS leave a detailed message on
my voice mail including log numbers, names, and phone numbers. Each time
I have gotten an excellent response, technologically speaking.
Dec- If I'm not around when the call comes in, I get short message, like:
"This is Dec calling. Good bye." This leads to a terrible game of phone
tag. I hate that. The response has been improving and has even become
useful. It's about time. I still never know who's gonna call me back.
It's rarely the same person.
Second, lets talk cost and contract styles.
Sun- We have a Sun 4/280, 3/260, and many 2/50,60's. They are all on one
contract for hardware and software. One P.O., one bill, one phone number,
and 99% of the time, the same person calls me back with a good background
in his head of who and what he or she is dealing with. The cost is around
$2000 monthly. (the diskless aren't covered for H/W)
Dec- We have a MicroVAX and a VAX8250. We have one software contract for
each machine and one hardware contract for each machine. That's FOUR
contracts to keep track of for 2 machines!! How STUPID!! The support
numbers are even more stupid. Ultrix is Ultrix is Ultrix. Minor
differences for the different hosts that it runs on. Software support for
the 8250 comes from TAXachusetts (Massachusetts) and for the MicroVAX I
call Atlanta. Now for the good one. 8250 Hardware support has the same
phone number as the MV S/W in Atlanta, but MV H/W support has a completely
different number, I think in Colorado. You'ld think they'ld get it
together by now. They're working on it. Boy, contracts and myself can
hardly wait. Costs........
S/W for 8250 $410 monthly
S/W for MV II $375 monthly
H/W for 8250 $500 Guestimate (1st yr included in purchase price)
H/W for MV II $744 monthly (Major haggling to get this low price!)
Total $2000 monthly
Now I don't understand how someone can flame Sun's support group. They
are tiny and young compared to Dec, but to me, they are showing Dec how
things should be run. I call one number at Sun and get all the support I
need from one contract. That to me is OUTSTANDING!!
All comments welcome.
-animal
------------------------------
Date: Wed, 7 Sep 88 18:08:11 PDT
From: Doug Moran <moran@ai.sri.com>
Subject: tftpboot on clients can cause packet storm
Potential source of packet storms: The symptom is that the network is
flooded with ND packets: the traffic program showed over 30% utilization
of the network (10% is normally considered a heavy load) with 90+% being
ND packets. Three Sun-3/1xx or 3/60's are sufficient to bring a Sun-3/1xx
server to its knees and to very effectively clog the Ethernet for any
other hosts.
This problem was found in SunOS 3.5 and may well occur in versions back to
3.2. It has been reported to Sun (Service Order 209380) and I have been
told that the problem is fixed in 4.0. We have been running with this
configuration since March and had no problems until mid-August. We have
not yet identified the circumstances under which the "feature" was tickled
and are no longer actively looking.
Background:
===========
Clients boot from the server using the TFTP network service. Using TFTP
opens up a major security hole because there is no authentication (no
login or passwd) so anyone on the Internet can take any publicly readable
file from your system (e.g., /etc/passwd). To remedy this problem
(introduced in SunOS 3.0, remedy in 3.2), Sun provides a variant of the
tftp server called tftpboot (pgm /usr/etc/in.tftpbootd). This variant
changes the root to /tftpboot so that tftp can only look at the boot
files. I suspect Sun's tftpboot program is a variant of the normal tftp
program with a chroot at the very beginning.
The problem:
============
I changed my /etc/servers file on my server to use tftpboot instead of
simply tftp (by switching which line is commented out). This file is one
of the system files I rdist off my server to all clients (we have some
custom network services added and I wanted to avoid having different files
for the server and for the clients). The problem arises because the
clients do not have a /tftpboot directory. If someone attempts to connect
to the tftp server on a client, inetd starts the tftpboot server and when
chroot fails, tftpboot apparently exits. We observed inetd repeatedly
forking and starting new copies of tftpboot. We surmise that tftpboot is
not cleaning up a buffer associated with the attempted connection and
consequently inetd thinks there is a new connection request.
Our workaround was to have a separate /etc/servers files for the server
and for the clients, with both tftp and tftpboot commented out the the
servers file for the clients. An alternative (that we did not try) is to
create an empty /tftpboot directory on each client -- I rejected this
because I didn't want to have to remember to create this directory on new
clients.
Diagnosis aids:
===============
Running "ps x" and "netstat -a" on an client clearly shows the culprit,
The problem was that once the packet storm begins, it takes forever for
these to load and execute -- we found an involved client and then shutdown
all other clients so that these programs would run in less than geologic
time.
tcpdump and etherfind were no help because until we knew what we were
looking for, we couldn't keep enough history to see the tftp packets.
-- Doug Moran, AI Center, SRI International
------------------------------
Date: Wed, 7 Sep 88 17:48:04 EDT
From: smb@research.att.com
Subject: SL/IP is broken if used with ALM-2's
I don't think I have ALM driver source, so I can't be sure, but what
usually causes the 'panic: mget' message is if a network device driver
interrupts at a level higher than splimp(), which is equivalent to spl3().
Here's what happens... Something in the network code wants to do
something with the mbufs. The macros all do an splimp(), which masks off
the Ethernet and other network devices. Meanwhile, the serial board
interrupts at a higher level. The SLIP driver sees an end-of-packet
indicator, and tries to allocate an mbuf. The system then dies a painful
death...
The proper fix would be to ensure that the ALM-2 board interrupts at level
3 or below. Presumably, this is what Sun says can't be done. A second
solution would be to change splimp() to use a higher level than 3. You
risk (for example) loss of mouse data if you do this, though; see the
``Writing Device Drivers'' manual for details. But the change is easy,
either via source or via adb.
--Steve Bellovin
------------------------------
Date: Wed, 7 Sep 88 14:24:20 EDT
From: Chuck Musciano <chuck@trantor.harris-atd.com>
Subject: Problems with fork() and wait()
I have a program which forks about ten processes, which go off and do
useful work (including calling execv() to run rsh) and then terminate with
exit(0). The main program does a wait(). When the first process
finishes, the wait() informs the main program, which goes on to do more
work. After this work, it calls wait() again, and continues in this loop
until no more children remain.
The problem is that after informing me of perhaps two or three children,
wait() says there are no more, even though I know there are. I thought
that children hung around as zombies until the parent "reaped" them with
wait().
To test his, I caught the SIGCHLD signal, and was able to immediately do a
wait() and detect each child termination reliably. It's as if a child
hangs around a little while, but then is thrown away if the parent doesn't
catch him fast enough. This seems to contradict the documentation for
wait(). Can anyone shed some light on this? Have I misunderstood how
wait() is supposed to work?
You may wish to reply via mail, rather than through Sun-Spots, since this
may not be Sun-specific. For those who might need to know, I am running
3.4 on a 3/60.
Chuck Musciano
Advanced Technology Department
Harris Corporation
(407) 727-6131
ARPA: chuck@trantor.harris-atd.com
------------------------------
Date: Wed, 7 Sep 88 16:09:25 CDT
From: Stephan Wasserroth <wasserroth@fokus.berlin.gmd.dbp.de>
Subject: Problems with Sun-TOPS and Sunlink-X.25 (X.29)
Hello!
Today I installed TOPS for Sun. This is a (software-only) product for
connecting Apple MAC II to SUN-NFS. It supports the Apple-Talk-protocolls
on the ethernet.
After rebuilding the kernel with TOPS, the Sunlink-X.29 server does not
work. It gives the following error messages:
43: could not create socket
9: could not set process group
9: could not read X25 host address
9: bind failed
.... and much more errors.
Versions involved: SunOS 3.4, Sunlink X.25 5.0, Sunlink MCP 5.0, TOPS 2.0
The only change done so far, was the installation of the TOPS kernel
routines. No daemons have been started. The files /etc/rc /etc/rc.local
haven't been changed yet.
Any hint welcome.
DFN-EAN: <wasserroth@fokus.berlin.gmd.dbp.de>
ARPA: <wasserroth%fokus.berlin.gmd.dbp.de@relay.cs.net>
GMD-FOKUS
Stephan Wasserroth Hardenbergplatz 2
System Manager for D-1000 Berlin 12
VAXes and Sun-WS Fed. Rep. of Germany
PS: Who will fix this failure?? SUN (because Sunlink X.25 is involved),
or SUN (because TOPS is a spin-off of SUN)
------------------------------
End of SUN-Spots Digest
***********************