Sun-Spots-Request@RICE.EDU (William LeFebvre) (08/22/88)
SUN-SPOTS DIGEST Friday, 19 August 1988 Volume 6 : Issue 192
Today's Topics:
Re: fsck making disks shudder: use "preen".
Re: Third party maintenance
Re: strange timing problem in /usr/ucb/Mail
Re: ALM2 problem confirmed
Re: multiple .ttyswrc
RAM, RAM, who's got the RAM
sunview is sloooooooow.
patch to pix2six.c
Extension cables on sun video
ncheck; bug in 3.5 cpio
bug in 4.0 broadcast addresses?
Problems with GNU emacs under SunOS4.0
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: Tue, 16 Aug 88 03:57:59 PDT
From: hoptoad.UUCP!gnu@cgl.ucsf.edu (John Gilmore)
Subject: Re: fsck making disks shudder: use "preen".
Two things here. First, I *have* seen disks that would move 1/4'' while
seeking. While working at Data General, we had disks that would walk six
inches across the floor and pull their cables out if you did some heavy
seeking for a few hours!
The other thing is, there is no good reason to be running "fsck -p".
Chris Torek wrote a program called "preen" that does the *right* thing,
which is to fire off an fsck on each disk arm, and when each one finishes,
fire off another one on that arm. It figures out the disk arms from the
disk partition names. The way Unix fsck does it, you wait for all the
fsck's in one "pass" to finish before the next set starts. Of course,
preen checks the root separately first, in case it needs to reboot after
fixing it, and returns the right exit codes to /etc/rc.boot -- so preen
can drop in right in place of the fsck -p there.
Chris posted it to net.sources in 1985; I'm surprised that Berkeley and
Sun never picked it up. Greg Noel fixed a bug soon thereafter, Jeff Mogul
wrote a man page, and I made some minor changes to make it work better
with NFS, and add debugging. Here's a shar file for the sun-spots
archives.
[[ It has been placed in the archives. However, since this is utility is
more general than just a Sun utility, it has ben placed in the "public"
directory. The shar file is called "preen.shar" and is 15376 bytes long.
It can be retrieved via anonymous FTP from the host "titan.rice.edu" or
via the archive server with the request "send public preen.shar". For
more information about the archive server, send a mail message containing
the word "help" to the address "archive-server@rice.edu". --wnl ]]
------------------------------
Date: Tue, 16 Aug 88 09:47:24 EDT
From: jjb@gaea.cs.wayne.edu (Jon J. Brewster)
Subject: Re: Third party maintenance
Yes, there's at least one such vendor:
Motorola Inc.,
Field Service Division
1701 Valley View Lane
Dallas TX 75234
(214) 888-2350
The usual disclaimers apply.
------------------------------
Date: Tue, 16 Aug 88 11:01:05 EDT
From: dae@shire.cs.psu.edu
Subject: Re: strange timing problem in /usr/ucb/Mail
Work-Phone: +1 814 865 9505
Home-Phone: +1 814 862 4811
> From: King Ables <ables@mcc.com>
>
> If the Cc: line has several addresses on it so that it wraps to
> a 2nd line AND if you hit ^D and <RETURN> (the <return> in
> response to the Cc: line prompt) VERY QUICKLY, there seems to
> be a timing problem where the 2nd line's worth of text (the
> part that was wrapped) isn't gathered up and processed so you
> wind up with a partial CC: line going out.
The way mail lets you edit things (like ~h and the Cc: prompt if you have
askcc set) is by printing the prompt and then using the TIOCSTI ioctl to
"type in" the contents of the line (one character at a time, sigh). Since
there's no way to lock your keyboard or anything, if you hit return before
it's done, you split the line. Without adding an ioctl that will
atomically type in more than one character at a time (I've always wondered
why that wasn't done in the first place), there's no fix (other than
adding a cbreak input-line editor to mail, which is an avoidance rather
than a fix).
[[ Another nice "feature" of this can be seen when one of the lines is
longer than the terminal input buffer (255 characters). After all the
TIOCSTIs fill the buffer, the terminal starts beeping at you. --wnl ]]
-king
ARPA: ables@mcc.com
UUCP: {gatech,nbires,seismo,ucb-vax}!cs.utexas.edu!pp!ables
------------------------------
Date: Tue, 16 Aug 88 11:05:16 PDT
From: limes@sun.com (Greg Limes)
Subject: Re: ALM2 problem confirmed
In comp.periph, Ken Mandelberg writes:
We are running SunOS 4.0 on a Sun 4/280. We are having a serious problem
with our ALM2. After a few hours from boot the ALM2 goes into what I call
"history" mode....
Harry Edmon writes:
I also have a Ciprico controller (3220) and an ALM2 running SunOS 3.5 on a
Sun 3/160 with the same problem. Does anyone have a clue as to the source
of this problem?
Actually, a simple problem with a simple solution. What has happend is
that there is some rather incorrect (read bad) coding in the input silo
handlers for the ALM-2. Incoming characters are ripped out of the board as
fast as possible and shoved into a ring buffer; in this particular
implementation, there is not only a fill pointer and a drain pointer, but
there is also a separate silo counter.
This "history" mode is an artifact of the silo counter getting out of sync
with the silo pointers.
The fix is to make the silo code tight; the current code can be tightened,
or the algorithm can be made better. I chose to go the second way, and the
silo counter is gone from my sources.
Periodicly, I cons up an install script, package it all up, and send the
bundle over to the Answer Center. They are then free to distribute this to
people having problems. The latest one I sent them had the string "(yapt
3.1)" included in the SCCS ID strings for several modules. I hope this is
the one that has been made available by the good people at
turing.cs.rpi.edu; so far, each version fixes a few more problems than the
previous.
Before y'all send me mail about your problems -- PLEASE PLEASE PLEASE call
the answer center. You have the number. Would you rather have me answering
thousands of letters detailing bugs that I am already aware of, or fixing
these bugs? If your problem is truely new and different, and not being
addressed by engineering, the front line phone people will get it to us.
More fixes are on the way. Honest, folks, we *do* listen ...
-- Greg Limes [limes@sun.com]
Ducking and Running Madly for Cover
Are disclaimers needed on this list, or are y'all adults?
------------------------------
Date: Tue, 16 Aug 88 19:00:31 EDT
From: "Doug Arnold" <dna@emmy.umd.edu>
Subject: Re: multiple .ttyswrc
Danielle Heinzer <ESC1298@ESOC.BITNET> writes
> I need to program different function keys for different
> windows running simultaneously. ... The .ttyswrc file has
> to be changed as soon as the mouse points a new window.
As far as I can see the .ttyswrc file is read when the window is opened,
not when a key is clicked. (I verified this by opening a window and
removing my .ttyswrc. The keys defined (by mapo) still worked. Then I
opened a new window and restored .ttyswrc. The new window ignored the key
definitions.) Thus your application should install the correct .ttyswrc,
open the window, and restore the default .ttyswrc.
Douglas N. Arnold
dna@emmy.umd.edu or na.arnold@score.stanford.edu
------------------------------
Date: 16 Aug 88 08:39:00 EDT
From: ridolfil@esdvax.arpa
Subject: RAM, RAM, who's got the RAM
This is just a note to help clear up the RAM supply question. I asked my
local SUN Rep "why can Helios deliver memory and you can't?" <I belive in
being clear> His reply (shortened 'cause you don't have all day) is as
follows:
a) There is a DRAM shortage. (Right)
b) Orders for SUNs are high. (Maybe)
c) The "Gov't" controls who gets the availible DRAMs (???)
d) All vendors get equal shares of the availible DRAMs
Conclusion: Sun has the same # of DRAMs as Helios. Since Sun moves more
volume, Helios delivers faster.
To the Big Vendor goes the backlog.
Larry Ridolfi
------------------------------
Date: 16 Aug 88 10:50 -0700
From: Steve Cumming <stevec%lccr.sfu.cdn@relay.ubc.ca>
Subject: sunview is sloooooooow.
Here's a fairly major irritant. About 6 months ago, I tested one of the
Control Data 300M SCSI disks on my Sun 3-50 running 3.2. My subjective
impression was that it speeded up window management considerably - not to
mention the win of having /usr localy available.
Imagine my dismay now that I am running 4.0. Window service is painfully
slow. Every time the mouse so much as crosses a window boundary, there is
a flurry of disk activity.
It seems to me that sunview is failing to cache something or other that it
should be.
Does any one have any comments or fixes? 4.0 has really degraded
performance in this respect.
Stece Cumming
School of Computing Science
Vancouver BC
stevec@lccr.sfu.cdn
uunet!ubc-cs!fornax!stevec
------------------------------
Date: Tue, 16 Aug 88 14:02:21 EDT
From: Vick Khera <khera@brillig.umd.edu>
Subject: patch to pix2six.c
Recently, I was using a filter program I got from SunSpots to convert Sun
raster file images into DEC Sixel format. The program works fine for full
screen images, but it chokes on smaller images, such as those from
dumpregion. I fixed the program to read those files correctly and
generate the proper Sixel files. The context diff follows.
Vick Khera <khera@brillig.umd.edu>
------< cut here >------
*** pix2six.c.orig Fri Aug 5 15:48:41 1988
--- pix2six.c Fri Aug 5 15:48:59 1988
***************
*** 25,30 ****
--- 25,32 ----
**
*/
+ static char rcs_id[] = "$Header: pix2six.c,v 1.2 88/08/05 15:36:35 khera Exp $";
+
#include <stdio.h>
#include <rasterfile.h>
***************
*** 45,51 ****
int argc;
char *argv[];
{
! int i, j, row, char_count;
char this_char, last_char;
/*
--- 47,53 ----
int argc;
char *argv[];
{
! register int i, j, row, char_count;
char this_char, last_char;
/*
***************
*** 101,108 ****
for (i=0; i<OUT_LINE_LEN; i++)
output_line[i] = '\0';
for (i=0; i<6; i++) {
! fread(scan_line, (hdr.ras_width>>3), 1, stdin);
! store_line(scan_line, (hdr.ras_width>>3), i);
}
/*
--- 103,111 ----
for (i=0; i<OUT_LINE_LEN; i++)
output_line[i] = '\0';
for (i=0; i<6; i++) {
! j = hdr.ras_length / hdr.ras_height;
! fread(scan_line, j, 1, stdin);
! store_line(scan_line, j, i);
}
/*
------< cut here >------
------------------------------
Date: Tue, 16 Aug 88 15:58:04 EDT
From: okunewck@gondor.cs.psu.edu (Phil OKunewick)
Subject: Extension cables on sun video
Judging from the articles I've seen, people seem to be having a wonderful
time using coaxial cable to extend their Sun monitors. The results have
been somewhere between "readable" and "good".
This has me somewhat perplexed. Looking at the pinouts for the video
connector, it appears to be a differential video signal with TTL dc sync
signals. (Would somebody care to confirm or deny the "differential video
signal"?)
If it is a differential signal, than coaxial cable is the WRONG stuff to
use. TWISTED PAIR will give better results (and is much cheaper). Coax
gets all the external noise on the outside conductor, thereby doing
terrible things to the difference between the two voltages (this produces
"snow".) In addition, the capacitance of coax will cause the "blurred" or
"smeared" effect people are talking about.
Similar symptoms can be obtained on the television in your living room -
just play mix-and-match between the paired and coax inputs. (There's also
a problem of impedance mismatch, but we won't discuss that today.)
EXPERIMENTAL RESULTS: We are running a monitor here on a 75 foot
twisted-pair cable (tested at 150 feet) with ABSOLUTELY NO smearing or
snow. We're using an incredibly cheap kind of wire (I happened to have it
lying around).
I think the ideal wire would be shielded pairs (belden 8777 or ethernet
drop cable comes to mind.) Run both video signals in one pair, run the
sync's seperately through two other pairs, and be sure to ground the
shield.
---Phil OKunewick
okunewck@psuvax1.bitnet
------------------------------
Date: Tue, 16 Aug 88 15:28:22 mdt
From: era@scdpyr.ucar.edu (Ed Arnold)
Subject: ncheck; bug in 3.5 cpio
Thanks to the many readers who responded to my question about whether
ncheck works on Sun systems. The answer is YES ... you just have to be
willing to wait a *long* time, esp. if your system is as heavily loaded as
ours.
The reason I asked the question in the first place, is an item that was
posted to comp.bugs.{bsd,sys5} about a bug in cpio. This bug exists in,
among other SVR3-based systems, one I'm running on: SunOS 3.5, and I've
personally seen it in action. The symptom is that cpio silently fails to
link files back together that were originally linked, when their inode
numbers are greater than 32767. So, BEWARE: if you use cpio to produce
distribution tapes, do system backup, etc., you may well end up with
something different than what you started with, when you read your tape
back in.
For further info about the bug, contact the original poster: Ian
Donaldson, rcodi@yabbie.rmit.oz.
Ed Arnold * NCAR (Nat'l Center for Atmospheric Research) * Mesa Lab
PO Box 3000 * Boulder, CO 80307-3000 * 303-497-1253
era@ncar.ucar.edu [128.117.64.4] * {ames,gatech,noao,...}!ncar!era
------------------------------
Date: Tue, 16 Aug 88 14:29:40 EDT
From: weltyc@fs3.cs.rpi.edu (Christopher A. Welty)
Subject: bug in 4.0 broadcast addresses?
We are using a sun4/280 SUNOS 4.0 and are having problems with, among MANY
other things, `ifconfig'ing an interfaces broadcast address. We use an
eight bit subnet field and our local broadcast address is all ones (255).
When I ifconfig the interface as follows:
ifconfig ie0 -trailers netmask 255.255.255.0 broadcast 128.213.5.255 up
it works fine for a few minutes and then routing goes away, that is, the
hosts can no longer reach other hosts outside it's local subnet. When I
check the interface, the broadcast address has changed to 128.213.5.0 - on
it's own! How is this happening? Anyone else seen this? My temporary -
and quite unsatisfactory - fix was a script that wakes up every four
minutes and ifconfigs the interface to the right broadcast address. Any
ideas? I have a call into sun software support but there has been no
response as yet.
Christopher Welty --- Asst. Director, RPI CS Labs
weltyc@cs.rpi.edu ...!rutgers!nysernic!weltyc
------------------------------
Date: 16 Aug 88 11:48 -0700
From: Steve Cumming <stevec%lccr.sfu.cdn@relay.ubc.ca>
Subject: Problems with GNU emacs under SunOS4.0
Wer'e in the process of moving our network from 3.4 to 4.0. I thought I'd
play with a really large and mysterious piece of code, to see what I'd
trip over.
So, I moved my Gnu emacs version 17 over to my test bed machine, and built
it. In the process of building, it links all the modules into a big
executable called temacs. This temacs is supposed to load up a version
number, some electric lisp stuff, and then (I think) dump out an
executable image of itself.
The porblem is that it core dumps with a segmentation fault when it tries
to load. dbx is no help, because I have made temacs shared, I gather from
the manual.
As you can tell, I'm over my head in this, and don't really know how to
proceed. But I need to do something quick, because I doubt this is the
only instance of the problem.
I expect similar difficulties in porting unisoft emacs, tex and other
things.
[[ We brought up TeX and friends under 4.0 using the web2c package. We
had no problems. --wnl ]]
Does anyone have any helpful suggestions?
Steve Cumming
School fo Computing Science
Vancouver BC
stevec@lccr.sfu.cdn
uunet!ubc-cs!fornax!stevec
------------------------------
End of SUN-Spots Digest
***********************