Sun-Spots-Request@RICE.EDU (William LeFebvre) (08/29/88)
SUN-SPOTS DIGEST Sunday, 28 August 1988 Volume 6 : Issue 202
Today's Topics:
Re: Unix Domain sockets crash Sun OS 3.?
Re: flush on an icon
Re: mice for sun3
A Sony GDM monitor for your Sun-3
Multiple bitmap interchange formats
Bug in alloca ()
gethostbyname vs. yp in SunOS 4.0
booting discless => "if_snd full"
SunOS 4.0 uucico trouble
CDC 9773-1.3G on a Sun 3/280 or 4/280?
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: Wed, 24 Aug 88 09:47:27 MDT
From: pag@hao.ucar.edu (Peter Gross)
Subject: Re: Unix Domain sockets crash Sun OS 3.?
In v6n194 I wrote:
>I have two relatively simple programs (server and client) that test Unix
>Domain sockets, which will crash any Sun (3 or 4, haven't tried a 2)
>running Sun OS 3.2 or Sun OS 3.5. It appears that when an AF_UNIX socket
>is closed and unlinked when there is unread data in it, goodbye system!
>...
Had I only quaffed a dose of memory-restoring elixir, I would have
remembered fixing this bug in December, 1983! I checked back through bug
fixes in the Vax 4.2bsd sources, discovering in the file sys/uipc_socket.c
the following log entry:
RCS file: RCS/uipc_socket.c,v; Working file: uipc_socket.c
head: 6.3
locks: ; strict
access list:
symbolic names:
comment leader: " * "
total revisions: 2; selected revisions: 2
description:
4.2BSD uipc_socket.c
__________
revision 6.3
date: 83/12/01 10:38:07; author: root; state: Exp; lines added/del: 15/3
Bug fix: termination of a program which invoked a listen on a UNIX
domain socket would cause an infinite loop at net interrupt level.
>From: Mike Laman (sdcsvax!laman)
This was fixed in 1983, yet the bug still exists in SunOS 3.5. Didn't Sun
track the 4bsd bug fixes? I shudder to think of the number of bugs that
were reported (and fixed) in bugs.4bsd, but not picked up by Sun.
--peter gross
pag@hao.ucar.edu
------------------------------
Date: Wed, 24 Aug 88 17:16:10 +0200
From: mcvax!sor.inria.fr!vassili@uunet.uu.net
Subject: Re: flush on an icon
Reference: v6n177
In SunSpots v6n177, Danielle Heinzer asks how a user may be informed that
new output has arrived on an iconic (closed) `display window' (sic).
wnl was puzzled by that message, so am I. What is a `display window'?
Assuming that its a good old shelltool displaying output from a user
program, then there may be a solution:
Assume that the user program has the form
<process... process... process..>
<print output>
<process... process... process..>
<print output> and so on
What you can do is, change the user program to print <ESC>[1t whenever its
ready to print new output to the screen. This escape sequence opens the
window (its like clicking the icon).
So the program changes to:
<process... process... process..>
printf("\033[1t");
<print output>
<process... process... process..>
printf("\033[1t");
<print output> and so on
This make be a bit to abrupt for the user though. So you may only wish to
change the icon label, e.g.
<process... process... process..>
printf("\033]LREADY\033\\\n"); /* change icon label */
<print output>
printf("\033]LWorking\033\\\n"); /* restore label */
<process... process... process..>
printf("\033]LREADY\033\\\n"); /* change icon label */
<print output>
printf("\033]LWorking\033\\\n"); /* restore label */
and so on
Apart from that, I have seen a version of a/the terminal emulator for X
windows where the icon is a reduced image of the window (with one or two
pixels representing a character). Its very impressive when you see it
scroll.
Hope this helped.
Vassilis Prevelakis
vassili@sor.inria.fr
------------------------------
Date: Wed, 24 Aug 88 15:56:12 +0200
From: mcvax!sor.inria.fr!vassili@uunet.uu.net
Subject: Re: mice for sun3
In SunSpots V6 Number170 Laura Agapay (laa%janus.Berkeley.EDU) writes:
> Does anyone know who sells [sun3 mice] (other than Sun)?
Well, why don't you ask your sun3 mouse? :-) The manufacturer's name and
address appears on the label on the underside of the mouse (at least on
all the mice I've come across). In other words RTFMouse :-)
In case this is not so with your mouse, please accept my apologies;
the address is:
Mouse Systems, MSC Technologies Inc.
Santa Clara, CA 95051
USA
Vassilis Prevelakis
vassili@sor.inria.fr
------------------------------
Date: 24 Aug 88 09:20:00 MST
From: diegert@sandia-2.arpa
Subject: A Sony GDM monitor for your Sun-3
If you have seen both a Sony GDM monitor (as John Fowler did at Sun's
booth at the SIGGRAPH) and a Hitachi monitor (aka Sun's option 253), you
should agree with John's assessment: you want to order your new Sun with
the Sony.
There is good news and bad news on configuring a Sun-3 with the Sony GDM
monitor. Lets say you want 24 bits/pixel so you can see all those
magnificent Sony colors, and you want snappy, not boring displays when you
paint your scientific visualization with these colors. Sun's "TAAC-1
Application Accelerator" (option 221) is Sun's only option with the DAC's,
memory, and processor to meet your wants. The good news is that the TAAC
already ships (and has since beta) with a predefined configuration file (
/usr/taac/taac1/hardware/sonyGDMsync ) for driving a GDM monitor. The bad
news is that Sony does not sell GDM monitors to end users, even through
its professional video representatives. (If this is bs, please let me
know!) More good news, John reports that Sun is "in negotiation" with
Sony. More bad news, John reports that Sun's version of the GDM monitors
will be "modified in some way such that they are unique."
In your Sun-3/TAAC/GDM configuration, you will want a second monitor to
attach to a more usual Sun frame buffer for NeWS or SunTools. I use the
"high resolution monochrome monitor" (option 252) wired to the frame
buffer on the Sun-3 cpu board. When I need more desktop, I loop output
from a Sun CG3 through my TAAC to a "it was easy to order" Hitachi
monitor.
With a separate monitor for your desktop, you can take advantage of the
TAAC's flexible software control of its video output. For example, if you
get your hands on a GDM monitor, you can setup the TAAC with file
"sonyGDMsync", and watch your graphics (but not your desktop) on the GDM.
If you just want your show on a standard videotape, plug the TAAC outputs
into your VCR, setup the TAAC with file "ntscsync", and make your video.
(Actually the TAAC outputs are RGBS. You will need an external "encoder"
box to feed a VCR. The TAAC will generate its own sync, or will genlock
to an external NTSC sync.)
The README file in $TAAC1/hardware describes some types of video that Sun
(Transcept) has already programmed for the TAAC:
__________
This directory contains TAAC-1 hardware specific files:
taconfig - configuration data including keying ,parameters
spatial offsets, single or dual monitor setup
and sync formats for dual monitor operation.
sunsync - 1152 x 900 active, 66 Hz, non-interlaced sync file
(Sun standard video)
ntscsync - 648 x 486 active, 30 Hz, interlaced sync file
NTSC (RS-170)
hiressync - 1024 x 1024 active, 60 Hz, non-interlaced sync file
(useable with Sun monitors)
rs343sync - 1024 x 1024 active, 30 Hz, interlaced sync file
*sync - sync files created for specific monitors
The user is referred to the utility "tatool" for interactive modification
of the configuration file. Additional information is provided in the
installation manual.
-rw-r--r-- 1 42 794 May 5 17:12 README
-rw-r--r-- 1 42 331 May 17 18:20 hiressync
-rw-r--r-- 1 42 1222 May 5 17:02 ikegami_dm511h_sync
-rw-r--r-- 1 42 735 Mar 30 14:36 mit66600sync
-rw-r--r-- 1 42 1136 Mar 30 14:36 ntscsync
-rw-r--r-- 1 42 1129 May 5 17:02 rs343sync
-rw-r--r-- 1 42 736 Mar 30 14:36 sonyGDMsync
-rw-r--r-- 1 42 1147 Mar 30 14:36 sunsync
-rw-r--r-- 1 42 86 May 16 10:26 taconfig
__________
Carl Diegert
intvax!diegert@ariel.unm.edu
diegert@sandia-2.arpa
------------------------------
Date: Wed, 24 Aug 88 10:36:50 EDT
From: <montanaro@sprite.steinmetz.ge.com> (Skip Montanaro)
Subject: Multiple bitmap interchange formats
Jef Poskanser (jef@lbl-rtsg.arpa) wrote some nice bitmap interchange
utilities and made them available (somewhere at MIT I believe), along with
many megabytes of raster images. They work fine, if somewhat slowly.
Juergen Wagner (gandalf@csli.stanford.edu) recently released bmx,
apparently a similar package.
Rather than suffer (as a user) with what may turn into a proliferation of
bitmap conversion packages, I suggest that Jef, Juergen, and other
interested parties get together (electronically, of course) to stem this
tide.
Skip Montanaro (montanaro@sprite.steinmetz.ge.com, montanaro@ge-crd.arpa)
------------------------------
Date: Wed, 24 Aug 88 13:14:52 EDT
From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
Subject: Bug in alloca ()
I just ran into a bug in alloca (while working with the GNU C compiler).
The problem is that it can sometimes return an invalid address if the
proper address is 4 or 8 bytes after a 64K boundary. Also, it won't work
right if the size is right around 64K (between 65533 and 65535).
The reason for both of these bugs is that an addqw instruction is used
where an addql should be. To get a fix, just disassemble (using adb)
alloca; it is only eight instructions long. Just make up a new alloca.s
with the addqw's replaced by addql's.
------------------------------
Date: Wed, 24 Aug 88 13:18:14 CDT
From: natinst!brian@cs.utexas.edu (Brian H. Powell)
Subject: gethostbyname vs. yp in SunOS 4.0
My apologies if this has already been discussed...
Our sun 3/160 is a gateway between two networks. Network 1 consists of
several PCs and Macs (via an Appletalk<->ethernet gateway) where hosts
(i.e., small computers) are often down. Network 2 consists of several
Suns and PCs. The gateway is the ypserver for domain "a". There's also a
YPdomain "b" on network 2, but the gateway is not part of it.
We've aliased ftp to be "ftp `ipname`" where "ipname" is a program that
looks up the ut_host (hostname) field in the utmp file and prints it out.
That worked fine under SunOS 3.2 (without YP). In 4.0, when I'm one of
the non-gateway machines on network 1, ftp says "unknown host".
Ftp works successfully if you use the 4-byte ip number instead of the
hostname. So I tried to rewrite ipname (now ipnumber) to first look up
the hostname in utmp, then call gethostbyname. Gethostbyname returns NULL
when I do the look up. Gethostbyname works fine if I use different host
names, but certain hostnames (perhaps just the active ones not running any
YP?) don't work.
I ultimately rewrote ipnumber so that it loops through all the host
entries (with gethostent) until the hostnames match, then it returns the
IP number from that.
What have I done wrong? Am I misunderstanding YP? Any help would be
appreciated.
Brian H. Powell National Instruments Corp.
brian@natinst.uucp 12109 Technology Blvd.
cs.utexas.edu!natinst!brian Austin, Texas 78727-6204
AppleLink:D0351 (512) 250-9119 x832
or if that doesn't work, you can use brian@cs.utexas.edu.
------------------------------
Date: Wed, 24 Aug 88 17:34:55 +0200
From: Gunnar Lindberg <lindberg@cs.chalmers.se>
Subject: booting discless => "if_snd full"
After we upgraded our 3/50:s and 3/60:s to SunOS 3.4 we get a great number
of "le0: WARNING: if_snd full" printouts when we reboot any of them. I've
had the opportunity to watch the net with an analyzer and although the
booted client does not seem to suffer much, the net and all other hosts
sure does.
Booting a discless Sun client goes something like:
PROM: revARP (to find out who I am)
load TFTP-boot
TFTP-boot: revARP
load /vmunix (or similar)
/vmunix revARP
-> ICMP_MASKREQ (find out subnet mask)
...
Now, the "ICMP_MASKREQ" is sent out using IP broadcast, which means that
every host on the network has to handle it. On our network almost all of
them (120-130) "feel" a need to answer. Unfortunately none of these knows
the Ethernet address of the requestor, so they all have to use ARP to find
out... A number of "little endians" also have the doubtful habit of
returning the subnet mask in wrong byte order.
One reason for the upgrade was to get rid of ARP-storms when somebody used
an IP broadcast with host part set to all one:s; instead we now get it
when we reboot. This is better, no doubt, but far from perfect and we do
need to have it fixed.
We've reported this to Sun in Sweden and got an update to 3.4.2. It did
fix the mask byte order problem (which was minor to us) but did not fix
the "new ARP-storm" problem.
Since we don't have sources I can't suggest any real changes, but I guess
it should be possible to simply remember who sent the "revARP" reply and
ask that system again. If that fails, one could use broadcast as a last
resort.
Gunnar Lindberg
Department of Computer Science
Chalmers University of Technology
S-412 96 Gothenburg, SWEDEN
lindberg@cs.chalmers.se
------------------------------
Date: Wed, 24 Aug 88 11:12:51 CDT
From: natinst!brian@cs.utexas.edu (Brian H. Powell)
Subject: SunOS 4.0 uucico trouble
I installed SunOS 4.0 on our Sun 3/160 last week, and immediately had
troubles with uucico (and lots of other things, but that's besides the
point).
We had been using the modem connected to tty00 on our SysTech MTI board in
slots 11 and 12. It worked fine under SunOS 3.2.
Under 4.0, when receiving files, it would work fine at the beginning, but
at some point, we'd pause for a second or so before sending an ACK. (We
are using a 2400 baud modem.) Then it would work fine for a few seconds,
and then another pause. The pauses would get longer and longer until one
side or the other hung up.
It seemed to happen only when receiving, but since we receive more than we
send out, that may just be coincidence. I tried using the 3.2 uucico, but
that failed in the exact same way.
Finally, I moved the modem to ttyb on the CPU board. Things started
working fine when dialing out. Unfortunately, dialing in is broken.
Apparently, setting the flags field to zero for zs0 doesn't turn off
software carrier detect, or perhaps hardware carrier detect is broken.
Anyway, when I turn on the ttyd? port that I've assigned to ttyb, the cua?
port can't be used. (uucico returns NO DEVICE, tip returns "all ports
busy".) So we can't dial in; we can only dial out. Sigh.
The uucico problem, I feel, might have something to do with VME traffic
getting lost on the bus between slots 1 and 12. We've got 7 boards (a
XY451, a XY753, a XY472, a memory board, a second ether board, a SCSI
board (for rst8), and one of our own GPIB-1014-1S boards) between the CPU
and the MTI board. Just to make sure, I pulled our own board out of the
system, and the problem persists. Nine boards is a lot. Perhaps SunOS
4.0 can't handle it. This is just wildly guessing, of course.
Anybody have any suggestions on what to do about either uucico with the
MTI board or the bi-directionality of our modem on ttyb? Thanks in
advance.
Brian H. Powell National Instruments Corp.
brian@natinst.uucp 12109 Technology Blvd.
cs.utexas.edu!natinst!brian Austin, Texas 78727-6204
AppleLink:D0351 (512) 250-9119 x832
------------------------------
Date: Wed, 24 Aug 11:30:49 1988
From: eric@ulysses.homer.nj.att.com (Eric Lavitsky[hmm])
Subject: CDC 9773-1.3G on a Sun 3/280 or 4/280?
Has anyone successfully hooked up a CDC 9773 disk drive to a Sun 3/280 or
4/280? We're thinking of purchasing our server sans disk and getting an
XY753 and a CDC drive. It would be nice to know if we could boot off this
configuration. Can anyone think of a reason why we wouldn't be able to?
Thanks,
Eric
ARPA: eric@topaz.rutgers.edu or eric@ulysses.att.com
BIX: asdg
UUCP: {wherever!}ulysses!eric or {wherever!}rutgers!topaz!eric
SNAIL: 34 Maplehurst Ln, Piscataway, NJ 08854
------------------------------
End of SUN-Spots Digest
***********************