Sun-Spots-Request@RICE.EDU (William LeFebvre) (08/04/88)
SUN-SPOTS DIGEST Monday, 1 August 1988 Volume 6 : Issue 160
Today's Topics:
Administrivia: what topics should be discussed?
Minor changes to contool
I propose a hardware bitch/comment mailing list/group.
Problems with transcript software
Re: Success networking an AT with a VMS machine?
Exabyte buying tips?
Booting OS4.0 from a Ciprico 3220 (LONG)
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: Mon, 1 Aug 88 11:51:12 CDT
From: William LeFebvre <phil@Rice.edu>
Subject: Administrivia: what topics should be discussed?
A submission that appears in this digest, along with many others that have
appeared this year, has prompted me to ask this question: exactly what
topics should be discussed in this forum? This is a mailing list about
Sun workstations and other Sun processors. It is clear that anything
directly pertaining to Sun hardware and the Sun operating system should be
discussed here. It is also clear that discussion of any software intended
to run exclusively on a Sun is a valid topic. What about generic Unix
programs such as "gcc" or other GNU software? Should they be discussed
here? What about applications of Sun software on other machines? The
example appearing in this digest is "how can I get an IBM AT to talk
PC-NFS with a VAX VMS machine?" This does not involve any Sun hardware.
It does not seem like it would be interesting to the Sun community at
large. But it does involve PC-NFS, a program that is (presumably) sold
and supported by Sun. What about new Postscript fonts for Transcript? Or
other Postscript-related topics? There is a list devoted exclusively to
the discussion of Postscript.
There is a whole basketfull of topics that are very remotely related to
Sun, but don't seem (to me anyway) to be particularly interesting to the
general readership of this list. What topics should I direct elsewhere
and what ones should I include? I am very interested in feedback on this.
This is your list and I am reluctant to adopt a sweeping editorial policy
without input from the readers. Please mail your comments and opinions to
"sun-spots@rice.edu". I will read/edit/summarize them. If you want to
communicate directly with me on this topic, feel free to send me mail
directly at "phil@rice.edu".
William LeFebvre
Your moderator
phil@Rice.edu
------------------------------
Date: Thu, 30 Jun 88 20:24:38 EDT
From: Matt Landau <mlandau@diamond.bbn.com>
Subject: Minor changes to contool
Contool is pretty nice, but I had the following two problems with it.
(1) I run X11 on top of SunView from time to time, with one of my
xterms acting as the console. When I leave X, I need to be able
to send console input back to contool. Therefore, I added a
"Become Console" menu item. Selecting it causes contool to
grab console output again, in case it's been redirected since
contool was started.
(2) I found the menu organization inconvenient, so I reworked it
a bit. Contool now has its own top-level menu, with the SunView
frame commands on a submenu.
Here are the diffs for these two changes:
[[ The diffs have been placed in the archives under "sun-source" as
"contool.1.0.diff". Warning: these diffs are for the old version of
contool. I used patch to apply them to version 1.1 and two of the hunks
failed. So use this with discretion. The diff is 5090 bytes in length.
It can be retrieved via anonymous FTP from the host "titan.rice.edu" or
via the archive server. For more information about the archive server,
send a mail message containing the word "help" to the address
"archive-server@rice.edu". --wnl ]]
------------------------------
Date: Wed, 20 Jul 88 12:15:15 PDT
From: Jason Venner <jason@spar.slb.com>
Subject: I propose a hardware bitch/comment mailing list/group.
I will even volunteer to be the moderator, which will probably be needed
to keep the net censor's happy.
An initial mailing list name could be:
hardware-review@spar.slb.com
Jason
jason@spar.slb.com
{hoptoad,hplabs,decwrl}!spar!jason
[[ Presumably you mean Sun and Sun related hardware? Or any hardware at
all? Can I gripe about my microprocessor-controlled toaster? It can't
toast the bread evenly. --wnl ]]
------------------------------
Date: Wed, 20 Jul 88 12:01:07 EDT
From: John T. Nelson <jtn@potomac.ads.com>
Subject: Problems with transcript software
> From: Chuck Musciano <chuck@trantor.harris-atd.com>
> Subject: Re: Problems with Apple Laser-writer and Sun
>
> Aha! We use "real" software, the TranScript driver from Sun....
Speaking of the trasncript software, has anyone solved the problem with
footers being hacked off at the bottom of pages with the new transcript
software. Let me explain...
Sun's transcript software version 1.1 worked fine although there were a
few driver bugs where the software would become confused now and then.
Then we upgraded to transcript software version 2.1 dated 1985 and the
drivers started behaving much more intelligently....
BUT
all of our footers at the bottom of troff output are being mysteriously
cut in half, that is the top half of the footer is displayed and the
bottom part of the lettering extends beyond the area that is printed.
Talking to Sun, they concluded that Adobe had changed the size of the page
that was printed to conform to some kind of international page size which
is different from American size page sizes. The Sun person said they were
negotiating with Adobe about this but ALL customers using Adobe drivers
would have this problem. And that was the last I heard from them.
My quick and dirty fix is to use superscripted footers. This seems to
help. Moving the page around with the tools Sun supplies doesn't really
help as the actual size of the page has increased.
Can anyone verify this at their site and does anyone have a fix? It is
most definately a bug in thef trasncript software and has nothing to do
with OS releases (we're running 3.4).
------------------------------
Date: THU, 21-JUL-88 13:24 N
From: <MOROSSI%ASTRTS.INFNET%IBOINFN.BITNET@icnucevm.cnuce.cnr.it>
Subject: Re: Success networking an AT with a VMS machine?
We should like to contact people who have succeded in connecting IBM AT
with a VAX VMS with PC-NFS. We have problems.
L. Lampi and C. Morossi
Osservatorio Astronomico
via G. B. Tiepolo 11
I-34131 Trieste (Italy)
Electronic mail address: psi 2222403259
Span 40057
INFNET ASTRTS
Usernames : Lampi Morossi
------------------------------
Date: Wed, 20 Jul 88 17:08:23 EDT
From: Bennett Todd <bet@orion.mc.duke.edu>
Subject: Exabyte buying tips?
We got an Exabyte from Peripheral Devices; they sell the Delta
Microsystems' packaging of the Exabyte. It sticks 2.3G onto a 2hr 8mm
videotape cartridge (~$9/cart); it takes us about 5 hours to fill one up
taking multiple dumps (many, many dumps!) and piping them back to the
machine with the Exabyte via rsh. A majority of the time is being wasted
by the networking software; the Delta Microsystems device driver and the
Exabyte drive should be able to jam the sucker full in little more than 2
hours, if you could stuff data into it quickly enough. The installation
went extremely smoothly, and the thing has worked flawlessly ever since.
Our sales contact for Peripheral Devices is:
Eric Madsen
+1 407 487 1880
We routinely order piles of stuff from them, and have been quite satisfied
to date. We have worked with another Delta Microsystems device ordered
through them (the SS-800W WORM drive), and overall I am quite happy with
the hardware, software, and support from Delta Microsystems.
------------------------------
Date: Tue, 19 Jul 88 18:41:27 PDT
From: Center for Computational Sciences and Engineering <ccse%hub@hub.ucsb.edu>
Subject: Booting OS4.0 from a Ciprico 3220 (LONG)
For those of you who were dismayed by the fact that Sun is apparently
stonewalling any "non-standard" third-party disk controller vendors by not
releasing the technical information required to build the boot proms and
programs for Sun OS4.0, here is a ray of sunshine: we're running two Sun
3/260's under Sun OS4.0 with nothing but Ciprico 3220 SMD disk controllers
attached to Toshiba disk drives.
For those of you who may wonder "Why use a non-standard
(non-Sun-supported) disk controller and/or non-Sun-standard drives?" The
answer is: the Ciprico controllers are much faster, with a 512K byte
cache, with which you have NO rotational delay, and a maximum contiguous
block count of 40; while the standard Sun Xylogics controller has a max
block count of 1, and a 4 ms rotational delay. Moreover, the Ciprico
subsystem is cheaper. We selected the Toshiba drives because we got more
megabytes per megabuck :^). Thus, even with substantial educational
discounts from Sun, Ciprico device drivers and Toshiba disk drives are
much cheaper. We are planning to replace ALL of our Xylogics controllers
in five Sun 3/260 servers (each acting as a subnet gateway) with Ciprico
controllers, in order than some amount of performance improvement may be
realized.
The requirements are that you must have a Sun OS3.[45] server running with
a spare client partition from which you can boot the new server to run
OS4.0. You must also, of course, have a Ciprico 3220 SMD controller, the
Sun Boot Kit appropriate for your architecture (our was for Sun 3/260),
and the Ciprico device driver source code for OS 4.0. You will also have
some kind of disk to attach to the Rimfire 3220; we used Toshiba MK-286
and MK-388.
The steps are (in brief):
a. Build the appropriate kernel with the Ciprico Rimfire
device driver under OS3.x. Basically, you follow
Ciprico's BootKit instructions for OS3.[45], and make a
OS3.[45] kernel for your machine
b. Install this kernel into the ND partition from which you
will boot your new server (which will be temporarily
running as an ND client). At this point, you'll need to
run "/dev/MAKEDEV rf0" in the client partition's /dev
directory to create the device inodes. Part of the
Ciprico instructions includes modifying MAKEDEV
appropriately, based on the block device index and the
character device index, obtained when /usr/sys/sun/conf.c
is modified.
c. Boot your server as an ND client, and using the "rfutil"
program which came with the boot kit, configure and format
your drives. This is the catch: currently, "rfutil" seems
to reliably work only under OS 3.x, so you must initially
configure and format the drives using a 3.x kernel. Once
you build such a kernel, however, you can keep it for
later use. You should label the disk with partitions
suitable for OS 4.0: having the d and e partitions set up
appropriately for the expected number of clients as
/export/root and /export/swap will be the filesystems on
these partitions, respectively.
The "rfutil" program compiled successfully
under OS 4.0 (after some minor typos were eliminated -- we
have a "developmental" version), but the "g" and "p"
commands didn't work: they weren't able to write the disk
label information to the kernel. The source was present,
but I didn't debug this further.
d. After formatting the drives (rf0 and rf1), as we had an
existing OS 4.0 system up and running, we copied the
entire / and /usr partitions from the the running OS 4.0
system onto the new disk. Also copy the "boot" program
supplied with the Rimfire bootkit into the root partition.
e. Mount the new root partition with the command: "mount
/dev/rf0a /mnt". Then, configure the following files
correctly for your new server:
/mnt/etc/fstab should have something like:
/dev/rf0a / 4.2 1 1
/dev/rf0g /usr 4.2 1 2
/dev/rf0h /home 4.2 1 3
/dev/rf0d /export/root 4.2 1 4
/dev/rf0e /export/swap 4.2 1 0
/mnt/etc/rc.boot should set the hostname correctly
f. Copy the OS3.5 /usr/mdec/installboot script into your
/usr/sys/rf directory, to save it for later use. Do the
command:
installboot rfboot /dev/rf0a
which will write the "rfboot" program into the boot blocks
of "rf0a".
g. Now, you'll need an OS 4.0 kernel which has been
configured with the Rimfire controller. We did this on
another OS 4.0 system that was already running. We
followed the OS 4.0 instructions from Ciprico, which came
as an addendum to the driver source. The paths were
different, but the changes were basically the same: You
must modify /usr/sys/sun/conf.c to modify the "bdevsw"
table, and the "cdevsw" table, remembering the position in
each table at which the "rf" device driver was referenced;
/usr/sys/sun/swapgeneric.c must be modified to include a
reference to the "rfcdriver"; the block device number must
added to a line in the "devices" file; and the source code
files must be copied to /usr/sys/sundev, and "rf.c"
inserted into /usr/sys/sun3/files. The Ciprico
instructions did NOT match the default configuration of
the controller jumpers with respect to the priority level:
the instructions specify "priority 2" while the board is
jumpered for "3". We just changed the config file to say
"priority 3", and it works fine.
After building the kernel, copy it into the root partition
of the new disk. Do this by mounting /dev/rf0a on /mnt,
and copying vmunix to /mnt.
Note that when you configure the device driver this time,
the block and character device numbers will possibly (most
likely) be different; be sure to use the NEW numbers when
modifying MAKEDEV for OS 4.0. After modifing
/etc/MAKEDEV, be sure to copy MAKEDEV into
/mnt/dev/MAKEDEV (assuming that /dev/rfa0 is still mounted
on /mnt), and run it from that directory to make the root
partition device nodes on the drive valid for the OS 4.0
unix which you have just built. Note that you are
currently referencing the drive using a device node from
the client root partition which actually lives on the
server for the temporary client. But, when you boot using
the Rimfire 3220, the root partition on the attached disk
must have valid /dev inodes to reference the partitions
under the kernel which will be running, namely OS 4.0.
g. At this point, you have:
1. A disk formatted and labelled under OS 3.[45], but
partitioned appropriately for OS 4.0.
2. The disk contains OS 4.0 in the root partition
3. Valid /dev/rf[0-3][a-h] device nodes
4. /usr partition has the appropriate Sun OS 4.0 binaries
You can now boot: if you have not already replaced the Sun
boot proms with the Ciprico boot proms, you should now do
so (being very careful about static electricity). If the
proms are correctly inserted, the command
>b rf()
should attempt to boot the system from the new disks using
the Ciprico controllers. If something is not right, you
can just do:
>b ie()
to boot the system from its temporary client partition,
and once up, fix whatever you forgot to do. Then, try
rebooting as before.
As the system boots the first time under OS 4.0, fsck under 4.0 will
adjust the directory inodes to be an even multiple of 512 bytes; this
will not adversely affect rebooting under 3.5 in case you need to fix
something.
The only catch to all of this is that "rfutil" currently doesn't work well
under OS 4.0. I hope, though, that with a little debugging time, Ciprico
will have this fixed and I'll be able to add and format more drives
without going back to a 3.5 system.
The best thing would be if Sun were to continue its previous policy of
providing at least consulting services to 3rd-party vendors in order to
develop alternative boot subsystems. Either that, or Sun should seriously
look at supporting better disk controllers. They've taken a good step
towards generalizing their "format" program, but I don't think it will
support any other controllers except the ones which have had device
drivers "hard coded" into the program. If they continue the
generalization a little further, it should be possible to develop a
program to drive any reasonably standard SMD controller.
Feel free to contact me if you need assistance; if you call because
something I've described above doesn't work for you, please be sure that
you have eliminated all "cockpit errors" before calling.
Alan Stebbens Computer Resource Manager
Center for Computational Sciences and Engineering (CCSE).
University of California, Santa Barbara
3111 Engineering I
Santa Barbara, CA 93106
ARPA: aks@hub.ucsb.edu
BITNET: aks%hub@ucsbuxa.bitnet
CSNET: aks%ucsb@relay.cs.net
UUCP: ...{ucbvax,sdcsvax,cepu}!ucsbcsl!aks
VOICE: (805) 961-3221
------------------------------
End of SUN-Spots Digest
***********************