Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/17/84; site hao.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcrdcf!trwrba!cepu!hao!pag
From: pag@hao.UUCP (Peter Gross)
Newsgroups: net.unix-wizards
Subject: V7 "proc on q" diagnostic message
Message-ID: <1266@hao.UUCP>
Date: Mon, 19-Nov-84 14:49:06 EST
Article-I.D.: hao.1266
Posted: Mon Nov 19 14:49:06 1984
Date-Received: Wed, 21-Nov-84 01:33:50 EST
Distribution: net
Organization: High Altitude Obs./NCAR, Boulder CO
Lines: 21

In V7 Unix (and perhaps others) there is a diagnostic printf "proc on q"
in the routine setrq() which puts its argument on the run queue.  The
message is the result of finding the given process already on the run
queue.  We were getting this message occasionally in early morning hours.
I changed the printf() to a panic() to get a better handle on what
was happening.  It turned out to be a program which does a double-
buffered copy of the root file system to a spare file system (uses the
program "dbuf" which was posted to USENET long ago).  This program forks
off 4 processes, 2 each for reading and writing, and does lots of signalling
back and forth.  The panic comes when one process sends another an EMT
signal to indicate that an I/O operation has completed.  The kernal traps
the kill() system call, calls psignal(), which in turn calls setrq().
setrq() finds that the proc is already on the runq (yet it's p_stat was
SSLEEP!).  Sounds like a race condition to me.  Our kernel is highly
hacked for performance (load-based scheduling, auto-nicing, forced swapping
of cpu-bound procs, etc.)  I am curious if anyone else has seen the
"proc on q" message, and what caused it.

--peter gross
hao!pag			UUCP
hao!pag@seismo.ARPA	ARPA