[comp.sys.sun] SUN-Spots Digest, v5n14

Sun-Spots-Request@RICE.EDU (Vicky Riffle) (05/15/87)

SUN-SPOTS DIGEST           Thursday, 14 May 1987            Volume 5 : Issue 14

Today's Topics:
                   Re: PC-NFS and Ethernet interfaces?
                 Re: Generating Sun2 binaries on a Sun3?
                        Re: swap space allocation
   Re: Bug in SUN 3.2, 3.3 machdep.c (or movc.s) "panic: memall intrans|want" 
	             Re: Duplicate IP address (v5n13)
                  IP fragmentation, and how to avoid it?
                       screen saver or shut it off?
                              writing tools?
              Getting a SUG tape code to run on my Sun3/110?
                  Xylogics 450 disk controller for sale
		           acucntrl for Suns?

------------------------------------------------------------------------

Date: Tue, 12 May 87 06:46:59 EDT
From: suneast!hinode!geoff@sun.com (Geoff Arnold)
Subject: Re: PC-NFS and Ethernet interfaces?

>From: a_lie%vax.runit.unit.uninett@tor.nta.no (Anund Lie)
>Subject: PC-NFS and Ethernet interfaces?
>I understand PC-NFS as delivered by Sun only supports the 3Com 3C501
>Ethernet interface. How dependent on this interface is PC-NFS really?
>Is it possible to swap the Ethernet driver part of PC-NFS for a driver
>(for instance from some PC TCP/IP package) for another Ethernet card
>(possibly by writing a small amount of code acting as "glue")?
>Anund Lie
>Norwegian Institute of Technology
>a_lie%vax.runit.unit.uninett@nta-vax.arpa

The current version (PC-NFS 2.0) supports the 3Com 3C501, the Ungermann-Bass 
NIC and the Micom-Interlan NI5010 boards.  We are planning to add support for 
further boards in the future and welcome input on which drivers people need 
most urgently. 

The drivers are not (even remotely) compatible with those from any other 
PC TCP/IP package, whether commercial or academic. Given source to a 
link-level driver for some other board it's not too painful to
implement a PC-NFS driver, but to date we haven't published (read:
documented for external consumption) the procedures necessary to do 
so. Furthermore at the present time we don't have the resources to do
driver (or other) customer specials.

We are also shipping the PC-NFS Programmer's Toolkit which provides
Berkeley-style sockets, RPC, XDR and Yellow Pages support in the form of
libraries for Microsoft C V4.0. Applications built with the Toolkit
will work with PC-NFS 2.0 on any of the above boards.

Geoff Arnold
Sun Microsystems - East Coast Division
(UUCP: sun!suneast!geoff ;  ARPA: garnold@sun.com)

------------------------------

Date: Tue, 12 May 87 13:21:11 CDT
From: bbc@rice.edu (Benjamin Chase)
Subject: Re: Generating Sun2 binaries on a Sun3?

The following, from ehrhart@spam.istc.sri.com (Tim Ehrhart)
>
>Wrong:      cc -mc68010 -O -c myprog.c
>            cc -mc68010 myprog.o -lm -o myprog
>
>Right:      cc -mc68010 -O -c myprog.c
>            cc -mc68010 myprog.o /usr.MC68010/lib/libm.a -o myprog

although in the correct spirit, is unfortunately not quite good enough.
The C runtime library, /lib/libc.a, is linked in automatically, and on a
68020 contains a few 68020 modules.

Also, specifying the -pg flag complicates things significantly, since the
names of the libraries change, and sometimes their location, too (eg.
/lib/libc.a vs.  /usr/lib/libc_p.a).  Some of the -pg variants don't seem
to exist (or is it just Rice that doesn't have libpixrect_p.a, etc.?).
Also, whereas adding the -pg flag changes the names of the libraries,
adding the -g flag causes the inclusion of another library,
/usr/lib/libg.a.  All these little details can be very frustating to the
person constructing the ld command from scratch because he/she wants to do
a "cross compile" from one flavor of sun to the other.

Wouldn't it be convenient if cc and ld new more about the m680?0 flags and
ld could be told where to find the various flavors of libraries?

The -m680?0 flags *are* documented, although they are hidden under the
manual pages for as(1).  To me this hints at the lack of support for these
flags throughout the rest of cc and friends.

	Ben Chase	Dept. of Computer Science
	bbc@rice.edu	Rice University

------------------------------

Date: Wed, 13 May 87 08:38:18 PDT
From: jonab@cam.unisys.com (Jonathan P. Biggar)
Subject: Re: swap space allocation

When swap space is allocated, the amount requested is rounded up to the
nearest power of 2.  Thus the wasted space sum of the difference
between the rounded up value and the original request over all requests.

There is really nothing you can do about this but wait for a better
swap allocation scheme.

Jon Biggar
jonab@cam.unisys.com

------------------------------

Date: Wed, 13 May 87 17:56:45
From: craig@bonnie.uci.edu (Craig Rolandelli)
Subject: Re: Bug in SUN 3.2, 3.3 machdep.c (or movc.s) "panic: memall intrans|want" 

For those of us unfortunates, without sources, SUN has a patch for this.  
Just give them a call (800 USA 4 SUN) and ask for the bzero patch.  They will 
email it to you uuencoded.

Craig Rolandelli

UUCP: ucbvax!ucivax!craig
INTERNET: craig@ics.uci.edu

------------------------------

Date: Wed, 13 May 87 10:54:03 EDT
From: ucbcad!ames!seismo!rochester!ritcv!mmr@ucbvax.berkeley.edu (Margaret Reek)
Subject: Re: Duplicate IP address (v5n13)

About the duplicate ip address problem Paul Allen refered to, I have
seen this when a system has another system's name in its rc files.
Then when it looks up its address in /etc/hosts, it is using the same
address as another system, and both systems will get the message printed 
on their consoles.  Changing the rc file makes the problem go away.

	Margaret Reek

------------------------------

Date: Mon, 11 May 87 16:50:31 PDT
From: dplatt@teknowledge-vaxc.arpa (Dave Platt)
Subject: IP fragmentation, and how to avoid it?

I've run into some problems on a Sun 3/52 workstation running SunOS
3.2 that I've been told may involve IP packet fragmentation.  The
primary symptom is that SMTP mail deliveries "hang up" and abort with
a read timeout.

Background: my Sun is sitting on a 10 Mbit Ethernet with the default
ifconfig for the Ethernet board;  the MTU for the Ethernet interface
is 1500 bytes.  The system is configured so that packets destined for
IP addresses not on our net are sent to our Vax 8650 (Ultrix 1.2),
which ipforwards them to the Internet TIP.  The MTU for the Vax's
"imp0" interface is 1006 bytes.

Problem: if a process on the Sun establishes a TCP connection with a
peer running on a host somewhere on the Internet (e.g. an SMTP
server), and then sends a large burst of data, the Sun will typically
queue up about 4k of data in the TCP buffers at one time.  This
apparently results in the sending of an IP packet that approaches the
Sun's 1500-byte MTU; when the packet passes through the Vax on its way
to the IMP, it is apparently fragmented.  Some system or gateway seems
to drop the fragmented IP packet on the floor.  The Sun's TCP never
receives an acknowledgement for the TCP segment, retries the
transmission periodically, and eventually aborts the connection.

The problem typically occurs in the later stages of an SMTP session.
The Sun's SMTP mailer is able to connect with its peer on another
Internet host, go through the "MAIL FROM" and "RCPT TO" steps, and
receive permission to send the message body.  If the message is short
(< 1k bytes), everything works fine;  if it's too long, then the
timeout occurs.

This problem appears to occur only when the host I'm trying to connect
with lies on a local-area net... and not all LANs are affected.  I've
been told that certain gateways are incapable of reassembling
fragmented IP packets;  other gateways seem to work just fine.

Question for the gurus:  is there any way to reconfigure my Sun's le0
interface so that its MTU doesn't exceed that of the 8650?  If so, how
do I do it?  Or, is there a better solution to the problem?  Or,
finally, have I totally misunderstood the problem?

advTHANKSance,

                Dave Platt

------------------------------

Date: 13 May 87 06:48:49 GMT
From: wyle%ethz.UUCP%cernvax.bitnet@berkeley.edu (Mitchell Wyle)
Subject: screen saver or shut it off?

There is a raging debate going on here about whether we should turn off
our Sun-3/50s, apple macintoshes, laserprinters, and other sundry
computer hardware, or whether the daily switching increases the failure
rate.

If the failure rate is significantly increased, then turning machines
off wastes energy.  The energy required to manufacture, ship, and
replace a computer is larger than the energy it wastes while not being
used at night.

Should all monitors be shut off at night?  What about weekends?

Thanks for your wisdom.  If there are enough "me too" responses, I'll
summarize to the net.

--
Mitchell F. Wyle          |csnet or arpa: wyle%ifi.ethz.chunet@relay.cs.net
Instituet fuer Informatik |uucp:          wyle@ethz.uucp ...!cernvax!ethz!wyle
ETH Zentrum / SOT         |telephone:     011 41 1 256 5235
8092 Zuerich, Switzerland |"Sic itur ad astra"

------------------------------

Date: Tue, 12 May 87 13:17:57 EST
From: rodger%QUCIS.BITNET@wiscvm.wisc.edu (Jim Rodger)
Subject: writing tools?

This is just an inquiry about the availability of writing tools to
run on SUN/UNIX systems. There appear to be many such tools (spell
checkers, thesauri, dictionairies etc.) in the PC/DOS world. Is it
really the case that there are very few of these for UNIX users, or
am I just underinformed? Pointers to specific products would be
greatly appreciated.

Jim Rodger

------------------------------

Date: Wed, 13 May 87 10:56:03 EDT
From: duncan%andy.bgsu.edu@relay.cs.net (Comer Duncan)
Subject: Getting a SUG tape code to run on my Sun3/110?

I recently received the SUG tape and have tried to put up the 
cellular automaton code submitted by Wolfram and Packard.  First, the
executable code 'ca' dies with a remark that it can't find /dev/cgone0.
After hunting around a bit I found that the above device was set in 
the file cgraph.c.  So, not knowing any better I changed it to
/dev/fb.  The compile then got further along and died at the load step
when it complained about not finding the function clear(). I looked and
found clear() in the file select.c.  After commenting out the reference
the clear() the compile and load completed.  However the code does
not run properly.  It seems to get into a loop from which it can not
apparently get out of during the beginning stages of data entry.
I then changed /dev/fb to /dev/cgtwo0, but no improvement occurred.
Thus, I conclude that either or both of my hacks were indeed that.
I am hoping someone has tried and succeeded in putting ca up on
a Sun3/110.

I would really appreciate any and all suggestions of avenues to 
try next.  I don't think that the originators of the ca code 
should have to maintain it in an upgrade from Sun2 to Sun3.
So I hope that those in the Sun-Spots group will be able to 
help me out.

Thanks very much for any help.

Comer Duncan
duncan@bgsu.edu
Department of Physics and Astronomy
Bowling Green State University
Bowling Green, OH 43403
(419) 372 8108

------------------------------

Date: 14 May 87 02:14:13 GMT
From: elijah!tarsa@seismo.css.gov (Greg Tarsa)
Subject: Xylogics 450 disk controller for sale

		For Sale
		~~~~~~~~
Xylogics 450 SMD controller board.
	Latest revision; from Sun 2 equipment.
	Working. $1100.

If interested, call (603)668-8349
    or send electronic mail to {decuac,decvax}!elijah!tarsa.

Greg Tarsa
Tarsa Software Consulting
33 Seabee Street
Bedford, NH 03102-2048
(603)668-8349

------------------------------

Date: Wed, 13 May 87 10:57:41 PST
From: mike@mc1.jpl.nasa.gov (Mike Tankenson)
Subject: acucntrl for Suns

Excuse me, but does anyone out there have a version of 4.3 acucntrl running
on a Sun workstation?  If so, and if we're not violating any licenses,
could you please e-mail me a copy?  Many thanks.

--mike

Mike Tankenson                Telos/Jet Propulsion Laboratory - NASA
4800 Oak Grove Drive, Pasadena, CA.  91109            (818) 354-1447
Uucp: seismo!cit-vax!jplpro!mike
Arpa: jplpro!mike@cit-vax.ARPA -or- mike@jplpro.JPL.NASA.GOV

------------------------------


End of SUN-Spots Digest
***********************