From owner-cvs-sys  Tue Sep 10 13:34:41 1996
Return-Path: owner-cvs-sys
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id NAA12136
          for cvs-sys-outgoing; Tue, 10 Sep 1996 13:34:41 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA12131;
          Tue, 10 Sep 1996 13:34:34 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id GAA02194; Wed, 11 Sep 1996 06:15:48 +1000
Date: Wed, 11 Sep 1996 06:15:48 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199609102015.GAA02194@godzilla.zeta.org.au>
To: cvs-all@freefall.freebsd.org, CVS-committers@freefall.freebsd.org,
        cvs-sys@freefall.freebsd.org, peter@freefall.freebsd.org
Subject: Re: cvs commit:  src/sys/i386/isa syscons.c
Sender: owner-cvs-sys@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>  Modified:    sys/i386/isa  syscons.c
>  Log:
>  Hack workaround XFree86 switching failure when used with /dev/sysmouse
>  and xdm, possibly in general.
>  
>  What was happening was that the server was doing a tcsetattr(.. TCSADRAIN)
>  on the mouse fd after a write.  Since /dev/sysmouse had a null t_oproc,
>  the drain failed with EIO.  Somehow this spammed XFree86 (!@&^#%*& binary
>  release!!), and the driver was left in a bogus state (ie: switch_in_progress
>  permanently TRUE).

This reminds me of what happens when crtscts is locked on for the mouse.
My mouse doesn't supply CTS, so draining takes forever.  Killing XFree86
require kill -9 from somewhere other than the console IIRC, and leaves
the console driver in a bogus state.  Some graphics cards go into a
strange state when XFree86 is started up again in this state.  Sometimes
XFree86 manages to kill itself after a timeout, but the console driver
is left in a bogus state.

Bruce