Sun-Spots Digest, v6n209
William LeFebvre
Sun-Spots-Request at RICE.EDU
Wed Aug 31 14:24:14 AEST 1988
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 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, 30 Aug 88 23:19:53 CDT
From: William LeFebvre <phil at 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 at 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 at emory.ARPA BITNET: arnold at emory
UUCP: { decvax, gatech, }!emory!arnold DOMAIN: arnold at emory.edu (soon)
------------------------------
Date: Tue, 30 Aug 88 08:56:50 EDT
From: flynn at 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 at cpsvax.cps.msu.edu flynn@{msudoc,eecae}.UUCP FLYNN at MSUEGR.BITNET
------------------------------
Date: Mon, 29 Aug 88 13:31:46 -0700
From: jns%meridian.com at 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 at 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 at 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 at 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 at 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 at capsogeti.fr
------------------------------
Date: 27 Aug 88 23:40:29 GMT
From: oliveb!stpstn!aad at 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 at 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 at 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 at 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 at 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 at uk.ac.man.cs
------------------------------
Date: Mon 29 Aug 88 19:55:49-PDT
From: Bob Knight <KNIGHT at 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 at 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 at 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
***********************
More information about the Comp.sys.sun
mailing list