Sun-Spots-Request@RICE.EDU (William LeFebvre) (08/29/88)
SUN-SPOTS DIGEST Friday, 26 August 1988 Volume 6 : Issue 198
Today's Topics:
Re: 4.0 multi-file system dumps to one tape (bug)
Re: troff leaders
yp provided by HP
Botch in SunOS4.0 ttytab crashes system
bug in xt device driver will cause other device drivers to panic
Sun f77 -fswitch overhead. Comparison with HP9000/350
boot prom support for 3rd party peripherals vendors
Need help with Gnu emacs on the Sun
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: 20 Aug 88 05:47:13 GMT
From: elroy!grian!liz@ames.arc.nasa.gov (Liz Allen-Mitchell)
Subject: Re: 4.0 multi-file system dumps to one tape (bug)
> When specifying the no-rewind option in the dump script for the device
> that you are writing to (ie., /dev/nrst8) the driver writes two eof
> markers at the end of the dump. Dumping other files to the tape may occur
> successfully however the problem occurs when trying to read back data from
> the tape.
I more or less stumbled onto a way to read off such a tape. Try calling
recover using something like:
restore ibfs 126 /dev/rst0 3
This would normally get the 3rd dump off the tape, but if you've written
the tape using /dev/nrst0, this will get the 2nd dump you made. If you
specify 5, you get the third dump you made, etc. A bit strange, but...
- Liz Allen-Mitchell liz@grian.cps.altadena.ca.us
ames!elroy!grian!liz
------------------------------
Date: Thu, 25 Aug 88 07:56:47 PDT
From: ames!vsi1!ubvax!ardent!paul@pasteur.Berkeley.EDU (Paul Ausick)
Subject: Re: troff leaders
ufnmr!ufnmr_1!mike@bikini.cis.ufl.edu (Michael D. Cockman):
> Could anyone tell us if the leader function ( \a ) in troff is functioning
> as shown in the 'Tabs, Leaders, and Fields' section of the troff manual ?
> If there is no software bug in troff, could someone show us how to use the
> leader function correctly ??
>
> Reply to:
> Username: ufnmr!mike
> Node: bikini.cis.ufl.edu
>
The troff leader function has always worked for me just as described in
the troff manual. The description leaves a great deal to be desired,
however.
Here are the macros I use to print the Permuted Indexes to our versions of
the Unix Reference Manuals:
________
.\" Permuted index definition
.ll 5i
.lt 5i
.nr ep 2.5i
.dePx
.tr~
.nr)y \n(.lu-1i
.nr)x \\n()yu/2u
.dss2 ~~~
.dss4 ~
.dss5 ~
..
.dexx
.ta\\n(.luR
.ti0
.lc .
.ps9
.vs11
.nf
.dss1
.if\w'\\$2' .ds s1 ~\|
.dss3
.if\w'\\$4' .ds s3 ~\|
\h'\\n()xu-\w'\\$1u\\*(s1\\$2\\*(s2'u'\\$1\\*(s1\\$2\\*(s2\\$3\\*(s3\\$4\\*(s4\a
\\*(s5\\$5
..
_________
The '.lc .' request defines the leader character to be a '.'. The final
line of the 'xx' macro uses the escape sequence '\a' to print a series of
dots up to the right adjusted tab specified in the first line of the 'xx'
macro definition. This is just a slight redefinition of the standard 'xx'
definition that comes with the Unix manuals we bought from AT&T.
Hope this helps.
------------------------------
Date: Sun, 21 Aug 88 10:23:53 -0100
From: enea!kuling!irf@uunet.uu.net (Bo Thide)
Subject: yp provided by HP
>From: mkhaw@teknowledge-vaxc.arpa (Mike Khaw)
>
>Aside from SunOS and Ultrix, what other vendors supply and support yp on
>their Unix boxes and how up to date is their NFS/yp compared to SunOS?
HP provides NFS + yp on their HP9000/3x0 (MC68000, 68010, 68020, 68030)
series (for both HP-UX and 4.3 BSD) and on their HP9000/8x0 (HP-PA/RISC)
series (HP-UX only). Haven't tried it (yet), though ....
Bo Thide', Swedish Institute of Space Physics, S-755 90 Uppsala, Sweden
Phone (+46) 18-300020. Telex: 76036 (IRFUPP S). UUCP: ..enea!kuling!irfu!bt
------------------------------
Date: Fri, 19 Aug 88 20:08:30 PDT
From: mkp@hac2arpa.hac.com (Mike K. Peterson)
Subject: Botch in SunOS4.0 ttytab crashes system
We upgraded one of our servers to 4.0 a couple of days ago, and were happy
to regain certain elements of 4.3bsd functionality we had grown accustomed
to on VAXen a couple of years back... ;-)
The server in question has a VT100-compatible terminal on ttya as its
console. During an editing session on /etc/ttytab, ttya was marked as
"on," followed by a quick "kill -HUP 1" and equally quick system crash.
I suppose one could argue, "What the hell were you doing spinning off a
getty on ttya anyway?" but this behavior still seems lame to me.
Has anyone noticed an admonition against the above in the 4.0 docs?
be forewarned,
Mike Peterson mkp@hac2arpa.hac.com
Hughes Aircraft Company
Space & Communications Group
------------------------------
Date: Fri, 19 Aug 88 23:24:14 EDT
From: hedrick@aramis.rutgers.edu (Charles Hedrick)
Subject: bug in xt device driver will cause other device drivers to panic
I'm never sure when it is worth reporting bugs to this list as well as to
Sun. But we've had a couple of failures recently that were hard enough to
track down that it seems worth trying to save others the trouble as well.
[[ Bugs should always be reported to Sun, because that's the best way to
get them fixed. Reporting bugs to Sun-Spots is also a good idea because
it helps out others and someone out there might have a temporary fix or
workaround. --wnl ]] Here's the first one.
We are in the process of installing Ciprico 3220 disk controllers on our
larger Sun 4 systems. We found that on systems with Sun 6250bpi tape
drivers, the Ciprico device driver paniced with an unaligned memory error.
It turns out that the xt device driver allocates a block of memory 18
bytes long using rmalloc. Rmalloc doesn't do anything to make sure that
blocks it returns are aligned on full-word boundaries. Thus on the Sun 4
the caller must make sure that it always requests blocks that are a
multiple of 4 bytes. Most drivers do, but the xt does not. This means
that the *next* device driver to ask for memory will get a misaligned
block, and will panic. This is rather hard to debug, since the problem
seems to be associated with a driver that is in fact innocent. If you
have source, in xt.c, find the call to rmalloc and replace the sizeof with
a hardcoded 20 (decimal). If not, you can do it in adb. Look for a "mov
0x12,%o1" in xtprobe. In our copy of 3.2 it is at xtprobe+70. In 4.0, it
is at xtprobe+4c. You can change the instruction to move 0x14,%o1 as
follows:
adb -w whatever
xtprobe+70?i should display mov 0x12,%o1
.?X should display 92102012
.?W 92102014 changes the 0x12 to 0x14
.?i should display mov 0x14,%o1
^D
Presumably you'll apply this to a copy of xt.o in /sys/sun4/OBJ before
building a new kernel. This problem could occur with any new device
driver. It seems to be a miracle that it doesn't happen with systems
using Sun's devices. Presumably they work only because the xt is probed
late in the sequence. (The problem would show up only on systems with an
odd number of tape drives.)
------------------------------
Date: Sun, 21 Aug 88 15:42:31 gmt
From: Bo Thide' <enea!irfu!heating!bt@uunet.uu.net>
Subject: Sun f77 -fswitch overhead. Comparison with HP9000/350
Reference: v6n172 v6n152
I ran the ratfor program on my HP9000/350 (where -fswitch is +bfpa) which
has the same hardware as the Sun3/260. As is clear from the results
below, the HP +bfpa also has a high overhead. But I was surprised to see
how much faster code the HP f77 produces -- almost twice as fast as Sun's!
Note that I am not using the new, faster (and cheaper, sic) HP FPA. (I
did'n run the test without the write statement since currently HP f77 only
has an assembly code optimizer.)
Comments?
-Bo
Bo Thide', Swedish Institute of Space Physics, S-755 91 Uppsala, Sweden
Phone: (+46) 18-403000. Telex: 76036 (IRFUPP S). Fax: (+46) 18-403100
INTERNET: bt@irfu.uu.se UUCP: ...enea!kuling!irfu!bt
define N 10000000
double precision data(2), add, sub, mul, div
integer i
data(2) = 1
do i=2,N {
data(1) = data(2)
data(2) = i
add = data(2) + data(1)
sub = data(2) - data(1)
mul = data(2) * data(1)
div = data(2) / data(1)
}
write(6,*) add, sub, mul, div
stop
end
========hardware configuration=========================================
node name short name equipment
---------------+---------------+------------------------------
watvlach vlach older 3/50 with new MC68881
vlsisun1 sun1 older 3/160 with old MC68881
vlsisun2 sun2 3/160 with new MC68881 and FPA
vlsisun3 sun3 3/260 with MC68881
node name short name equipment
---------------+---------------+---------------------------------
heating.irfu hp350 HP9000/350 with 68881 and old FPA
========test results with and without -O compile flag==================
cpu cpu times in minutes without using -O
name -fsoft -f68881 -ffpa -fswitch
-------+-------+-------+-------+--------
vlach 56.0 14.0 ---- 20.1
sun1 52.6 10.1 ---- 20.8
sun2 52.8 12.2 5.1 10.2
sun3 29.4 10.3 ---- 13.5
name +M (68881) +ffpa +bfpa
-------+-------+-------+-------+--------
hp350 15:28 9:23 3:57 5:25
cpu cpu times in minutes using -O
name -fsoft -f68881 -ffpa -fswitch
-------+-------+-------+-------+--------
vlach 56.7 14.2 ---- 21.3
sun1 53.3 15.4 ---- 22.3
sun2 53.4 12.5 2.0 10.8
sun3 29.8 10.4 ---- 14.0
name +M (68881) +ffpa +bfpa
-------+-------+-------+-------+--------
hp350 15:30 4:39 1:44 4:30
------------------------------
Date: Mon, 22 Aug 88 01:57:37 EDT
From: Rayan Zachariassen <rayan@ai.toronto.edu>
Subject: boot prom support for 3rd party peripherals vendors
[ quote from Chuck Hedrick: ]
> The main place openness is losing is in peripherals. It's clear that
> somebody has decided Sun needs to stop losing as much disk business to
> third parties. The normal Sun approach in such a situation is to come out
> with high-speed controllers and find other innovative solutions. However
> in this case, somebody has decided to make it difficult to put good disk
> controllers into the system, and to force people to keep buying Xylogics
> 451's. This is bad for both the customers and Sun, and is not consistent
> with the way Sun normally does business. I'm sure it will stop when
> appropriate people in Sun think about it.
No it won't. Sun is hiring ex-DEC people like crazy (and DEC is hiring
ex-IBM people, and MIPS is (trying to) hire ex-Sun people.... a regular
food chain). These people are taking their philosophy with them into high
positions within Sun. In particular, the two people in charge of disk
peripherals are ex-DEC employees; I met one of them during a trip to Sun
recently. The bottom line from that discussion was that Sun will not in
any way aid third-party peripherals vendors whose products compete with
Sun products *according to Sun's judgement*. I.e. company X produces a
high-performance SMD controller, but we (Sun) think our product is good
enough for our customers, so we do what we can to discourage that vendor.
In regard to Ciprico (and generally applicable), their concerns were:
- they consider installation of a 3rd-party vendor-supplied boot prom to be
modification of the Sun CPU and do not want anybody to do that to their
systems. The reason for this is that they consider too many of their
customers to be bozos so that if a disk problem or boot path problem
occurs with 3rd party disks they don't want Sun field support to waste
its time when the customer calls them instead of the 3rd party vendor.
- they consider the boot prom code to be part and parcel of SunOS, and the
vendor must buy rights to redistribute ALL OF SUNOS, in addition to a
source license, in order to be able to supply slightly modified proms.
Ciprico and Interphase apparently refused to pay the cost of this (no wonder).
Apparently SunOS licensing is so intimately tied to SysV licensing that
Sun can't change the licensing terms without AT&T's nod (even on code AT&T
has no claim over -- the boot support) (I'm not sure I believe this, but
that's what was said).
So far I'm quoting my understanding of their position from that meeting.
My opinion on this is that the support concern is a valid business matter,
and not cooperating with 3rd-party vendors for that reason is a legitimate
business decision (though not one I agree with of course). However, we
were two SysAdmins in that meeting who cried foul at the idea that the
boot prom is part of the Sun CPU hardware, that you need a SunOS
redistribution license to redistribute doctored proms, and that Sun didn't
even *think* of licensing boot prom code separately from SunOS. Even
though Suns dealings with respect to 3rd-party vendors has been
*extremely* irritating (and cost us almost 5000$US so far in unanticipated
expenses), I am more concerned (i.e. ticked off) at the *way* they went
about it and the lack of thinking they show, as well as their lack of
consideration for their customers. They are acting as if they know what
is best for us; well that is NOT their decision to make. This is one of
the reasons we have dropped DEC. When we heard early this year that Sun
was planning to do this, we didn't believe they would make such a bad
move.
They did say they realized their performance in the I/O subsystem area has
been lousy, and are working on products to improve it (i.e. so we won't
need to go to 3rd-parties to get optimally configured systems). We told
them that that wasn't the point of the issue. *We* want to make the
choice, not have it made for us.
Anyway, Sun has made its decision. We have decided the warm fuzzy feeling
we had wrt Sun a couple of years ago is thoroughly gone, and for the first
time in a long time are looking at competing systems where the corporate
attitude is more friendly than Suns.
I've said these things to Sun in meetings and in writing, I'm just posting
it here to give people at large a clearer perspective (Suns, and mine).
rayan
------------------------------
Date: Fri, 19 Aug 88 13:26:50 BST
From: Richard Evans <mcvax!topexp!rde@uunet.uu.net>
Subject: Need help with Gnu emacs on the Sun
We have a problem with GNU Emacs on Suns, and I'm completely stuck and
would welcome any hints on what to do next...
We have been using an earlier version of GNU Emacs (17.64) for some time
and recently got hold of the source distribution for version 18.49. The
new version works fine on our 3/50s and 3/60s but behaves strangely on our
3/280 time-sharing machine. The symptom is that whenever we use it on an
ALM-2 (sixteen-line multiplexor) line, it hangs up the terminal on exit.
You type C-x C-c, get the message about no files need saving and your
terminal then dies. This problem does not arise when using Emacs on one
of the CPU serial lines (ttyb). Looking at the process list shows that
the emacs process has terminated; if you try to log off by killing the csh
process, it gets stuck <exiting> for ever. Rebooting the machine (with or
without trying to kill the csh process) gives a warning that some
processes wouldn't die.
It looks as though one of the tty ioctls in Emacs could be having a nasty
side effect on the ALM-2. Unfortunately, I don't really know where to
start looking for the problem. Making a new version without the Sun
windows stuff does not cure the problem.
We are running OS 3.5 on a Sun 3/280 with 16MB and two ALM-2 boards. The
problem occurs on lines from both boards, so I do not think that it is a
hardware fault.
Richard Evans
Topexpress Ltd.
13/14 Round Chruch Street
Cambridge
CB5 8AD
UK
Phone: +44 223 355427
------------------------------
End of SUN-Spots Digest
***********************