Sun-Spots-Request@RICE.EDU (William LeFebvre) (04/12/88)
SUN-SPOTS DIGEST Monday, 11 April 1988 Volume 6 : Issue 51
Today's Topics:
Re: Two Displays on a 3/60FC (2)
Re: Ethernet problems
Re: Mods for lengthy usernames?
on/rexd -- just say no!
further to Sun 4 ie1 interrupts
Need uucico trailblazer dialing info
fonts et al for high resolution monitors?
YA Icon
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: Fri, 1 Apr 88 00:46:10 EST
From: Henry BJ Krempel <krempel@pacrat.npac.syr.edu>
Subject: Re: Two Displays on a 3/60FC (1)
Reference: v6n39
I believe I've done this. All you have to do is, plug the monochrome
monitor into the monitor plug, and the color into the RGB. Then, make
sure that the /dev/cgone0 device exists.
Then follow the instructions in "man suntools" on "Multiple Displays" The
adjacentscreens command will enable you to track the mouse across the two
screens.
------------------------------
Date: Sat, 2 Apr 88 11:24:24 EST
From: perry@sambation.bellcore.com (Perry Metzger)
Subject: Re: Two Displays on a 3/60FC (2)
Reference: v6n39
This is in reply to the person who called up sun and asked about running
two monitors on his 3/60.
My Sun 3/60 is running with two monitors. I just plugged the monochrome
monitor into the mono port and let it go. As I understand it, there are
two display controllers in the color configuration; the monochrome AND the
color. You aren't using any of the bits off of the color controller to
run with two monitors.
So far, no problems.
Perry
------------------------------
Date: Fri, 01 Apr 88 08:42:36 EST
From: ted@braggvax.arpa
Subject: Re: Ethernet problems
Reference: v6n40
>From: Craig Leres <leres%lbl-helios@lbl-rtsg.arpa>
>......... Clearly, you shouldn't forward a packet if you only have one
>network interface. Nor should you forward a packet out the same interface
>it came in on.
Idealy no. However it can come in useful at times. Several times I have
run into the case where some suns on an ethernet could see certain suns on
the same cable, and not others. (I suspect it had to do with ies vs ecs
and marginal tranceivers). When this happens, and the systems in question
are hours away, or have to work right now, you can route to the sun you
can't see through one of the suns you can talk to. I would be
disappointed it this capability went away.
Ted Nolan
ted@braggvax.arpa
------------------------------
Date: Fri, 1 Apr 88 21:59:49 EST
From: Chris Torek <chris@mimsy.umd.edu>
Subject: Re: Mods for lengthy usernames?
Evan R. Moore asks:
>Does anyone out there know of a modification/hack/param setting/compile
>option/spell or suitable incantation to make Suns recognize more than 8
>characters [in login names]??
To which Our Moderator noted
>[[ Sadly, fixing "login" and "getty" won't entirely take care of the
>problem (yes, getty deals with usernames).
Indeed not. The way to change this is is to alter /usr/include/utmp.h,
which reads in part
/*
* Structure of utmp and wtmp files.
*
* Assuming the number 8 is unwise.
*/
struct utmp {
char ut_line[8]; /* tty name */
char ut_name[8]; /* user id */
If you make ut_name bigger, all your old login records must be converted
or discarded. This is not a serious problem; at worst such a conversion
program is a few hours' hacking. So one would change ut_name to, say, 12
or 16. You then must recompile the entire system source. Anything that
looks in <utmp.h>---and there is at least one C library routines that does
(`getlogin'), so that innocent-looking programs are not always
innocent---must be recompiled.
Once you have done this, you then spend the next few months or years
finding and fixing programs that were written unwisely. It is
inordinately odious to get at that `8' (12? 16?), because
>... It might help if there was a parameter defined in an include file
>to be the maximum length of a username (similar to MAXNAMLEN for files)
>but such a parameter has not traditionally existed in Unix systems. --wnl]]
[[ Oops: that should have been "...has traditionally not existed...". ]]
and indeed, there is no such parameter, at least in the versions of SunOS
with which I am familiar (up to 3.2). The following is an excerpt from a
local program that does not assume the number 8:
struct utmp _ugly; /* only way to get size of login names */
#define NAMELEN (sizeof _ugly.ut_name)
char UserName[NAMELEN]; /* login name of user uid */
which I think describes quite well the method for defining the constant.
(The variable `_ugly' is used nowhere else in the code.) (Yes, UserName
could be stored in _ugly.ut_name.)
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
[[ Something tells me you have had to deal with this in the past. --wnl ]]
------------------------------
Date: Thu, 31 Mar 88 21:44:26 MST
From: "Bill Mitchell" <sunquest!whm@arizona.edu>
Subject: on/rexd -- just say no!
Stuff like on/rexd really makes me wonder about Sun's software development
process. The idea of mounting filesystems in /tmp seems so ludicrous to
me that I can't believe that it ended up in a product. Even if "find"
doesn't get you, a harried superuser might "rm -rf /tmp/*" to solve a /tmp
fill-up on a Sun with a 70mb disk and have a 800mb filesystem in another
building disappear as a side effect. Why not use something like
/usr/spool/rexd for the rexd mounts instead? Mounting filesystems in /tmp
is like storing money in a garbage can!
Note that "find ... -fstype nfs -prune" doesn't completely solve the
problem: there was a bug in find (I think it's fixed in 3.4) that would
produce a null fstype if it encountered a stale filesystem while looking
through /etc/mtab. Since "" != "nfs", it would then descend into the NFS
filesystem.
And even if the concept of mounting filesystems in /tmp doesn't bother
you, rexd has a security hole that's as big as any in recent memory (if
you're on or can be reached from a network that you don't completely
control).
Bill Mitchell
sunquest!whm@arizona.edu
{allegra,cmcl2,ihnp4,noao}!arizona!sunquest!whm
[[ I agree with Mr. Mitchell. /tmp means TEMPORARY! The only file
systems you should be mounting in /tmp are ones whose entire contents are
expendable. Anything in the /tmp subtree (whether it is in a subdirectory
or not) should not be expected to last more than a few hours---a day at
the most. Mounting someone else's real NFS file system there clearly
violates this thinking. The same is true of /usr/tmp. --wnl ]]
------------------------------
Date: Thu, 31 Mar 88 15:38 EST
From: SYSRUTH@UTORPHYS.BITNET
Subject: further to Sun 4 ie1 interrupts
After my last posting about Sun 4/ie1 problems, I have heard from several
other people who have configurations very similar to ours (diskless
clients on ie0, backbone connection through ie1). Without exception they
are all experiencing the same problem: "spurious interrupt" messages on
ie1. So the problem is a generic one.
I have also had further information from the local Sun office about why
this might be occurring. There are two reasons, either or both of which
might be the cause.
First of all, the Sun 4 drives the bus differently than the Sun 3's, which
might result in some timing differences that could cause problems.
A more likely possibility (which also affects the Sun 3/200 series, and I
did hear from one 3/280 owner with the same problem) is due to the way in
which the Intel chip set handles interrupts. It is a fairly complicated
scenario but I will try to explain it as clearly as possible :-). When the
interface receives a packet, it sends an interrupt to the CPU for
servicing. If the CPU is busy at the time, the ie will hold the
packet/interrupt status. During this time, though, if the interface
receives another packet, it will clear the first interrupt. At this point
it is possible for the CPU to attempt to service the first interrupt, only
to find it has been cleared. It will then generate the "spurious
interrupt" message.
Usually this is only a problem with ie1 because (as our service person put
it) "it doesn't have the luxury of being on-board" like ie0, and thus has
to go through the bus.
This is most probably the cause of our problem. We usually have 1 or 2
back- ground jobs running on our Sun 4, of the CPU-intensive kind which
could quite literally run forever (just keep computing until the machine
crashes or shuts down). So the CPU is always "busy". And we generally only
see the message when the backbone Ethernet is producing more traffic than
usual destined for the Sun 4, which could easily result in extra packets
arriving before the first interrupt has been serviced.
At any rate, unless they redesign the ethernet chips to behave
differently, or the CPU/kernel to treat cleared interrupts differently,
the problem will not go away.
As far as the crashes we experienced are concerned, I can only hazard a
guess that perhaps the load was so heavy that ie1 was actually losing
packets (it is not as fast as ie0 thanks to the Multibus adapter and
having to use the bus) due to buffer overflow, and this was then causing
errors in the programs (rrestore, rlogin, rsh) which were waiting for
them. The message we got was generally "Bad Trap", which seems to fit the
bill.
I hope this helps other people who may be buying Sun 4's. As long as you
put diskless clients on ie0 (which is practically required and is really
just common sense anyway) you should not have any problems using it as an
nd server (unless it arrives post-4.0, and then it will all be different
anyway :-) ).
Ruth Milner
Systems Manager
University of Toronto Physics
------------------------------
Date: Thu, 31 Mar 88 17:40:22 PST
From: tekbspa!tss!joe@uunet.uu.net (Joe Angelo)
Subject: Need uucico trailblazer dialing info
Okay, I know answer to this is in a SUN-SPOTS digest, someplace...
We are running SUNOS 3.4 (and plan on keeping it that way) and are ready
to connect our trailblazers up (we'll be running 3.0 trailblazers with the
3.1 upgrade here and 4.0(?) trailblazers in boston).
I've already patched UUCICO to recognize the string "19200" (instead of
"4800") as a proper baud rate; however ACUHAYES[9600] and ACUHAYES[19200]
don't really work as the ACUHAYES dialer doesn't quit understand the
equivent return code for "CONNECT FAST", thus the CALL FAILS.
What I could use from someone is:
- A patch to the UUCICO dialer routers for ACU type HAYES,
since UUCICO is stringless, I can't easliy play with it.
(sure, I can use adb to search, but I'm not to sure where...)
I'd be more then willing to sacrafize ACUHAYES[300] for
ACUHAYES[9600].
-OR-
- A NICE L.sys entry that contains all of the needed AT commands
for proper setup. If you provide this, keep in mind that this
modem will be shared amoung users, so it's state can't be
garunteed and please don't say "Just do this" as the SUN
manuals do... I need details! If you provide this information,
also, if you can and have time, try to indicate:
- The internal PROM settings (AT&V output)
- If the modem is on a CPU port and cable config.
- If the modem is on an ALM/mti port and if the
ALM/mti port is setup for h/w or s/w DTR
(via the mti flags field in the kernel
config file...) as well as any cabling specs.
Playing with modems and printers is *always* alot of fun, my method is to
just go threw all the permutations until everything works with everything.
But, between managing 8 3/280s and 140 3/60s and 4 3/160s and 5 3/50s and
.... I have little time to play with things and absolutely must seek
HELP!!
Ps: Now you know where all the 3/60s went....
Pps: Anyone have any 3/60 memory? ... WANNA BUY SOME?
... I do.
Ppps: I would like to thank SUN for the wonderful help Teknekron & I have
received over the past year --> Your marvelous, SUN, simply marvelous.
Pppps: SUN: Please ask me to write the next SUNOS upgrade script....
Joe Angelo -- Senior Systems Engineer/Systems Manager
at Teknekron Software Systems, Palo Alto 415-325-1025
uunet!tekbspa!joe -OR- tekbspa!joe@uunet.uu.net
------------------------------
Date: Fri, 1 Apr 88 14:26:43 PST
From: schooler@venera.isi.edu (Eve Schooler)
Subject: fonts et al for high resolution monitors?
I recently switched from using a standard Sun monitor to Sun's high
resolution monitor. Because of the resolution, fonts, icons, cursors, and
windows appear 3/4 as big. The default font size of 14 is amusingly (!)
small and is not suitable for extended use by someone who works in front
of the computer most of the day.
After looking in /usr/lib/fonts/fixedwidthfonts for something more
appropriate, I found that there were very few larger size fonts availabe
(at least on our network which is running release 3.4). Any font size 18
or larger seems to look ok, yet only Courier style fonts exist in point
sizes 18 and 24, and Gallant style in point size 19. Sigh.
I wonder if there are additional fonts out there that someone might know
about? And new icons, cursors, system software, and/or tools that make
the upgrade to a high resolution monitor less painful?
Thanks.
Eve Schooler
schooler@venera.isi.edu
------------------------------
Date: Wed, 30 Mar 88 17:48:15 EST
From: rsalz@pineapple.bbn.com
Subject: YA Icon
We use this icon to keep younger children away from "SU" windows....
/* Format_version=1, Width=64, Height=64, Depth=1, Valid_bits_per_item=16
*/
0xFFFF,0xFFFF,0xFFFF,0xFFFF,0x8000,0x0000,0x0000,0x0001,
0x8000,0x000F,0xF800,0x0001,0x8000,0x00F0,0x0780,0x0001,
0x8000,0x0300,0x0060,0x0001,0x8000,0x0C00,0x0018,0x0001,
0x8000,0x3000,0x0006,0x0001,0x8000,0x4000,0x0001,0x0001,
0x8000,0x8000,0x0000,0x8001,0x8001,0x0000,0x0000,0x4001,
0x8002,0x0000,0x0000,0x2001,0x8004,0x0300,0x0060,0x1001,
0x8008,0x03E0,0x03E0,0x0801,0x8010,0x00F8,0x0F80,0x0401,
0x8010,0x0018,0x0C00,0x0401,0x8020,0x0000,0x0000,0x0201,
0x8020,0x0060,0x0300,0x0201,0x8040,0x0198,0x0CC0,0x0101,
0x8040,0x0200,0x0020,0x0101,0x8080,0x0000,0x0000,0x0081,
0x8080,0x0000,0x0000,0x0081,0x8080,0x0000,0x0000,0x0081,
0x8080,0x0000,0x0000,0x0081,0x8100,0x0000,0x0000,0x0041,
0x8100,0x0000,0x0000,0x0041,0x8100,0x0000,0x0000,0x0041,
0x8100,0x0000,0x0000,0x0041,0x8100,0x0000,0x0000,0x0041,
0x8100,0x0000,0x0000,0x0041,0x8100,0x0000,0x0000,0x0041,
0x8100,0x0007,0xF000,0x0041,0x8100,0x007F,0xFF00,0x0041,
0x8080,0x01F8,0x8FC0,0x0081,0x8080,0x07F0,0x87F0,0x0081,
0x8080,0x0FF0,0x87F8,0x0081,0x8080,0x0FF0,0x87F8,0x0081,
0x8040,0x1FF0,0x85FC,0x0101,0x8040,0x1E10,0x843E,0x0101,
0x8020,0x3810,0x040E,0x0201,0x8020,0x2008,0x0803,0x0201,
0x8010,0x4008,0x0801,0x0401,0x8010,0x0008,0x0800,0x0401,
0x8008,0x0006,0x3000,0x0801,0x8004,0x0001,0xC000,0x1001,
0x8002,0x0000,0x0000,0x2001,0x8001,0x0000,0x0000,0x4001,
0x8000,0x8000,0x0000,0x8001,0x8000,0x4000,0x0001,0x0001,
0x8000,0x3000,0x0006,0x0001,0x8000,0x0C00,0x0018,0x0001,
0x8000,0x0300,0x0060,0x0001,0x8000,0x00F0,0x0780,0x0001,
0x8000,0x000F,0xF800,0x0001,0x8000,0x0000,0x0000,0x0001,
0x8000,0x0000,0x0000,0x0001,0x8000,0x0000,0x0000,0x0001,
0x8000,0x0000,0x0000,0x0001,0x8000,0x0000,0x0000,0x0001,
0x8000,0x0000,0x0000,0x0001,0x8000,0x0000,0x0000,0x0001,
0x8000,0x0000,0x0000,0x0001,0x8000,0x0000,0x0000,0x0001,
0x8000,0x0000,0x0000,0x0001,0xFFFF,0xFFFF,0xFFFF,0xFFFF
------------------------------
End of SUN-Spots Digest
***********************