From owner-freebsd-commit  Tue Oct 31 23:48:02 1995
Return-Path: owner-commit
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id XAA29328
          for freebsd-commit-outgoing; Tue, 31 Oct 1995 23:48:02 -0800
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id XAA29301
          for cvs-all-outgoing; Tue, 31 Oct 1995 23:47:53 -0800
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id XAA29285
          for cvs-sys-outgoing; Tue, 31 Oct 1995 23:47:50 -0800
Received: from jhome.DIALix.COM (root@jhome.DIALix.COM [192.203.228.69])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA29269
          ; Tue, 31 Oct 1995 23:47:35 -0800
Received: (from peter@localhost) by jhome.DIALix.COM (8.6.12/8.6.9) id PAA01090; Wed, 1 Nov 1995 15:46:21 +0800
Date: Wed, 1 Nov 1995 15:46:21 +0800 (WST)
From: Peter Wemm <peter@jhome.DIALix.COM>
To: Bruce Evans <bde@zeta.org.au>
cc: davidg@Root.COM, CVS-commiters@freefall.freebsd.org,
        cvs-sys@freefall.freebsd.org
Subject: Re: cvs commit: src/sys/kern tty_subr.c
In-Reply-To: <199511010555.QAA17404@godzilla.zeta.org.au>
Message-ID: <Pine.BSF.3.91.951101153052.22432Q-100000@jhome.DIALix.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-commit@FreeBSD.org
Precedence: bulk

On Wed, 1 Nov 1995, Bruce Evans wrote:
> >I used to have this problem occasionally with the specialix driver, and in
> >the end the interrupt routine had to do a lot of tests to attempt to
> >intuit whether or not he cblocks were currently reserved or not.  The
> 
> That's why I don't like silently ignoring the problem.  Reporting it
> nastily should have been good for getting drivers fixed.  si.c was
> relying on TS_CONNECTED but TS_CONNECTED isn't set quite right for it.
> TS_CONNECTED shouldn't be set in ttymodem() unless TS_ISOPEN is set.
> If you fix this, then change the recent fix to ttyopen() to set
> TS_CONNECTED if carrier is on as well as if CLOCAL is set.
> 
> Bruce

My main thoughts on the issue is that it doesn't _need_ to panic.. :-)  
The system can quite safely recover from it.  Yes, a nasty message is a 
good idea, but bombing the kernel seems a little drastic.

Cheers,
-Peter