Sun-Spots-Request@Rice.edu (William LeFebvre) (09/14/88)
SUN-SPOTS DIGEST Tuesday, 13 September 1988 Volume 6 : Issue 228
Today's Topics:
Re: Bigger icons for frames
Re: Notiication on receiving new mail
Re: top 2.5 on 386i doesn't work
Apple LW II NT problems fixed--thanks!
semantics of ioctl using TIOCCONS
tftpboot ``broadcast storms''
Bug report: csh command argument limits
fpa/dbx bug
4.0 NFS/yp bug (sun 4)
Delays in more, emacs etc
DECNET input packet dropped
Problems with Internetwork Router
Information on TAAC board?
sun windows and IBM 43XX's?
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: Mon, 12 Sep 88 09:09:17 EDT
From: Chuck Musciano <chuck@trantor.harris-atd.com>
Subject: Re: Bigger icons for frames
> I was trying to assign bigger icons to frames, like two 64 x 64 icons
> joined together. I tried concatenating the two images I got from iconedit
> and increasing the ICON_HEIGHT/ICON_WIDTH in "icon_create" but it did not
> work.
Make sure that you fix up the header in the icon file, since the
icon_load() routine (undocumented, but available in <suntool/icon_load.h>)
uses these numbers to create the initial icon pixrect. If you get the
ICON_{WIDTH,HEIGHT} set right, it should work; I've created icons of all
sorts of sizes this way.
Chuck Musciano
Advanced Technology Department
Harris Corporation
(407) 727-6131
ARPA: chuck@trantor.harris-atd.com
------------------------------
Date: 12 Sep 88 22:28:58 GMT
From: mkhaw@teknowledge-vaxc.arpa (Mike Khaw)
Subject: Re: Notiication on receiving new mail
I've been using the "faces" program posted to comp.sources.misc by someone
at SMI in Australia. It works pretty well for mail notification (it's
also supposed to be able to monitor print queues, but I haven't had a need
for that).
Mike Khaw
--
internet: mkhaw@teknowledge.arpa
uucp: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge.arpa
hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
------------------------------
Date: Mon, 12 Sep 88 18:30:43 BST
From: mcvax!ritd.co.uk!mr@uunet.uu.net
Subject: Re: top 2.5 on 386i doesn't work
The "problem" is that the 386i uses COFF format object files (rather than
a.out). This seems to mean that external symbols are NOT prefixed by a "_"
(as in "_nproc"). I have hacked top2.5 to cope with the 386i (i.e. remove
the "_"), but find that I get funny complaints about nlist'ing one of the
symbols. Ignoring this doesn't seem to matter. Further investigations
suspended due to pressure of work.
Martin Reed, Racal Imaging Systems Ltd
uucp: mr@ritd.co.uk,{uunet!ukc!ritd,sun!sunuk!brains}!mr
Global String: +44 252 622144
Paper: 309 Fleet Road, Fleet, Hants, England, GU13 8BU
------------------------------
Date: Mon, 12 Sep 88 16:24:47 MDT
From: dbd%benden@lanl.gov (Dan Davison)
Subject: Apple LW II NT problems fixed--thanks!
Thanks to all who replied.
The problem was in part a wrong baud rate. But the strangest part is that
didn't fix it. Changing an errant Ethernet terminal server made the
printer start working!! A termserver was given an IP address which was
later given to a workstation. The termserver was informed of the change
of IP address, but one of its sixteen ports was still responding at the
old address and generally mucking things up. A Bridge tech rep showed up,
fixed the address problem, and the printer started working! What I
especially don't understand is that the workstation the printer was local
to couldn't print on it either.
Special thanks to mcvax!tnosoes!tom@uunet.uu.net and lrj@helios.tn.cornell.edu
who sent termcaps with some nifty twiddles.
If this isn't enough info for those who contacted me by e-mail with
similar problems, let me know.
Sun-Spots comes through again!
dan davison
------------------------------
Date: Mon, 12 Sep 88 09:03:40 EDT
From: Chuck Musciano <chuck@trantor.harris-atd.com>
Subject: semantics of ioctl using TIOCCONS
I use this feature to grab the console in contool. As far as I can tell,
the parameter to the ioctl is ignored. That is, TIOCCONS gives that pty
the console attribute, and you can't take it away until someone else uses
TIOCCONS to take it for themselves.
Chuck Musciano
Advanced Technology Department
Harris Corporation
(407) 727-6131
ARPA: chuck@trantor.harris-atd.com
------------------------------
Date: Mon, 12 Sep 88 17:22:17 EDT
From: dupuy@columbia.edu (Alexander Dupuy)
Subject: tftpboot ``broadcast storms''
This is caused when the /usr/etc/in.tftpbootd shell script is specified in
the /etc/servers file, and the directory /tftpboot does not exist, or has
no copy of /usr/etc/in.tftpd. What happens is that inetd gets a tftp
request (probably a broadcast one). It then fork/execs the shell script,
which looks something like this:
/usr/etc/chroot /tftpboot in.tftpd
The chroot program just makes a chroot(2) system call and execs it's third
argument. This fails, the shell script exits, and since nothing has been
read from the udp socket passed as fd 0, inetd still sees an incoming
request, and everything happens again. This causes a *lot* of swapping
and paging, even though nothing is really being done. The fix is to add a
few lines to the in.tftpbootd shell script so that this won't happen.
#! /bin/sh
if [ -d /tftpboot -a -x /tftpboot/in.tftpd ]
then
exec /usr/etc/chroot /tftpboot /in.tftpd $1
else
sleep 100000000 # prevent repeated respawning
fi
You can do fancier things, like try to read the socket, but this will slow
down the loop enough that it won't jam your ethernet.
The problem here is basically with inetd, though. I have seen similar
ethernet congestion caused by rpc.statd's failing (as a result of changes
to /pub/vmunix which confused the nd block cache on clients) and inetd
kept on starting new rpc.statd's, which kept on failing. I know /etc/init
has a feature which will cause it to disable a failing /etc/getty on a
terminal line. Something like this could be added to inetd.
@alex
------------------------------
Date: Mon, 12 Sep 88 16:40:02 EDT
From: schwartz@gondor.cs.psu.edu (Scott Schwartz)
Subject: Bug report: csh command argument limits
Reply-To: bugs@blitz.cs.psu.edu
Machine Type: Sun 4/260S
O/S Version: SunOS 4.0
Organization: Computer Science Department
The Pennsylvalia State University
333 Whitmore Laboratory
University Park, PA 16802
Phone Number: +1 814 865 9723
Description:
The man page for csh(1), under LIMITATIONS, states that
the system limits command arguments to 10240 characters.
The man page for execve(2), under ERRORS (E2BIG) indicates
that this value should be 1048576. The shell should allow
full length argument lists, or indicate in the man page that
it will only allow less than the system imposed limit.
Repeat-By:
echo {1,2,3,4,5,6,7,8,9,0}{1,2,3,4,5,6,7,8,9,0}{1,2,3,4,5,6,7,8,9,0}\
{1,2,3,4,5,6,7,8,9,0}{1,2,3,4,5,6,7,8,9,0}
-- Scott Schwartz
<schwartz@gondor.cs.psu.edu>
------------------------------
Date: Tue, 13 Sep 88 01:30:00 EST
From: Jim Hudgens <hudgens@ray.met.fsu.edu>
Subject: fpa/dbx bug
Serious bug exists in fpa/dbx combination after installing serial patch to
4.0.
The following trace was run on a Sun 3/280 server running SunOS 4.0 (with
the serial port patch applied). Synopsis: compile a program with -ffpa
option and -g option, run under dbx, and FPA crashes (the system still
runs though). Server has a FPA board, as well as several other boards
(VPC, ICON Dr11w emulator, 16M memory). This behavior started immediately
after applying the serial port patch. Problem is there with/without
suntools running. Does not seem to be affected by activity on tape, disk,
etc. Very repeatable.
-f68881 seems to be unaffected. Obvious short term solution is to
disable the fpa.
I've reported to Sun, but we are not on software support. Anyone have any
clues or workarounds?
Jim Hudgens
hudgens@ray.met.fsu.edu
__________
ray% cat test.c
main()
{
double x,y,z;
x=1.0;
y=2.0;
z = x / y;
}
ray% cc -ffpa test.c -g
ray% dbx a.out
Reading symbolic information...
Read 41 symbols
(dbx) run
Running: a.out
a.out: FPA KERNEL BUS ERROR
trap address 0x8, pid 206, pc = f05bb78, sr = 2000, stkfmt a, context 5
Bus Error Reg 88<INVALID,FPABERR>
unknown fault address 0 faultc 0 faultb 0 dfault 0 rw 0 size 0 fcode 0
page map 0 pmgrp 18
D0-D7 100 2 1 0 0 0 18 5
A0-A7 f0cdb63 e0000c01 77634 f10350c ffff97fc f10350c ffff9700 ffff96e8
Begin traceback...fp = ffff9700, sp = ffff96e8
Called from f0670f6, fp=ffff9714, args=f0cdb62 e0000c00 100 ffff9748
Called from f031c3a, fp=ffff9748, args=15 f0cda58 0 5
Called from f02675e, fp=ffff9760, args=5 ffff97b4 10 10
Called from f06b8d2, fp=ffff97a8, args=0 0 0 efffd54
Called from f004830, fp=0, args=4bc 0 4 1
End traceback...
FPA BUS ERROR: IERR == ff01ffff
----------( from other window ...)
ray% ps -x
PID TT STAT TIME COMMAND
175 co IW 0:00 -csh (csh)
183 co S 0:02 suntools
184 co S 0:00 selection_svc
206 ? Z 0:00 <defunct>
195 p0 S 0:04 cmdtool -C
196 p0 I 0:00 -bin/csh (csh)
204 p0 I 0:00 dbx a.out
212 p2 R 0:00 ps -x
------------------------------
Date: 12 Sep 88 17:40:40 GMT
From: trudel@caip.rutgers.edu (Jonathan D. Trudel)
Subject: 4.0 NFS/yp bug (sun 4)
(don't know if I sent this already, so here's another copy...)
Here's an interesting bug...We just got a Sun 4/110 with the 4.0 software.
We have it running as a yellow pages client of a 3/160 running 3.2. When
we have it in this configuration, it cannot do NFS mounting of any
machine, even itself. I have found that if I turn off yp service, I can
do the mounting.
The 4/110 is a standalone machine with its own disk, and only gets user
files and yp info from the 3/160.
Any clues? Anyone else experience this? Granted, I can work around it,
but that doesn't solve the real problem.
Jon
------------------------------
Date: Mon, 12 Sep 88 17:52:41 BST
From: Richard Tobin <richard%aiai.edinburgh.ac.uk@nss.cs.ucl.ac.uk>
Subject: Delays in more, emacs etc
I think this is probably a manifestation of a tcp problem, hopefully
well-known...
When using various programs that output a screenfull of text (notably more
and gnu emacs) it often happens that about a third of the page is output,
then there is a several-second delay, and the rest appears. This happens
when remotely logged-in from a shelltool, and in remote xterm windows.
Typing any character (or in X, moving the cursor out of the window)
usually causes the page to be completed immediately.
This happens on a 3/50 (running 3.2) talking to a 3/180 (running 3.5).
I conjecture that the 3/50 is dropping a packet, and having to wait for it
to be retransmitted. I vaguely remember hearing about something like this
before, but can't find any details. Any clues?
-- Richard
Richard Tobin, JANET: R.Tobin@uk.ac.ed
AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
------------------------------
Date: Mon, 12 Sep 88 14:30:26 CDT
From: selig@xanth.msfc.nasa.gov
Subject: DECNET input packet dropped
We've experienced a problem here with SunLink DNI that has me (and
apparently SUN) stumped. Sometimes, out of nowhere, we get line-after-line
of "DECNET input packet dropped". The processor is locked up and the
"cylon warrior" in the back of the 3/60 is shifting at the rate of 1 LED
per second or two. No keyboard input has any effect. Not even L1-A. It
happens rarely, but when it does, we have to power cycle to reboot. There
is some slight correlation with the user doing a 'man' command, but I'm
not real positive about that for cause and effect.
I checked w/ the SUN hotline about this and their only response was to
send me some patch stuff with a preamble message (left from an internal
SUN mailing I think) that indicated that they didn't think it would solve
the problem. That would be OK, but one of the things they DID do was
remove the "DECNET input packet dropped" message. Therefore, if the
problem showed up, I would have no indication that it was the DNI problem.
I would just have a dead machine. That's just not acceptable.
So, I'm turning here to see if anyone has any light they can shed on this
problem. We have a SUN4/260 running OS3.2-REV2 and a 3/60 running OS3.5.
We are running DNI version 5.0 on the diskless 3/60 client.
All help would be appreciated. Probably respond to the address below
and I'll summarize the result.
--bill
US MAIL: Bill Selig NASA/MSFC ES53
Huntsville, Al 35812 USA
TPC: (205)-544-7608
FTS: 824-7608
SPAN: sam::selig
INTERNET: selig@xanth.msfc.nasa.gov -OR-
selig%sam.span@fedex.msfc.nasa.gov
BITNET: selig%sam.span@star.stanford.edu
UUCP: uunet!selig@sam.SPAN -OR- uunet!sam.span!selig
------------------------------
Date: Mon, 12 Sep 88 11:08:32 PDT
From: Robert Schwartzkopf <bobs%rcc@rand-unix.arpa>
Subject: Problems with Internetwork Router
We have also had many problems getting INR to run. When our gateway (a
3/50 running 3.5) forwards packets from the serial line we're running INR
over to our ethernet it munges the size of the packet, causing a BABYL
error on the gateway and "giant packet" errors on all of the sun consoles
on the local ethernet. It only seems to munge packets of a particular
size (346 bytes including headers), packets of other sizes work fine.
We have come up with a file that causes rsh to hang consistently whenever
we cat it over the INR. Given the following configuration, the command
"rsh R cat bogus.file" when executed on host L will cause the rsh to hang
forever:
___ ___ ___
| L | ethernet | G | INR | R |
|___|----------|___|------------|___|
The first N packets sent from R through G to L arrive correctly, the last
one (length 346) arrives at the gateway G correctly as near as I can tell,
but when G forwards the packet from the INR to the ethernet it adds 4100
(0x1004) to the size of the packet, causing the "giant packet" and "babyl"
errors. Every 30 seconds the connection times out and retransmits with
the same result. The first 346 bytes of the bad packet look correct
except for the length, the next 4100 are garbage.
If anyone has made the INR work I'd appreciate hearing from them, Sun
hasn't been much help on this one.
Bob Schwartzkopf
------------------------------
Date: Mon, 12 Sep 88 13:45:58 -0400
From: lrj@helios.tn.cornell.edu
Subject: Information on TAAC board?
We are currently considering the purchase of a Sun4 with a TAAC board and
would like to gather the opinions of people who are actually using this
equipment. This machine would be an addition to an existing Sun3 network.
If you have or have used a Sun4 with the TAAC board, please send me your
thoughts on it; both the hardware and the software. How easy is it to
use? How buggy is the software? Is it a gem or a real dog? Should we
just get crayons and some paper? :)
Sun has provided us with all the glossies, as well as the name of a person
who is using the TAAC; however I highly doubt that Sun is likely to put us
in contact with someone who is unhappy with the board. (not to knock Sun,
it'd be stupid for *any* company to hook up a potential customer with a
dissatisfied one)
I will summarize to Sun-Spots if there is enough interest.
Lewis R. Jansen, Systems Manager
Lab of Atomic and Solid State Physics
Cornell University, Ithaca NY
(607) 255-6065
Internet: lrj@helios.tn.cornell.edu
------------------------------
Date: 13 Sep 88 04:51:36 GMT
From: sean@arizona.edu (Sean O'Malley)
Subject: sun windows and IBM 43XX's?
I would like to be able to open a SUN window (or x window) to an IBM 43XX
runing VM. This machine apparently supports TCP/IP so in theory it should
be possible. The problem (or so I have heard) is getting the correct key
sequence correspondences to properly emulate some terminal that the IBM
understands. I would appreciate hearing from anyone who has successfully
accomplished this feat. (If you have any freeware that I could use so much
the better.)
Sean O'Malley
CSNET:sean@arizona.edu
------------------------------
End of SUN-Spots Digest
***********************