From owner-cvs-sys  Sun Dec  1 10:01:47 1996
Return-Path: owner-cvs-sys
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id KAA23749
          for cvs-sys-outgoing; Sun, 1 Dec 1996 10:01:47 -0800 (PST)
Received: from precipice.shockwave.com (ppp-206-170-6-83.rdcy01.pacbell.net [206.170.6.83])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA23741;
          Sun, 1 Dec 1996 10:01:42 -0800 (PST)
Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.8.3/8.7.3) with ESMTP id KAA02353; Sun, 1 Dec 1996 10:01:27 -0800 (PST)
Message-Id: <199612011801.KAA02353@precipice.shockwave.com>
To: Bruce Evans <bde@zeta.org.au>
cc: bde@freefall.freebsd.org, cvs-all@freefall.freebsd.org,
        CVS-committers@freefall.freebsd.org, cvs-sys@freefall.freebsd.org
Subject: Re: cvs commit: src/sys/i386/isa sio.c 
In-reply-to: Your message of "Sun, 01 Dec 1996 23:35:47 +1100."
             <199612011235.XAA19611@godzilla.zeta.org.au> 
Date: Sun, 01 Dec 1996 10:01:27 -0800
From: Paul Traina <pst@shockwave.com>
Sender: owner-cvs-sys@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

  From: Bruce Evans <bde@zeta.org.au>
  Subject: Re: cvs commit: src/sys/i386/isa sio.c
  >OK, we're in perfect agreement there.  So now, the $24 question is:
  >
  >"If I set comdefaultrate to 115200 and don't open /dev/ttyd0, exactly what
  > is going to happen every time we output a character?"
  
  The speed will be 9600 to begin with.  It will be changed to 115200.
  Then the character will be written.  Then the output routine will spin
  until the output is incomplete.  Then the speed will be restored to
  9600.
  
  Context switching the speed (and other h/w state) is bad iff input is
  arriving while you're switching and if input arrives while you're not in
  the spinloop waiting for it.  This is bad for gdb of course.  There is
  a simple workaround: set the initial speed of /dev/ttyd0 to 115200 and
  don't neglect to open it (stty 115200 </dev/ttyid0; stty -f /dev/ttyd0).
  
  There may be other problems at 115200.  It's not clear how input at any
  speed works - if you do a block of output large than the input fifo size,
  then input is certain to be lost while the output routine is spinning.
  gdb-remote apparently doesn't do this often.  I wrote some better
  buffering code a few months ago but got confused by a hardware bug and
  never finished.
  
Good, I'm glad we agree on your explanation of what will happen now that
you've cleaned up this code.  This is the same thing that WAS happening
before.

Now, that we're in sync on the effect, I will re-state that that effect is
utterly bogus.  You should have the ability to set this in the kernel and
set the default rate so that when you're bringing up a system (before the
user has has the ability to stty /dev/ttyid0 to 115200) you don't switch
baud rates constantly.

This was causing a real problem with gdb, which is why I hacked it in the
first place.

Please either restore my changes, or do something that you prefer that allows
someone to avoid this serial port context change.

Paul