HDTenEightyP/NetNews huggingface dataset:
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi,comp.benchmarks,comp.dcom.lans.ethernet
Subject: Re: How can I measure CPU-time and Network traffic time ?
Date: 28 Jul 92 03:01:19 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <1992Jul27.202416.6297@cbnewsl.cb.att.com> sdo@cbnewsl.cb.att.com (scott.orshan) writes:

| In article <nnbjkh8@zuni.esd.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes:
| >In <1992Jul24.075446.23229@news.uni-stuttgart.de> wnkretz@ikesg1.energietechnik.uni-stuttgart.de (Oliver Kretzschmar) writes:
| >|    who can tell me, how I can measure the CPU time of a program
| >|    or a routine inside a program. Exists there any other possibilities
| >|    as with time ? Does anybody know, how I can measure network
| >|    transfer time and other datas of network traffic in distributed
| >|    programsystems developed with SUN RPC's on SGI ? Please mail me
| >|    your informations !
| >
| >See 'man pixie prof ftimer gettimeofday time times'.  One or more
| >of those should help.
| 
| This may not apply to the SGI machines, but some machines (Sequent and
| Pyramid at least) provide a microsecond resolution timer/counter
| that is accessible via a user level instruction or memory reference,
| thus avoiding the system call overhead and lack of resolution of the
| system calls.  (See GETUSCLK() on the Sequent).

We provide this only on the IP5 class machines with IO3 boards currently;
see master.d/mem.  Other machines will have it in the future, although
they will likely be at different frequencies.  There is a 24 bit counter
on the IP12 class machines, but it is in the same pages as some other
'dangerous' registers, so we haven't made it available.

The r4000 also has a freerunning counter at the CPU frequency, but it
can only be accessed in system mode, so it would take a system call
to get at it, which is too much overhead for some jobs.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
Newsgroups: comp.sys.sgi
From: langer@monashee.sfu.ca (Steve Langer)
Subject: Re: lp/lpr printer hacks
Keywords: lp lpr
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Wed, 29 Jul 1992 22:02:36 GMT

In article <dittrich.712439536@milton> dittrich@milton.u.washington.edu (Dave Dittrich) writes:
>langer@monashee.sfu.ca (Steve Langer) writes:
>
>>  What I did is to create a dummy user, called "printer", who has /usr/bin/lp
>>for a shell, and no password. (Please tell me if this is a horrible
>>security risk!) Then I can print from a remote machine that doesn't have lp
>>by running
>
>Yes it is.  And what is more, you have now told everyone on the net that
>your machine can be logged into!  Fix it ASAP!

  Well, I didn't post from the machine involved, naturally. I also put a
password on the account, which makes it require an .rhosts file. Is this
still a problem?  This method seemed much simpler than the various
alternatives.

           -- Steve
From: TKIRKMAN%TINY@msus1.msus.edu (Tom Kirkman)
Newsgroups: comp.sys.sgi
Subject: pcnfs printing to SGI-attached printers?
Date: 22 Jul 92 16:34:05 GMT


I've ftp from sgi.com pcnfsd which has worked fine for serving the SGI-attached
disks to pcs, but I've been unable to configure the SGI to allow pcs to
print on SGI-attached printers.  Since pcnfsd is not supported by SGI I was
not too surprised that TAC could provide no help.  Can anybody on the net
provide guidance on printing to SGI-attached printers via pcnfsd?

Thanks,

Tom Kirkman, Dept of Physics, St. John's University, Collegeville, MN
From: tomw@orac.esd.sgi.com (Tom Weinstein)
Newsgroups: comp.sys.sgi
Subject: Re: 24 bit color under X11 on Personal IRIS
Date: 31 Jul 92 00:14:04 GMT
Reply-To: tomw@esd.sgi.com
Organization: Silicon Graphics Inc.

In article <1992Jul30.070038.17110@bruce.cs.monash.edu.au>, alanf@bruce.cs.monash.edu.au writes:

> Since we have 24bit colour displays on some of our IRIS's I thought it would
> be easy to access the display at this resolution using Xlib TrueColor or
> DirectColor.  Unfortunatly it looks as if the version of Xlib or the X server
> we have (came with IRIX 4.0.x) does not support 24bit colour.

> The Xlib call XDisplayPlanes returns 8 and it looks like that's all it
> supports.

> Does anyone know if I am doing something wrong.  Is the problem with Xlib
> or with the server? (or how can I find out?).

The XDisplayPlanes() function is just a wrapper around the macro
DisplayPlanes().  All it does is return the depth of the root window.
If you use xdpyinfo, I'm sure you'll find that you have a 24 bit deep
visual available.

--
Love is a conveyor belt of   |   Tom Weinstein  tomw@orac.esd.sgi.com
warmth  -- Jackie Chan       |                  tomw@bears.ucsb.edu
Newsgroups: comp.sys.sgi,fj.sys.sgi,comp.graphics
From: wnkretz@ikesg1.energietechnik.uni-stuttgart.de (Oliver Kretzschmar)
Subject: How can I improve records from GENLOCK on a videorecorder ?
Organization: IKE
Date: Thu, 23 Jul 1992 05:34:36 GMT



   Hey,

   we have a 4D/20 with GENLOCK board running IRIX 4.04. We
   transfer a pal-display to a videorecorder and record on this
   computer image sequences, but the result was not so good. When we
   transfer the display directly to the TV, the quality is quite
   good. Have anybody an idea to improve the quality for recording ?
   Please mail me your informations.

   Thank you for your efforts,

       Oliver
-- 
  ______     ______
 /   @@ \   /   @@ \
 \______// \\______/
        I   I          wnkretz@ikesg1.energietechnik.uni-stuttgart.de
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: shadow passwords on Indogo NEEDED NOW.
Date: 29 Jul 92 01:35:36 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <1992Jul28.081456.1004@bacchus.esa.oz.au> hunter@bacchus.esa.oz.au (James Gardiner [Hunter]) writes:
| I run a public access machine and am planning on putting an Indigo
| in its place.  Due to the fact that most anyone can get access
| to this machine, I NEED shadow passwords.
| In the past users have cracked passwords and tried to hack my machine.
| The best defence is to make it hard for them to get untracable access.
| Shodow passwords is a BIG part in this.
| I am amazed that IRIX does not have this option.
| Has anyone got any suggestion on what I should do?
| 
| If IRIX is suppose to be SVR4 by the end of the year does this mean
| it will have C2 security?  I am sure SVR4 has that.

I don't think anyone from SGI has ever made a commitment to SVR4 by
the end of the year.  SVR4 doesn't have C2, although it may have
most of what is necessary should someone decide to get it certified.

I'm not sure if we will include shadow passwords in our SVR4 port or
not, although many folks have asked for not (I'm not saying we won't,
just that I don't know).
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
From: johnston@hertz.ee.washington.edu ( Craig Johnston 8838249 )
Newsgroups: comp.sys.sgi
Subject: Will R4K Indigo allow for user programing of the audio DSP?
Date: 28 Jul 92 14:35:35 GMT
Organization: University of Washington, Seattle


	As I understand it, the Indigo's MC56001 DSP controls the audio and
serial I/O.  However, it doesn't appear that a user application can tap that
resource to do their own bidding.  Things that come to mind include processing
waveforms from test equipment, special serial protocols, audio compression.
Is there any plan to make this processor user programable in future machines?
Why not in these machines?  Just curious, It would open up a number of other
uses for a machine like the Indigo.

	Craig Johnston         as          johnston@maxwell.ee.washington.edu
Newsgroups: comp.sys.sgi
From: jhall@convex.com (Jon Hall)
Subject: Using more than 255 minor devices
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
Distribution: usa
Date: Wed, 22 Jul 1992 18:55:01 GMT
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

I have an optical jukebox which has 144 shelves with 2 sided platters, so I
need to have 288 minor devices. Since the max number of minor devices is 255
(2^8), I decided to use consecutive major numbers.

To get the first device sysgened in, I added a "USE: jb" entry to the system 
file, added a jb entry to the master.d directory, and then a "jb.o" driver 
module to the boot directory, and everything worked fine. But then I tried, 
adding a jb1 entry (with major # + 1) to the master.d directory, but the system
still won't recognize that major number. So what else do I need to do??

Please post the answer and don't send email

Thanks!!

Newsgroups: comp.sys.sgi
From: portuesi@tweezers.esd.sgi.com (Michael Portuesi)
Subject: Re: Memory upgrades for R4000 Indigos
Organization: Silicon Graphics Inc.
Date: Wed, 22 Jul 92 17:10:26 GMT

In article <1992Jul22.160210.9849@eagle.lerc.nasa.gov>,
steve@pitacat.lerc.nasa.gov (Steven H. Izen) writes:
|> In article <1992Jul21.064111.1619@microunity.com>,
|> jsw@microunity.com (Jeff Weinstein) writes:
|> 
|> >  Actually neither is true.  The main problem with the r3k
|> > indigo was that there just wasn't room on the CPU board
|> > to put the chips that did the memory interleaving/control,
|> > so they had to go on the back of the simms. It was
|> > definitely not a conspiracy on the part of SGI marketing
|> > to squeeze more money out of customers.  The engineers
|> > sincerely felt bad to have to make that sort of engineering
|> > trade-off, and vowed never to do it again.  They have lived
|> > up to it in the new r4k indigo.
|> 
|> This all makes sense for the inidgo, but does the same argument
|> apply to the 4D/35 as well?


It does, but since there are no plans to produce an R4000
upgrade for the Personal Iris line, the point is moot.

Before the inevitable flames about "abandoning" the
Personal Iris line arrive, let me point out that
producing the 4D/35 was very difficult from both an
engineering and manufacturing standpoint.  The R3000A
in the 4D/35 worked only with some unconventional hacks
to meet cooling requirements, and the electronics module
had to be redesigned to fit in the chassis.  An R4000
upgrade would be frought with even more engineeering
problems.  It would be difficult and costly for us to
manufacture.

I'm sure Dave Olson could provide more details about the
difficulties involved, but I just wanted to point out
that we aren't trying to screw our Personal Iris
customers, or try to "milk more money" out of them by
"forcing" them to upgrade to the Indigo.  The PI design
has simply reached the end of its life, from an
engineering and manufacturing standpoint.

-- 
Michael Portuesi   Silicon Graphics, Inc.   portuesi@sgi.com
Newsgroups: comp.sys.sgi
From: olson@anchor.esd.sgi.com (Dave Olson)
Subject: Re: Memory upgrades for R4000 Indigos
Organization:  Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 23 Jul 92 07:53:06 GMT

In <grl.711852048@groucho> grl@brb.dmt.csiro.au (Greg Lehmann) writes:
| Are the SIMMs the same as used in the new Crimson? How many pins do they
| have? Are there any special rules about installing them like having to do
| it in pairs?

No, the SIMMs are not the same as Crimson.  The SIMMs are 36 bits
wide, and have to be installed in multiples of 4 (that is, you have
to fill a bank at a time with SIMMs of the same size).

I'd have to go count the number of contacts; I don't know off the
top of my head.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
Newsgroups: comp.sys.sgi
From: olson@anchor.esd.sgi.com (Dave Olson)
Subject: Re: How can I do an automatic backup?
Organization:  Silicon Graphics, Inc.  Mountain View, CA
Date: Wed, 29 Jul 92 01:40:55 GMT

In <22828@oasys.dt.navy.mil> paraska@oasys.dt.navy.mil (Pete Paraska) writes:
| I have a 4-mm DAT tape drive on a 4D/30 PI.  I wish to have the backup
| program do a backup in the evening without any user intervention.  I
| figure I should put something in the crontab script, but don't know
| how to go about doing this.  Any help (example script) would be appreciated.

Several have been posted to this group in the past couple of months,
try the archives to see if you can find them.

| I ran the backup script from the toolbox on a new out-of-the-box DAT
| tape to see if things were working when I recently installed the tape
| drive.  When I executed the backup tool, the tape drive spun for
| a while with the list of files in the backup window stalled.  After
| a while, the tape stopped spinning and a message box appeared saying
| that tape 1 was full and to insert tape 2.  Since only about 20K worth
| of files had scrolled by in the backup window, I knew that tape 1 was
| not full.  So I just hit the "accept" button to overwrite tape
| 1.  I don't know if this backup was successful.

I'll bet if you look in /usr/adm/SYSLOG (or in the console window), you
will see some kind of SCSI error reported.  Probably the drive isn't
seated correctly, or you have some other SCSI cabling/termination problems,
but without the errors, it is hard to tell.

| What bothers me is that user intervention was needed to do the backup,
| i.e., I had to fool the program into thinking I had inserted tape 2.

Fool the program?   What do you mean by that?  If the tape really had
reached the end, and you 'fooled' the program, you would be overwriting
the data on the first tape with what should be on the second.

| If this is the way the backup script is going to work with the DAT drive,
| I don't think my plans for an automatic unattended backup will be fruitful.

As long as what you want to backup actually fits on a single tape, and
you have the hardware problems fixed, there should be no problem...
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
Newsgroups: comp.sys.sgi
From: olson@anchor.esd.sgi.com (Dave Olson)
Subject: Re: Problem with Tape Backup -- blocksize mismatch
Organization:  Silicon Graphics, Inc.  Mountain View, CA
Date: Sun, 26 Jul 92 20:37:09 GMT

In <1992Jul26.123233.29447@ringer.cs.utsa.edu> senseman@ricky.brainlab.utsa.edu (David M. Senseman) writes:

The problem is probably you are defaulting to /dev/tape for mt and List_tape,
and for some reason that probably is a link to the fixed block size device,
although our standard link for DAT is the variable block size, non-byte
swapping device, but in the script where you make the tape, you are using
variable blocksize, byte swapping device.  bru will software byte swap
for you after detecting it, but that means you are byte swapping twice,
which is sort of silly.  Anyway, check to see what /dev/{nr}tape are
linked to, and I would use /dev/rmt/tps0d#nrnsv if you want to
explictly specify it.

It could also be that the links are right, but the blocksizes were
different.  It appears that you made the tape with b40 or b20k, judging
from the error message, and List_tape uses the bru default of b20,
although your script doesn't seem to be specifying a block size (are
you sure that is actually the script used?)

You might also try 'mt blksize'
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
From: jamison@yuma.acns.colostate.edu (Jamie Gulden)
Newsgroups: comp.sys.sgi
Subject: HELP: GL question (about swinopen)
Date: 21 Jul 92 20:28:06 GMT
Distribution: usa
Organization: Colorado State University, Fort Collins, CO  80523


Sorry to be begging for help but this program is supposed to be
running at the Showcase Expo next week (yeah I know...)


When you open a sub window with swinopen is its configuration
completely independent from its parent?

What I'm trying to do: open the parent window as RGB, singlebuffered
to use for a menu area.  Open a sub-window as RGB, doublebuffered,
z-buffered, and with different viewing matricies.  Is this supposed
to work?   It doesn't seem to be (for me at least)


here's the code I'm trying to use:

   /* open and initialize main (menu) window */
   prefposition((long)100,(long)1100,(long)100,(long)949);
   main_window = winopen("ShowCase");
   RGBmode();
   drawmode( NORMALDRAW );
   gconfig();

   ortho2( -0.5, 1001 - 0.5, -0.5, 850 - 0.5 );
   viewport( 0, 1001 - 1, 0, 850 - 1);
   cpack(0xff404040);
   clear();
   linewidth( 3 );
   qenter( REDRAW, main_window );
   gflush();

   /* open and initialize graphics window */
   gr_window = swinopen( main_window );
   winposition(200,1000,0,800);
   RGBmode();
   doublebuffer();
   zbuffer(TRUE);
   drawmode( NORMALDRAW );
   glcompat(GLC_ZRANGEMAP, 0);
   gconfig();
   /* projection and viewing is set elsewhere but different from 
    * the main window */

Thanks for any help, Jamie
jamison@vangogh.vis.colostate.edu
CSU Computer Visualization Laboratory  (303)491-1578
Newsgroups: comp.sys.sgi
Subject: Re: nntp porting problem
From: doelz@comp.bioz.unibas.ch (Reinhard Doelz)
Date: Fri, 31 Jul 1992 06:23:56 GMT
Reply-To: doelz@urz.unibas.ch
Organization: EMBnet Switzerland [BASEL]   
Keywords: nntp sgi

In article <reed.712507835@teal>, reed@teal.csn.org (Jim Reed) writes:
|> I have been trying to get nntp.1.5.11 ported to a 340/4d running 4.0.1, so far without luck.  The program compiles fine now, but will hang in the middle of the program server/timer.c.  
|> 

It worked for me if I inserted a #undef in the beginning of timer.c: 
/*
 * Machinery to run routines off timers.
 */
#include "common.h"
#undef USG
#ifdef TIMERS

Forgive me if this is a pragmatic hack. Any attempts of collegues to convince
me that the timer.c is correct failed - it really bombs out while compiling
the standard code. 

regards 
Reinhard 


-- 
+----------------------------------+-------------------------------------+
|    Dr. Reinhard Doelz            | RFC     doelz@urz.unibas.ch         |
|      Biocomputing                | DECNET  20579::48130::doelz         |
|Biozentrum der Universitaet       | X25     022846211142036::doelz      |
|   Klingelbergstrasse 70          | FAX     x41 61 261- 6760 or 267- 2078     
|     CH 4056 Basel                | TEL     x41 61 267- 2076 or 2247    |   
+------------- bioftp.unibas.ch is the SWISS EMBnet node ----------------+
               -----------------------------------------
Newsgroups: comp.sys.sgi
From: wollman@trantor.emba.uvm.edu (Garrett Wollman)
Subject: Debugging filesystem question...
Organization: University of Vermont, EMBA Computer Facility
Date: Wed, 29 Jul 1992 14:27:23 GMT

Say I am debugging a program, and have included fork() in the list of
system calls to stop at.  Furthermore, I have set the current process
with both PR_FORK (child process inherits tracing flags across a fork)
and PR_RLC (run on last close).  The question is, will the child
process stop upon exit from fork() like the parent will, and if so,
what do I have to do to get it run free after it does so?

TIA.

-GAWollman

-- 
   Garrett A. Wollman  = wollman@emba.uvm.edu = UVM is welcome to my opinions
                       =    uvm-gen!wollman   =
   That's what being alive is all about.  No deity, no higher goal
   exists, than to bring joy to another person.    - Elf Sternberg
Newsgroups: comp.sys.sgi
From: cohen@lindsay.psychiatry.uiowa.edu
Subject: Re: 24 bit color under X11 on Personal IRIS
Date: Fri, 31 Jul 1992 15:28:21 GMT
Organization: University of Iowa

In article <TOMW.92Jul30171404@orac.esd.sgi.com> tomw@orac.esd.sgi.com (Tom
Weinstein) writes:
>In article <1992Jul30.070038.17110@bruce.cs.monash.edu.au>,
alanf@bruce.cs.monash.edu.au writes:
>
>> Since we have 24bit colour displays on some of our IRIS's I thought it would
>> be easy to access the display at this resolution using Xlib TrueColor or
>> DirectColor.  Unfortunatly it looks as if the version of Xlib or the X
server
>> we have (came with IRIX 4.0.x) does not support 24bit colour.
>
>> The Xlib call XDisplayPlanes returns 8 and it looks like that's all it
>> supports.
>
>> Does anyone know if I am doing something wrong.  Is the problem with Xlib
>> or with the server? (or how can I find out?).
>
>The XDisplayPlanes() function is just a wrapper around the macro
>DisplayPlanes().  All it does is return the depth of the root window.
>If you use xdpyinfo, I'm sure you'll find that you have a 24 bit deep
>visual available.

Are you sure about that?  I thought that the Personal Irises (4D20G) only had 8
bits of visual to start with (and end with).  If there is a way to get 24 bit
color out of a 4D20, I would appreciate a pointer on how to get it.

thanks

Newsgroups: comp.sys.sgi
From: artibee@noangel.wpd.sgi.com (Mary Artibee)
Subject: Re: Serial ports on IRIS
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Tue, 28 Jul 1992 23:07:35 GMT

> WHAT is the difference between the serial port devices -- ttym, ttyd, ttyf?

You might want to read duart(7) which says, in part:

     By opening either the ttyd*, ttym*, or ttyf* device of a port, different
     hardware signals are supported.  Typically, ttyd* is used for direct
     connect devices such as most terminals; ttym* is used for devices that
     use modem control such as modems; and ttyf* is used for devices that
     understand hardware flow control such as most printers.  See serial(7)
     and the chapter "Terminals, Modems, and Dumb Printers" in the IRIS-4D
     System Administrator's Guide for detailed information on supported
     signals.

	...

SEE ALSO
     stty(1), serial(7), termio(7), keyboard(7), cdsio(7), system(4)


Hope this helps.

/Mary Artibee, artibee@sgi.com
From: senseman@ricky.brainlab.utsa.edu (David M. Senseman)
Newsgroups: comp.sys.sgi
Subject: Re: Problem with Tape Backup -- blocksize mismatch
Date: 27 Jul 92 02:26:00 GMT
Organization: University of Texas at San Antonio

In article <npqdqq0@zuni.esd.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes:
>In <1992Jul26.123233.29447@ringer.cs.utsa.edu> senseman@ricky.brainlab.utsa.edu (David M. Senseman) writes:
>
>The problem is probably you are defaulting to /dev/tape for mt and List_tape,
>and for some reason that probably is a link to the fixed block size device,
>although our standard link for DAT is the variable block size, non-byte
>swapping device, but in the script where you make the tape, you are using
>variable blocksize, byte swapping device.  bru will software byte swap
>for you after detecting it, but that means you are byte swapping twice,
>which is sort of silly.  Anyway, check to see what /dev/{nr}tape are
>linked to, and I would use /dev/rmt/tps0d#nrnsv if you want to
>explictly specify it.
>

I will confess that we have had some problems with links in the
past since this machine also has a 1/4" Archive Viper (150 MB QIC)
attached and we have done a number of links between the various
drivers and drives. What is the best driver for the Viper? 

BTW, this is probably a stupid question, but what is the primary
difference between the drivers in /dev/mt/tps* and in /dev/rmt/tps* -- 
when do you use "mt" and when do you use "rmt"?

Thanks :)
-- 
"Is this the party to   |  David M. Senseman  (senseman@lonestar.utsa.edu)
 whom I am speaking?"   |  Brain Research Laboratory
          --Ernestine   |  The University of Texas at San Antonio