[comp.sys.sun] Sun-Spots Digest, v6n214

Sun-Spots-Request@Rice.edu (William LeFebvre) (09/03/88)

SUN-SPOTS DIGEST        Thursday, 1 September 1988    Volume 6 : Issue 214

Today's Topics:
                         Re: CDC 9766 disk drives
                         Re: Clock losing 30 days
                  Re: screenblank and Netnews software 
                            Re: RS-232 problem
                  Re: booting discless => "if_snd full" 
               Re: subshell vs. top-level shell in suntools
                 Re: Don't try to figure out what it does
                       screenblank, 3.5/4.0 choice
           .cshrc command environment (was: ownership problem)
                       broadcast storm at boot time
                          tar: filename too long
                 When is iodone not iodone? (Ans: in 4.0)
                           Sun4 Tape Interface?
                        data acquisition to Sun 3?

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, 31 Aug 88 16:16:44 PDT
From:    harker@parns.nsc.com
Subject: Re: CDC 9766 disk drives

I got this information on the CDC-9766 disk drive from Kim Rogers in Sun
Consulting.  She Said I could post it to SunSpots as long as I gave her
credit.  Thanks Kim, it works like a champ (or did untill the drive gave
up the ghost, and I decided not to fix it).  Remember to format all of
your disk packs before you use them.  When I do not have the original
defect list I run the scan option of diag without random bit patterns
(This goes through five different patterns) and I run 5 passes of surface
analysis.  This seems to find most of the disk defects.

Robert Harker, All around good guy
	harker@nsc.com,
	{sun,decwrl,hplabs}!nsc!harker
__________

	"Connecting a CDC-9766 to a Sun under 3.2"

You must be using a Xylogics 450 Revision 'E' or later controller (a
Xylogics 451 is acceptable).

Set the sector switches to the following settings:

        	110001 011000
	    bit 0           11

Which corresponds to 31 sectors (30 data, 1 for slip sectoring).

[The sector switches are located in the logic card cage in the back of the
drive - card number 6]

Run 3.2 FCS diag and tell it the following:

	Controller Bus Location?                        ee40
	Unit number?                                    0
	Drive Type [menu appears]                       [other]

	number of data cylinders                        820
	number of alternate cylinders                   3
	number of bytes per sector                      628

	first head                                      0
	physical partition                              0
	number of heads                                 19

	drive type                                      0
	ASCII Identification                            CDC-9766

	number of data sectors per track                31
	interleave                                      1

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

Date:    Wed, 31 Aug 88 18:51:57 PDT
From:    Steve Schlaifer x4-3171 <steve@mahendo.jpl.nasa.gov>
Subject: Re: Clock losing 30 days
Reference: v6n203

> Every time I reboot my 3/160, I get the message
> 
>   WARNING: clock lost 30 days  -- CHECK AND RESET THE DATE!
> 
> ...and sure enough it has.  Anyone know how to fix this?  Thanks....
> 

Have you installed the TOD clock patch that was posted quite some time
ago?  It fixed this problem on a 3/60 and a 3/160 running SunOS 3.5 here.

	--Steve Schlaifer (steve@mahendo.jpl.nasa.gov)

[[ A file explaining how to install the infamous "TOD" patch is available
in the archives under "sun-spots" as "tod-patch".  Mail a message
containing the line "send sun-spots tod-patch" to "archive-s
erver@rice.edu"
if you want a copy.  This fix was announced in the first digest of this
year.  --wnl ]]

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

Date:    Wed, 31 Aug 88 21:07:00 PDT
From:    Craig Leres <leres@helios.ee.lbl.gov>
Subject: Re: screenblank and Netnews software 

mlijews@nswc-wo.arpa writes:
> [...]  I have seen as many
> as 8 screenblanks running on the same machine.  Certainly, there is no
> need for more than one screenblank per machine!

Why not just make /usr/bin/screenblank mode 700 and fire up a single copy
from /etc/rc.local?

	Craig

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

Date:    Wed, 31 Aug 88 23:08:53 EDT
From:    attcan!utzoo!henry@uunet.uu.net
Subject: Re: RS-232 problem

> ... The output voltage from the clock seems "reasonable" (around 4
> volts - anything over 3 is kosher for RS-232).  Nothing I've tried -
> either hardware or software - has helped me read the thing on the Sun...

We have two misconceptions here, I'm afraid.

First, if you are using the Sun CPU-board ports, note that these are *not*
RS232 ports.  They are RS423 ports.  RS423 is generally compatible with
RS232, but not if you try to bend the rules.

Second, 4 volts is *not* kosher for RS232.  RS232 *receivers* are supposed
to recognize 3 volts, but RS232 *transmitters* are supposed to send at
least 5 volts.  (The two-volt difference is noise margin.)

You can get away with an awful lot of rule-bending with RS232, and 4-volt
output will usually work.  But I bet the Sun's RS423 ports don't like it,
and that's where the problem lies.  To fix this, you need to either put
the clock on a real RS232 port (e.g. an ALM port) or boost the voltages to
bring them into conformance with the spec.  (Check both voltages -- it
wouldn't surprise me if the positive voltage was +4 but the negative one
was 0 instead of -4.  That's another out-of-spec kludge that often works
with RS232 but probably won't with RS423.)

You might write a nasty letter to Heathkit while you're at it.

	Henry Spencer at U of Toronto Zoology
	uunet!attcan!utzoo!henry henry@zoo.toronto.edu

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

Date:    Thu, 1 Sep 88 08:59:01 +0200
From:    Gunnar Lindberg <@relay.cs.net:lindberg@cs.chalmers.se>
Subject: Re: booting discless => "if_snd full" 

A few days ago I sent out a mail about this problem (it's all in Sun-Spots
v6n202 so there's no need to repeat it). Shortly after that I received
this:

>From: Craig Leres <leres@helios.ee.lbl.gov>
>
>>Now, the "ICMP_MASKREQ" is sent out using IP broadcast...
>
>I discussed this back in June. I don't have 3.4 source so I'm not
>positive this will work for you, but I suggest you use adb to patch
>the first instruction of the routine icmp_sendmask() in OBJ/ip_icmp.o
>to be a rts. This should keep your systems from making the subnet mask
>request....

We've done exactly this and it works like a dream. Many thanks Craig!
More explicit:

    /etc/rc.boot:
	ifconfig le0 $hostname ... netmask 255.255.0.0	B-net, no subnet
    adb -w /pub/vmunix
    icmp_sendmask?w 4e75				"rts"
    reboot discless clients and watch silence :-)

    adb -w /sys/OBJ/ip_icmp.o				for future
    icmp_sendmask?w 4e75


Now, I guess that "icmp_sendmask()" wasn't written just for fun, so there
must be drawbacks that we haven't seen yet. Could somebody make a comment
on this, please?

	Gunnar Lindberg

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

Date:    Thu, 01 Sep 88 09:29:55 -0400
From:    malis@cc5.bbn.com
Subject: Re: subshell vs. top-level shell in suntools

The following, if placed in your .cshrc, properly distinguishes between
top-level and non-top-level shells.  It works both in and out of suntools,
and on Ultrix as well.

It works by keeping track of your csh depth in the environment.  It knows
if you are in suntools by looking for WINDOW_PARENT to be defined.

Andy
__________

if ($?CSHDEPTH) then
   @ cshdepth=$CSHDEPTH + 1
else
   @ cshdepth=1
endif
setenv CSHDEPTH $cshdepth
if ($?WINDOW_PARENT) then
   @ cshx = $cshdepth
else
   @ cshx = $cshdepth + 1   
endif
if ($cshx > 2) then
   # whatever you want to happen in a non-top-level shell, such as:
   unset ignoreeof
endif

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

Date:    Thu, 1 Sep 88 09:48:28 PDT
From:    eggert@sm.unisys.com (Paul Eggert)
Subject: Re: Don't try to figure out what it does

In Sun-Spots 6:204 wnl writes:

	This program is great!  Grab a copy.  Don't try to figure out what it
	does, just compile it and run it.

In a world that contains computer viruses, this is risky advice to give to
the public.

[[ 1: it comes only as source; do you really think someone would try to
distribute a virus only as source?  2: it has my stamp of approval; I
wouldn't say something like that about a program unless I felt confident
that it was non-malicious.  3: The author, Chuck Musciano, has posted many
programs and contributed in a very positive way to this list; I seriously
doubt that he would have any malicious intent.  Although in the general
case you are correct in thinking that one should not blindly trust a
program, in this particular case I think that would be over-reacting.
--wnl ]]

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

Date:    Thu, 1 Sep 88 22:56:25 EST
From:    munnari!basser.cs.su.oz.au!rex@uunet.uu.net
Subject: screenblank, 3.5/4.0 choice
Reference: v6n207, v6n208

In v6n208 mlijews@nswc-wo.arpa want to know about multiple screenblanks
running. The way we solved this problem is to add screenblank to
/etc/rc.local. In this way ALL machines are guaranteed to have screenblank
running. Not only while users were logged in. 

One minor anoyance with the sunOS systems is that people who are rlogin'd
into machines do not have their process group killed when they log out.
Not only screenblank but any other async process they run is left lying
about when they log out. Is this just a bug with the 3.5 we are running or
is it a 'feature' that is destined to remain?

In v6n207 phri!roy@philabs.philips.com (Roy Smith) asks on upgrading to
3.5 or 4.0. We run a network of 30 workstation with 3 servers and had to
upgrade from 3.2 to 3.5 since we are now running 3/60's. When we had to
decide whether to go to 4.0 we decided to stay with 3.5 for a while as 4.0
is just "AWFUL" (so says our sun man). 4.0 seems to be universally
acknowledged as VERY SLOW, and people are running their old 3.X binaries
on the 4.0 systems, which says something!

The difference between 3.2 and 3.5 is marginal (subnets and 3/60 support)
and I would suggest that 3.5 is your best choice. We have decided to wait
for 4.7 (most probably due for release in 1989 the way things are going
:-) as 4.0 doesn't seem to fix any of our problems, but does introduce new
ones.

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

Date:    Wed, 31 Aug 88 18:09:53 MDT
From:    dlc%beta@lanl.gov (Dale Carstensen)
Subject: .cshrc command environment (was: ownership problem)

ruba@biophys.uucp writes:
> I have a silly problem on a 3/260 running SunOS3.4. Everytime when I
> open a window I get the the message:
> 		/dev/ttyp?: Not owner
> Piping a text through a filter in vi gives me the the funny message:
> 		Where are you?

These responses and another more recent messages about a strange response
to rsh that didn't happen with rlogin to the same hosts are probably
symptoms of having environment-dependent commands in ~/.cshrc, with no
exit for environments like sub-shells to vi or rsh allowed by:

  if ($?USER == 0 || $?prompt == 0) exit

before the offending commands.  "Where are you?" in particular comes from
the command tset.  Perhaps the "Not owner" comes from biff?

	Dale Carstensen
	dlc@lanl.gov
	cmcl2!lanl!dlc

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

Date:    Thu, 1 Sep 88 11:49:10 EDT
From:    smb@research.att.com
Subject: broadcast storm at boot time

Thanx for your suggestions; the problem was indeed related to the ICMP
subnet mask.

Here's exactly what was happening.  At boot time, the diskless Suns were
sending out ICMP subnet mask requests.  Our diskful Suns, including the
servers, had no subnet mask set (we don't use subnetting at the moment),
so they didn't reply.  Any other diskless Suns would reply if they were
up; if they had received a bad subnet mask, they'd reply with that, making
life impossible.

The bug we had to contend with was in our Mt. Xinu 4.3bsd NFS VAXen.  They
send out a subnet mask in host byte order, not network byte order,
confusing the workstations.  To be sure, our vanilla 4.3 machines have the
same bug; however, they have the additional bug that they send back an
information reply instead of a subnet mask reply, so they're harmless...
We also have a CCI 6/32 (Tahoe) running 4.3 Tahoe beta; this has the same
bug as the Mt. Xinu code, but since the host byte order on the Tahoe is
the same as network byte order it gives a (coincidental) right answer...

To summarize -- we are getting two bad replies from VAXen, two harmless
bad replies from VAXen, a good reply from a Tahoe, and 0-3 good replies
from other diskless Suns...  We're going to fix the VAXen to give the
proper reply; until then, we'll probably set the subnet mask on our other
Suns, so that they'll increase the odds of a right answer...  Or we may
just adb the sendmask request routine out of existence, as Craig has
suggested.

	--Steve Bellovin

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

Date:    Wed, 31 Aug 88 23:08:46 EDT
From:    attcan!utzoo!henry@uunet.uu.net
Subject: tar: filename too long

>The tar that is distributed with SunOS 3.4 has an annoying "feature" ...
>it apparently has a 100 character filename buffer.  Why is this? ...

This is not a problem with the particular implementation of tar, it is
a problem with the tar format.  The tar header block only has 100
characters for the filename.  This was arguably shortsighted (although
let me tell you, it was a damn sight better than tar's predecessors!)
but cannot be fixed compatibly.  This one isn't Sun's fault; *ALL*
pre-POSIX tar implementations have this limitation.  POSIX has done some
trickery to stretch the limit to 255 in a more-or-less compatible way.

	Henry Spencer at U of Toronto Zoology
	uunet!attcan!utzoo!henry henry@zoo.toronto.edu

[[ I'm sure that many more people will point this out.  Thanks in advance
for all the responses, but I will probably not include any more.  --wnl ]]

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

Date:    Wed, 31 Aug 88 11:19:23 EDT
From:    dyer@spdcc.com (Steve Dyer)
Subject: When is iodone not iodone? (Ans: in 4.0)

A couple of weeks ago, I asked members of this list whether there were any
device-driver-visible changes between Sun OS 3.x and 4.0.  There certainly
didn't seem to be any obvious ones to me, having read the 4.0 changes,
release notes and having reread the latest device driver manual revision.
Nevertheless, a magtape driver which worked fine under OS 3.5 would
mysteriously hang when compiled under 4.0.

Well, it turns out that my call to iodone(bp) in the interrupt routine
wasn't always performing a wakeup under 4.0!  So, my sleep on bp during
the code to support ioctls was hanging forever.  I fixed it by replacing
the iodone with a { bp->b_flags |= B_DONE; wakeup(bp); }, but that
sequence was always no more and no less what iodone(bp) used to do in
every flavor of UNIX I've ever seen.  I don't have Sun 4.0 sources handy,
so I don't know what "features" were added to what was always a rather
straighforward set of senmantics!

Anyone in the know know what iodone (biodone) does differently under 4.0
as compared with earlier releases?

---
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {harvard,husc6,linus,ima,bbn,m2c,mipseast}!spdcc!dyer

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

Date:    Thu, 1 Sep 88 11:07:13 EDT
From:    Jeff Piper <jep@ebfs2.cl.msu.edu>
Subject: Sun4 Tape Interface?

I would like to know the requirements to interface a CYPHER F880
MICROSTREANMER tape drive to a Sun4.  I need sources for the interface and
drivers which will run on a Sun4 under SunOS 4.0.

	Jeffery E. Piper
	BITNET: 15332jep@msu
	ARPA:		jep@ebfs2.cl.msu.edu
	VOICE:	(517)353-2999

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

Date:    Thu, 1 Sep 88 11:41:57 EDT
From:    Ned Danieley <ndd@sunbar.mc.duke.edu>
Subject: data acquisition to Sun 3?

We are interested in acquiring data to a Sun 3/160. We are currently doing
this with a couple of IKON dr11 emulators and writing to the disk.
However, we would like to go to an even higher data rate (about 500k bytes
per second) and it doesn't look like our current setup can do that. I've
been told that transferring data into VMEbus memory, as opposed to Sun
memory, might be faster, since we wouldn't be contending with the CPU for
the private memory bus. Does anyone have any experience transferring large
amounts of data into VMEbus memory? How fast can it be done? What
technique do you use to access the memory: do you mmap it, or use a
driver?

Any help would be greatly appreciated.

Ned Danieley (ndd@sunbar.mc.duke.edu)
Basic Arrhythmia Laboratory
Box 3140, Duke University Medical Center
Durham, NC  27710
(919) 684-6807 or 684-6942

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

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