Sun-Spots Digest, v6n274
William LeFebvre
Sun-Spots-Request at Rice.edu
Wed Oct 26 14:48:53 AEST 1988
SUN-SPOTS DIGEST Tuesday, 25 October 1988 Volume 6 : Issue 274
Today's Topics:
Re: uuencode ASCII--EBCDIC
Re: System V shared memory "zombies"
Re: UUCP, bug or feature
Xylogics 753 vs 7053?
Xylogics 753 vs 7053 and 451
Upgrade 3/50 to 8 MBytes
Better fix for NSTREAMS
Responses to 'S' Query
possible compiler bug on Sun 4, sys4-3.2
sun 4/260 Floating Point Problem
Getting info from damaged system?
Performance on 3/50's with SunOS 4.0?
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: Fri, 21 Oct 1988 14:32:06 CET
From: A0096 at DK0RRZK0.BITNET
Subject: Re: uuencode ASCII--EBCDIC
The problems using uuencoded files on bitnet are well known at this side.
It is impossible for us to maintain comp.sources and GNU-diffs with a
predictable amount of work. In oposite there is no need for any problems
at all. The program dumas-uuen(de)code puts a character table in front of
the actual uuencoded file which is affected by all conversions as well.
Analyzing this header it can recover the original file. This procedure
works well for years in the atari networld were most programs are
distributed binary only. The program is extremely smart and can deal with
most attacks like permuted characters, trailing blanks, any kinds of
envelopes and so on. You can split the file to small pieces in case of
more restrictive mailers and reconstruct it totally automatically. The
best method of distributing files as tested for years is: compress (4.0)
and dumas-uue in junks of 20Kb. If more sites would agree to that
standard, mailing would be much faster due to reduced traffic and more
secure for sites connected over whatever gateways.
Thomas Pfenning
ps: the C-source originally from berkeley adapted to european bitnet problems
is available from server at marvin.eleceng.bradford.ac.uk mail based with the
text send utils/dumas.arc
University of Cologne, Institute for Theoretical Physics, West Germany
------------------------------
Date: Thu, 20 Oct 88 13:05:01 EDT
From: John Ioannidis <ji at ncs.columbia.edu>
Subject: Re: System V shared memory "zombies"
Reference: v6n262
>From: harvard!ll-xn!munsell!jwf at gatech.edu (Jim Franklin)
>
> [Summary: shared memory segments created using shmget(2) outlive the
> process that created them. They can be marked for deletion, but then
> they become unusable by other processes while they still exist.
> Even if all processes attach to the segment before it is flagged for
> deletion, there are cases where this is just not enough]
>Has anyone found a clean solution to this problem?
There is nothing clean about System V-type IPC. :-)
I have a solution that might be good for what you want. Remember the
ftok(3) call? Reserve an ID, say, '\177' (the DEL character) to make keys
for segments that should be deleted when all processes attached to them
die. The ID appears as the high-order byte of the key. Then have an awk
script that will go through the output of ipcs -m -o, look for segments
whose key starts with 0x7f and for which the NATTCH field is 0 and delete
them. The following script would do the trick:
for i in `ipcs -mo | awk '$1=="m" && $3~/0x7f/ && $7==0 {print $2}'`
do
ipcrm -m $i
done
If you have nawk, it's just
ipcs -mo | nawk \
'$1=="m" && $3~/0x7f/ && $7==0 {system(sprintf("ipcrm -m %s",$2))}'
Now, there is a hitch:
*** BUG REPORT (with fix) ***
ipcs(1) on SunOS 4.0 reports NATTCH incorrectly. The problem lies in the
fact that the shm_nattch field of the shmid_ds structure for the shared
memory segment is not updated when a segment is attached -- there is no
need to. Its value is actually the value of the refcnt field of the
anon_map structure associated with the segment, and that's maintained
properly. The only time shm_nattch is set is when you do a
shmctl(IPC_STAT), and subsequent ipcs(1) report NATTCH correctly. If a
process terminates, though, the shm_nattch field stays incorrect until YA
proccess does a shmctl(IPC_STAT). Fixing this in the kernel is not worth
it, as the field is ONLY used by the IPC_STAT code. Rather, the following
fix to ipcs.c will follow the pointers properly and return the correct
value for NATTCH.
____________________ CUT HERE ____________________
*** ipcs.c.orig Thu Oct 20 16:42:00 1988
--- ipcs.c Thu Oct 20 16:42:00 1988
***************
*** 17,18 ****
--- 17,19 ----
#include <sys/shm.h>
+ #include <vm/seg_vn.h>
#undef KERNEL
***************
*** 90,92 ****
char hostnm[64]; /* used for gethostname() */
!
/* Go through the options and set flags. */
--- 91,94 ----
char hostnm[64]; /* used for gethostname() */
! struct anon_map amp; /* used to get refcount */
!
/* Go through the options and set flags. */
***************
*** 222,224 ****
if(oflg)
! printf("%7u", mds.shm_nattch);
if(bflg)
--- 224,230 ----
if(oflg)
! {
! reade(mds.shm_amp, &, sizeof(amp));
! printf("%7u", amp.refcnt-1);
! }
!
if(bflg)
____________________ CUT HERE ____________________
Hope all this helps, (and I hope noone has posted this before -- I was out
of touch for about a month).
/ji
In-Real-Life: John Ioannidis
Organization: GIP ALTAIR [IN2-INRIA-LRI]
P-Address: Domaine de Voluceau, BP 105 / Rocquencourt 78153 Le Chesnay / France
V-Address: +33 1 39635417
E-Address: ...!mcvax!inria!bdblues!ji, ji at bdblues.altair.fr
Alt-E-Address: ji at columbia.edu
------------------------------
Date: Fri, 21 Oct 88 10:02:29 PDT
From: vsi1!lmb at ames.arc.nasa.gov (Larry Blair)
Subject: Re: UUCP, bug or feature
I discovered a "feature" in uucp that will let you do what you want to.
If you begin the phone number in the L.sys file with a alphabetic string,
the value for that string in the L-dialcodes file is prepended to the
number that follows. More importantly, if the replacement string begins
with an "S", the Hayes dialer prepends only "AT" rather than the usual
"ATDT". I use this feature to set registers on my Trailblazer.
L.sys:
site Any ACUHAYES 19200 fast999-9999 ogin: vsi1
L-dialcodes:
fast S50=255DT
Note that since the Hayes dialer was no longer generating the "DT", I had
to do it at the end of the string.
Larry Blair ames!vsi1!lmb lmb%vsi1.uucp at ames.arc.nasa.gov
------------------------------
Date: Thu, 20 Oct 88 17:52:07 PDT
From: Richard Smith <smiddy at spam.istc.sri.com>
Subject: Xylogics 753 vs 7053?
What is the difference between the Xylogics 753 and the Xylogics 7053? I
know we have a couple of 7053s here, but no 753s.
Smiddy at spam.istc.sri.com
------------------------------
Date: Fri, 21 Oct 88 7:16:56 EDT
From: "Tim G. Smith" (Mechanical) <tsmith at usna.mil>
Subject: Xylogics 753 vs 7053 and 451
> I just received a 4/280 with 2 of the 900 Meg disks, and it has the same
> tired old Xylogics 451 controller...
> Has anyone been able to swap their 451 for a 753 or 7053?...
I haven't swapped any 451's but I have bought some 753's. I would suggest
just trashing the 451 if need be and ordering a 753. Your system is going
to be so slow with those nice fast drives being choked to death by the
451. I belive the 753 is availible for about $2500 or so- not very
expensive and well worth the money for the performance gain over the 451.
If I were you I would avoid getting a 7053 as I don't think it supports
3.0MBy/sec data transfer (I belive it is limited to 2.4MBy/sec). Many of
the newer disk drives support 3.0MBy/sec (Fujitsu M2382K, CDC Saber among
others). I have been told that sun will maintain the 753 as well as the
7053. I know that it is possible to get a 753 from Sun Federal if you are
a big customer who REQUIRES 3.0MBy/sec transfer rates.
Check with the normal third party vendors if you want more info. I have
had good experiences with:
Software Associates
(215) 967-1846
(800) 4551-2875
My sales rep is Dave Suter.
Usual disclaimer.... I am just a satisfied customer- I don't work for the
folks or anything devious like that...
Good luck,
Tim Smith
US mail:ECSD/CADIG mailstop: 11G E-mail:
US Naval Academy internet:tsmith at USNA.MIL
Annapolis, MD 21402 uucp :...!uunet!usna!tsmith
MaBell :(301)267-4413
------------------------------
Date: Fri, 21 Oct 88 14:31:38 EDT
From: mitel!avalon!carter at uunet.uu.net (Mike Carter)
Subject: Upgrade 3/50 to 8 MBytes
Clearpoint is working on a product to upgrade SUN 3/50 memory to 8 MBytes.
It's not available yet, but it's an option to keep in mind for those who
are running OS4.0. Contact Clearpoint for availability and pricing info.
In the US, call 1-800-CLEARPT, and in Canada call (416) 620-7242. (No,
this is not a paid advertisement!)
We're using Clearpoint memory for SUN 3/60's and SUN 4/110's, and are
happy with the results. The price is a lot better than SUN's price (but
still a whole lot higher than it was 12 months ago...).
Mike Carter
Mitel Corporation
uucp: uunet!mitel!carter
------------------------------
Date: Fri, 21 Oct 88 09:07:06 EDT
From: ehrlich at shire.cs.psu.edu (Dan Ehrlich)
Subject: Better fix for NSTREAMS
Machine Type: Sun 4/260S O/S Version: SunOS 4.0
Organization: Computer Science Department, The Pennsylvania State University
333 Whitmore Laboratory, University Park, PA 16802
Phone Number: +1 814 865 9723
Description:
The number of stream data strutures allocated in the kernel is controlled
by the definition of NSTREAMS in /sys/conf.common/param.c. Unfortunately
as shipped this is hard coded as 32. The enclosed patch attempts to
compute a 'better' value based on the number of ptys, installed mcp/alm
boards, etc. The other stream constants (also hard coded as shipped)
should probably be based on NSTREAMS, but time has prevented me from
delving that deeply into the source code to determine whom is related to
whom and in what way.
Fix:
Apply the following patch to /sys/conf.common/param.c and recompile the
kernel.
*** /tmp/geta9750 Fri Oct 21 08:56:19 1988
--- /tmp/getb9750 Fri Oct 21 08:56:19 1988
***************
*** 153,159 ****
#define NBLK (NBLK4096 + NBLK2048 + NBLK1024 + NBLK512 + NBLK256 + NBLK128 + \
NBLK64 + NBLK16 + NBLK4)
! #define NSTREAM 32
#define NMUXLINK 87
#define NSTRPUSH 9
#define NSTREVENT 256
--- 153,167 ----
#define NBLK (NBLK4096 + NBLK2048 + NBLK1024 + NBLK512 + NBLK256 + NBLK128 + \
NBLK64 + NBLK16 + NBLK4)
! #include "pty.h"
! #include "zs.h"
! #include "mcp.h"
! /*
! * NPTY - # of pty from config file
! * NZS - # of CPU serial port controllers (almost always 2)
! * NMCP - # of ALM/MCP boards from config file
! */
! #define NSTREAM (NPTY + (2*NZS) + (17*NMCP) + 16)
#define NMUXLINK 87
#define NSTRPUSH 9
#define NSTREVENT 256
------------------------------
Date: 21 Oct 88 14:55:00 EDT
From: Greg Morrison <MORRISON at CARLETON.BITNET>
Subject: Responses to 'S' Query
Hi -- thanks very much to the 20(!) people who took time to send me
information about where to get the S and S-PLUS statistical programs...
the information has been very helpful to us. A representative mailing was
that from Douglas Bates:
> The latest version of S is documented in the book "The New S Language:
> A Programming Environment for Data Analysis and Graphics" by Richard
> A. Becker, John M. Chambers, and Allan R. Wilks (Wadsworth, 1988).
> In there they state that information on obtaining source code for
> S can be obtained from
>
> AT&T Software Sales
> P.O. Box 25000
> Greensboro, North Carolina 27420
> (800) 828-UNIX
>
> S includes a device driver for SunWindows but does not include dynamic
> graphics facilites for SunWindows. These facilities are available in
> S-PLUS, an enhanced version of S, sold by
>
> Statistical Sciences Inc.
> 2825 Eastlake Avenue East, Suite 106
> P.O. Box 85625
> Seattle, Washington 98145-1625
> (206) 322-3841
Greg Morrison <MORRISON at CARLETON.BITNET>
------------------------------
Date: Thu, 20 Oct 88 18:27:11 MST
From: mc%miranda.uucp at moc.jpl.nasa.gov (Mike Caplinger)
Subject: possible compiler bug on Sun 4, sys4-3.2
Consider the following C program:
typedef union {
int *i;
char *s;
float *f;
} vp;
main() {
int i;
char *s = "hi there";
float f;
printf("%x %x %x\n", &i, s, &f);
foo(&i);
foo(s);
foo(&f);
}
foo(a)
vp a;
{
printf("%d %x %x %x\n", sizeof(a), a.i, a.s, a.f);
}
On a Sun 3, this yields the correct (?) result:
effff50 20034 effff48
4 effff50 effff50 effff50
4 20034 20034 20034
4 effff48 effff48 effff48
On a Sun 4 under sys4-3.2, the result is incorrect:
fefffe8c 8008 fefffe84
4 0 0 0
4 68692074 68692074 68692074
4 0 0 0
If we examine the assembler output, we find, preceding the call to
printf in foo, the sequence
ld [%i0],%o2
ld [%i0],%o3
ld [%i0],%o4
call _printf,5
which should in fact be
mov %i0,%o2
mov %i0,%o3
mov %i0,%o4
call _printf,5
by my reading of the definition of C unions.
Has this been fixed in 4.0 on the Sun-4 (or perhaps broken on the Sun 3
with 4.0?)
[[ I just checked on our Sun 3 running 4.0, and it produces the correct
result (modulo pointer value differences, of course). --wnl ]]
Mike Caplinger, mc at moc.jpl.nasa.gov
------------------------------
Date: Fri, 21 Oct 88 10:24:09 EDT
From: marc at aplpy.jhuapl.edu (Marcus Gates)
Subject: sun 4/260 Floating Point Problem
I was running a simple-minded floating point benchmark on our sun4 and ran
into a problem (The benchmark is just a loop which does floating-point
computations). If I don't optimize when I compile, the program runs
quickly and uses mostly user time. If I optimize it then it runs for an
VERY LONG time and uses mostly system time. I suspect that the usage of
system time indicates that the sun is emulating floating-point, somehow
forgetting that it has the FPA available. Has anyone else seen this
problem?? We are running the 4.0 OS.
marc gates
johns hopkins applied physics lab, laurel, md
UUCP: ...bpa!cp1!aplcen!aplvax!marc
Internet: marc at aplpy.jhuapl.edu
------------------------------
Date: Fri, 21 Oct 88 09:56:52 EST
From: David Pipes 6-2248 <PIPES at nssdca.gsfc.nasa.gov>
Subject: Getting info from damaged system?
We have a Sun-2 which has been severely heat-damaged. It will not run
reliably for more than an hour or so. It has no ethernet connection, and
we have discovered that the tape drive attached to it is also broken.
(The machine was out of use for a long period of time...).
I have been asked to get some data off of the disk and onto some other
medium before the machine is carted off. The method I am considering is
to take the disk out and daisy-chain it to either a Sun-3 (Sunos 3.4) or a
Sun-4 (Sunos 4.0). It could then presumably be accessed like any other,
and the necessary files copied over to the regular system disk.
I believe I understand the hardware procedure to do this, but what do I
need to do to access the disk? Can I just mount it like any other device
and go? If not, how should I go about reading it? Is this idea just
plain crazy?
Please respond to me. I will summarize replies to here.
Thanks in advance!
David Pipes
Reply to: pipes at nssdca.gsfc.nasa.gov
David Pipes
NSSDCA
NASA Goddard
Greenbelt, Md. 20771 301-286-2248
------------------------------
Date: Fri, 21 Oct 88 10:37:48 PDT
From: sytek!syteka!sridhar at hplabs.hp.com (Sridhar Acharya)
Subject: Performance on 3/50's with SunOS 4.0?
We have a 3/160 server and a bunch of 3/50's with local disks.
We were thinking of upgrading to Sun0S 4.0. I keep hearing that
4.0 requires a lot of memory and there may be performance degradation
in 3/50's when we migrate to 4.0 since the 3/50 have only 4 Meg.
Does anybody have an idea how the performance is with 4.0 on 3/50's
with the above/similar configuration.
Thanks.
Sridhar Acharya
sun!sytek!syteka!sridhar or hplabs!sytek!syteka!sridhar
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list