Sun-Spots Digest, v6n52
William LeFebvre
Sun-Spots-Request at RICE.EDU
Wed Apr 13 14:49:24 AEST 1988
SUN-SPOTS DIGEST Tuesday, 12 April 1988 Volume 6 : Issue 52
Today's Topics:
Re: 256 Colormap problem and inherited colormaps
Re: Mysterious Ethernet problems
Re: Problems configuring cua0 on a 3/160 zs0
Re: simulation package info
bug with Sun FPA board
VME bus speeds
Exabyte EXB-8200 8mm Tape drive
A real problem with getfd
clearing display on 110C, 60C
proper devices for a 3/60C
Info on P-NUT and Nest - Address corection
Suntools on both color amd b/w planes?
SUN 3/60 crashing with network traffic
Menu items with varying heights under SunTools?
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: Fri, 1 Apr 88 22:43 EST
From: Andre Marquis <Bodick at cis.upenn.edu>
Subject: Re: 256 Colormap problem and inherited colormaps
The easiest way to have all the subwindows (panels, canvases, etc.) and
subframes in an application share the same colormap is the following:
base_frame = window_create(NULL, FRAME, 0);
pw_setcmsname(window_get(base_frame, WIN_PIXWIN), "colormap_name");
pw_setcolormap(window_get(base_frame, WIN_PIXWIN), 0, 256,
red, green, blue);
window_set(base_frame, FRAME_INHERIT_COLORS, TRUE, 0);
red, green, and blue are arrays of unsigned char [256] that are the
colormap you want. The SunView manual explains the parameters for the
function calls above (Which I may have incorrect since this is from
memory.). Any subframes or subwindows created with base_frame as their
base frame will "inherit" the colormap and you need not explicitly set the
colormap for those subwindows. This strategy could stand to be more
apparently documented especially since putting the FRAME_INHERIT_COLORS
attribute in the window_create call is ineffectual. It must appear after
the base frame is created and its colormap is set.
Andre Marquis
bodick at cis.upenn.edu
------------------------------
Date: Sun, 3 Apr 88 16:17:31 +0200
From: leonid at TAURUS.BITNET
Subject: Re: Mysterious Ethernet problems
Reference: v6n40
This is again concerning my previous posting about a problem when a Sun
server gets stock with "ie0 resetting" and stops all transmission.
In fact, there are two problems that cause this condition, one is a
software problem and the other is hardware.
The hardware problem was due to a bad transceiver that connected tho
ISOlan fun-out unit to the thick cable. This transceiver (Ilterlan
NT-100) while transmitting created an odd pulse after the end of the
packet. I have located this behaviour with an osciliscope, replaced this
transceiver and the problem gone away.
The software problem is in the "ie" device driver in SunOS 3.4, which
accordingly to our Sun rep is fixed in release 3.5.1 (!?). The problem is
with detecting the chip's various error conditions and resetting it.
Seems that the driver failed to reset the chip correctly and thus failed
to transmit any packets.
This problem accured to both our servers cause they both are connected to
the same fun-out unit and through it to the sme xceiver, and both run
3.4.2.
Leonid
------------------------------
Date: Mon, 4 Apr 88 19:34:21 -0400 (EDT)
From: John Gardiner Myers <jm36+ at andrew.cmu.edu>
Subject: Re: Problems configuring cua0 on a 3/160 zs0
In v6n43 Ron hitchens <vixen!ronbo at cs.utexas.edu> asserts:
> Yes, you've missed something completely. The cua0 mechanism is NOT a
> method of using one tty port for both dialin and dialout. It is simply a
> method of allowing a process to open a serial port, which has hardware
> carrier detect configured, when there is no carrier present. These are
> two entirely different things.
Incorrect. On a 3/150 which I used to administer, we were able to use the
cua0 mechanism to use one tty port for both dialin and dialout. The trick
is to get the modem to assert carrier detect if and only if there is an
incoming (or outgoing) call.
When /dev/cua0 is open, opens of /dev/ttyd0 will block. The modem must
not continuously assert carrier detect or the open of /dev/ttyp0 by getty
will not block and thus it will already be open when /dev/cua0 is opened.
RTFM, zs(4).
John G. Myers Internet: jm36+ at andrew.cmu.edu
LoseNet: ...!seismo!hao!wiscvm.wisc.edu!andrew!nobody
------------------------------
Date: Mon, 4 Apr 88 13:27:44 BST
From: Eric Ole Barber <mcvax!nw.stl.stc.co.uk!sizex at uunet.uu.net>
Subject: Re: simulation package info
1) QNAP2 from simulog, 3 avenue du Centre, 78182 St. Quentin en Yvelines,
France
2) Simula from Lund Software AB, Lilla Sodergatan 19, S-22353 LUND, Sweden
+ DEMOS from Graham Birtwistle at Calgary
Mixed analysis and simulation is possible with QNAP2 (and with PAWS I
believe).
------------------------------
Date: Sun, 3 Apr 88 16:03:43 PDT
From: mkp at iseesun.dpl.scg.hac.com (Michael Peterson)
Subject: bug with Sun FPA board
Here's a bug report and workaround from Nate Itkin
(ni at dcn1.dcn.scg.hac.com). We haven't seen this problem (no FPAs here
;-)), but it sounds like a nasty, pernicious one.
[There is a] bug in the Sun FPA board I thought you should know about
(perhaps you already do). First some background:
Over the last 4-5 weeks, DCN has been experiencing severe network problems
(to the point where clients wouldn't even boot off of the server). Too
make a long and painful story short, Sun replaced everything but the
kitchen sink without improving the situation. Then came the breakthrough.
After working with Sun software support for several weeks, they ran a
database check of all known bugs in the FPA. Low and behold it turns out
that some FPA instructions run longer than 4 cycles and subsequently place
a time out on the bus. This effectively prevents any nfsd or biod daemons
from servicing rpc calls and the network crumbles like a house of cards in
a tornado.
The fix is to change the switch settings at J0201 on the FPA board as
follows:
OLD NEW
----------------------------- -----------------------------
sw 1 2 3 4 5 6 7 8 sw 1 2 3 4 5 6 7 8
| | | | | | | | | | | | | | | |
off on off on off on on on on on off on off on on on
------------------------------- ------------------------------
This change raises the timeout limit from 4 to 5 cycles and miraculously
the network functions again. Sun claims that the offending instructions
are rare, but I countered with the fact that the most destructive code was
generated by their f77 compiler.
I wouldn't dive right in and change this unless you start having problems.
However, if and when you do, this is one you want to know about. The
symptoms are exactly like a failing transceiver or ethernet controller.
Hopefully, you wont have to spend money replacing these items like I did.
Nate Itkin ni at dcn1.dcn.scg.hac.com
...!scgvaxd.hac.com!dcn1!ni
Michael K. Peterson mkp at scgvaxd.hac.com
Space & Communications Group mkp%scgvaxd.hac.com at oberon.usc.edu
Hughes Aircraft Company
213 416-0323
------------------------------
Date: Mon, 4 Apr 88 10:52:34 EDT
From: Ned Danieley <ndd at sunbar.mc.duke.edu>
Subject: VME bus speeds
A couple of weeks ago, I posted a question about the speed of the Sun VME
bus when doing DVMA transfers from a DRV11-like card to memory. I received
several replies, the gist of which is that I should expect such transfers
to be somewhat slow, since they would have to have their addresses
translated through the MMU and contend with the CPU for memory access.
This is both good and bad news. The good news is that the performance we
are getting seems to be the expected performance; the bad news is that
we'll have to do something else to get the required speed for the next
generation of our d/a system.
Thanks for the help.
Ned Danieley (ndd at sunbar.mc.duke.edu)
Basic Arrhythmia Laboratory
Duke University Medical Center
Durham, NC 27710
(919) 684-6807 or 684-6942
------------------------------
Date: Mon, 4 Apr 88 14:40:07 MST
From: bull at noao.arizona.edu (Frank Bull CCS)
Subject: Exabyte EXB-8200 8mm Tape drive
We just got our first Exabyte EXB-8200 8mm tape drive today from Perfect
Byte Inc (in Omaha) and want to inform the Sun world that it does indeed
work as advertised. The long wait for Exabyte to "cure" the bugs in the
EXB-8200 was worth the wait. Installation was simple and quick. Tests with
both 'tar' and 'dump' went well. Using the recommended 'blocking factor'
of 1024 allowed incredible amounts of data to be written to tape. Also,
wrote multiple 'tar' and 'dump' files on the same tape and had no problems
reading them.
bull at noao.arizona.edu
Frank Bull
Central Computer Services
National Optical Astronomy Observatories
PO Box 26732
Tucson, Arizona 85726
(602) 325-9208
------------------------------
Date: Mon, 4 Apr 88 18:07 EST
From: Rob Kutschke <KUTSCHKE at UTORPHYS.BITNET>
Subject: A real problem with getfd
A question asked about getfd(3f) by <ida at eagle.warwick.ac.uk> in v6n43
reminded me of a problem which I encountered in getfd(3f).
First, the answer to the original question is that any fortran routine
which calls getfd requires the following declaration:
INTEGER GETFD
[[ Thanks also to esmond at msr.epm.ornl.gov and others who have pointed or
will point this out. --wnl ]]
My own problems began when I discovered that if I open a fortran unit,
other than 0,5 or 6, to a terminal, then the '$' format specifier no
longer works properly. Apparently, the other logical units are opened
line buffered, rather than unbuffered, without considering whether they
are disk files or terminals. One solution to the problem is to use
setbuf(3s), as in the example below.
This example illustrates that getfd does not always return the file
descriptor, sometimes it returns the file descriptor plus one!
1) getfd returns 0,1,2 for lu=5,6,0 ( stdin,stdout,stderr),
respectively. This is as expected.
2) I have never seen the value 3 returned.
3) If the value is >= 4, then the value must be decremented by 1 in
order for the call to setbuf to work!
Does anyone know why the decrement is needed; my own belief is that
getfd is incorrect. The error occurs on a SUN/3-280 running
SUN UNIX 4.2 Release 3.4.
Sincerely,
Rob Kutschke
University of Toronto bitnet: kutschke at utorphys
Department of Physics internet: kutschke at oldkat.toronto.edu
Toronto, Ont
M5S 1A7
/* Set buffering mode to "unbuffered" on fortran logical unit LU.
getfd(3f) is a fortran library routine
I have no idea why fd needs to be decremented if it is >=4.
*/
#include <stdio.h>
unbuf_(lu)
long int *lu;
{
long int fd, *getfd();
fd = getfd_(lu);
if ( fd >= 4 ) fd = fd - 1;
return( setbuf( (&_iob[fd]), NULL ));
}
------------------------------
Date: Mon, 4 Apr 88 11:10:02 EDT
From: Ned Danieley <ndd at sunbar.mc.duke.edu>
Subject: clearing display on 110C, 60C
A couple of weeks ago, I posted a question about how to clear the screen
of a 3/110C or 3/60C. We run stringart as a screensaver when the console
is not in use, but any messages that get written to the screen would not
be removed by stringart. I got a couple of replies that pointed out that
stringart is dealing with the color planes, whereas system messages write
to the monochrome plane. One can use switcher(1) with the -e option to
change from one to the other, and then clear the overlay. From inside a
program, one can use a fragment like:
group = pr_get_plane_group(bw);
pr_set_plane_group(bw, PIXPG_OVERLAY_ENABLE);
pr_rop(bw, 0, 0, bw->pr_size.x, bw->pr_size.y, PIX_CLR, NULL, 0, 0);
pr_set_plane_group(bw, group);
to clear the overlay.
Ned Danieley (ndd at sunbar.mc.duke.edu)
Basic Arrhythmia Laboratory
Duke University Medical Center
Durham, NC 27710
(919) 684-6807 or 684-6942
------------------------------
Date: Mon, 4 Apr 88 11:15:18 EDT
From: Ned Danieley <ndd at sunbar.mc.duke.edu>
Subject: proper devices for a 3/60C
(This is my day for thanking people.)
A couple of weeks ago I posted a question about the proper devices to use
with a 3/60C to access the color and mono frame buffers. It turns out that
a 3/60C uses cgfour0 for color and bwtwo1 for the overlay plane. In
contrast, the 3/110C uses cgfour0 and bwtwo0. Thanks for all the help.
Ned Danieley (ndd at sunbar.mc.duke.edu)
Basic Arrhythmia Laboratory
Duke University Medical Center
Durham, NC 27710
(919) 684-6807 or 684-6942
------------------------------
Date: MON APR 04, 1988 11.12.54 EST
From: "Nick Iliev" <NI00 at LEHIGH.BITNET>
Subject: Info on P-NUT and Nest - Address corection
In vol.6, issue 34 I gave an incorrect INTERNET address. If anyone out
there has something to say about network simulation with P-NUT (U.C.I.'s
Petri Net Utility Tools) and Nest 2.5 (Columbia's network simulation
package) please reply to
Nick Iliev <ni00 at lehigh.edu>
Lehigh University, CSEE Dept.
Packard Lab #19
Bethlehem, Pennsylvania 18015
(215) 694-8136
INTERNET : CE460XX at vax1.cc.lehigh.edu
------------------------------
Date: Tue, 29 Mar 88 11:32:20 EST
From: ames!srs!matt at sally.utexas.edu
Subject: Suntools on both color amd b/w planes
We just (yesterday) got our first color Sun and I've been given the task
of converting some of our tools to use its capabilities. In trying to
familiarize myself with the new hardware, I've been trying to get suntools
running on both the overlay (b/w) plane and on the 8 bit color planes at
the same time. The following procedure works fine:
log in to the workstation and run:
suntools -d /dev/cgfour0 -overlay_only -toggle_enable
now in a shelltool:
suntools -8bit_color_only -toggle_enable &
switcher -d /dev/cgfour &
use switcher to flip to the other desktop and run:
switcher &
The problem is that the way this procedure is documented in the Sun
manuals (both for suntools and switcher) doesn't work. It appears that
for some reason, the /dev/bwtwo0 device isn't mapping correctly to the b/w
overlay plane of /dev/cgfour0. The method given in the manuals is:
log in to the workstation and run:
suntools -d /dev/cgfour0 -8bit_color_only -toggle_enable
now in a shelltool:
suntools -d /dev/bwtwo0 -toggle_enable &
switcher -d /dev/bwtwo0 &
When I use switcher to flip to the b/w plane, it flips but there is no
desktop and no mouse/cursor. I am stuck until I can rlogin from another
machine and kill the suntools that is supposedly running on /dev/bwtwo0.
We have appropriately made both /dev/cgfour0 and /dev/bwtwo0 (major device
numbers 39 and 27 respectively). We are running Sun OS 3.2 except for the
kernel on the 3/60 which is based on 3.4. Anyone know what the problem is?
Matt Goheen
S.R. Systems
rochester!srs!matt
srs!matt at cs.rochester.edu
matt%srs.uucp at harvard.harvard.edu
------------------------------
Date: Fri, 1 Apr 88 19:32:15 CST
From: ihnp4!drutx!fidder at sally.utexas.edu
Subject: SUN 3/60 crashing with network traffic
I am new to the list so if this is an old rehash forgive me.
I have been working on a network (udp) application for remote file access
and remote execution, and am having problems with my SUN 3/60 crashing.
After some investigative work with ADB and the 4.3 sources, I was able to
determine that in a few of the crashes a corrupted cblock was at fault.
However, after patching that the system just crashed somewhere else.
Here are some of the specifics:
SUN 3/60 (diskless)
SunOS 3.4
The crashes seem to be related to running suntools (and lots of active
virtual memory). There is a pseudo driver needed, but when not running
suntools I can have several active connections running without problems.
If anyone can provide any helpful hints I would appreciated it. Thanks,
Ted Fidder
ihnp4!drutx!fidder
(303)538-5106
------------------------------
Date: Sun, 3 Apr 88 23:53:10 EDT
From: mike at ninja.cc.umich.edu (Michael Nowak)
Subject: Menu items with varying heights under SunTools?
As part of a research project, we need to implement menus which have items
of various heights. We are using SunTools. I tried to set the
MENU_MARGIN of each item when it is created but it doesn't seem to have
the right effect: each items is shifted on the left as expected but the
item heights are all the same. What I'd like are items which line up on
the left side of the menu but vary in height. My thought is to draw the
items manually in the code and set the image of the item. Is there an
easier way to do this?
In Real Life: Michael Nowak
Via Internet: mike at ronin.cc.umich.edu
Via UUCP: uunet!umix!ronin.cc.umich.edu!mike
Working for but in no way representing the University of Michigan.
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list