Return to BSD News archive
Path: sserve!manuel.anu.edu.au!munnari.oz.au!news.hawaii.edu!ames!sun-barr!olivea!uunet!news.univie.ac.at!news.tu-graz.ac.at!fstgds01!chmr From: chmr@fstgds01.tu-graz.ac.at (Christoph Robitschko) Newsgroups: comp.unix.bsd Subject: Re: More on pccons/XFree86 problems (keyboard hangs) Keywords: 386BSD X11 XFree86 console pccons Message-ID: <1992Dec15.083801.11567@news.tu-graz.ac.at> Date: 15 Dec 92 08:38:01 GMT References: <1992Dec13.172900.451@ponds.uucp> <1992Dec14.115444.12691@news.tu-graz.ac.at> <veit.724353177@du9ds3> Sender: news@news.tu-graz.ac.at (USENET News System) Organization: Technical University of Graz, Austria Lines: 44 Nntp-Posting-Host: fstgds01 In article <veit.724353177@du9ds3> veit@du9ds3.fb9dv.uni-duisburg.de writes: >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. The pccons device is normally used by getty (via /dev/vga). And the reason why pcclose is not called on 'kill -1 syslogd' is most probably another process which has /dev/console open. It *is* called on my system (checked with the kernel debugger). BTW, I can easily reproduce this bug *outside* of X windows, by killing all processes which potentially have /dev/console open (This is not difficult, since I only have update and syslogd running). The console the locks up and there is *no keyboard echo* on the screen. The system is usable again after there is some output to the pccons device. I.e., try: (sleep 30; echo nixnix > /dev/vga) & kill syslogd (and possibly others) >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: > [patch deleted] This patch is certainly mandatory, but I doubt that it fixes the keyboard hang, because not only the input to the shell is blocked, but also there is no keyboard echo on the screen. But I am glad thatyour codrv does not have that problem. >Holger Christoph -- ..signature: Protocol wrong type for socket