Sun-Spots-Request@RICE.EDU (William LeFebvre) (08/31/88)
SUN-SPOTS DIGEST Tuesday, 30 August 1988 Volume 6 : Issue 209 Today's Topics: Administrivia Re: formatting unusual drives, sun 4, sunos 4.0 Re: /usr/5bin/m4 is broken under SunOS 4.0 Re: Problems with GNU emacs under SunOS4.0 More about alignment problems in device drivers for Sun 4 1) 4.0 dump eof "bug" & 2) 4.0 dump s flag bug in scanf uucp mailer vs. smartuucp mailer (4.0 sendmail) SunOS 4.0 work station routing problem Sunview RES converters? Library Database Software? Pascal 1.1 in the UK? SUN-2 SCSI disk summary 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, 30 Aug 88 23:19:53 CDT From: William LeFebvre <phil@Rice.edu> Subject: Administrivia The end is in sight! Barring any unforseen circumstances, I anticipate being all caught up by the end of the week, if not sooner. At that time I can go back to a more reasonable rate of 1 digest a day (maybe one or two extra a week as needed). So everyone please bear with me and this information explosion just a little while longer. I promise I won't let it get that far behind again (well, at least not for a few more months). Also, the archive server queue is currently very long because of all the requests for touchup. It might take a few days to fill some of the requests. Now, back to your digest.... William LeFebvre ------------------------------ Date: 29 Aug 88 18:11:36 GMT From: emory!arnold@gatech.edu (Arnold D. Robbins {EUCC}) Subject: Re: formatting unusual drives, sun 4, sunos 4.0 In v6n197 I wrote about the various problems I was having with some unusual disk drives. >A) How can I get the system to see the CDC drive? Since it is currently >the only drive on the controller, MUST it be drive 0? I got a '0' plug, and put a terminator on the drive, and the system sees it fine. However, format has problems with it still. It does an ioctl to get information from the drive, e.g. the number of sectors per track. The ioctl succeeds, but it returns a 0 for several of the values. Format then gives up since the returned value does not match what's in the file. I suspect that this drive just isn't up to doing the kinds of things we need like more modern drives are. However, if anyone can tell me different, I'd be interested in hearing. >B) Does any one have the BPS and BPT numbers for packs in a CDC 9766? Can >I get away with leaving those numbers out? I got the bytes/sector number from our Sun salesman. >C) The fmt_time and drive_type fields are only supplied for entries for >the Xylogics 450 controller. Why? Is it a problem leaving them out for >drives I intend to have on a Xylogics 753? These don't seem to be a problem so far. Another thing that has shown up is that format invariably tries to get the original defect list off both the Fuji 2344 and the CDC 9766, and fails, so it read the drive and builds its own list. I admit to being out of my leagure here; should it be able to find the list or is this normal? Thanks, -- Arnold Robbins ARPA, CSNET: arnold@emory.ARPA BITNET: arnold@emory UUCP: { decvax, gatech, }!emory!arnold DOMAIN: arnold@emory.edu (soon) ------------------------------ Date: Tue, 30 Aug 88 08:56:50 EDT From: flynn@pixel.cps.msu.edu (Patrick Flynn) Subject: Re: /usr/5bin/m4 is broken under SunOS 4.0 >PROBLEM... >SunOS 4.0 has a broken /usr/5bin/m4 that returns nothing but a newline in >response to the builtin macro "incr"... >FIX >Bring back the binary of /usr/5bin/m4 from the Sys4-3.2_rev2 tape. Or, if you have the source for System V m4: Compile the m4 source *without optimization*. Looks like Sun forgot to check and see if the optimizer broke the code. Pat Flynn, Dept. of Computer Science, Michigan State University flynn@cpsvax.cps.msu.edu flynn@{msudoc,eecae}.UUCP FLYNN@MSUEGR.BITNET ------------------------------ Date: Mon, 29 Aug 88 13:31:46 -0700 From: jns%meridian.com@ics.uci.edu Subject: Re: Problems with GNU emacs under SunOS4.0 I compiled Gnumacs 18.51 on our Sun 3 + SunOS 4.0 systems. It works beautifully, EXCEPT that every once in a while, just after it garbage collects, the next command (e.g. \C-H B to look at the bindings) produces an odd internal error message about a garbaged list pointer, prints something that is presumably the numeric value of the pointer, and does not perform the command. If the command is then repeated, everything is fine. It's disconcerting, but apparently not harmful. Has anyone else had a similar-but-disastrous experience? How thin is the ice when that happens? -jns ------------------------------ Date: Mon, 29 Aug 88 22:45:26 EDT From: hedrick@aramis.rutgers.edu (Charles Hedrick) Subject: More about alignment problems in device drivers for Sun 4 I just got a response from Sun about an issue I mentioned a week or so ago. We had problems with the Ciprico disk controller because rmalloc returned a block of memory that was not aligned on a 4-byte boundary. rmalloc itself has no code to align what it returns. So the only way one could make sure that pointers are aligned is if all the callers ask for blocks that are a multiple of 4 bytes. I noticed that the xt driver did not, and fixed it. That allowed us to get the Ciprico controller up. As it turns out, it was not a complete fix. We still crashed after a bit of operation. Sun now tells us that rmalloc makes no guarantees, and there is no convention for callers to ask for blocks that are a multiple of 4 bytes. If you need an aligned block, align it yourself. This means you have to have code like foo = rmalloc (size + 2); if (foo & 2 != 0) foo += 2; They didn't even guarantee that the address will be an even number, but there's Sun code that depends upon it, so presumably it actually will be. Now I don't really approve of this sort of malarky, and the guy at Sun implied that if they had been thinking more carefully they probably wouldn't either. I suspect that the Sun device drivers don't have any fields larger than 16 bits (they're mostly warmed-over Multi-bus drivers after all), and nobody thought about it until they had too much existing code to convert. But at least now you know the rules. Here's what we put at the beginning of the Ciprico device driver. I now believe it is more pessmistic than it needs to be. It makes no assumptions at all about what address we may get, but it tries to be friendly by always asking for a multiple of 4 bytes. But it does work, and should be a general solution. /****************************************************************\ * replace rmalloc and rmfree with versions that make sure * * everything is aligned and a multiple of 4 bytes. We've had * * problems both with calls in this code that are not a mult * * of 4 and other drivers that allocate stuff that isn't * \****************************************************************/ char * xrmalloc (addrspace, size) int *addrspace; int size; { char *retval; char *blockaddr; int align; int newsize; newsize = (size + 11) & 0xfffffffc; blockaddr = (char *)rmalloc(addrspace, newsize); retval = (char *)(((int)blockaddr + 7) & 0xfffffffc); *(retval - 1) = retval - blockaddr; *(retval - 2) = newsize - size; return (retval); } xrmfree (addrspace, size, ptr) int *addrspace; int size; char *ptr; { size = size + *(ptr - 2); ptr = ptr - *(ptr - 1); rmfree (addrspace, size, ptr); } #define rmalloc xrmalloc #define rmfree xrmfree ------------------------------ Date: Mon, 29 Aug 88 13:40:09 PDT From: Paul O'Neill <pvo3366@neptune.oce.orst.edu> Subject: 1) 4.0 dump eof "bug" & 2) 4.0 dump s flag Reference: v6n197 1) 4.0 dump eof "bug" > When specifying the no-rewind option in the dump script for the device > that you are writing to (ie., /dev/nrst8) the driver writes two eof > markers at the end of the dump. Dumping other files to the tape may occur > successfully however the problem occurs when trying to read back data from > the tape. 'mt fsf x' works on these multi-dump tapes. Just count each dump as 2 files. If a tape has 3 dumps already on it, do a 'mt fsf 6' from BOT before putting the 4th dump on it. Do a 'mt fsf 2' from BOT before restoring from the 2nd dump, a 'mt fsf 4' from BOT before restoring from the 3rd dump, etc. (do a 'setenv TAPE /dev/nrst8' to use mt syntax as shown) 2) 4.0 dump s flag >Evidently the s flag for dump has a different meaning in 4.0 than in 3.x. >The man page for dump now says the default is 425 (instead of 3825). >However, it neglects to mention what size to use for a 600 ft. tape. The ... assuming the c flag and /dev/nrst8--then 290 works as s's argument for a 300 ft tape and 590 works as s's argument for a 600 ft tape. Note that these are only necessary if the dump is going to use more than one tape (hit EOT). If you know that the dump is less than 1 tape and you are planning on putting multiple dumps on that tape, then specify the tape length exactly. Now you will know how much of the tape is used and how much is left for future dumps. Paul O'Neill pvo@oce.orst.edu Coastal Imaging Lab OSU--Oceanography Corvallis, OR 97331 503-754-3251 ------------------------------ Date: Mon, 29 Aug 88 17:35:18 -0100 From: Thomas Grossi <mcvax!capsogeti.fr!grossi@uunet.uu.net> Subject: bug in scanf The following call to scanf: scanf("%*[^\n]%*c"); does not consume the newline character when there are no intervening characters (i.e., the length of the first field = 0). However the newline *is* consumed by the following pair of calls, which should be semantically equivalent: scanf("%*[^\n]"); scanf("%*c"); We are running version 3.4 at the moment. The funny thing is that the single call in the first example used to work under version 3.2! We sent in a bug report to sun!bugs last December, but -- as is always our experience -- it seems to have fallen on deaf ears (not even an acknowledgement of the report). Thomas Grossi Cap Sogeti Innovation Grenoble, France grossi@capsogeti.fr ------------------------------ Date: 27 Aug 88 23:40:29 GMT From: oliveb!stpstn!aad@ames.arc.nasa.gov (Anthony A. Datri) Subject: uucp mailer vs. smartuucp mailer (4.0 sendmail) The SunOS 4.0 sendmail.main.cf file defines two mailers called uucp and smartuucp. It says that smartuucp uses uucp transport by domain-style naming. I can't find any other reference to the smartuucp mailer -- can someone tell me just what the difference is? I have little knowledge of the workings of the TECO-reminiscent sendmail.cf file, but I suspect that the difference is that smartuucp sends out the hostname with the domain on the end. How naive am I being? Anthony A. Datri,SysAdmin,StepstoneCorporation,stpstn!aad ------------------------------ Date: Mon, 29 Aug 88 15:43:29 -0500 From: abe@mace.cc.purdue.edu (Vic Abell) Subject: SunOS 4.0 work station routing problem I would appreciate hearing from anyone who has information about the cause and/or solution of the following routing bug in a 3/50 running SunOS 4.0. After the 3/50 (128.210.7.1) has booted from its server (128.210.7.1), and when rc.boot has just started to execute, the work station has an incorrect default route via 128.210.7.8. (The subnet mask for the 128.210.7 subnet is 0xffffff00.) Note that routed has not yet started -- none of the daemons and servers have been started, so the default is being established during or shortly after boot - e. g., by init. Now, 128.210.7.8 is an Ethernet on an HP system, also a server for HP diskless work stations. However, I can remove the HP server from the Ethernet and it still becomes the 3/50's default route during boot. Here's the strangest fact of all: the 128.210.7.1 server, a 3/280, has a host route to 128.210.9.1 via 128.210.7.8 in its routing tables. If I remove that route, the 3/50 will have a correct default route of 128.210.7.1 after it boots. A further indication that the trouble may originate in the 3/280 server is that it is impossible to use route(8) to set a network route to 128.210.9 (subnet mask 0xffffff00) via 128.210.7.8. Even with the use of "-n", route insists on installing a host route (netstat indicates UGH) to 128.210.9.0 via 128.210.7.8. Thus, it appears that subnetting is not working properly, or, at least, that 4.0 is not inferring a subnet mask of 0xffffff00 from the one for the interface to 128.210.7. What's happening? Where is the bogus default coming from? Is the 3/50 getting it from the 3/280's routing tables? How? Vic Abell Purdue University Computing Center ------------------------------ Date: 29 Aug 88 13:56:19 PDT (Monday) From: "Kumar_Swaminathan.LSBGEGPCAD"@xerox.com Subject: Sunview RES converters? Need info. about converters between Sunview raster file format and Xerox's RES (Raster encoding std.) --Thanx --sk ------------------------------ Date: 29 Aug 88 23:38:07 GMT From: van-bc!placer1!amos@beaver.cs.washington.edu (Kevin Amos) Subject: Library Database Software? I am looking for a library database package to run on a Sun-3. It would be used in Australia by 2 dedicated users and 1 dial-up user. Any suggestions would be appreciated. Thanks -- Kevin Amos Placer Dome Inc. Internet: amos@placer1.com uucp: ubc-vision!van-bc!placer1!amos ------------------------------ Date: Tue, 30 Aug 88 10:27:17 BST From: Mike Keeley <mjk%R7.CS.MAN.AC.UK@cunyvm.cuny.edu> Subject: Pascal 1.1 in the UK? Does anyone have Pascal 1.1 for a Sun-3 in this country? [[ "This country" is, presumably, the United Kingdom. --wnl ]] Even a Beta test version? If so, could you please e-mail me. The knowledge that a version exists would be extremely helpful. Thanks -- Mike Keeley (Manchester Univ.) mjk@uk.ac.man.cs ------------------------------ Date: Mon 29 Aug 88 19:55:49-PDT From: Bob Knight <KNIGHT@csli.stanford.edu> Subject: SUN-2 SCSI disk summary Sorry this is so brief, but I really stopped investigating this after I decided to keep SMD stuff for a while... Bob ____________________ --From: David.Maynard@K.GP.CS.CMU.EDU One good place to start might be the Sun-2 resellers. I've had good experiences with Steve at Adcomp (800)882-0007. I've never bought anything from the, but APEX (800)654-8222 will supposedly compete strongly with them. --From: croft (Bill Croft) Bob, I dont have any answers, but I do recall that there was a mailing list once started called something like 'suns-at-home', for folks with older or used Sun equipment in their homes. I'll bet other Sun-2 owners on limited budgets have done some research on this... [Does anyone know anything about this? --- RMK] [[ Its formation was announced in v6n5. I don't know if it is still active. It grew out of the "Suns at Home SIG held at last year's SUG conference. To join, mail a request to "suns-at-home-request@ea.ecn.purdue.edu". --wnl ]] --From: Jeff Woolsey <ames!ll-xn!ames!ucbcad!nsc.NSC.COM!woolsey> Well, only the new-in-the-box disk is mine; the other belongs to a friend who is out of the country for at least another week. We bought them on spec, having an (it turns out inadequate) intel SMD controller for the Multibus (20-bits. It was cheap.). Did I mention that these are 5 1/4" disks? Anyway, ask again in a week and we'll see what happens. [Jeff has two 100 MB SMD drives that he is (possibly) selling. --- RMK] ____________________ So, that's what I got from the net. I finally got the system. It has two Fuji 2322 80MB SMD disks, and the card cage is full (4 MB memory, associated peripherals.) Since my immediate need was a tape drive to replace the cratered Cipher, I got that. I am going to run SMD for a while. I've obtained some (CHEAP!) Fuji 2284s that I'm going to hopefully cobble into one working drive for the near term. However, here's what I found for pricing: Both Apex and Adcomp will sell you a SUN SCSI host adaptor for $550. Digital Solutions, Inc. (916)638-5606 will sell you a Emulex MD21 SCSI-ESDI controller for ~$300+. Can't remember the exact price. Computer Surplus Store (408)434-0168 has Adaptec SCSI-ESDI 4520s for $98+$8 for the manuals. They would also sell Micropolis 1355s in twos for $1000 each. Rich Morin is putting together something for his system. He promised to share the results when it happens. I'm going to be happy for awhile with what I have. I plan to do something early next year when some personal and industry dust clears. If anybody else embarks on this sort of project, I'd like to hear the war stories... Thanks, Bob ------------------------------ End of SUN-Spots Digest ***********************