Sun-Spots Digest, v6n174
William LeFebvre
Sun-Spots-Request at RICE.EDU
Mon Aug 8 15:19:28 AEST 1988
SUN-SPOTS DIGEST Sunday, 7 August 1988 Volume 6 : Issue 174
Today's Topics:
Re: Amount of virtual memory
Re: printf problems on the Sun-4
malloc() and OS4
bm
find processes on SunOS 4.0
mkfs/newfs: not enough inodes (SunOS 4.0)
Device driver changes between Sun OS 3.x and 4.0?
using ieee floating point NaN's?
Can I have two networks on one interface?
Formatting a non-Sun SCSI disk?
frame buffers on color 3/60's?
Performance Measurement?
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: Mon, 01 Aug 88 12:19:08 PDT
From: weiser.pa at xerox.com
Subject: Re: Amount of virtual memory
> I've not tried it, but since SunOS 4.0 you should just be able to say:
>
> mkfile 16M /somewhere/useful/extraswap
> swapon !$
I've tried it, works fine.
In fact, you don't even have to mkfile, just touch. But then the file
grows as it is used for swap, and so may not be contiguous, and so have
poor performance. Ought to work, though.
-mark
------------------------------
Date: Tue, 2 Aug 88 01:45:42 EDT
From: bill at research.att.com
Subject: Re: printf problems on the Sun-4
Reference: v6n158
In v6n158 Dan Franklin commented on the printf bug that causes
printf("%g\n",0.1) to print ".1" instead of "0.1" and states:
> This output change is so stupid and gratuitous that I
> suspect Sun didn't decide to do it, but rather picked it up from some
> brain-damaged AT&T change
AT&T's System-V always has (and still does, I checked) printed "0.1" for
the statement above. Dan, please check your facts before maligning
things.
By the way, the printf bug does not just occur on Sun-4's, but also shows
up on Sun-3's running SunOS 4.0.
-Bill Schell
AT&T Bell Labs, Murray Hill, NJ
allegra!bill
------------------------------
Date: Tue, 02 Aug 88 11:34:05 +0200
From: Torsten Beyer <unido!bilbo.irb!tb at uunet.uu.net>
Subject: malloc() and OS4
In Sun-Spots Digest v6n151 Dave Jones asked me to spupply my test
program, which (at least on our SUNs) demonstrates the "wrong" behaviour
of malloc(). So here we go :
#include <stdio.h>
#define SIZE 10240000
main()
{
char *p, *malloc();
printf ("Start first malloc()\n");
p = malloc ( SIZE);
printf ("Ok p = %lx\nPress any key...\n",p);
getchar();
free (p);
printf ("Start 2nd malloc()\n");
p = malloc (SIZE);
printf ("Ok p = %lx\nPress any key...\n",p);
getchar();
}
This produces the following output from ps aux :
after the first malloc() :
tb 555 0.0 0.910064 56 p5 S 0:00 tst
^^^^^
and after the 2nd malloc() :
tb 555 0.0 1.120072 64 p5 S 0:00 tst
^^^^^
Replacing SUNs malloc with standard 4.3 malloc() shows "right" behaviour.
Strange enough p points to the same adress in both malloc()s in the above
program, although memory size has doubled. Any hints ?
[[ I tried this on a Sun 3 running vanilla SunOS 4.0. The virtual size
did not increase. --wnl ]]
ciao
-Torsten
Torsten Beyer e-mail : tb at unido.uucp
University of Dortmund ..uunet!unido!tb
IRB tb at unido.bitnet
P.O.Box 500500
D-4600 Dortmund 50 voice : +49 231 7552422
West-Germany
------------------------------
Date: Tue, 2 Aug 88 14:40:29 BST
From: Eric Ole Barber <mcvax!nw.stl.stc.co.uk!sizex at uunet.uu.net>
Subject: bm
Sounds nice, but as far as I know I have no access to comp.sources.unix.
Obviously I could ask for a "personal" copy, but the wnl-s of this world
know that is a pain. I wonder if the Rice archive could act as a relay,
and handle 'send comp.sources.unix bm' in the obvious way. bm is just an
example - it's not on comp.sources.unix yet anyway. Thanks, Eric
[[ How would I automate the retrieval? I think there is some sort of
mail-response server for the Unix-sources archives. They're all the rave
these days. I'll let you know if I hear anything about one. For those
who don't know, "bm" is an fgrep-like program that uses the Boyer-Moore
fast string searching algorithm. --wnl ]]
------------------------------
Date: Fri, 22 Jul 88 12:26:46 MDT
From: cs.utah.edu!caeco!olyis!sol!jlp at cs.utexas.edu (Jan L. Peterson)
Subject: find processes on SunOS 4.0
After seeing Richard Tobins cute program to find processes that are
accessing nfs filesystems, I decided to try and make it run under SunOS
4.0. Several things have changed in 4.0 due to the new virtual memory
system.
Also, someone asked how well debuggers work with the new shared libs. My
experience shows that they don't. Primarily, if the executable image gets
modified while the program is running in the debugger, it hangs the
debugger. Pre-4.0 used to say "process killed due to text modification".
Apparently, it's just trying to page in the appropriate page and not
finding it and trying again, ad infinitum. Anyway, we now link
development programs -Bstatic while they are being worked on.
Here's my program, in hand-assembled shar form:
========== cut here ==========
: run this through /bin/sh
sed -e 's/^X//' << \SHAR_EOF > ff4.c
X/*
X * ff4 - find processes accessing an nfs file system under SunOS 4.0.
X * inspired by a program by Richard Tobin (R.Tobin at uk.ac.ed)
X *
X * converted to grok SunOS 4.0 by Jan L. Peterson (jlp at olyis.UUCP)
X * I place my mods in the public domain, do with them what you
X * will. No warranties, etc.
X *
X * original copyright notice follows:
X * Copyright Richard Tobin, AIAI 1988 (R.Tobin at uk.ac.ed)
X * May be freely redistributed if this notice remains intact.
X *
X * compilation instructions:
X * cc -o ff4 ff4.c -lkvm
X * chgrp kmem ff4
X * chmod g+s ff4
X */
X
X#include <kvm.h>
X#include <nlist.h>
X#include <fcntl.h>
X#include <sys/param.h>
X#include <sys/types.h>
X#include <sys/time.h>
X#include <sys/user.h>
X#include <sys/proc.h>
X#include <sys/vnode.h>
X#include <sys/vfs.h>
X#include <stdio.h>
X
Xstruct file { /* cheating here to prevent having to */
X int f_flag; /* define KERNAL. see <sys/file.h> */
X short f_type; /* for descriptions of these fields */
X short f_count;
X short f_msgcount;
X struct fileops {
X int (*fo_rw)();
X int (*fo_ioctl)();
X int (*fo_select)();
X int (*fo_close)();
X } *f_ops;
X caddr_t f_data;
X off_t f_offset;
X struct ucred *f_cred;
X};
X
X#define DTYPE_VNODE 1
X
Xkvm_t *kd; /* kernal descriptor */
Xchar *progname;
X
Xmain(argc, argv)
Xint argc;
Xchar *argv[];
X{
X struct statfs fs_stat;
X struct proc *p, proc;
X struct user *u;
X int f;
X struct file file;
X
X progname = argv[0];
X
X if (argc != 2)
X error("usage: %s filesystem\n", progname);
X
X if (statfs(argv[1], &fs_stat))
X xperror("statfs");
X
X printf("looking for id %x %x\n", fs_stat.f_fsid.val[0],
X fs_stat.f_fsid.val[1]);
X
X if (!(kd = kvm_open(NULL, NULL, NULL, O_RDONLY, progname)))
X xperror("kvm_open");
X
X if (kvm_setproc(kd))
X xperror("kvm_setproc");
X
X while (p = kvm_nextproc(kd))
X {
X bcopy((char *)p, (char *)&proc, sizeof(proc));
X if (proc.p_pid <= 2)
X continue; /* 0 == swapper, 1 == init, 2 == pagedaemon */
X if (proc.p_stat == SZOMB)
X continue; /* zombie process */
X if (!(u = kvm_getu(kd, &proc)))
X {
X printf("warning, couldn't read u area for process %d\n",
X proc.p_pid);
X continue;
X }
X check(u -> u_cdir, fs_stat.f_fsid,
X "process %d current directory\n", proc.p_pid, 0);
X check(u -> u_rdir, fs_stat.f_fsid,
X "process %d root directory\n", proc.p_pid, 0);
X for (f = 0; f < NOFILE; f++)
X if (u -> u_ofile[f])
X {
X if (kvm_read(kd, u -> u_ofile[f], &file, sizeof(file)) == -1)
X {
X perror("kvm_read");
X continue;
X }
X if (file.f_type == DTYPE_VNODE)
X check(file.f_data, fs_stat.f_fsid,
X "process %d descriptor %d\n", proc.p_pid, f);
X }
X }
X if (kvm_close(kd))
X xperror("kvm_close");
X}
X
X
Xcheck(v, id, format, arg1, arg2)
Xstruct vnode *v;
Xfsid_t id;
Xchar *format;
Xint arg1, arg2;
X{
X struct vnode vnode;
X struct vfs vfs;
X
X if (!v)
X return;
X
X if (kvm_read(kd, v, &vnode, sizeof(vnode)) == -1)
X {
X perror("kvm_read");
X return;
X }
X if (kvm_read(kd, vnode.v_vfsp, &vfs, sizeof(vfs)) == -1)
X {
X perror("kvm_read");
X return;
X }
X if (bcmp(&vfs.vfs_fsid, &id, sizeof(fsid_t)) == 0)
X printf(format, arg1, arg2);
X}
X
Xerror(message, arg1)
Xchar *message, *arg1;
X{
X fprintf(stderr, message, arg1);
X exit(1);
X}
X
Xxperror(message)
Xchar *message;
X{
X perror(message);
X exit(1);
X}
SHAR_EOF
exit 0
enjoy it.
-jan-
------------------------------
Date: Tue, 2 Aug 88 11:48:02 EDT
From: dupuy at columbia.edu (Alexander Dupuy)
Subject: mkfs/newfs: not enough inodes (SunOS 4.0)
We're bringing up a Sun-4 fileserver, which will take over much of the
news and mail duties here. We have two 898M Hitachi drives, with those
biiiig cylinders (1005 sectors ~= 500K each). I wanted to create a nice
little 50M filesystem with lots of inodes for news. This doesn't seem to
be possible.
The most inodes/cylinder group which mkfs or newfs allows is 2048. With
the default 16 cylinders/group, this works out to 1 inode / 4K, which is a
bit low for news. I went and pulled the old Sun-Spots issue off the
archive server to see what the workaround was. The solution which someone
came up with then was to use 8 cylinders/group - fairly obvious in
retrospect. Unfortunately, under SunOS 4.0, mkfs/newfs say:
"cylinder groups must have a multiple of 16 cylinders"
which does not warm my heart. On a Sun-3 running SunOS 3.5, the minimum
seems to be 4 cylinders/group. Is there a reason for this? What would
happen if I compile my old 3.5 mkfs source under 4.0 and build an 8
cyl/grp filesystem anyhow? I suspect the kernel will panic and die at
some point, and don't care to find out the hard way.
So, does anyone out there have any useful suggestions?
@alex
--
inet: dupuy at columbia.edu
uucp: ...!rutgers!columbia!dupuy
------------------------------
Date: Mon, 1 Aug 88 15:24:17 EDT
From: dyer at arktouros.mit.edu (Steve Dyer)
Subject: Device driver changes between Sun OS 3.x and 4.0?
I wrote a fairly vanilla tape driver for Sun OS 3.something (not sure what
revision it was) which has worked just fine in kernels up to Sun OS 4.0.
Doing some very mechanical rearrangements of include files produced a
driver which compiles and links into the Sun OS 4.0 kernel, but operations
do not complete (they're usually stuck sleeping, prob. in physio). I know
that the hardware is working, because I can boot a version of Sun OS 3 on
the same machine and the driver works fine.
Can someone point out any gross differences I should bear in mind? A
quick look at the new May 88 revision of "Writing Device Drivers for..."
didn't have anything leap out at me.
Thanks,
Steve Dyer
dyer at spdcc.com
dyer at arktouros.mit.edu
------------------------------
Date: 1 Aug 88 17:00:48 GMT
From: Robin Rohlicek <rohlicek at bbn.com>
Subject: using ieee floating point NaN's?
I'm trying to take advantage of the ieee floating point implementation on
a Sun 4 (SunOS3.2_rev2). In IEEE Std-754, there is a discussion of two
types of nonnumbers (NaN's). The way I understand it (sect. 6.2), "quiet"
NaN's don't signal exceptions when used as operands while "signaling"
NaN's behave as invalid operands. However, there is only one binary
representation specified for NaN's (sect. 3.2) -- what distinguishes the
signaling and quiet versions? Also, when trying the use Sun's quiet_nan()
and signaling_nan() routines, the signaling_nan() returns Inf instead of
NaN.
Am I missing something?
Robin Rohlicek
BBN Labs, Cambridge MA.
------------------------------
Date: 1 Aug 88 18:28:47 GMT
From: pyramid!leadsv!laic!nova!darin at decwrl.dec.com (Darin Johnson)
Subject: Can I have two networks on one interface?
We have put in a vitalink here. This allows ethernets in different
buildings to act as one large ethernet. This means that I can now talk to
machines I couldn't talk to before. However, not all of these machines
have gotten around to using the net addresses.
Is there a way to configure my Sun so that it can talk to machines on the
same ethernet, but who have different internet network numbers? (for
example, 192.9.200 and 129.197.31)
Darin Johnson (...pyramid.arpa!leadsv!laic!darin)
(...ucbvax!sun!sunncal!leadsv!laic!darin)
------------------------------
Date: Tue, 02 Aug 88 11:34:05 +0200
From: Torsten Beyer <unido!bilbo.irb!tb at uunet.uu.net>
Subject: Formatting a non-Sun SCSI disk?
By the way, has anyone outhere tried to format a non SUN SCSI disk (330Mb
drive in our case) using SunOS4.0 format (under MUNIX) ?? We keep getting
strange faults here. The disc has 1218 data cylinders and 2 alternate
cylinders. Its has been succesfully formatted under 3.4. Doing so under
4.0 however fails with format telling us that it can't write backup labels
and bad track table to cylinder 1219. Decreasing the amount of data
cylinders to 1216 with 2 alternate cylinders produces the same error on
cylinder 1217. Obviously format isn't able in any case to write backup
label and bad track table to the highest given cylinder. Our SUN hotline
types didn't show much interest in helping to find this error ("do you use
a SUN disc ?","No","Hmm, seems we can't help you then.."), so perhaps
someone out there as already found a solution to this ??
Torsten Beyer e-mail : tb at unido.uucp
University of Dortmund ..uunet!unido!tb
IRB tb at unido.bitnet
P.O.Box 500500
D-4600 Dortmund 50 voice : +49 231 7552422
West-Germany
------------------------------
Date: 2 Aug 88 15:03 +0100
From: Jiri Dvorak <dvorak at iam.unibe.ch>
Subject: frame buffers on color 3/60's?
Under suntools on our 3/60 (diskless, color, SunOS 3.5) several utilities
accessing directly '/dev/fb' do not read/write from the same 'desktop' as
suntools. This holds e.g. for 'screendump', 'dumpregion', the mystery
programs 'ferkel' and 'decay', and other. screendump, for example, writes
a completely white rasterfile, ferkel and decay are running with no
visible effect.
As the problem can be eliminated with the suntools option
'-8bit_color_only', I assume that suntools accesses some bw desktop,
whereas the other programs access a color desktop. The strange thing is
that on a 3/260 (color, SunOS 3.4), suntools with default parameters does
not behave in the same way, i.e. screendump, dumpregion return rasterfiles
copied from the visible screen.
Why this different behaviour on color 3/60 versus color 3/260? Can I make
some changes to the 3/60 to behave the same way as the 3/260? As we have
3/50 monochrome's and 3/60 color's mounting the same /usr and used by the
same users, an alias suntools 'suntools -8bit_color_only' is no solution.
Any hints appreciated.
(ps: this problem may be related to Michael Nowak's screenblank problem in
v6n159)
Jiri Dvorak dvorak at iam.unibe.ch or
Institut fuer Informatik dvorak%iam.unibe.ch at relay.cs.net
und angewandte Mathematik UUCP: ..!uunet!mcvax!iam.unibe.ch!dvorak
Universitaet Bern
Switzerland Phone: (+31) 65 49 02
------------------------------
Date: Fri, 29 Jul 88 11:37:03 EDT
From: Mark Levison <levisonm%qucis at waterloo.edu>
Subject: Performance Measurement?
I am currently attempting to measure the performance (response time) of
several of my programs. If anybody has any suggestions as to what
utilities I might use that give a better idea of the I/O use and the like,
I would appreciate the suggestions. Further if anybody knows of any
pitfalls that I should look out for, like file fragmentation, program and
data files on different filesystems etc, please pass them on. The system I
am using is a SUN 3/160 running SUN/OS 3.2, we have 1 Super Eagle disk
partioned into several filesystems, the system is completely isolated from
any others and when tests are run I am the sole user. Please e- mail any
suggestions or pointers (levisonm at qucis.uucp) and if there is enough
intrest I will summarize and post back here.
Mark Levison
(levisonm at qucis.uucp)
Reseacrh Assistant
Computing Science Dept.
Queens University
Kingston Ont.
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list