Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!bloom-beacon!snorkelwacker!usc!samsung!shadooby!sharkey!cfctech!teemc!ka3ovk!ki4pv!cdin-1!dsinc!lgnp1!penrij!soup
From: soup@penrij.LS.COM (John Campbell)
Newsgroups: comp.unix.xenix
Subject: Re: Failed kill -9
Summary: race condition
Message-ID: <64@penrij.LS.COM>
Date: 24 Dec 89 16:31:53 GMT
References: <[628]unix@oldcolo.UUCP> <[628.1]unix;1@oldcolo.UUCP> <1989Dec23.031934.1395@virtech.uucp>
Organization: penrij, Perkasie PA
Lines: 42

In article <1989Dec23.031934.1395@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes:
> In article <822@scorn.sco.COM>, rogerk@sco.COM (Roger Knopf 5502) writes:
> > signal. If you get into one of these routines and can't get out (bug
> > or HW failure, its never _normal_), the process will be unkillable
> > by any signal. More details can be supplied for those interested.

> A very normal way of getting into this situation is to go to a 
> terminal and cat /etc/termcap.  Once the output starts, do a CTRL-S.
> after a few seconds (once the output buffering has filled up) the cat
> process will no longer be killable.  However, once a CTRL-Q is typed
> at the terminal, any signals sent to the cat process will be delivered.

	I ran across this back 6 years ago on an Intel 286/310 w/ 544 _and_
	188 cards.  I was told that it was caused by a "race condition"
	in the serial port handler, that it can't close the session until
	it flushed the buffers- which it can't do without being released
	by flow control.  I had a lot of fun working around this;  I did
	eventually do it by "cheating"-  we were connected to a serial port
	LAN (Ungermann-Bass Net/One) so a "daemon" activity looked for a
	locked process and would disconnect his session, connect to him,
	receive ALL of the traffic, then tell the process to restart after
	releaseing the net session.  This trick worked.

	It turns out that Intel claims to have corrected the problem in
	XENIX R3.4-  which I have installed but no longer in a position
	to test.  Of course, I don't have the right version of firmware
	for my 544 cards, but...  what the hell...

	Now for a real laugh:  On the Convergent SPC they had a nice bug
	in the LP driver (since claimed as fixed) which, when the printer
	ran out of paper (or went off-line) in the middle of a print job
	would LOCK UP THE WHOLE SYSTEM.  The solution: re-load the printer
	with paper (if needed) and place it on-line.  The system would
	pick up where it left off.  This was for the parallel port printer.

	Since the SPC200 is the Unisys 6000/50 (and SYSINU never has the
	current OS version) I wonder if the bug/feature/whatever still
	lives?

--
 John R. Campbell					  (soup@penrij.LS.COM)
		 "In /dev/null no one can hear you scream"