Sun-Spots-Request@RICE.EDU (William LeFebvre) (06/30/88)
SUN-SPOTS DIGEST Wednesday, 29 June 1988 Volume 6 : Issue 126
Today's Topics:
Re: 4.0 SOS questions
Re: HyperC*rd for the Suns
Re: Strange behaviour of pw_line() under SunView
Re: Problems with CDC EMD (368M) drives
Re: Amount of virtual memory
Re: subnet mask console message
more keyboard madness
prompt and sed in 4.0
SUNOS 4.0 experiences & impressions
max filesystem size under 4.0?
VLSI tools under Sun OS 4?
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: Sun, 19 Jun 88 23:10:11 PDT
From: JLarson.pa@xerox.com
Subject: Re: 4.0 SOS questions
> can't ftp into a 4.0 SOS machine unless I use the user name root
anonymous ftp works fine to my Sun OS 4.0 machine, after following the
setup instructions in the ftpd man page.
> I'm running ypserv with the old secret -i flag just
> like I do on our 3.n systems but have no joy.
4.0 versions of ypserv don't use the "-i" option. You have to build yp
host.by* maps using the "-b" option of makedbm. (See the makedbm man
page). You will probably also need a new version of ypserv from Sun which
fixes a critical bug with the "-b" option. mallen@sun.com should be able
to help you with this.
John Larson, Xerox PARC
------------------------------
Date: Mon, 20 Jun 88 09:24:06 EDT
From: Chuck Musciano <chuck@trantor.harris-atd.com>
Subject: Re: HyperC*rd for the Suns
A public domain version of this would be great, but please do not restrict
it to just the NeWS environment. With the unbundling of NeWS, and the
growing number of X users, it would have to be useable in X and SunWindows
to be really useful. I would only use a SunWindows version. Since we
have so much time already expended in SunWindows, it will be costly to
move to another window system any time soon.
Chuck Musciano
Advanced Technology Department
Harris Corporation
(407) 727-6131
ARPA: chuck@trantor.harris-atd.com
------------------------------
Date: Mon, 20 Jun 88 11:44:34 PDT
From: david@sun.com (David DiGiacomo)
Subject: Re: Strange behaviour of pw_line() under SunView
Reference: v6n116
>From: mcvax!swivax!anjo@uunet.uu.net (Anjo Anjewierden)
>
>The function pw_line() for drawing a variety of lines under SunView
>exhibits somewhat strange behaviour when used as in the following
>function:
>...
> { struct pr_brush p_brush;
> struct pr_texture p_texture;
The problem is right here. You are not initializing the pr_texture
struct. Either declare it as static or bzero it before use.
>I have not found any documentation on "struct pr_texture", any pointer to
>such documentation is greatly appreciated.
It's documented in the pixrect section of the 3.2, 3.3, 3.4, 3.5, and
Sys4-3.2 release manual. In 4.0 the pixrect manual was finally reprinted,
and the pr_line info is included there.
------------------------------
Date: Mon, 20 Jun 88 11:22:12 PDT
From: ames!polstra!jdp@sally.utexas.edu (John D. Polstra)
Subject: Re: Problems with CDC EMD (368M) drives
Reference: v6n112
It sounds very much as though you have multiple or missing terminators on
some of the SMD signals. I experienced very similar symptoms after I
added an Eagle drive to a controller that already had an M2322 on it. It
turned out that there were a couple of very non-obvious and poorly-
documented terminators inside the M2322, in addition to the "obvious"
ones. I've never looked inside an M2333, but my guess is that it has the
same problem.
You want to have all of the terminators in the drive that is at the end of
the daisy-chain (the farthest electrically from the controller). You must
remove all terminators from the other drives. I am assuming that your CDC
drive is at the end of the chain, so it should have all of its terminators
installed. You must remove all terminators from the M2333.
Now, on the M2322, there are four "obvious" and documented terminators.
These are the four DIP packages which are in sockets near the "A" cable
connector. (The "A" cable is the one with more wires.) They are the only
DIPs that are in sockets; the others are soldered in. Remove all four of
those.
The "hidden" terminators (on the M2322, at least) are on the BUSYH and
BUSYL signals. These are enabled / disabled by two jumper clips in the
corner of the PC board near the "B" cable connector (the narrow one).
Each jumper clip straddles two pins in a row of three. To disable these
two terminators, move each jumper clip to the other position.
I hope this takes care of the problem.
John Polstra (jdp@polstra.uucp)
John D. Polstra & Co., Inc.
(206) 932-6482
------------------------------
Date: Mon Jun 20 17:53:18 1988
From: portal!cup.portal.com!donp@sun.com
Subject: Re: Amount of virtual memory
I have only recently had occasion to get into the "nitty-gritty" of the
kernel and have a general question.
A bit of background: We are running a Sun 3/160 with Sun OS 3.4. Major
hardware includes a Super Eagle disk with a Xylogics 451 controller, and a
16-channel RS232 multiplexer.
The question: what determines the maximum amount of virtual memory
available for all processes on the system? Recently, "memory hog"
programs caused users to get "out of memory" messages when they tried to
run other, smaller programs. The "out of memory" seemed to occur when the
"vmstat" command gave an "avm" value of greater that 9000 or so.
Thinking some additional physical memory would help, I added 4 Meg. to
increase total system memory to 12 Meg. Well, we still get the "out of
memory messages" with avm > 9000.
Clearly, I don't understand all that's going on. Can anyone provide a
(reasonably brief) answer?
Thanks,
Don Parmentier
Email: donp@cup.portal.com.UUCP
[[ One of the constraints on process virtual memory that people tend to
forget is swap space. To get more swap space you need to either (1)
repartition your hard disk (a serious endeavor) or (2) get another disk
and do interleaved swapping. You can find out how much swap space is left
with "/etc/pstat -s". I don't know about other sites, but swap space is
the most serious constraint on our multi-user Sun 3/280 (it only has one
disk). --wnl ]]
------------------------------
Date: Mon, 20 Jun 88 19:40:43 PDT
From: Craig Leres <leres@helios.ee.lbl.gov>
Subject: Re: subnet mask console message
Phil Wherry writes:
> Every couple of days for a while now, a number of Suns on our Ethernet
> have been displaying the message "Setting subnet mask to 0xffff0000" in
> the console window. Nobody I've spoken to has any idea what is causing
This kernel printf indicates that your Suns are receiving icmp "mask
reply" messages. Normally, a mask reply message is only sent in response
to a "mask request" request. But in your case, it sure sounds like you
have a host or hosts on your ethernet that are broadcasting mask replies.
To find out which host is sending these icmp messages out, you might try
running tcpdump:
tcpdump -e proto icmp
If you don't have tcpdump, check out etherfind(8C) to see how to do the
equivalent with etherfind.
Starting with 3.X of SunOS (the first version that had subnet support),
the system broadcasts a icmp mask request on bootup in a feeble attempt to
learn the subnet mask. This is why you usually see the "Setting subnet
mask ..." message on bootup (right before the fsck).
Early versions would accept anything as a subnet mask; this means that a
single broken host can keep every diskless Sun on the net from booting.
(For example, an early release of 4.3 BSD send mask replies in the wrong
byte order; you can't talk to anybody if your netmask has the high order
bits turned off.)
At least by 3.5, the network code was changed to reject obviously bad
netmasks. Also, mask replies are ignored if a netmask has already been
set. But if you depend on this mechanism a single misconfigured host can
give you the wrong netmask when you boot. And if you pick up a bad
netmask, you'll propagate it to other Suns when they boot. For these
reasons, it's best to put an explicit "netmask 0xffffff00" (or whatever)
on the ifconfig lines in /etc/rc.boot.
People running 3.5 on an ethernet with a large number of Suns may notice
the message "nd: output error 55" on bootup. Although Sun doesn't
distribute the source to nd, it has been determined that the number in
this kind of message is an errno value. Error 55 is "No buffer space
available." Probably what happens here is that your when Sun broadcasts a
mask request it gets back too many replies too quickly and experiences a
temporary shortage of mbufs.
We build our kernels from source (3.5) and have commented out the netmask
request code. Sites without source could disable this feature by patching
the first instruction of icmp_sendmask() in ip_icmp.o to a rts.
Craig
------------------------------
Date: Sun, 19 Jun 88 01:47:12 EDT
From: Scott Schwartz <schwartz@cs.swarthmore.edu>
Subject: more keyboard madness
I've been following the discussin of console lockup, and thought I'd
contribute my $0.02.
About two years ago, on a 3/160 running 3.2 with a terminal on ttya for a
console, I noticed that whenever a certain user logged in, the console
would go catatonic. It was discovered that this person had a "setkeys
reset" in his login script. Apparently, if you have the console device in
your kernel, but are running with a tty as the actual console, thinks like
setkeys are fatal. Certainly one could simply remove the entries
/dev/kbd, /dev/mouse, and /dev/fb, as has been suggested in sun-spots.
For that matter, why build your kernel with those devices in the first
place if you are never going to attach a real sun console to the machine?
-- Scott Schwartz schwartz@cs.swarthmore.edu schwartz@cs.psu.edu
------------------------------
Date: Mon, 20 Jun 88 10:35:01 PDT
From: garlick@ucsco.UCSC.EDU@ucscc.ucsc.edu (Tim Garlick)
Subject: prompt and sed in 4.0
Bob,
I'm not sure why your sed script isn't working, (we haven't gone to SunOS
4.0 yet) but here is a one-liner that will set your prompt to what you
want, probably faster:
set prompt = "`hostname`(\!)% "
-Tim Garlick (garlick@ucsco.ucsc.edu)
------------------------------
Date: Mon, 20 Jun 88 14:57:25 CDT
From: clyde@emx.utexas.edu (Head UNIX Hacquer)
Subject: SUNOS 4.0 experiences & impressions
Having spent the last week or two bare knuckling SUN OS 4.0 on our
menagerie of SUNS (new 4/260 & 3/50s and old 2/50s), I have both some
kudos and brickbats.
1. POWER
We ordered our SUN-4 with a Eagle XMP drive, but was able to get one of
the new 900-MB drives instead. We were told that the rack would need a
110-volt 30 amp circuit, so we had one installed (actually an old 220-volt
circuit was rewired).
Lo and behold, what appeared was a rack which requires a 220-volt, 30 amp
circuit! It appears that new big disk drive eats A LOT of power on
spinup. So the local SUN office gave us bogus specifications, though
probably due to lack of information about the new drives and rack
configuration.
So our SUN-4 sat for a week and a half before the University electricians
showed up to re-rewire the circuit. SUN technical folks - when you change
the environmental specs, PLEASE LET LOCAL TECH SUPPORT FOLKS KNOW!! We
were not happy with having a SUN-4 paperweight around the office.
A couple more points about the rack: The fan used is EXTREMELY NOISY!!!
There is really no excuse for using one small, high-velocity noisemaker
where a larger, slower and quiter fan would do as well. Also, our SUN-4
is POWER PIG and generates a TREMENDOUS amount of heat. This rack is NOT
the sort of thing you want in your office (which is just where ours has to
be).
There are NO (none) 110-volt convience outlets on the power sequencer
panel. We will have to install power strip and run another power cord to
install our 110-volt powered auxillary devices (modems and such) in the
rack. This doesn't make any sense to me.
2. SUNINSTALL
Suninstall is an VERY GOOD program. I had to muddle through a session with
the old brain-dead-at-birth 'sunsetup' and hated it for a number of
reasons, mostly because it assumed it knew more than I did. ("Yes, I
really want to use a Class B IP number.")
This installation went as smoothly has any UNIX installation of any kind
I've ever done. (An ULTRIX installation I did was almost as easy and
complete). I don't miss the graphic interface at all. One serious
complaint I have is that suninstall could not be run from the installed
system, even in SINGLE-USER mode.
Unfortunately for us, in the middle of installing the SUN 2 support we had
a power failure. We had to figure out how to hand-roll this stage, since
suninstall kept complaining about being multiuser.
3. DISKLESS BOOTING
We could NOT get our diskless 2/50s to successfully boot. When our 3/50s
came, they would not boot either. Each would get RPC errors trying to
talk to bootparamd (which quickly became our least favorite SUNOS 4.0
program). Either the boot program would hang trying to find out what NFS
filesystem to mount to get /vmunix from, or the kernel load would succeed
and then would panic because of an RPC error, again trying to talk to
bootparamd.
Snooping around with etherfind on another SUN, we eventually saw that
there was a rogue MicroVax running VMS and something called MultiNet which
was answering the SUN RPC calls from our diskless clients. The RPC
messages from these systems were totally bogus, but their mere presence
was enough to break the boot program and the kernel when they were trying
to talk to the server's bootparamd. We were able to silence these
babblers and that problem went away.
But there was another problem. When we set up our system, we used FULLY
QUALIFIED host names for everything. Well, this led to NFS mount paths
such as 'sirius.cc.utexas.edu:/export/root/mizar.cc.utexas.edu', which
broke the boot programs' head VERY BADLY. Eventually in desperation we
de-qualified every host name we could find (/export/root/*,
/etc/bootparams, /etc/ethers, /etc/hosts) and the boot programs started
working. We have yet to sort out where we can use fully qualified names
and where we cannot.
On top of that, our 2/50s boot VERY VERY SLOWLY on a busy Ethernet. I
don't expect blinding speed from a poor 68010, but the sluggigh and
non-deterministic booting behavior of our 2/50s is not at all reassuring.
I am NOT IMPRESSED at the ruggedness of the SUNOS 4.0 boot system - I
think more beta testing should have been done on a large, heterogenous
Ethernet. The 'boot' program desperately needs to be made a LOT more
robust to survive out there on real networks where God only knows what
sort of machines are out there babbling at each other.
Well, enough for now - I will submit another snapshot of SUNOS 4.0
impressions at a future time (I'm trying to get X11R2 working right on my
new 3/50).
-Clyde Hoover
Compuation Center, The University of Texas at Austin
------------------------------
Date: Mon, 20 Jun 88 10:51:39 EDT
From: dms@wheaties.ai.mit.edu (David M. Siegel)
Subject: max filesystem size under 4.0?
Does anyone know if Sun fixed the bug in OS 3.X that limited filesystems
to be under 512 Mbytes? (The page table entry didn't have enough bits in
it to handle larger filesystems)
-Dave
------------------------------
Date: Mon, 20 Jun 88 17:06:56 EDT
From: Gary Dare <dare@eevlsi.ee.columbia.edu>
Subject: VLSI tools under Sun OS 4?
Has anyone had problems bringing up or running VLSI design tools on their
Sun stations running Sun OS 4? If so, could you please share your
problem(s) and solutions, if any?
Merci,
gld
Gary L. Dare
> dare@eevlsi.ee.columbia.EDU
> gld@cunixc.BITNET
------------------------------
End of SUN-Spots Digest
***********************