From: veit@du9ds3.fb9dv.uni-duisburg.de (Holger Veit)
Newsgroups: comp.unix.bsd
Subject: Re: More on pccons/XFree86 problems (keyboard hangs)
Date: 14 Dec 92 17:12:57 GMT
Organization: Uni-Duisburg FB9 Datenverarbeitung
Reply-To: veit@du9ds3.fb9dv.uni-duisburg.de
NNTP-Posting-Host: du9ds3.fb9dv.uni-duisburg.de
Keywords: 386BSD X11 XFree86 console pccons

In <1992Dec14.115444.12691@news.tu-graz.ac.at> chmr@fstgds01.tu-graz.ac.at (Christoph Robitschko) writes:

>In article <1992Dec13.172900.451@ponds.uucp> rivers@ponds.uucp (Thomas David Rivers) writes:
>>  Try it out yourself, inside of an X window, do a :
>>
>>     kill -1 `cat /var/run/syslog.pid`
>>
>>  and your keyboard will lock up.
>>
>>
>>I will probably try and examine the stock pccons.c to determine where
>>the problem can be corrected... but if someone has an idea/fix, feel
>>free to beat me to it...
>>
>The problem is that the pccons driver is used in two ways: first in 
>the standard way through pcopen() etc., and second as a console device
>through cnopen(). 
>The cn???() calls simply call the corresponding pc???() routines, which 
>is OK for open(), read() and write(), but not for close(), because
>the close routine is only to be called when the LAST reference to 
>the device was closed. But when the last reference to the console device
>is closed (as happens when you kill or SIGHUP the syslogd), cnclose()
>calls pcclose(), no matter if there are any references to the pccons
>device (such as the keyboard input for your shell or X server).
>pcclose() then thinks there is no more reference to it and disables
>keyboard input.

>One possible solution would be to modify pcclose() to only do the real
>close operation if there are really no more files open on it (A sort of
>reference count or reference bits for each device type is needed).

>I don't know if any of the replacement pccons (or codrv) drivers fix this.


>							Christoph
>-- 
>.signature: Connection timed out

Ok, my second followup. I have just checked my system with codrv and I didn't
succeed in reproducing this effect :-). Since I do not do reference counting
in codrv, there must be a different reason. I found that pcclose in *not*
called on 'kill -1 syslogd'. This is because usually the pccons device is
normally not used at all (e.g. by csh or x386/keyboard input), so the vnode
refcount for /dev/console is quite accurate.
But then, what *might* be the reason, despite the fact that codrv uses a
real /dev/kbd instead of a /dev/console switched into scancode mode?
I had a "keyboard hang" with an earlier, unpublished version of codrv, in this 
case, however, with a crashing or  'xterm -C'. The not so obvious reason is
that closing a pty that happens to have the TIOCCONS attribute does not
invalidate the constty pointer. So constty-> points to an invalid
struct tty, which has been marked as closed. So it is not directly the 
keyboard that hangs, but the csh which has this (invalid) tty open, waits on
'ttopen' (see this with ps -axl on a connected terminal). The mandatory
fix for this is the following:

*** tty_pty.c.old	Tue Oct  6 03:33:52 1992
--- tty_pty.c	Tue Oct  6 03:33:33 1992
***************
*** 265,270 ****
--- 265,271 ----
  	return (0);
  }
    
+ extern struct tty *constty;	/* -hv- 06.Oct.92*/
  ptcclose(dev)
        dev_t dev;
  {
***************
*** 275,280 ****
--- 276,285 ----
    	tp->t_state &= ~TS_CARR_ON;
  	tp->t_oproc = 0;		/* mark closed */
  	tp->t_session = 0;
+ 
+ /* XXX -hv- 6.Oct.92 this might prevent the "hanging console bug" with X11 */
+ 	if (constty==tp)
+ 		constty = 0;
  }
  
  ptcread(dev, uio, flag)


This fix should also work with old pccons, at least it does no harm.

Holger
-- 
|  |   / Dr. Holger Veit         | INTERNET: veit@du9ds3.fb9dv.uni-duisburg.de
|__|  /  University of Duisburg  |
|  | /   Dept. of Electr. Eng.   |          "Understand me correctly:
|  |/    Inst. f. Dataprocessing |     I'm NOT the WIZARD OF OS" (Holger)