Sun-Spots Digest, v7n10
William LeFebvre
Sun-Spots-Request at Rice.edu
Thu Nov 10 16:44:05 AEST 1988
SUN-SPOTS DIGEST Wednesday, 9 November 1988 Volume 7 : Issue 10
Today's Topics:
Re: Remote booting a Sun-3/280 -- failure!
Re: emergency bootables
Re: TTY Windows in SunView
Re: UU[EN|DE]CODE troubles
Summary of troff previewers for the Sun
GNU-EMACS 18.51 and 386i
386i's MS-DOS emulator and Postscript output
not playing with a full deck
Sun 4/110, OS4.0 Crashes
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 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 at rice.edu" or mail the word "help" to the same address
for more information.
----------------------------------------------------------------------
Date: Tue, 1 Nov 88 20:45:39 PST
From: pyramid.com!leadsv!hart at cs.utexas.edu (Howard Hart)
Subject: Re: Remote booting a Sun-3/280 -- failure!
Reference: v6n273
> problem is that when standalone copy is running, we try:
>
> From: ie(0,80c65,0)minifs
>
> and it doesn't work.
The above instructions were a typo on Sun's part. It should be:
From: ie(0,80c65,1)minifs
Where 1 is the number of the public partition, which is most likely the
same for most systems. There was one more typo a couple of lines down
under section B.9. It should read as below for the same reasons (I may be
wrong on this but its easy to try out.) :
> b ie(0,80c65,1)boot -a
The writeup is buried in the README first for OS 3.2, page 3
I saw Greg Wood's response in v6n334 and he's probably right about class
A, B and C incompatibilities, but I got exactly the same results on my
class C network where the previous stand/copy worked fine but the minifs
didn't. Try it and see.
Howard C. Hart
Lockheed Missiles and Space Co.
Orgn 59-53, Bldg 593
Sunnyvale, CA 94086
(408) 743-2253
uucp: sun!sunncal!leadsv!hart
------------------------------
Date: Wed, 2 Nov 88 11:34:20 EST
From: frank at morgan.com (Frank Wortner)
Subject: Re: emergency bootables
Jay Albert <albert at mssun7.msi.cornell.edu> wrote:
>As a new SysAdmin, I am nervous about our disks. I would like to be able
>to reboot our Sun3/260 server and 4 Sun3/50 clients off of any of them if
>one or more fail.
> [...]
>I have copied our kernel vmunix, as well as diag and boot, into
>directories in [3 different disks on the server]
>Will they be usable if Doomsday comes, and is there anything else I should
>do?
It depends on what kind of a Doomsday scenario you are envisioning.
Unless you take further steps, those kernel copies will only insulate you
from problems resulting from the deletion of those particular files.
I.e., if someone says "rm /vmunix", you could still boot, albeit
painfully. However, boot, diag and vmunix aren't the only critical files
in SunOS (or Un*x). Removing /bin/sh and/or /etc/init will also render a
system quite unbootable. There are quite a number of disk/file trashing
scenarios that can turn a computer system into a noisy paperweight. We
haven't even begun to talk about hardware failures yet.
I think you'd be better off with a copy of your entire root disk. It's
simpler to set up, and (I believe) more foolproof. Let's say you normally
boot from /dev/xy0a. Make another root partition on /dev/xy1a or
/dev/xy2a (etc.). Add to that a swap partition on those disks (/dev/xy1b
and/or /dev/xy2b). Now create a kernel that can boot and swap on the
various partitions, and you're in business. I have such an arrangement
myself. While it's not the ultimate, it certainly does work. I've tried
it -- happily only as an experiment.
In any event, it pays to be able to have more than one recovery plan. You
should have at least one copy of the distribution tape handy. If your
disk dies, and your extra disk-based copies of the OS are trashed, you
will need to start somewhere.
Frank
P.S. All recovery plans RELY ON BACKUPS. I've found out the hard way.
------------------------------
Date: Wed, 2 Nov 88 15:02:34 CST
From: hsc at vuse.vanderbilt.edu (Hsuan Chang)
Subject: Re: TTY Windows in SunView
Paul R. Jordan writes:
> ...Is there a hard limitation on the number of TTY windows in one
> application ?...
and Ellery Chan replies recently:
> The different SunView window objects use up file descriptors, of which
> your program has a finite number (probably ~30). There is a handy table
> on p.54 of the SunView Programmer's Guide that says: ...
I would like to add that Ellery was referring to the old manual for SunOS
3.x. For SunOS 4.x, the file descriptor has been increased to 64. (check
manual page 57 of the new SunView Programmer's Guide.
- hsc at vuse.vanderbilt.edu
Hsuan Chang
Image Processing Lab
Computer Science Dept
Vanderbilt University
Box 1679, Station B.
Nashville, Tn 37235
------------------------------
Date: Thu, 3 Nov 88 10:47:48 EST
From: dph at jabba.psu.edu (David P. Huenemoerder)
Subject: Re: UU[EN|DE]CODE troubles
Reference: v7n1
There is a character translation solution that I have come across in the
Atari ST networld. It is a version of uuencode (the Dumas version) which
puts a character translation table before the "begin" line, which uudecode
reads. So if a site uses a funny table, its translation is included and
will be properly decoded. This has solved all my troubles in downloading
files through an IBM. It also has the additional features of breaking
encoded files into user specified sizes and putting an "include <file>" at
the end. Uudecode can then essentially "cat" all the encoded files itself
while decoding. The table looks something like:
table
!"#$%&'()*+,-./0123456789:;<=>?
@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
and the begin ... line follows.
This version is backwards compatible with normal encoded files (as long as
no characters got munged, but it knows something about valid characters),
so you won't need two versions of uu[en|de]code. Sources have been
posted. Don't ask me for them. Some places to look are:
Bitnet: a file server in Houston:
uh-info at uhupvm1 atarinet
Internet anonymous ftp:
umich (35.195.16.4)
ssyx.ucsc.edu (128.114.133.1)
I don't know if this has propagated to other computer groups.
David Huenemoerder
internet: dph at astro.psu.edu
------------------------------
Date: Wed, 2 Nov 88 12:02:04 PST
From: ucdavis!csusac!csun!polyslo!gshute at ucbvax.berkeley.edu (Glenn C. Shute)
Subject: Summary of troff previewers for the Sun
Thanks to everyone for your replys.
Here is a summary of troff previewer's for the Sun.
===================================================
As we all know by now X11 Release 3 sources include a troff previewer for
the Sun in the user contributed section.
Many people use suntroff and find the "EXCELLENT" it was made available on
Sun User Group (SUG) tape no. 2.
ximpv
X Imagen previewer - It requires that you use iroff - SLOW
xproof
Displays ditroff output. Plays some funny games with fonts, but
is much faster than ximpv.
Both of these can display ditroff graphics, as produced by pic, and
picgraph, etc. Neither can handle Postscript. There is supposedly a
Postscript previewer, xps....
Elan Computer Group, Inc. sells a package called EROFF which is the AT&T
Documenter's WorkBench (DWB), including device independent troff, nroff,
tbl, eqn, pic, grap, macros, etc., plus bug fixes and enhancements
including bitmap graphics inclusion, and drivers for the HP LaserJet line
of printers and PostScript printers (an Imagen driver is also available).
Automatic HP Soft Font downloading is done for the LaserJets. Downloadable
Adobe PostScript fonts may also be used. DWB and the printer drivers are
also available separately. All of this is available on dozens of
different UNIX machines and under MS-DOS.
Our soft copy screen previewer EVIEW is available for Suns under SunView,
many systems under X-Windows V10R4, and support for X11 is in progress.
All of DWB 2.0 and EROFF's enhancements are supported by EVIEW.
Jeff Lo
Elan Computer Group, Inc.
410 Cambridge Avenue, Suite A
Palo Alto, CA 94306
(415) 322-2450
..!{ames,hplabs,uunet}!elan!jlo
==========================
Our troff users thank you.
Personally I use the texx previewer under X and find very easy to use. I
have nothing to compare it to, but it does seem slow.
Glenn C. Shute Computer Science Department Cal Poly, SLO. Ca.
gshute at polyslo.CalPoly.EDU or {csun,voder,trwind}!polyslo!gshute
------------------------------
Date: Wed, 2 Nov 88 07:55:06 CST
From: Jody Winston <shell!jody at gazette.bcm.tmc.edu>
Subject: GNU-EMACS 18.51 and 386i
On of the "features" of the 386i is a "new and improved" keyboard. The
keypad not only has more keys than the Sun-3 style keyboard, but some of
the keys generate diferent escape sequences. This can cause problems if
you use GNU-EMACS and the terminal file sun.el. The following keys on the
386i do not work: R1-R6, R8, R10, R12, R14, Ins, Del, Enter, +, -, and Num
Lock. I fixed the problem in the following manner:
[[ Most of this article was a bunch of Gnu emacs functions. The entire
text of the artice can be found in the archives under "sun-source" (since
it is mostly source) as "386i.gnuemacs.keys". It is 5781 bytes long. 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 at rice.edu". --wnl ]]
These additions allow the complete use of the 386i keypad and displays
the status of the num lock on the mode line.
------------------------------
Date: Wed, 2 Nov 88 12:14:15 CST
From: Jody Winston <shell!jody at gazette.bcm.tmc.edu>
Subject: 386i's MS-DOS emulator and Postscript output
The dos2unix command that is supplied with the 386i removes the extra
carriage returns and fixes the end of line character in MS-DOS files, but
does not remove other control characters that might be found in the file.
Several PC products which produce Postscript output have control Ds in the
file (^D). If this file is sent to a Postscript printer, the printer
complains about the file and refuses to print it. I wrote a small C
program that strips off the ^M, ^D, and ^Z in the MS-DOS file so that the
file can be printed on a Postscript printer.
#include <stdio.h>
#define CTLM '\015'
#define CTLD '\004'
#define CTLZ '\032'
#define INPUT 0
#define OUTPUT 1
main(argc, argv)
int argc;
char *argv[];
{
char buffer[10];
register i;
while (read(INPUT, buffer, 1) == 1)
if ( (buffer[0] != CTLD) && (buffer[0] != CTLM) && (buffer[0] != CTLZ) )
write(OUTPUT, buffer, 1);
}
To use the program modify your setup.pc like this:
#
#
# DOS DEVICE UNIX DEVICE PATH NAME
#
LPT1 xlate | lpr
Where xlate is the name of the above filter program.
Jody Winston jody at shell.uucp
...!{sun,psuvax1,bcm,rice,decwrl,cs.utexas.edu}!shell!jody
Shell Development Company, Bellaire Research Center
P.O. Box 481, Room 2202
Houston, TX 77001 (Voice: 713 663-2050)
------------------------------
Date: Wed, 2 Nov 88 18:52:10 CST
From: thompson at umn-ai.cs.umn.edu (William B. Thompson)
Subject: not playing with a full deck
The following bug report was submitted directly to Sun, but I think that
it may be important enough to forward to Sun-Spots:
____________________
There is a bug in canfieldtool that can cause serious difficuties. Twice
now I have been about to win when canfieldtool has lost a card. Once it
was a missing an 8 of clubs. Just now it was a missing a 5 of spades. My
faith in the reliability of sun software (not to mention my general well
being) has been shattered. I expect this grevious problem to be fixed
IMMEDIATELY.
The manual entry for canfield says:
> BUGS
> It is impossible to cheat.
The entry should be changed to reflect the fact that while the user can't
cheat, the program can and does! [[ Yeah! Just like gammontool! :-)
--wnl ]]
William B. Thompson
University of Minnesota
------------------------------
Date: Wed, 2 Nov 88 08:55:32 MST
From: roberts%studguppy at lanl.gov (Doug Roberts @ Los Alamos National Laboratory)
Subject: Sun 4/110, OS4.0 Crashes
I seem to be able to make my 4/110 crash in a number of unexpected ways.
This particular machine is running with 20 MB of memory: 4 MB of the 256K
SIMMS, and 16 MB of Helios. The system boots off of a CDC Wren-V (702 MB
unformatted, ~602 MB formatted).
The following are excerpts from /usr/adm/messages [[ I have stripped off
the more-or-less redundant information at the front of each line except
the first in each case. --wnl ]]:
1. I don't know what caused this one...
Oct 22 19:18:17 candygram vmunix: cmdtool: Data fault
kernel read fault at addr=0x400ce4, pme=0x70000000
Bus Error Reg 80<INVALID>
pid=179, pc=0xf8034600, sp=0xffffec58, psr=0x800cc5, context=3
g1-g7: 800ce6, 4002e1, 4, 0, 0, 0, 0
Begin traceback... sp = ffffec58
Called from f8040ff8, fp=ffffecb8, args=400ce0 f80f8648 86 80 f80ee5e8 0
Called from f8035270, fp=ffffed18, args=ff04cd34 f80f8648 4002e0 80000000 ff04cd34 ff06c980
Called from f80441a8, fp=ffffed78, args=ff04ccec f80f8648 f8037304 0 4002e1 0
Called from f8042a64, fp=ffffedd8, args=ff04cd10 f80f8648 ff052ea8 1 f80f9968 ff0726fc
Called from f8034b30, fp=ffffee38, args=ff04cd58 f80f8648 9002e3 86 4 f80f2f20
Called from f80416dc, fp=ffffee98, args=ff04cd58 86 3 0 4002a4 1
Called from f8035578, fp=ffffeef8, args=ff04cd34 f80f2c00 ff06c980 f80f8720 f812d208 f80415a0
Called from f8005544, fp=ffffef58, args=0 4000e0 1000 ff04cd34 f81301e8 0
Called from f776fa00, fp=f7fff050, args=3 4 f7fff02c 4024 4350 1
End traceback...
panic: Data fault
zs3: silo overflow
syncing file systems... [3] 2 [3] [2] [2] done
dumping to vp ff078028, offset 164180
2. This on occured while running format on the Wren-V (I was forced to
format the disk on a Sun 3 running OS3.5)...
Nov 1 10:17:39 candygram vmunix: sw0: swintr: ignoring spurious phase
last phase= 0x8 (COMMAND)
csr= 0x1405 bcr= 0 tcr= 0x4
cbsr= 0x6d (STATUS) cdr= 0x21 mr= 0x2 bsr= 0x0
target= 0, lun= 0 DMA addr= 0xf02000 count= 1024 (1024)
cdb= 8 0 2 60 2 0
Can't invoke init, error 2
panic: icode
syncing file systems... done
dumping to vp ff053c28, offset 164180
sw0: sw_arb_sel: scsi bus continuously busy
sw0: resetting scsi bus
last phase= 0x87 (Cmd complete MSG)
csr= 0x140d bcr= 0 tcr= 0x0
cbsr= 0x6d (STATUS) cdr= 0x0 mr= 0x0 bsr= 0x0
target= 0, lun= 0 DMA addr= 0xfbe000 count= 8192 (8192)
cdb= a 2 c0 bc 10 0
3. This one occured while a tar was running in a shelltool, and GNU
EMACS 18.52 emacstool was attempting to save a file.
Nov 1 17:29:46 candygram vmunix: BAD TRAP
emacs: Memory address alignment
addr=0x1
pid=213, pc=0xf8072278, sp=0xffffebb8, psr=0x4000c4, context=0
g1-g7: 0, 4000e4, ffffffff, fffffffc, 44, 0, 0
Begin traceback... sp = ffffebb8
Called from f807240c, fp=ffffec20, args=63747572 14 4 13 63747572 0
Called from f807093c, fp=ffffec80, args=ff147ae8 1d 0 80000000 2 1e
Called from f8076db8, fp=ffffece0, args=ff13dc20 ff13dc80 ff13dc80 1e ff13d274 ff147534
Called from f8072b10, fp=ffffed40, args=ff13dc20 5133c38 ffffff 4000e1 f810a018 ff13af6c
Called from f802df2c, fp=ffffeda0, args=ff13af6c 1000 ff13af6c 0 f8088bb4 0
Called from f802caa4, fp=ffffee00, args=f8130438 f8130438 8401 4000a3 f8135c10 0
Called from f802ca18, fp=ffffee60, args=ff65b200 f80e8918 9 f8130438 80 20
Called from f80949d0, fp=ffffeec0, args=ffffefe0 f80d8588 f80d8588 1 ffffefb4 ffffefe0
Called from f8005960, fp=ffffef58, args=8000000 1 1000 1 1 8
Called from d0bbc, fp=f7fff2f0, args=0 1 1 f7fff2d0 1 12bc00
End traceback...
panic: Memory address alignment
syncing file systems... SunOS Release 4.0 (unix.candygram) #2: Mon Aug 29 16:58:40 MDT 1988
Douglas Roberts
Los Alamos National Laboratory
(505)667-4569
dzzr at lanl.gov
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list