HDTenEightyP/NetNews huggingface dataset:
From: dsg@blackbird.mitre.org (David S. Goldberg)
Subject: Re: lint doesn't recognize '#' ansi operator
Organization: The Mitre Corp., Bedford, MA.
Date: Thu, 17 Dec 1992 13:54:43 GMT


>>>>> In article <1992Dec17.102241.12183@itnsg1.cineca.it>,
>>>>> root@itnsg1.cineca.it (Valter Cavecchia) writes:

Valter> This is not a bug, lint doesn't recognize the # ansi
Valter> "tokenizer" because it actually uses "cpp" and not "acpp"
Valter> (lint ignores -ansi keywords).  This is really annoying...  Is
Valter> there any fix to this?

I don't have a true fix, but I've been annoyed by this too.  My
solution (I call it a kludge) has been to preprocess the file with
acpp, redirecting to another file, and then running lint on that
second file.  It's not as nice as having lint use acpp directly
because line numbers don't always match up, but it does help somewhat.

--
Dave Goldberg                      UNIX Systems Programmer/Administrator
Post: The Mitre Corporation MS B020 202 Burlington Rd. Bedford, MA 01730
Phone: 617-271-2460
Domain: dsg@mbunix.mitre.org  UUCP: {your neighborhood}!linus!mbunix!dsg 

Newsgroups: comp.sys.sgi.bugs,comp.sys.sgi.admin
From: dwong@sgi.com (David Wong)
Subject: Re: Ethernet bug in 4.0.5F indigos
Organization: Silicon Graphics, Inc.
Date: Thu, 17 Dec 92 19:17:37 GMT

In article <BzEs7E.CJ1@wm.estec.esa.nl> guy@wmsg02.wm.estec.esa.nl (Guy Brooker) writes:
>In article <1992Dec16.221212.11863@umbc3.umbc.edu>, dave@umbc8.umbc.edu (David A Freeman) writes:
> > Hello,
> > 	I noticed that in 4.0.5F, in the file /usr/sysgen/master.d/if_ec2
> > the value of the ec_rcvinit_delay variable is 13    In 4.0.5 the value 
> > was 13333.  I checked with SGI and found that the correct value is 13333
> > for all 4.0.X software. All of our r4000 4.0.5F systems and the distribution 
> > media that we have received have the variable set to 13. 
> > 
>
>
>I checked my file after reading your note, as I also have recently installed 4.0.5F. I was surprised to find that not only this entry was wrong but also the value of ec_oflow_limit. This was an error in 4.0.5(A), corrected by a release
>notes errata. THERE WAS NO SUCH ERRATA with my 4.0.5F which came with the
>indigo Video Board. I had assumed therefore that the error had been fixed, 
>aparently NOT.
>
>Whats going on SGI ?? Are there other bugs from previous releases that must	still be fixed manually ? How come old bugs creep back in ???
>
>To summarise, the if_ec2 that comes with 4.0.5F looks like this 
>
>*#ident "$Revision: 1.7 $"
>*
>* eh - SGI Hollywood/Magnum ethernet driver
>*
>*FLAG	PREFIX	SOFT	#DEV	DEPENDENCIES
>-	if_ec	-	-	bsd
>$$$
>int ec_rcvint_delay = 13;	/* delay * 30ns to recv intrpt == .4ms */
>int ec_rbuf_num = 250;		/* num of buffers to allocate to enet recv chain */
>int ec_oflow_limit = 2;		/* exceed limit of oflows/per secs => promsc mode*/
>int ec_oflow_period = 30;	/* number of seconds per oflow period */
>int ec_promisc_time = 3600;	/* number of seconds to stay in promisc mode */
>
>and it SHOULD look like this, if the errata to 4.0.5 still stands...
>
>*#ident "$Revision: 1.7 $"
>*
>* eh - SGI Hollywood/Magnum ethernet driver
>*
>*FLAG	PREFIX	SOFT	#DEV	DEPENDENCIES
>-	if_ec	-	-	bsd
>$$$
>int ec_rcvint_delay = 13333;	/* delay * 30ns to recv intrpt == .4ms */
>int ec_rbuf_num = 250;		/* num of buffers to allocate to enet recv chain */
>int ec_oflow_limit = 10000;	/* exceed limit of oflows/per secs => promsc mode*/

the errata is for people running 4DDN such that the interface won't
switch to promiscuous mode.

>int ec_oflow_period = 30;	/* number of seconds per oflow period */
>int ec_promisc_time = 3600;	/* number of seconds to stay in promisc mode */
>
>I have had some problems with my ethernet since the new installation, and since
>changing to above they seem so far to have gone completely...

what sort of problem ?

>
>Guy
>
>-- 
>
>-------------------------------------        	Guy Brooker
>Internet: guy@wm.estec.esa.nl        		European Space Research and
>	  guy@wmsg02.dnet.estec.esa.nl		Technology Centre (ESTEC)
>	  gbrooker@estec.esa.nl
>Bitnet  : gbrooker@estec.bitnet		SPAN    : ESTERS::GUY
>Phone	: +31-1719-83611		Fax	: +31-1719-85617
>Mail	: ESTEC JW/WMS, Keplerlaan 1, 2200AG NOORDWIJK, The Netherlands
From: lau@sunset.ai.sri.com (Stephen Lau)
Newsgroups: comp.sys.sgi.bugs
Subject: Venice (Reality Engine) Graphics Panics
Date: 18 Dec 92 18:29:28 GMT
Distribution: comp
Organization: SRI International, Menlo Park, CA


I'm running on a 4 processor R3000 Reality Engine in 1600x1200 60HZ 
mode and every once in a while the graphics engine decides to go south
for a while. This usually happens while running a GL program of some
sort. It's not limited to third party or my own software, SGI demos
crash it too. 

Here's a dump I got in the /usr/adm/SYSLOG for a program I wrote which
defined 500 128x128 16 bit (originally 32 bit) textures and rendered
121 textures every frame. The other dumps I get from SGI demos and stuff
look almost exactly the same.

Crazypete is the system name. For those curious, it's a little pond
near Menlo Park.

----------------------------------------------------------------------
Dec 17 16:09:58 crazypete unix: WARNING: venice: vcstage change timed out
Dec 17 16:09:58 crazypete unix: WARNING: venice: lightweight deactivation timed out
Dec 17 16:09:58 crazypete unix: 
Dec 17 16:09:58 crazypete unix: WARNING: venice: idma timed out
Dec 17 16:10:01 crazypete Xsession: lau: fatal IO error 32 (Broken pipe)
Dec 17 16:10:07 crazypete unix: GE0: Venice GE Running... (bvdpuppy-bvd 9208271858 StackSize = 0x24000)
Dec 17 16:10:07 crazypete unix: GE0: dram fifo on - size = 64K
Dec 17 16:16:44 crazypete syslogd: restart
----------------------------------------------------------------------

From here you get you're normal system startup...

Any InSight would be of great help. 

An InSight CD would be nice too. =:) When is the bug disk coming out anyway?

Steve

-------------------------------------------------------------------------------
Stephen Lau                 lau@ai.sri.com| "I'm not sure if you're a 
SRI International                         |  mysterious person or just still
333 Ravenswood Ave., Menlo Park, CA. 94025|  water that doesn't run very deep."
(415) 859-2925              (415) 326-6200|               - Gene Kelly
-------------------------------------------------------------------------------





Newsgroups: comp.sys.sgi.bugs
From: spec01@solomon.technet.sg (Quak Wan Ling)
Subject: Pandora Login Failure
Organization: TECHNET, Singapore
X-Newsreader: TIN [version 1.1 PL8]
Date: Sun, 20 Dec 1992 11:32:39 GMT

I'm presently  using Iris Indigo running on OS 4.0.1
Suddenly one day nobody is able to log into the Indigo
using the pandora screen, even the root user !!!
However, other unix machines(not SGI) are able to rlogin
into the system. I tried using the diagnostic test when
rebooting the system  to check the system. It turns out no
error... Kindly help me out what's wrong with the system ???
Thanks... Pse post ASAP....
From: dwallach@zonker.cs.berkeley.edu (Dan Wallach)
Newsgroups: comp.sys.sgi.bugs
Subject: Re: 4.0.{4,5} blankscreen(FALSE) doesn't reliably unblank screen
Date: 16 Dec 1992 05:36:12 GMT
Organization: University of California, Berkeley
NNTP-Posting-Host: zonker.cs.berkeley.edu

In article <1992Dec14.230140.8608@news2.cis.umn.edu> slevy@noneuclid.geom.umn.edu (Stuart Levy) writes:
>Calling blanktime(0) alone worked under 3.3 and (I think) 4.0.1.
>But, when we upgraded to 4.0.4, it stopped working.  Apparently if the
>display was already blanked, blanktime(0) would *not* re-enable it, and we'd
>spend hours recording only to find black video.  So I changed that to
>	blankscreen(FALSE);
>	blanktime(0);
>but this was (sometimes? always?) ineffective -- the screen would remain blank. 

Try using the xset command:

    xset s noblank

--
Dan Wallach               "One of the most attractive features of a Connection
dwallach@cs.berkeley.edu  Machine is the array of blinking lights on the faces
Office#: 510-642-9585     of its cabinet." -- CM Paris Ref. Manual, v6.0, p48.
Newsgroups: comp.sys.sgi.bugs,comp.sys.sgi.admin
From: dave@umbc8.umbc.edu (David A Freeman)
Subject: Ethernet bug in 4.0.5F indigos
Organization: University of Maryland, Baltimore County Campus
Date: Wed, 16 Dec 1992 22:12:12 GMT

Hello,
	I noticed that in 4.0.5F, in the file /usr/sysgen/master.d/if_ec2
the value of the ec_rcvinit_delay variable is 13    In 4.0.5 the value 
was 13333.  I checked with SGI and found that the correct value is 13333
for all 4.0.X software. All of our r4000 4.0.5F systems and the distribution 
media that we have received have the variable set to 13. 



BTW:  I noticed this because of the ongoing problem with the indigo 
ethernet driver.  Sgi has sent us a new driver that will hopefully fix 
the problem with the ethernet driver going off line.



-- 
David Freeman
Systems Programmer			dave@umbc3.umbc.edu
Univ Md Baltimore County		dave@umbc             !bitnet
From: wmc@photon.com (Bill Cornette)
Subject: f77 compiler bug?
Organization: Photon Research Associates, Inc.
X-Newsreader: TIN [version 1.1 PL6]
Date: Tue, 15 Dec 1992 17:05:49 GMT

	I posted this to comp.sys.sgi but it appears to have disappeared with
the creation of these new groups, so here goes again.

	I seem to have encountered a compiler bug for SGI's f77 compiler.
I used the line of code


	QROT=DPROD(TREF,1./TEMP)**XK

where TREF=273.15, TEMP =304., and XK=1.50.  The resulting value for
QROT is identically 0.000000.  TREF, TEMP, and XK are declared REAL and
QROT is declared DOUBLE PRECISION.
	If I break the code up so

	
	QROT=DPROD(TREF,1./TEMP)
        QROT=QROT**XK

I get the right answer of QROT=0.85...

	This looks like a compiler bug to me.  Any comments?
---------------------------------------------------------------------------
---------------------------------------------------------------------------
William M. Cornette         Photon Research Associates, Inc.
(619) 455-9741              9393 Towne Centre Drive, Suite 200
FAX (619) 455-0658          San Diego, California  92121
wmc@photon.com
---------------------------------------------------------------------------
T.A.N.S.T.A.A.F.L.
Newsgroups: comp.sys.sgi.bugs,comp.sys.sgi.admin
From: dwong@sgi.com (David Wong)
Subject: Re: Ethernet bug in 4.0.5F indigos
Organization: Silicon Graphics, Inc.
Date: Thu, 17 Dec 92 18:57:07 GMT

In article <1992Dec17.065406.22404@shannon.ee.wits.ac.za> philip@concave.cs.wits.ac.za (Philip Machanick) writes:
>In article <1992Dec16.221212.11863@umbc3.umbc.edu> David A Freeman,
>dave@umbc8.umbc.edu writes:
>>	I noticed that in 4.0.5F, in the file /usr/sysgen/master.d/if_ec2
>>the value of the ec_rcvinit_delay variable is 13    In 4.0.5 the value 
>>was 13333.  I checked with SGI and found that the correct value is 13333
>>for all 4.0.X software. All of our r4000 4.0.5F systems and the
>distribution 
>>media that we have received have the variable set to 13. 
>
>On our R3000 Indigo running 4.0.1 it is set to 0. Is this something I
>should change?
>--
>Philip Machanick
>Computer Science Dept, Univ of the Witwatersrand, 2050 Wits, South Africa
>philip@concave.cs.wits.ac.za  phone: 27 (11) 716-3759  fax: 339-7965


this value is actually not a big deal.  it tells the HPC how long to wait
before generating an interrupt to the CPU after receiving a packet.  it
doesn't even get used under normal circumstance.  the driver looks at that
variable only when it detects some abnormal condition and switch to
promiscuous mode.  i put the change in by mistake in 4.0.5F.
Newsgroups: comp.sys.sgi.bugs,comp.sys.sgi.admin
From: amys@TheImprov.ncsa.uiuc.edu (Amy Swanson)
Subject: Re: Ethernet bug in 4.0.5F indigos
Organization: University of Illinois at Urbana
Date: Fri, 18 Dec 1992 19:43:03 GMT

In <BzGAyF.HFK@wm.estec.esa.nl> guy@wmsg02.wm.estec.esa.nl (Guy Brooker) writes:

>My machine occasionly lost contact with the NFS server, sometimes breifly, sometimes over extended periods, and allways with the News server breifly as information is requested. 

>Since making the two changes I mentioned, I have not seen these problems.


I was having the same type of problems, as evidenced by the scrolling of  
	NFS server <name> not responding still trying
	NFS server <name> ok"
in my console window and the SYSLOG, as well as the giant pauses as I tried 
to access the NFS mount.  I am running IRIX 4.0.5, too, so I looked at the
/usr/sysgen/master.d/if_ec2 file and found the same thing.  So I changed
the value of int ec_rcvint_delay to 13333 and the value of int ec_oflow_limit
to 10000 (as suggested by the previous post) and haven't seen the NFS 
problems, yet!

So, what gives?  Is this something I should look for and change on all my 
SGI systems?  It seems to make a difference in a heavy NFS-use environment.


Amy


--
=========
Amy K. Swanson
SGI Systems Administrator, NCSA
amys@ncsa.uiuc.edu
From: mmcohen@cats.ucsc.edu (Michael M Cohen)
Newsgroups: comp.sys.sgi.bugs
Subject: Re: 4.0.{4,5} blankscreen(FALSE) doesn't reliably unblank screen
Date: 15 Dec 1992 12:50:41 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: si.ucsc.edu


In article <1992Dec14.230140.8608@news2.cis.umn.edu> slevy@noneuclid.geom.umn.edu (Stuart Levy) writes:
>.....>
>After some frustrating months I stumbled on this workaround (!):
>	blankscreen(TRUE);
>	blankscreen(FALSE);
>	blanktime(0);

for me (4.0.5 vgx),

system('blanktime 0');
blankscreen(0);
... and afterwards ...
system('blanktime 20000');

always works

-- 

======================================================================
=   Dr. Michael M. Cohen                   mmcohen@dewi.ucsc.edu     = 
=   Program in Experimental Psychology     mmcohen@fuzzy.ucsc.edu    =
=   433 Clark Kerr Hall                    408-459-2655 LAB          = 
=   University of California - Santa Cruz  408-459-2700 MSGS         = 
=   Santa Cruz, CA 95064                   408-459-3519 FAX          = 
======================================================================
Newsgroups: comp.sys.sgi.bugs
From: slevy@noneuclid.geom.umn.edu (Stuart Levy)
Subject: 4.0.{4,5} blankscreen(FALSE) doesn't reliably unblank screen
Organization: Geometry Center, University of Minnesota
Date: Mon, 14 Dec 1992 23:01:40 GMT

We sometimes use the console of a VGX Iris here, running 4.0.5,
for single-frame video recording.  The recording software used to call just
	blanktime(0);
at the beginning of a session to ensure that (a) the screen was not blanked
and (b) it would stay that way.  (Since the screen is unviewable while
recording, we'd often run recording jobs remotely, so the console could well
have been idle long enough to go blank.)

Calling blanktime(0) alone worked under 3.3 and (I think) 4.0.1.
But, when we upgraded to 4.0.4, it stopped working.  Apparently if the
display was already blanked, blanktime(0) would *not* re-enable it, and we'd
spend hours recording only to find black video.  So I changed that to
	blankscreen(FALSE);
	blanktime(0);
but this was (sometimes? always?) ineffective -- the screen would remain blank. 

Often we'd then find it impossible to *unblank* the screen -- pounding on the
keyboard had no effect, and we'd have to kill the X server or reboot.
(Yes, /etc/config/system.glGammaVal was intact.)

After some frustrating months I stumbled on this workaround (!):
	blankscreen(TRUE);
	blankscreen(FALSE);
	blanktime(0);

You wouldn't think asking the screen to go blank would be essential to
unblanking it, but so it goes.  Don't know if this always works, but
it sometimes does.

    Stuart Levy, Geometry Center, University of Minnesota
    slevy@geom.umn.edu
From: kevin@tamri.com (Kevin Dalley)
Newsgroups: comp.sys.sgi.bugs
Subject: Re: lint doesn't recognize '#' ansi operator
Date: 18 Dec 92 03:06:40 GMT
	<DSG.92Dec17085443@blackbird.mitre.org>
Reply-To: kevin@tamri.com
Organization: TOSHIBA America MRI, South San Francisco, CA

In article <DSG.92Dec17085443@blackbird.mitre.org>
dsg@blackbird.mitre.org (David S. Goldberg) writes:

> Nntp-Posting-Host: blackbird.mitre.org


>>>>>> In article <1992Dec17.102241.12183@itnsg1.cineca.it>,
>>>>>> root@itnsg1.cineca.it (Valter Cavecchia) writes:

>Valter> This is not a bug, lint doesn't recognize the # ansi
>Valter> "tokenizer" because it actually uses "cpp" and not "acpp"
>Valter> (lint ignores -ansi keywords).  This is really annoying...  Is
>Valter> there any fix to this?

> I don't have a true fix, but I've been annoyed by this too.  My
> solution (I call it a kludge) has been to preprocess the file with
> acpp, redirecting to another file, and then running lint on that
> second file.  It's not as nice as having lint use acpp directly
> because line numbers don't always match up, but it does help somewhat.

Another solution is to "gcc -Wall".  Through in a few other warnings
if you so desire.  gcc gives substantially better warning messages
than either SGI's "cc -fullwarn" or lint.

--
Kevin Dalley
Toshiba America MRI, Inc.
kevin@tamri.com
Newsgroups: comp.sys.sgi.bugs
From: welman@cs.sfu.ca (Chris Welman)
Subject: Re: [beep] Indigo running 4d.4.0.1 not beeping
Organization: CSS, Simon Fraser University, Burnaby, B.C., Canada
Distribution: usa
Date: Tue, 15 Dec 1992 21:00:15 GMT

In article <1992Dec15.163729.27528@nas.nasa.gov> jns@ace.nas.nasa.gov (John N. Stewart) writes:
>Anyone else noticed that an Indigo running 4.0.1 fails to beep after
>awhile when running twm under X11R4? It seems to be happening here;
>I've heard of a patch in one of the later releases of 4d, but I'd
>rather see documentation first... which seems to be scarce.
>
>Any help?
>Tanx...

Sounds like a problem I had with ringbell() under 4.0.1 - getting 4.0.5
seemed to fix it...

Chris
Xref: sparky comp.sys.sgi.bugs:8 comp.sys.sgi.admin:35
From: philip@concave.cs.wits.ac.za (Philip Machanick)
Newsgroups: comp.sys.sgi.bugs,comp.sys.sgi.admin
Subject: Re: Ethernet bug in 4.0.5F indigos
Date: 17 Dec 92 06:54:06 GMT
Article-I.D.: shannon.1992Dec17.065406.22404
Organization: Computer Science Dept, Wits University
X-Xxdate: Thu, 17 Dec 92 08:47:24 GMT
X-Useragent: Nuntius v1.1.1d12

In article <1992Dec16.221212.11863@umbc3.umbc.edu> David A Freeman,
dave@umbc8.umbc.edu writes:
>	I noticed that in 4.0.5F, in the file /usr/sysgen/master.d/if_ec2
>the value of the ec_rcvinit_delay variable is 13    In 4.0.5 the value 
>was 13333.  I checked with SGI and found that the correct value is 13333
>for all 4.0.X software. All of our r4000 4.0.5F systems and the
distribution 
>media that we have received have the variable set to 13. 

On our R3000 Indigo running 4.0.1 it is set to 0. Is this something I
should change?
--
Philip Machanick
Computer Science Dept, Univ of the Witwatersrand, 2050 Wits, South Africa
philip@concave.cs.wits.ac.za  phone: 27 (11) 716-3759  fax: 339-7965
Newsgroups: comp.sys.sgi.bugs,comp.sys.sgi.admin
From: guy@wmsg02.wm.estec.esa.nl (Guy Brooker)
Subject: Re: Ethernet bug in 4.0.5F indigos
Organization: ESA/Estec/WMS, Noordwijk, The Netherlands
Date: Fri, 18 Dec 1992 10:39:50 GMT

In article <tnj3980@zuni.esd.sgi.com>, dwong@sgi.com (David Wong) writes:
 > In article <BzEs7E.CJ1@wm.estec.esa.nl> guy@wmsg02.wm.estec.esa.nl (Guy Brooker) writes:
 > 
 > the errata is for people running 4DDN such that the interface won't
 > switch to promiscuous mode.
 > 
 > >
 > >I have had some problems with my ethernet since the new installation, and since
 > >changing to above they seem so far to have gone completely...
 > 
 > what sort of problem ?
 > 

My machine occasionly lost contact with the NFS server, sometimes breifly, sometimes over extended periods, and allways with the News server breifly as information is requested. 

Since making the two changes I mentioned, I have not seen these problems.

I was running 4DDN, but have switched it off scince 4.0.5F. 

Guy

-- 

-------------------------------------        	Guy Brooker
Internet: guy@wm.estec.esa.nl        		European Space Research and
	  guy@wmsg02.dnet.estec.esa.nl		Technology Centre (ESTEC)
	  gbrooker@estec.esa.nl
Bitnet  : gbrooker@estec.bitnet		SPAN    : ESTERS::GUY
Phone	: +31-1719-83611		Fax	: +31-1719-85617
Mail	: ESTEC JW/WMS, Keplerlaan 1, 2200AG NOORDWIJK, The Netherlands

Newsgroups: comp.sys.sgi.bugs
From: jns@ace.nas.nasa.gov (John N. Stewart)
Subject: [beep] Indigo running 4d.4.0.1 not beeping
Organization: NAS, NASA Ames Research Center, Moffett Field, California
Date: Tue, 15 Dec 92 16:37:29 GMT
Distribution: usa



Anyone else noticed that an Indigo running 4.0.1 fails to beep after
awhile when running twm under X11R4? It seems to be happening here;
I've heard of a patch in one of the later releases of 4d, but I'd
rather see documentation first... which seems to be scarce.

Any help?

Tanx...


Newsgroups: comp.sys.sgi
From: mitch@rama.sydney.sgi.com ()
Subject: Re: is 4D/240 VGX w/ IRIX 3.3.2 SMP
Organization: Silicon Graphics Computer Systems,  Mtn. View CA. 94039
Date: Thu, 17 Dec 92 02:10:49 GMT

In article <1g6a2lINN6mv@fangio.asd.sgi.com>, rck@fangio.asd.sgi.com
(Robert Keller) writes:
|> dimpsey@austin.ibm.com writes:
|> >I have just received access to a SGI IRIS 4D/240 VGX running IRIX
|> >system V REL. 3.3.2.  Is this a symmetric multiprocessor or are the 
|> >processors following some master-slave configuration.  
|> 
|> All SGI multiprocessor machines are SMP.
|> >When I log in am I always on the same processor?  
|> No.  Furthermore, your shell process (any process, really) can 
|> seemlessly switch processors at any time.
|> 
|> >Can I bind a process to a processor??
|> 
|> Yes, checkout the mpadmin(1) man page.
|> 
|> ...robert

Please read the mpadmin page with care.

To some degree there are no good reasons to mpadmin 
anything.

The mpadmin and other hooks can make the machine look hung.
Users who mpadmin and npri processes are taking exact control
of a complex system.   More  problems are created than solved 
in my experience.  Since the trouble options are uid 0 restricted
there are almost never problems unless a system manager is careless.

They are very useful in some realtime contexts.  On systems with
four or more processors it is often useful to tinker with restricting
the last couple of processors while leaving 0 and 1 to free wheel.

In terms of process scheduling there is one runq each processor
obtains a reliable hardware lock.  Finds work to do on the runq 
pulls the process off the Q frees the lock and runs the process
untill the next time slice clock tick.

Then the runq is locked the last job placed back on the q.  The 
q is then inspected and the 'next' is picked off to run.  This part
is very vanila SysV inside the lock.   

Below this are more complex MP issues, but from a users point of view
there is only 1 runq.   Look at "ps -elf" listings.   There is a P
field to indicate which processor a process happens to be on.


Enjoy,
mitch
From: sgf@cfm.brown.edu (Sam Fulcomer)
Newsgroups: comp.sys.sgi
Subject: Re: tar, nfs, and restricted_chown
Date: 14 Dec 92 22:14:36 GMT

In article <1ggu1sINNp8q@guinan.cs.purdue.edu>, tzheng@cs.purdue.edu (Tom Zheng) writes:
|> 
|> In article <Bz882q.L2.2@cs.cmu.edu>, cline+@cs.cmu.edu (Kenneth Cline) writes:
|> |> A user logged into a Sun4 was unable to extract tarred files (created
|> |> by another user) to a disk mounted on our SGI machine.  Apparently,
|> |> SunOs tar chowns the new file to the old user before reading its
|> |> contents, and subsequent operations fail due to ownership conflict.
|> |> 
|> |> The fix was to build a new kernel for the SGI with restricted_chown
|> |> set to 1.  Now, "tar x..." works fine, but I would like to know if
|> |> this is a bug in SunOs tar (maybe, calling chown prematurely), an SGI
|> |> bug (which doesn't seem as likely), or simply conflicting features.
|> |> 
|> ...
|> source. I would be very interested to know who should be blamed for 
|> the problem, though.
|> 


Blame tar. It (obviously) tries to chown to the other user and doesn't complain
if the chown fails. The Sun fs code restricts chown. The default SGI code doesn't.
Sun tar should behave like the SGI tar and only chown if invoked by the 
superuser.

Now why anyone would want an unrestricted chown is another question entirely.

-- 
_/**/Sam_Fulcomer	sgf@cfm.brown.edu	What, me panic: uba crazy
Brown University  Center for Fluid Mechanics, Turbulence  and Computation