Sun-Spots Digest, v6n63
William LeFebvre
Sun-Spots-Request at RICE.EDU
Tue Apr 26 04:28:12 AEST 1988
SUN-SPOTS DIGEST Friday, 22 April 1988 Volume 6 : Issue 63
Today's Topics:
Re: Autoinitialization failure
Re: Adding 3rd SMD disk to Suns
slip for suns running 3.n
Symbolic Link Superceding Path Name
Request help with fstab entry for bg nfs mount
A Question about Shared memory
LaserJet+ support: 8 bit data?
NIT protocol on SUN questions ?
"rusers" RPC broadcasts on a SUN?
Problems attaching a printronix to a SUN 3?
SUN 4/280 SLIP to CISCO?
Article Index?
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: Sat, 16 Apr 88 00:16:42 PDT
From: hoptoad.UUCP!gnu at cgl.ucsf.edu (John Gilmore)
Subject: Re: Autoinitialization failure
If you declare "double sqrt();" your test case works fine. It's not a
compiler problem, just a misdeclared return type.
[[ Another "bug" bites the dust. How many times have we blamed our
programming mistakes on the compiler? Sigh. Thanks in advance to all the
others who will point out this bug as well. --wnl ]]
------------------------------
Date: Fri, 15 Apr 88 22:37:42 PDT
From: hoptoad.UUCP!gnu at cgl.ucsf.edu (John Gilmore)
Subject: Re: Adding 3rd SMD disk to Suns
This is no problem; while the "xy" driver used to limit you to 2 drives,
for no good reason, it was rewritten for SunOS 3.2 (or earlier?) and it
now supports 4 drives, same as the hardware.
The Sun packaging (for the 3/160 at least) only supports two drives due to
cabling restrictions. They have to build cables that withstand the FCC
regulations on spurious radio frequency emissions. On the other hand, you
the owner can reconfigure your system as desired, unless you actually
interfere with somebody (unlikely if it's your building). You can just
use standard SMD ribbon cables to daisy chain the 3rd disk to the first
two, and to hook a radial cable from one of the connectors on the Xylogics
board to the new drive. I fed the ribbon cable out one of the cutouts in
the backpanel of the Xylogics board, but you can just let it dangle out an
empty nearby slot, or come out between two slots.
If you are hanging a lot of disks on one controller, you will want to turn
on "overlapped seeks", which helps a bit. The older Xylogics controllers
cannot start a second seek or data transfer at any time if one is already
in progress, so it's not as fast as having two controllers, but the
measured speedup (not measured by me) is something like 15%. The catch is
that old Xylogics 450's have bugs when you try to use overlapped seeks;
you need to upgrade your Xylogics ROMs to the current level. If you're on
a Sun service contract, they should do it for free. If not, call
Xylogics.
Roy also asked whether it is worth getting a new controller if you need to
upgrade for some other reason. Two main reasons I can see for using a new
controller are: you'll be able to attach all the new, high transfer rate
disks like super duper Eagles and the NEC 1/2-wide disks; and the direct
VMEbus interface can move 32 bits in less time than the Multibus/VME
adapter could move 16. Also the new controllers tend to be better at
supporting overlapped seek, so that as soon as an I/O request comes in
from a user program, the kernel driver can start the disk seeking, without
waiting for an operation on a different disk to complete.
There was a whole ruckus (it seems like a year ago?!) between Interphase
and Xylogics for who would win the Sun contract for 32-bit VMEbus disk
controllers. Rumor is that Xylogics won it (also, Interphase is
advertising heavily to Sun users, and Xylogics isn't), but so far no
controller has been announced by Sun. I advise not upgrading your current
controller unless you really need to, until Sun figures out which one it
is really going to use.
John
------------------------------
Date: Thu, 14 Apr 88 11:13:54 EST
From: dsc at seismo.css.gov (David S. Comay)
Subject: slip for suns running 3.n
since i'm not sure if there is a slip distribution for the sun in the
sun-spots archive, i thought i would send you our latest one. it runs
fine on suns running version 3.n of the system as well with the latest tcp
software from berkeley & van jacobson.
dsc
[[ It has been placed in the archives as "sun-source/slip.shar" and is
38431 bytes in length. It can be retrieved via anonymous FTP from the
host "titan.rice.edu" or via the archive server with the request "send
sun-source slip.shar". For more information about the archive server,
send a mail message containing the word "help" to the address
"archive-server at rice.edu". --wnl ]]
------------------------------
Date: Sat, 16 Apr 88 10:28:47 EST
From: umix!lokkur!scs at rutgers.edu (Steve Simmons)
Subject: Symbolic Link Superceding Path Name
We're having an interesting little problem with symbolic links. We've
passed it up to Sun as a bug report, and they're still looking at it. In
the mean time I thought I'd see what the SunSpots people think of it:
We're developing a product that needs to be able to reliably predict the
location of a file across a wildly varying set of file system
configurations. The obvious solution was a symbolic link in a nice stable
place like /usr. We selected /usr/appl_dir ("usr application directory")
for the link name and set it up on a couple of our file servers to test.
The tests worked fine, but there's a side-effect that's driving us crazy.
On the server reliant, we set the link to point to /usr/reliant1. *SOME*
of the users whose home directories are in /usr/reliant1 now see their
path as /usr/appl_dir/user when using a client of reliant. Take user kcc
as an example. She has a client of reliant. If she logs in and does
'pwd', it returns '/usr/appl_dir/kcc'. [[ Now that is unexpected. Se
below. --wnl ]] If she does 'echo $cwd' it returns '/usr/reliant1/kcc'.
If she does 'echo ~', it returns '/usr/reliant1/kcc'. If *I* log into her
workstation, I get the same results. If user web logs into her
workstation, *he* gets '/usr/reliant1/kcc' consistantly. Using a bourne
shell gives exactly the same symptoms. Kcc and web have very similar
c-shell setups, but mine is wildly different.
Sound strange but annoying? That was my first impression, too. But
serious problems are starting to come out of it. Some debuggers put the
full path name of the source file into the .o file. So when kccs
co-worker kutnick wants to debug with kccs libraries, he can't do it
except from a client of reliant. [[ This is explainable. --wnl ]]
Any ideas? Everyone involved has 3/50s running 3.4.2.
Steve Simmons
Schlumberger CAD/CAM
scs at lokkur.uupc
[[ Csh expands ~ to be whatever is in the home directory field in the
user's entry in the passwd file (similarly for ~user). Symbolic links
won't affect it. The $cwd shell variable is updated by csh every time you
do a "cd". If the cd succeeds, cwd is updated *based on what you gave cd
as an argument*! In other words, this updating doesn't recognize when a
file is a symbolic link and the symbolic name will not get expanded.
/bin/pwd, on the other hand, obtains the path name to the current
directory by literally walking up the directory tree through the ".."
entries in the directories. Thus it should give you the *true* path name
with no symbolic links. And that's what has me confused about your
explanation above. If I understand what you have done, /usr/appl_dir is a
symbolic link to /usr/relaint1. So "ls -l /usr/appl_dir" should give you
something like "/usr/appl_dir -> /usr/reliant1". If this is true, then
pwd should give you reliant1 instead of appl_dir. The last problem is
explainable because debuggers determine the name of your current directory
the same way /bin/pwd does. It will never generate the name of a symbolic
link. --wnl ]]
------------------------------
Date: 15 Apr 88 00:47:30 CST (Fri)
From: uwvax!geowhiz!ben at rutgers.edu
Subject: Request help with fstab entry for bg nfs mount
Here at the Department of Geology & Geophysics, we have three Suns, two
3/280's and on 3/50. The server has two 474 MB Eagles, the client 3/280
has one eagle, and the 3/50 has a 141 MB Micropolis disk. We are running
3.4 SUN OS.
I have been playing with trying to get the server to mount the clients
file systems from fstab during the boot sequence. My local Sun software
support tells me just to place the mounts in the background, but that does
not seem to work. The client file systems are r/w and should be mounted
as hard mounts.
Here is an example of the kind of things I have tried, from the servers
fstab, snow is the name of the 3/280 client.
snow:/u2 /u2 rw bg,retry=10000,timeo=5,retrans=100,port=NFS_PORT,hard 1 0
Could someone give me the magic combination to put in my fstab file to
accomplish this.
Thanks in advance,
Ben Abernathy: Site and System Manager
Department of Geology & Geophysics UW - Madison
1215 West Dayton Street Madison, WI 53706
BELL: (608) 262 4912
ARPA: ben%geowhiz.uucp at spool.cs.wisc.edu
UUCP: {seismo, topaz, harvard, ihnp4}!uwvax!geowhiz!ben
BITNET: ben%geowhiz.uucp%spool.cs.wisc.edu at vms3.macc.wisc.edu
------------------------------
Date: Sat, 16 Apr 88 17:42:06 EDT
From: William Moran <moran-william at yale.arpa>
Subject: A Question about Shared memory
Is there any reason that the limit on shared memory is 512k in Sun OS 3.5?
My life would be made easier if this limit could be raised. Thanks.
Bill Moran
moran at cs.yale.edu
------------------------------
Date: Fri, 15 Apr 88 17:07:48 EDT
From: Peter Galvin <galvin-peter at yale.arpa>
Subject: LaserJet+ support: 8 bit data?
We have an HP laserjet+ hanging off of a Sun 3/280 which is managing to
output standard ascii text with much kludging. The problem is that it
seems to be refusing to output 8-bit data, such as TeX output converted by
the Beebe Laserjet+ driver. I'd be interested in talking to anyone who
has gotten a Laserjet+ to work in this way, since it seems like stealing
printcap files is easier than debugging laserjet behavior.
--Peter
------------------------------
Date: 15 Apr 88 13:52:11 GMT
From: "P. G. Cutting" <mcvax!newcastle.ac.uk!Peter_Cutting at uunet.uu.net>
Subject: NIT protocol on SUN questions ?
Im trying to write a simple ethernet monitor using the Network Interface
Tap (NIT) protocol on a SUN. The NIT documentation is sparse and
unhelpful.
My first question is DOES IT WORK ? (cos Im having major difficulties).
Im getting plenty of data appearing in the buffers. The documentation sais
this is made up of paired headers and raw packets.
As far as I can see the basic method should be as follows.
1) read buffer into a char array.
2) read in the first 20 bytes into a header structure as defined in
net/nit.h .
3) use the nh_datalen field of the header structure to read in the
trailing raw packet.
4) repeat 1) and 2) until empty.
5) read next buffer.
Seems straightforward, unfortunately nh_datalen is allways a series ie
(0,1,3,5,7...) or something similar. Why is nh_datalen in a union (it
doesnt make sence)? nh_wirelen is always garbage while nh_timestamp is
always correct.(?)
The documentation does not define a raw packet. Does it include
Source/dest addresses etc?
Does anyone know correct values for the nit_ioc structure, mainly
concerning the nioc_buf* fields.
Anyone got any example code?
Much appreciated.
JANET = Peter_Cutting at uk.ac.newcastle
ARPA = Peter_Cutting%newcastle.ac.uk at nss.cs.ucl.ac.uk
UUCP = ...!ukc!newcastle.ac.uk!Peter_Cutting
Peter Cutting,
Computing Laboratory,
The University of Newcastle,
Newcastle Upon Tyne,NE1 7RU,
ENGLAND.
------------------------------
Date: 15 Apr 88 15:35:36 GMT
From: murthy at arvak.cs.cornell.edu (Chet Murthy)
Subject: "rusers" RPC broadcasts on a SUN?
We here at Cornell have a lot of SUN-3's and several uVaxen, all running
NFS. The problem we have been having (I have been having) is that the
SUN-3's can run "rusers" to a specific machine, but "rusers" without
arguments, which, from the manual entry, is supposed to broadcast to all
machines, doesn't work on the suns, but DOES on the uvaxen.
That is, from arvak, a SUN, I can say "rusers loki", where loki is a sun,
and it works. From wayback, a uVax running 4.3+NFS, I can do the same.
>From arvak, saying "rusers" does nothing. from wayback, waying "rusers"
gets a long list of rusers output from a whole lot of machines on the
ethernet.
Anybody know what is going on here?
--chet--
In Real Life: Chet Murthy
ARPA: murthy at svax.cs.cornell.edu
SnailMail: Chet Murthy
North Woods Apts #20-2A
700 Warren Road
Ithaca, NY 14850
Office: 4162 Upson (607) 255-2219
MaBellNet: (607)-257-2542
------------------------------
Date: Sat, 16 Apr 88 11:30:14 PDT
From: Stuart Cracraft <cracraft at venera.isi.edu>
Subject: Problems attaching a printronix to a SUN 3?
We're getting repeated serial faults when attaching a printronix to a SUN
3. The printronix will occasionally be able to print small files such as
1K or 2K of ascii, but when we go up to 10K, we get the serial fault error
on the printronix error display.
The line between the sun 3 and printronix is a fresh null-modem line with
pins 2 and 3 swapped. Serial port b (/dev/ttyb) has been designated as the
printer port and shares the same major and minor device numbers as
/dev/lp0.
Files get correctly queued in /usr/spool/lp0, a lock file gets created,
but it just won't go beyond the 1K or 2K file-length before getting the
serial fault.
Any suggestions?
Stuart
P.S. Oh, by the way, the same printronix works perfectly on another
identically configured SUN 3.
[[ The Printronix printers we have want to do flow control with the modem
signals. I think the appropriate signals are RTS (pin 4) and CTS (pin 5).
When we forgot to pass those pins through, we had a problem identical to
the one you describe. If those signals are fully connected, it might be
the port on the Sun. --wnl ]]
------------------------------
Date: Fri, 15 Apr 88 08:01:07 PDT
From: bobw%chem.span at vlsi.jpl.nasa.gov (Bob Wood WA7MXZ, USU Chemistry)
Subject: SUN 4/280 SLIP to CISCO?
We need to tie our SUN 4/280 system into a CISCO terminal server. The
link between the SUN and the CISCO will be a 19200 baud RS-232 link. Does
anyone have any information on the CISCO box and if a SLIP link will work
between the SUN ALM-2 and the CISCO box?
Bob Wood BOBW at USU.BITNET
------------------------------
Date: Thu, 14 Apr 88 19:47:52 PDT
From: cvbnet!cvedc!exc!markh at sun.com (Mark A. Holm)
Subject: Article Index?
OK, I'll admit it. I lost the article that said where the article index
was and how to retreive it. Can you either send me direct or repost in a
digest, the instructions again. I have several immeadiate issues pending
that need to reference back issues. You post great information, I just
have a hard time back-referencing it.
Thanks,
Mark Holm ..tektronix!ogcvax!cvedc!exc!markh
Exceptions ..sun!cvbnet!cvedc!exc!markh
126 NE Grant Phone (503)648-8307
Hillsboro, Oregon 97124 Messages only until after 6:00 PM
[[ Well, shame on you. :-) There are "master indexes" for volumes 5 and 6
of the Sun-Spots digests. They are in the archives as "sun-spots/v5.index"
and "sun-spots/v6.index". Retrievable either by anonymous FTP or the
archive server (with a request like "send sun-spots v6.index"). --wnl ]]
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list