Sun-Spots-Request@RICE.EDU (William LeFebvre) (08/15/88)
SUN-SPOTS DIGEST Sunday, 14 August 1988 Volume 6 : Issue 183
Today's Topics:
Re: frame buffers on color 3/60's (2)
Re: problems with transcript software
Re: Questions about Uninterruptible Power Supplies
Re: malloc and OS4
Re: Finding out what files your programs are opening
xfig 1.4.1 avaliable
"lprv" shell script
Formatting a non-Sun SCSI disk
cmdtool (CONSOLE) keeps dying in SunOs 4.0
4.3 Dump for suns?
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: 9 Aug 88 05:27:03 GMT
From: mkhaw@teknowledge-vaxc.arpa (Mike Khaw)
Subject: Re: frame buffers on color 3/60's (1)
Reference: v6n174
> 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.
This has to do with the weirdo cgfour frame buffer, which is a dumb memory
device that is 10-bits deep per pixel. I've hacked our local copies of
dumpregion, ferkel and decay so that instead of using "/dev/fb", they call
fbname() (a function I wrote), to figure out the "real name" of the frame
buffer that the desktop is using.
If I had all the varieties of Sun framebuffer h/w in house, I might be
able to make this is 100% correct. As it is, we only have cgfours and
bwtwos, so fbname() returns "/dev/fb", EXCEPT if you're running a b&w
suntools desktop on a machine with a cgfour, in which case it returns
"/dev/bwtwo0" or "/dev/bwtwo1", as appropriate:
Anyway, here's my (I admit it's crude) rendition of fbname():
<--- cut here --->
#! /bin/sh
if test -f fbname.c; then
echo Will not overwrite existing fbname.c
exit 1
fi
sed -e 's/^X//' <<EOF > fbname.c
X/* fbname - returns a string which is the name of the frame buffer */
X
X/* executables that call fbname() need to link with -lsunwindow -lpixrect */
X
X/*
X * 08 aug 1988, Mike Khaw, Teknowledge, Inc.
X */
X
X#include <stdio.h>
X#include <errno.h>
X#include <sys/types.h>
X#include <sys/ioctl.h>
X#include <sys/file.h>
X#include <sun/fbio.h>
X#include <sunwindow/window_hs.h>
X
X char *
Xfbname()
X{
X int fd;
X char windevname[12];
X
X static struct fbgattr attr_buff;
X
X /* should return (NULL) or return ("/dev/fb") replace exit(errno)? */
X
X errno = 0;
X if ((fd = open("/dev/fb", O_RDONLY)) < 0)
X exit(errno);
X
X errno = 0;
X if (ioctl(fd, FBIOGATTR, &attr_buff) < 0)
X if (ioctl(fd, FBIOGTYPE, &attr_buff.fbtype) < 0)
X exit(errno);
X
X if (attr_buff.fbtype.fb_type == FBTYPE_SUN4COLOR &&
X we_getparentwindow(windevname) == 0)
X { /* in suntools on a Prism */
X int winfd;
X
X struct screen screen;
X
X errno = 0;
X if ((winfd = open(windevname)) < 0)
X exit(errno);
X
X win_screenget(winfd, &screen);
X close(winfd);
X
X return (screen.scr_fbname);
X }
X else
X return ("/dev/fb");
X}
EOF
exit 0
<--- cut here --->
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: Tue, 9 Aug 88 08:21:29 EDT
From: gfr%wolfgang@gateway.mitre.org (Glenn Roberts)
Subject: Re: frame buffers on color 3/60's (2)
Reference: v6n174
I haven't worked much with the 3/60 yet but it sounds like its frame
buffer is similar to the 3/110. The 3/110 has 10 bit planes: 8 for color,
one for monochrome, and one as "arbitrator" (decides whether color or
monochrome "shows" on the screen). You can reference the color planes as
/dev/cgfour0 and the monochrome as /dev/bwtwo0 (on the 3/60 I think you
need to reference /dev/bwtwo1 for monochrome).
Chapter 7 of the SunView Programmer's Guide states that "canvases and
graphic subwindows default to using the color plane whenever possible".
Non-graphic tools (e.g. text windows) seem to default to using the
monochrome plane. Thus at any given time you're likely to have a mix,
some tools using the color planes, some using the b&w plane. You can
explicitly control this situation by specifying -8bit_color_only or
-overlay_only (when you start up suntools) to force suntools to
respectively use either the color or monochrome planes exclusively. (BTW:
this is how you can get two copies of suntools running simultaneously: one
in the mono and one in the color planes. Move between them via
'adjacentscreens' or 'switcher'.)
If you invoke suntools with the -overlay_only flag your Sun should behave
just like a monochrome 3/60. Reference /dev/bwtwo1 to access the screen,
for example, a print screen could be invoked via:
screendump -f /dev/bwtwo1 | lpr -v
Hope this is of some help.
- Glenn Roberts, MITRE Corp., McLean VA (703) 883-6820
gfr%wolfgang@gateway.mitre.org
------------------------------
Date: Mon, 8 Aug 88 17:17:08 EST
From: lynxys!jim@ee.ecn.purdue.edu (Jim Wildman)
Subject: Re: problems with transcript software
Reference: v6n160
I can confirm what John Nelson <jtn@potomac.ads.com> submitted about the
footers of Transcript documents being chopped off. We have a 3/160
currently running OS3.4 and Transcript 2.1.
We first noticed the problem when we upgraded to Transcript 2.1. I spent
almost a year being transferred from one service engineer/department at
Sun with this bug!! They didn't really believe me until I sent a hard
copy of one of the Sun manual pages that I ran off with the footer chopped
in half. Moving the page around with the tools provided with Transcript
does not correct the problem. The answer I finally got was that it is
supposed to be fixed in the next release of Transcript (Fall '88???).
Contrary to what Sun told me, the problem occurs regardless of what
version of Laserwriter you are driving. I have demonstrated the problem
with both "Classic" and "Plus" versions of the Apple Laserwriters. The
service engineer I was working with is now always "busy" and does not
return my phone calls (convenient for him).
Jim Wildman
Lynxys, Inc
{ihnp4|iuvax|decvax}!pur-ee!lynxys!jim
PS What do you do when the person who is supposed to help ignores you??
------------------------------
Date: Mon, 08 Aug 88 17:14:20 PDT
From: Brent Chapman <capmkt!brent@cogsci.berkeley.edu>
Subject: Re: Questions about Uninterruptible Power Supplies
Reference: v6n163
In v6n163, Kevin C. Brown (kcb@macaw.jhuapl.edu) writes:
# Question: Does anyone know how to interface an UPS to a Sun so that when
# the UPS detects a power outage it signals the Sun to run a shutdown
# routine?
We have had wonderful luck with a unit from Best Power Technologies
(Necedah, WI; phone 800/356-5794 or 608/565-7200). It's been powering our
3/280 and 6 of our standalone 3/50 and 3/60 workstations for over a year
now, through several real and simulated (i.e., I popped the circuit
breaker by hand) power failures.
The unit is simply wonderful. Our 5 KVA unit will deliver at full
capacity for 15 minutes, and I can increase the runtime simply by adding
more batteries. It is small (about the size of a Sun deskside unit),
quiet, and cool. The unit is micro-processor controlled, and has a very
extensive set of monitoring and logging capabilities. Better yet, it has
an RS-232 port for monitoring and control. They have software for UNIX
systems which will cause automatic graceful shutdowns when run-time
remaining drops below a limit you specify; that way, you can ride out
power outages of less than the capacity of the unit, but still
automatically do a graceful shutdown when you've got only a few minutes of
power remaining.
The people at Best are wonderful, too. When we were considering UPS
units, their sales people were very good about getting me the information
and help that I needed, without being overly pushy to sell me one. Their
technical support people are very well trained, and you get excellent
turnaround time on service calls (I haven't had any problems with the
unit, but I've had them in for routine maintenance, and I've called them
about some puzzling things that showed up in the alarm and usage logs the
unit keeps).
For your 3/110 system, I would guess that you would need a 1000 or 1500 VA
unit (your Sun tech rep should be able to tell you how much power your
particular configuration draws). Best's 1000 VA unit runs for 30 minutes
at full load, and lists (as of 2/1/88; that's the latest price list I
have) at $2,845; the 1500 VA unit runs for 20 minutes at full load, and
lists at $3,795.
I have no relationship to Best other than as a very satisfied customer.
-Brent
--
Brent Chapman Capital Market Technology, Inc.
Computer Operations Manager 1995 University Ave., Suite 390
brent@capmkt.com Berkeley, CA 94704
{lll-tis,uunet}!capmkt!brent Phone: 415/540-6400
------------------------------
Date: Mon, 8 Aug 88 17:39:48 EDT
From: reg%lti.UUCP@bu-it.bu.edu (Rick Genter x18)
Subject: Re: malloc and OS4
Reference: v6n174
Submitted for your approval (do-dee-do-do do-dee-do-do :-):
> 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();
There is a call to getchar() between the two malloc() calls. This is the
first reference to the file stdin. Therefore, the buffer for stdin is
being malloc'd. Is it possible that this is screwing up the heap such
that malloc can not reuse the 10M space?
- reg
[[ That's a pretty good guess. I thought I had duplicated the problem
before, but now I cannot. One might want to put a getchar() before the
first malloc() just to see if it makes a difference. --wnl ]]
------------------------------
Date: Mon, 8 Aug 88 20:35:16 EDT
From: Fuat C. Baran <fuat@cunixc.cc.columbia.edu>
Subject: Re: Finding out what files your programs are opening
Reference: v6n168
ted@braggvax.arpa writes:
>If anyone knows a better way, please tell me but:
[Stuff about hacking the kernel open(2) and stat(2) routines to print
out the filename if a kernel variable is on deleted.]
How about using trace(1) and look at all opens? Below is the output
created by a
trace /bin/cat /etc/motd
open ("/usr/lib/ld.so", 0, 010000) = 3
read (3, "".., 32) = 32
mmap (0, 40960, 5, 0x80000002, 3, 0) = 0xf77c0000
mmap (0xf77c8000, 8192, 7, 0x80000012, 3, 32768) = 0xf77c8000
open ("/dev/zero", 0, 07) = 4
close (3) = 0
getrlimit (3, 0xf7fff7f8) = 0
mmap (0xf7800000, 8192, 3, 0x80000012, 4, 0) = 0xf7800000
getuid () = 278
getgid () = 306
open ("/etc/ld.so.cache", 0, 010000) = 3
fstat (3, 0xf7fff680) = 0
mmap (0, 8192, 1, 0x80000001, 3, 0) = 0xf7780000
close (3) = 0
open ("/usr/lib/libc.so.1.1", 0, 0) = 3
read (3, "".., 32) = 32
mmap (0, 327692, 5, 0x80000002, 3, 0) = 0xf7700000
mmap (0xf7748000, 32768, 7, 0x80000012, 3, 294912) = 0xf7748000
close (3) = 0
close (4) = 0
fstat (1, 0xf7fff958) = 0
open ("/etc/motd", 0, 0666) = 3
fstat (3, 0xf7fff958) = 0
mmap (0, 439, 1, 0x80000001, 3, 0) = 0xf76c0000
write (1, "SunOS Release 4.0 (NOALM32) #3: ".., 439) = 439
munmap (0xf76c0000, 439) = 0
close (3) = 0
close (0) = 0
close (1) = 0
close (2) = 0
exit (0) = ?
Unless I misunderstood your problem, this should be sufficient.
[[ That's funny. When I type "man trace" on my Sun 3 running version 3.5
of the operating system, it tells me that there is "no manual entry for
trace." Ted's patch was for a 3.5 system. I don't think he has a 4.0
system, and was not aware of the existence of "trace" under 4.0. --wnl ]]
--Fuat
ARPANET: fuat@columbia.edu U.S. MAIL: Columbia University
BITNET: fuat@cunixc.cc.columbia.edu Center for Computing Activities
USENET: ...!rutgers!columbia!cunixc!fuat 712 Watson Labs, 612 W115th St.
PHONE: (212) 280-5128 New York, NY 10025
------------------------------
Date: Mon, 08 Aug 88 19:05:36 -0400
From: Ken Yap <ken@cs.rochester.edu>
Subject: xfig 1.4.1 avaliable
xfig, an X11 version of fig, is available for ftp from
cayuga.cs.rochester.edu in xfig.tar.Z. It is a dual version and can be
compiled for SunView by editing the Makefile.
By the time this note appears in Sun-Spots, it should also be on
expo.lcs.mit.edu and in comp.sources.x.
The reason I am posting this to Sun-Spots when xfig is now machine
independent is to encourage people who have been thinking of hacking the
SunView version to work on this common version. I would hate to see 23
incompatibly hacked versions milling around the net.
This version (1.4.1) incorporates Frank Schmuck's LaTeX mode enhancements
but not Wayne Mesard's bitmap writing routine. Anyway that should be
trivial to merge.
Ken
------------------------------
Date: Mon, 8 Aug 88 22:15:31 EDT
From: Skip Montanaro <steinmetz!montnaro@uunet.uu.net>
Subject: "lprv" shell script
Reference: v6n171
If v6n171 I enclosed a shell script called lprv that allows me to print on
the VAX line printer from my Sun. WNL appended the note:
[[ Warning: it is a korn shell script! ... --wnl ]]
The only reason it's a korn shell script is that (presumably) ksh is
faster than sh, due to the builtin test command. You can safely replace
the first line with
#!/bin/sh
I only recently added the /usr/local/bin/ksh headline. Sorry for any
misunderstanding.
Skip Montanaro (montanaro@sprite.steinmetz.ge.com, montanaro@ge-crd.arpa)
[[ Oh! Well, when I saw the "ksh" in the first line, I looked closer at
the file. When I saw the function definitions (such as "help () {") I
assumed that the file would only work with the korn shell. I didn't
realize until just now that the Bourne shell distributed by Sun had that
capability. 4.2BSD didn't, did it? --wnl ]]
------------------------------
Date: Tue, 9 Aug 88 10:16:10 EDT
From: dupuy@douglass.cs.columbia.edu (Alexander Dupuy)
Subject: Formatting a non-Sun SCSI disk
If you haven't reconfigured (unplugged, moved, whatever) your disk since
you upgraded to 3.4, this doesn't apply. However, your problem does sound
somewhat like one which occurred here. It seems that formatting of some
SCSI disks is done by a special control signal, and does not involve the
data signals at all. Writing labels and bad track info, on the other
hand, does require a working data connection. A user here had incorrectly
connected the data cables, and the symptoms were just as you describe - a
normal format, up to the point where it tries to write labels onto the
disk. Hope this helps.
@alex
--
inet: dupuy@columbia.edu
uucp: ...!rutgers!columbia!dupuy
------------------------------
Date: 8 Aug 88 22:26:23 GMT
From: mcvax!cs.exeter.ac.uk!jme@uunet.uu.net
Subject: cmdtool (CONSOLE) keeps dying in SunOs 4.0
I am creating a window application using SunView and C. Currently I have a
cmdtool(CONSOLE), a shelltool, a performance meter and an emacstool
running. From time to time I am also testing my application. Sometimes my
CONSOLE window dies without any error messages what so ever. It is a
nuisance, but you can always starta new console. Are there any
explanation to this phenomena?
Thanks,
Jonas
------------------------------
Date: Mon, 08 Aug 88 17:20:34 -0400
From: Andy Wilcox <ajw@manatee.cis.ufl.edu>
Subject: 4.3 Dump for suns?
Anybody got the diffs handy, or know where they can be ftp'ed?
Thanks,
--Andy Wilcox
(ajw@manatee.cis.ufl.edu)
------------------------------
End of SUN-Spots Digest
***********************