Sun-Spots Digest, v6n31

William LeFebvre Sun-Spots-Request at RICE.EDU
Fri Mar 18 02:27:53 AEST 1988


SUN-SPOTS DIGEST         Thursday, 17 March 1988       Volume 6 : Issue 31

Today's Topics:
             Re: Capacity of CDC Wren IV, diag/format problem
         Re: screendump from SUN 3/110 to laserprinter; greyscale
                         'rexd' is 'on' something
                    Program to determine console type
         Sun's (lack of) support for INTERPHASE disk controllers
        Problems with VME bus timeouts:  Ironics board on a Sun-3
    Can't make a xylogics 450 and interphase controller live together
                 Problems configuring cua0 on a 3/160 zs0
                      Questions about Sun Shoeboxes
                       Grant Accounting on the SUN?

Send contributions to:  sun-spots at rice.edu
Send subscription add/delete requests to:  sun-spots-request at rice.edu
Bitnet readers can subscribe directly with the CMS command:
    TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name
Recent backissues are stored on "titan.rice.edu".  For volume X, issue Y,
"get sun-spots/vXnY".  They are also accessible through the archive
server:  mail the word "help" to "archive-server at rice.edu".

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

Date:    Thu, 3 Mar 88 13:43:10 EST
From:    Root Boy Jim <rbj at icst-cmr.arpa>
Subject: Re: Capacity of CDC Wren IV, diag/format problem
Reference: v6n19

> From:    Hans van Staveren <mcvax!cs.vu.nl!sater at uunet.uu.net>

> We recently acquired a CDC Wren IV diskdrive and put it to work....
> Does anyone know the nitty gritty details about this?

No, but I'll take a guess. Most likely the 307 refers to the `unformatted'
capacity. Formatted capacity is often quite a bit (~20%) less.  You seem
to have gotten 285/307 or 92% out of it, which is higher than normal.

There are other ways to lose space as well, even if the 307 truly
represents the formatted capacity. Our Eagles on a VAX running 4.3 BSD
have a geometry of 842 x 20 x 48. On a SUN 3 and a Sequent they only use
46 sectors, losing 5%. On another SUN 3 with sector slipping, they
actually have 47 sectors, but you still only get 46.

Creating file systems also eats space for inodes, cylinder groups, super
blocks, etc. on the order of 7%. Further, the last 10% of real usable data
blocks are not doled out to anyone but the superuser.

Unless you can be more specific I wouldn't worry about it.

Just think of it as another kind of tax :-)

(Root Boy) Jim Cottrell	<rbj at icst-cmr.arpa>
National Bureau of Standards
Flamer's Hotline: (301) 975-5688

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

Date:    Thu, 3 Mar 88 16:28:35 EST
From:    Root Boy Jim <rbj at icst-cmr.arpa>
Subject: Re: screendump from SUN 3/110 to laserprinter; greyscale
Reference: v6n19

> Are there laserprinters which can do greyscale?

The Apple Laserwriter does greyscale. The is a Postscript command called
`setgray' which takes a floating point number between zero and one, and
interprets it in the obvious way. This is the SUN's standard laser
printer, so I would imagine there is a way of producing screen dumps on
it. Good luck.

(Root Boy) Jim Cottrell	<rbj at icst-cmr.arpa>
National Bureau of Standards
Flamer's Hotline: (301) 975-5688
YOW!!!  I am having fun!!!

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

Date:    Thu, 3 Mar 88 15:21:40 cst
From:    grunwald at m.cs.uiuc.edu (Dirk Grunwald)
Subject: 'rexd' is 'on' something

This is a summary of a problem which hit us early in February.

We have 2 3/50's (Oboe & Melodian) and a 3/280 (Guitar) which is both a
workstation & a server. We have modified the Sun NFS to allow root access
across the workstations, primarily to allow us to read mail on any
machine.  One fateful day, I was sitting around compiling & said ``I'd
like to use the 'on'  command to use Oboe & Melodian''. Would that I had
never done this.  I set up the entry in services & everything worked fine
-- I could do compiles on the 3/50's and life was happy.

Until, of course, the day when I found 80% of our file system missing.

It turns out that 'rexd', which is used by 'on', temporarily mounts file
systems in /tmp. E.g. if I was in /foo/bar on Guitar, and said:

	% on oboe make

then /foo is mounted at /tmp/rexdXXXXXX on Oboe, and the commands are
executed from that mount point (i.e. /tmp/rexdXXXXX/bar, in this case).
This occurs even if /foo is already mounted on Oboe. Now, this isn't a
symlink, it's a mount point, which appears to be very different. The most
important difference is that ``find'' traverses mount points.

The same ``find'' which is used in /usr/lib/crontab to delete files older
than 3 days.

Now, in our case, 'rexd' did not remove those directories, when when the
cleanup of /tmp occurred at 3:30am, our (largest) partition was also
cleared.  However, even in the case of rexd working correctly, if you were
so foolish as to be using the 'on' command at 3:30, you'd be opening
yourself to having your files wiped out.

The same problem occurs, although to a lesser extent, if you don't have
NFS set up for common-root. In that case, you'd just delete files with
'other' access instead of all files. However, it's still a problem.

Two solutions to this are:
	1) Don't use 'on' or 'rexd'
	2) Have 'rexd' mount partitions somewhere else /rexd/rexdXXXX?

We're doing the former.

Dirk Grunwald
Univ. of Illinois
grunwald at m.cs.uiuc.edu

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

Date:    Wed, 2 Mar 88 14:50:26 PST
From:    Doug Moran <moran at ai.sri.com>
Subject: Program to determine console type

There have been several requests in this digest for programs to determine
the type of the console.  Below is a program that I wrote to produce an
identifying string (I start suntools in my .login file and use this pgm to
determine which arguments to use).

Caveat:  my cluster has only a few of these monitor types, so the pgm has
not been fully tested.

Note on coding style: the function wu_fbid is actually located in a local
library, accounting for what otherwise might appear to be a strange coding
style.
__________

main()
{
    char *wu_fbid();
    char *consoleid = wu_fbid("/dev/fb");
    if ( consoleid == 0 )
	write(1, "tty", 3);
    else
	write(1, consoleid, 3);
    write(1, "\n", 1);
}
#include <sys/ioctl.h>
#include <sys/file.h>
#include <sun/fbio.h>

/* decoding as of Release 3.4 : fbio.h 1.3 87/01/09 SMI */
	/* the convention for entries in this table is to translate the
	 * macros for frame buffer codes (in <sun/fbio.h>) to short names
	 * thus:
	 *	FBTYPE_SUNxBW		becomes bwx
	 *	FBTYPE_SUNxCOLOR	becomes cgx
	 *	FBTYPE_SUNxGP		becomes gpx
	 *	FBTYPE_NOTSUN[1-9]	becomes ns[A-J]
	 */
static char *decode_fb[FBTYPE_LASTPLUSONE] = {
	"bw1", "cg1",
	"bw2", "cg2",
	"gp2",
	"bw3", "cg3",
	"bw4", "cg4",
	"nsA", "nsB", "nsC"	/* Not Sun */
	};

char *
wu_fbid(fbname)
	char *fbname;
{
	struct fbgattr fbattr;
	int fd, ioctl_ret;
	if ( (fd = open(fbname, O_RDWR, 0)) == -1 )
		return(0);
		/* FBIOGATTR fails for early frame buffer types */
	if (ioctl_ret = ioctl(fd,FBIOGATTR,&fbattr)) {	/*success=>0(false)*/
		ioctl_ret = ioctl(fd, FBIOGTYPE, &fbattr.fbtype);
	}
	close(fd);
	if ( ioctl_ret == -1 )
		return(0);
	    /* The binary is obsolete and needs to be re-compiled:
	     * the ioctl returned a value beyond what was possible
	     * when the program was compiled */
	if (fbattr.fbtype.fb_type>=FBTYPE_LASTPLUSONE)
		return("unk");
	    /* The source is obsolete.  The table "decode_fb" does not
	     * have entries for some of the values returned by the ioctl.
	     * Compare <sun/fbio.h> to the entries in "decode_fb" */
	if ( decode_fb[fbattr.fbtype.fb_type] == 0 )	/* decode_fb is obs */
                return("unk");
	return(decode_fb[fbattr.fbtype.fb_type]);
}

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

Date:    Wed, 2 Mar 88 09:42:33 PST
From:    mordor!tolerant!vsi1!tim at sally.utexas.edu (Tim Richardson)
Subject: Sun's (lack of) support for INTERPHASE disk controllers

Is SUN going to support the INTERPHASE model 4200 disk controller.  In our
opinion, the 4200 is the best disk controller out there.

What I don't care for is the apparent willingness of SUN to support one
vendors equipment and a complete unwillingness to support another vendors
equipment.  This is inconsistent with the stated philosphy of having an
"open architecture" and third party support, which is really hyped by the
SUN sales dept.

The next item is the INTERPHASE model 4201 with SCSI port.  This
controller is an ESDI (4 ported) controller which has an option (extra
cost) as the SCSI port.  Since you need the ability to boot from the
1/4inch tape, this board will eliminate the need to take up two backplane
slots (1 for the disk controller and another for the SCSIbus Host
Adaptor.)

The problem right now is that SUN won't allow third party vendors to link
their own boot device code to the SUN3/xxx CPU's boot EPROM.  Can we get a
resolution to this problem.  

Anyone who wants to integrate their own hardware, or be an OEM of SUN's,
has these kind of problems.

Tim Richardson
VICOM Systems Inc.     sun!pyramid----\
2520 Junction Ave.     uunet!ubvax-----!vsi1!tim
San Jose, CA  95134    ucbvax!tolerant/
+1-408-432-8660

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

Date:    3 Mar 88 19:10:21 GMT
From:    wiley!bob at uunet.uu.net (Bob Amstadt)
Subject: Problems with VME bus timeouts:  Ironics board on a Sun-3

I've been trying to use an Ironics IV-3272 Data Transporter board in a Sun
3/180. This board is a DMA engine that moves data from one place to
another. We want to use it to move data between two custom VME boards.
It's advantage is that it moves data faster than the Sun CPU. There is one
problem though. The Ironics board does not always release the bus as
quickly as the Sun CPU expects. Occasionally when doing transfers using
the Ironics board, Sun UNIX crashes with the reason, "BUS TIMEOUT."

Has anyone run into a similar problem? Can this timeout be changed or
disabled either through software or hardware?

---Bob Amstadt
bob at wiley.uucp
{csvax.caltech.edu,uunet.uu.net,trwrb.uucp}!wiley!bob

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

Date:    Thu, 3 Mar 88 14:13:05 CST
From:    aslam at p.cs.uiuc.edu (Sohail Aslam)
Subject: Can't make a xylogics 450 and interphase controller live together

I have a xylogics 450 controller managing a fujitsu eagle M2351 in a SUN
2/170 server. I got hold of an old fujitsu M2284 disk (128Mb) along with
an interphase controller. Xylogics lives at address 0xee40. Following the
configuration scheme I put the interphase controller at 0x40 and built a
new kernel. Upon rebooting, the boot procedure tried to boot off of the
interphase controller which is not what I wanted. I tried moving the
xylogics to xyc1 at mbio ? csr 0xee48, the system correctly booted off of
xy1(1,0,0) but then it complained that there is an unknown controller at
0x40. Is there a problem with my hardware or has someone else run into
problems putting a xylogics 450 and an interphase controller in the same
box?  I am running SunOS 3.5.

Adva-thanks-nce
Sohail Aslam
Department of Computer Science
University of Illinois
arpa		aslam at a.cs.uiuc.edu
csnet		aslam at uiuc.csnet
usenet		{ihnp4,seismo}!uiucdcs!aslam

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

Date:    Thu 3 Mar 88 11:59:02-EST
From:    Michael van Biema <MICHAEL at cs.columbia.edu>
Subject: Problems configuring cua0 on a 3/160 zs0

I've been having trouble setting up /dev/cua0 and /dev/ttyd0 on a Sun
3/160 zs0 port 1.  I've done it before under nearly identical
circumstances, and given how simple it was last time, and given the
step-by-step instructions in the documentation, I'm somewhat embarrassed
by having to ask the net for help.  However...

As far as *I* can tell:

	/etc/ttys is correct (13ttyd0 and 02ttya -- don't need cua0 right?).
	/etc/gettytab is correct (standard entries for 2 and 3).
	kernel flags for zs0 are correct (0x2 since I'm using port A).
	major and minor numbers on cua0 and ttyd0 are correct (12 128 & 12 0).
	dip switches on the Hayes Smartmodem 1200 are correct (as per Sun doc).
	cable is correct (in fact all 25 pins, straight through).
	and of course ttya has been banished from dev.

But I've obviously missed something because:

	I can dial out (with kermit or tip) as many times as I like,
	with no problem.

	I can dial in as many times as I like, with no problem.
	On ttyd0: init turns to getty
		  getty turns to login
		  login turns to sh
		  sh dies (on exit) and a new init (with a new pid) starts
	This is the way it's supposed to happen, right?

	However, once I dial in (log in and then exit), I can't dial out
	without first:

		Killing the new init process that started on ttyd0,
		and thus causing init (pid 1) to start another one on ttyd0

		-or-

		momentarily disconnecting the RS232 cable

		-or- 

		power-cycling the modem

		-or-

		momentarily driving DTR or DCD high (negative voltage,
		binary one).  Note that the modem seems to do this
		itself as it disconnects.  Why should I have to do it
		again manually?

	If I don't do one of the above, perror says "no such device or
	address" after trying to open /dev/cua0.  open returns ok
	after I do one of the above, or if I haven't dialed in yet to
	begin with.

I assume that among the things I've supposedly configured correctly, there
is something that I've overlooked or just plain screwed up, but maybe I've
just missed something completely.  If anybody has any suggestions towards
either end, I'd like to hear 'em.

  -Thanx

Michael

MICHAEL at CS.COLUMBIA.EDU                       (ARPANet)
MICHAEL at CS.COLUMBIA.EDU@CSNET-RELAY           (CSNet)
MICHAEL%CS.COLUMBIA.EDU at CUNYVM                (BITNet)
...rutgers!columbia!cs!michael		      (USENet)

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

Date:    Thu, 03 Mar 88 12:16:24 EST
From:    williams%nrl-css.arpa at nrl-css.arpa
Subject: Questions about Sun Shoeboxes

We have a few of the Sun shoebox drives around here, and are planning to
get more.  In order to figure out what we really want, I need some
information about the insides of these boxes.  If anyone has dug into
these things and can answer any of the questions below, I'd really
appreciate it.

First, I am working from the following assumptions/facts.  Sun offers two
types of shoebox: the Shoebox Subsystem (SS), which has a disk drive (ours
are 141MByte) and an optional cartridge tape drive, and the Expansion
Shoebox (ES), which is a disk only.  (These may not be the exact names Sun
uses, but that doesn't matter here.)

The questions are:

	What SCSI addresses are used for the SS disk, the SS tape, and
	the ES disk?

	Where are the SCSI bus terminators, if any?  It the SS? the ES?
	both??

	Can the SCSI address(es) of an SS be changed easily, so that
	the drive in an SS can be the second SCSI drive (sd1[a-h])?
	One reason we want to do this is so we can make a "master SCSI
	disk", then use that to initialize a new (type SS) SCSI disk. By
	attaching the new disk to a Sun as sd1, with the master disk as
	sd0, we could simply dd the old disk onto the new one.

	Would modifying the SCSI addresses as suggested above void the
	warranty on the shoebox?

	Can the Expansion Shoebox be used as sd0, by modifying the SCSI
	address, and removing/adding a bus terminator?

Much thanks in advance,
Jim Williams

James W. Williams			williams at nrl-css.arpa
Information Technology Division		
Naval Research Laboratory		(202) 767-9035
Washington, DC

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

Date:    Thu, 3 Mar 88 07:48 EST
From:    <STELLABO at CSHLAB.BITNET>
Subject: Grant Accounting on the SUN?

We are trying to bring our administrative functions on to the SUN
computers to standardize all our computing.  Our major stumbling point is
an accounting package.  We are a non-profit research laboratory, with
funding from the NIH and private sources.  We need a GRANTs management
package that will run on a SUN-3.  This package should be able to:

        1) Process Purchase Orders with immediate Grant incumbrance.

        2) Process Payroll grant incumbrances.

        3) General ledger and sub legder accounting.

        4) Grant information management.

        5) and ... Inventory  (not critical)

Does anyone know of such a package.. ???  If so please contact me at:

Fred J. Stellabotte
Computer Systems Manager
Cold Spring Harbor Laboratory
stellabo at cshlab
(516) 367-8420

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

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



More information about the Comp.sys.sun mailing list