Sun-Spots Digest, v6n253
William LeFebvre
Sun-Spots-Request at Rice.edu
Tue Oct 11 02:24:26 AEST 1988
SUN-SPOTS DIGEST Friday, 7 October 1988 Volume 6 : Issue 253
Today's Topics:
Re: Problems with VME address spaces
Re: information on TAAC board
Re: ALM-2 and hardware flow control
amazing dump speed with 4.0
Booting clients and the yellow pages (SunOS 3.x)
Response Summary: SunOS 4.0 Concatenation Bug
load average
text: table is full
need help with SunView win_set_input_device() function
Touch screens for 19 in SUN systems?
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, 4 Oct 88 14:37:38 PDT
From: stevo at jane.jpl.nasa.gov (Steve Groom)
Subject: Re: Problems with VME address spaces
People have been asking for comments about experiences writing device
drivers for Sun4's, and in particular, about the VME interface on Sun4's.
I have been working on a couple of Sun4 drivers for the past several
months. Despite what Sun may have told you, I can say that there are
definitely some "gotcha's" and a few bugs involved. These are not with
Sun's implementation of the VME bus, but the Sun4 CPU's interface to it.
Here are the relevant facts (at least those relevant to my situation), as
I understand them. BTW, we're talking about a 4/280 running Sys4-3.2
here.
1) Sun4's don't do automatic bus sizing like Sun3's and 2's do.
If you make references that are unaligned or incorrectly sized, the
CPU generates a trap. This means that you can't do 32-bit
operations on a 16-bit VME device. The Sun3 CPU allowed this,
because the CPU automatically broke up the 32-bit reference into
two 16-bit ones. So, if you have a 16-bit VME device in a Sun3,
you can make 32-bit references to it, and on a Sun4, you can't.
The biggest reference you can make is the biggest reference the
board can actually understand. This rule also applys to Sun4 VME
devices that are mmap'd into user processes. If you mmap a
16-bit-data VME device, you can't do 32-bit references or you'll
get bus errors.
2) SPARC has ldd and std instructions, which load and store 64 bits
respectively. SPARC defines a 64-bit external data bus, but the
Sun4 CPU only implements a 32-bit bus with some special hardware to
do the conversion (i.e. converts 64-bit references into two 32 bit
references in quick succession). However, this hardware is only
between the CPU and on-board memory. It does not exist for the
VME.
3) There is a bug in earlier rev's of the Sun4 CPU, which causes the
CPU to not generate size traps when the CPU generates a 64-bit
reference to a 32-bit device. This means that when a 64-bit
reference is made to a 32-bit device, the data gets trashed because
the hardware to handle it properly just doesn't exist. The CPU
should trap these accesses.
4) The kernel's bcopy() routine (as of Sys4-3.2) optimizes data movement
by using ldd and std instructions in certain cases. It does detect
16-bit VME data spaces, and handles transfers to/from those
properly (i.e. using 16-bit references), but it does not detect
32-bit VME accesses - it just does the ldd's and std's anyway.
My understanding is that for this to work correctly, (3) must first
be fixed, because the mechanism for detection depends on bad
references being trapped.
You may be able to see the scenario I'm weaving here. I have a VME memory
board that I wanted to put in vme16d32. When I did that, I had problems
because of (4), which tickled the bug in (3). So, I had to put the board
in vme16d16 to avoid that bug. But then, I had problems with mmap in user
land because of (1). The latter is the smaller problem for me, so that's
what we've got now. I'd sure love to get back to d32 though, and double
my memory bandwidth!
We do not have a hardware contract on the machine I'm working on, so Sun
has said that they won't upgrade my CPU to fix the problem, even though it
is a BUG in the DESIGN, not a hardware failure, for anything less than the
30-day exchange rate ($10,000!). What I understand is that the bug is
fixed in CPU rev 12 and later, though I haven't been able to verify that
(yet). (BTW, the CPU rev can be identified by looking at the back side of
the little plastic zebra tag on the CPU board - mine's written in pen, and
says "08 rev 50", meaning rev 8.) I have also heard that there is a fixed
kernel bcopy out there somewhere, I don't know if it's in 4.0 or not.
Well, that's my horror story. I hope it teaches someone something. I
must say, however, that this is the only problem I've found with the Sun
with respect to these drivers, and other than that.
I welcome any corrections or comments, please send mail.
-steve
stevo at elroy.jpl.nasa.gov
------------------------------
Date: Tue, 4 Oct 88 12:30:08 EDT
From: "Ian S. Small" <ian at dgp.toronto.edu>
Subject: Re: information on TAAC board
Greg Sorenson writes:
> First, the display is "video keyed"...so in effect, you lose part of
> the color spectrum -- negating some of the TAACs benefits, in my opinion.
If this is a desperate problem, don't use the standard TAAC setup - use an
external monitor for the TAAC's video signal, and view an entire 1Kx1K
region. (This may result in your seeing some crud, depending on how you
have configured your code.)
> Second, it does not multitask. This means only one process can use the
> TAAC at once...
'Tis true, but not (to us, at least) overly objectionable. Come to think
of it, I've never seen a bitslice-architecture frame buffer multi-task.
Has anyone else?
As far as the programming environment is concerned, it is (as Greg points
out) getting better all the time; work done by people and shown at
SIGGraph this year bodes well for standard I/O support, among other
things. As far as assembly-like programming, you don't need it if you're
content for medium level speed; if you want your application to really
rip, you will end up assembly coding the innermost loops. (It's amazing
what four lines of assembler can do for you...)
ian
------------------------------
Date: Tue, 4 Oct 88 21:05:35 EDT
From: whb%boole%att at research.att.com (Wilson H. Bent)
Subject: Re: ALM-2 and hardware flow control
Reference: v6n245
> Are you sure that your ALM-2 does hardware flow control. None of ALM or
> mcp manuals tells anything about flow control, and I NEED IT.
>
> Vesa
We though this was true, too, until Sun pointed us in the direction of "16
Channel Asynchronous Line Multiplexer-2 Field Service Manual and
Installation Notes" (catchy title), Part No: 813-1029-05 of Dec 7, 1987,
Table 6-2: ports 0 through 3 have RTS, CTS, TXC, and RXC, in addition to
TXD, RXD, DCD and DTR present on all 16 lines. Poorly documented, to be
sure, but the wires are there. We're still figuring out what subset of
devices connected to our ALM-2s can make use of these lines, not to
mention how.
Wilson H. Bent, Jr. ... att!hoh-2!whb (whb at hoh-2.ATT.COM)
AT&T - Bell Laboratories HOH L-274A
Holmdel, NJ 07733 (201) 888-7129
------------------------------
Date: Tue, 4 Oct 88 14:55:33 CDT
From: maeder at symcom.math.uiuc.edu (Roman E. Maeder)
Subject: amazing dump speed with 4.0
I just upgraded the rest of our sun network to 4.0. An amazing improvement
is with dump. First of all it now handles cartridges correctly, without
any cheating with tape length etc. So for a level zero dump on a 600"
cartridge you can say
dump 0ucsf 600 /dev/nrst8 ...
The second big improvement is speed. I do a remote dump from a 3/60 with a
CDC Wren IV disk onto a cartridge on a 3/280 server. It streams, no
stopping and backing up! I can do a 98MB backup (1.63 tapes) in less than
20 minutes. Well done, Sun!
We did not notice any speedup for doing local dumps on a 3/160 (with an
eagle on an old Xylogics) for 4.0 over 3.5. We now tried to do the dumps
of this 3/160 using the remote tape drive on the 3/280 as well and it did
stream again! So it is much faster to use a remote cartridge tape drive
than the local one. I haven't done any backups on the 3/280 itself. I will
let you know if it can handle the I/O bandwidth itself of if using a
remote cartridge is again faster.
Roman Maeder
Univ. of Illinois,
Department of Mathematics
and
Center for Supercomputing Research and Development
------------------------------
Date: Tue, 4 Oct 88 14:09:57 EDT
From: rang at cpsin3.cps.msu.edu (Anton Rang)
Subject: Booting clients and the yellow pages (SunOS 3.x)
This may be common knowledge, but here goes anyway! Have you ever had a
problem where you couldn't boot a client--it just stuck looking for its
Internet address? Maybe other clients worked, but not this one--at least
until you disabled the yellow pages on the server?
Well, here's the problem. The client Ethernet address is perhaps
something like this (in the /etc/ethers file, and in the YP map).
8:0:20:0:11:07 gx4 (as added by Setup).
If your client isn't booting, try adding the line
8:0:20:0:11:7 gx4
That's right, take off the leading zero. THESE ADDRESSES ARE DIFFERENT AS
FAR AS THE YELLOW PAGES ARE CONCERNED! The client (actually, the
reverse-Arp daemon) is looking for 8:0:20:0:11:7, and not finding it. I
don't know if this applies to other bytes as well (besides the last one),
but it might.
Anton Rang (rang at cpswh.cps.msu.edu)
Michigan State University
Disclaimer: It works for us, but might not work for you.
------------------------------
Date: Tue, 4 Oct 88 13:58 EDT
From: VERMETTE at sdr.slb.com
Subject: Response Summary: SunOS 4.0 Concatenation Bug
Folks...
Remember me? I'm the guy who posted what I thought was a SunOS 4.0 bug in
Fortran string handling. (See Sun-Spots v6, issue 237 for the complete
details) The bug had the basic form:
character*80 string
string = string(1:some_number) // 'stuff'
On SunOS 3.4 this produced expected results. Under SunOS 4.0 I was getting
arbitrary characters tacked onto the end of string after the concatenation
was completed.
Well...it turns out that this is NOT REALLY a BUG after all, but merely a
case of my getting trapped in the tar pit of f77 standards interpretation.
This was correctly pointed out by John Stewart <WAPJAS at CARLETON.BITNET> in
Sun-Spots v6, issue 243. In Fortran, if a and b are character strings, the
very in- tuitive expression a = a + b is simply wrong. In an EMail message
to me, Rob Kutschke <kutschke at oldkat.physics.utoronto.CA> was kind enough
to actually quote the ANSI standard...
'Here is a quote from Section 10.4, " Character Assignment Statement", on
p.10-2/3 of ANSI X3.9-1978:
The form of a character assignment statement is
v = e
where v is name of a char variable, char array element,
or char substring
e is a char expression
Execution ... causes evaluation of expression e and assignment and
definition of v with the value of e. NONE OF THE CHARACTER POSITIONS
BEING DEFINED IN v MAY BE REFERENCED IN e. v and e may have different
lengths...' [Emphasis by Kutschke].
Just to flog the deceased equine a little more, this re- striction is also
stated in Sun's Fortran Programmer's Guide dated Feb 17,1986, as the first
sentence on page 99: "The left and right sides of a character assignment
statement may not share storage."
However, some questions remain: While Sun states this restriction clearly
in the Fortran Programmer's Guide, (which they shipped us with SunOS 3.4)
my code example RUNS FINE under 3.4. Why did Sun decide to change their
interpretation of the For- tran standard between 3.4 and 4.0? Where else,
if anywhere, have they made other shifts in interpretation of the ANSI
standard?
Long windedly yours,
-- Mark Vermette
vermette at sdr.slb.com
------------------------------
Date: Tue, 4 Oct 88 14:05:36 EDT
From: doug at icase.edu (Doug Peterson)
Subject: load average
The command 'w' reports
1:57pm up 14 days, 5:28, 1 user, load average: 0.30, 0.07, 0.02
User tty login@ idle JCPU PCPU what
doug console 23Sep88 30:18 292:43 23:50 perfmeter -Wp 1012 760 -Ws 64 48
doug ttyp0 Mon 7am 30:17 18 18 -bin/csh
doug ttyp1 Mon 7am 53 3:39 2:38 w
doug ttyp2 Mon 7am 10 2:12 2:12 rlogin icase -l croot
doug ttyp3 Mon 7am 22:13 12 12 rlogin icase
The values given for load average represent the previous 1, 5, & 15 averages.
Does anyone know the algorithm which is used to derive these values?
System load is a combination of factors, not just cpu activity. I've seen
values anywhere from 0 to 70, and response at 70 is a lot worse than 7 or
0.7. I bet I'm not the only one who'd like to see a clear explanation.
Doug Peterson
Systems Manager
ICASE
Mail Stop 132C
NASA Langley Research Center
Hampton, VA 23665-5225
(804) 865-4090
FTS: 928-4090
------------------------------
Date: Tue, 4 Oct 88 15:19:47 EDT
From: tom at icase.edu (Tom Crockett)
Subject: text: table is full
We have recently installed X11R2 on our Sun 3/50 workstations here at
ICASE. We are currently running SunOS 3.5. Our X users are having
trouble with a message, evidently from SunOS, complaining about
text: table is full
This typically occurs during makes or compiles when there are a lot of
processes active at the same time. It causes processes to die before they
get started. Users generally have 2 or 3 xterms running, along with an
xclock or two, an xload, xbiff, and maybe one or two other clients. We
almost never have this problem when running suntools, even with heavier
workloads.
Have other people noticed this phenomenon? Is X really that much more
demanding than suntools? Does anyone know of a solution or workaround?
Tom Crockett
Institute for Computer Applications in Science and Engineering
M.S. 132C, NASA Langley Research Center
Hampton, VA 23665
e-mail: tom at icase.edu
phone: (804) 865-4097
------------------------------
Date: 4 Oct 88 17:07:33 GMT
From: harvard!ll-xn!adelie!munsell!delboeuf!syc at gatech.edu (Sy Chang)
Subject: need help with SunView win_set_input_device() function
Sun allows user to install Virtual User Input Devices (VUID) with SunView
by calling win_set_input_device(). However, I failed to install a terminal
as a VUID. The error message was - WIN ioctl number 80186732: Unknown
error. The terminal was attached to /dev/ttyb. My operating system was
version 3.4. If anyone can help to figure out why it failed, I would
appreciate. The following was my test program.
........
#include <suntool/sunview.h>
#include <suntool/canvas.h>
main ()
{
Frame base_frame;
Canvas canvas;
int inputfd; /* input device id */
int windowfd; /* window id */
inputfd = open ("/dev/ttyb", O_RDONLY);
..............
base_frame = window_create (NULL, FRAME, 0);
canvas = window_create (
base_frame,
CANVAS,
WIN_EVENT_PROC, input_event_proc,
WIN_CONSUME_PICK_EVENTS, WIN_IN_TRANSIT_EVENTS,
LOC_STILL, 0,
WIN_CONSUME_KBD_EVENTS, WIN_ASCII_EVENTS, 0,
CANVAS_RETAINED, TRUE,
0);
windowfd = (int) window_get (canvas, WIN_FD);
..............
/* failed here */
if (win_set_input_device (windowfd, inputfd, "/dev/ttyb") == -1) {
fprintf(stderr,"install failed\n");
close (inputfd);
exit(-3);
}
close (inputfd);
window_main_loop(base_frame);
exit(0);
}
static
int
input_event_proc (event)
register Event * event;
{
..........
}
------------------------------
Date: Tue, 4 Oct 88 11:51:03 PDT
From: nsche at atr-18.hac.com (Norm Scherer)
Subject: Touch screens for 19 in SUN systems?
Has anyone had any experience with any touch screens which will work on a
19" sun?
Norm Scherer
Software Engineering Division
Hughes Aircraft Co., Ground Systems Group,
Fullerton Ca.
(nsche%atr-2s at hac2arpa.hac.com or nsche at atr-2s.hac.com)
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list