Sun-Spots-Request@Rice.edu (William LeFebvre) (10/10/88)
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@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, 4 Oct 88 14:37:38 PDT From: stevo@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@elroy.jpl.nasa.gov ------------------------------ Date: Tue, 4 Oct 88 12:30:08 EDT From: "Ian S. Small" <ian@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@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@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@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@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@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@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@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@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@sdr.slb.com ------------------------------ Date: Tue, 4 Oct 88 14:05:36 EDT From: doug@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@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@icase.edu phone: (804) 865-4097 ------------------------------ Date: 4 Oct 88 17:07:33 GMT From: harvard!ll-xn!adelie!munsell!delboeuf!syc@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@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@hac2arpa.hac.com or nsche@atr-2s.hac.com) ------------------------------ End of SUN-Spots Digest ***********************