From owner-freebsd-hackers  Thu Jul 11 16:06:16 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id QAA12766
          for hackers-outgoing; Thu, 11 Jul 1996 16:06:16 -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 QAA12758
          for <hackers@FreeBSD.org>; Thu, 11 Jul 1996 16:06:08 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id IAA18667; Fri, 12 Jul 1996 08:54:57 +1000
Date: Fri, 12 Jul 1996 08:54:57 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199607112254.IAA18667@godzilla.zeta.org.au>
To: alex@fa.tdktca.com, graichen@axp5.physik.fu-berlin.de
Subject: Re: sio / modem problems
Cc: hackers@FreeBSD.org
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

>> i have an internal creatix phone-master modem - which will be detected in
>> FreeBSD 2.0.5 but not in the 2.1.0 RELEASE or the march 2.2 snap - it's

The probe didn't change (not even one byte of the source) between 2.0.5R
and 2.1.0R.

Revision 1.135 on 25 Feb introduced some delays in the probe in the hope
of fixing this problem.  These should be in the March 2.2 snap.

These changes are missing from -stable :-(.  (Or `:-)' if they actually
make things worse :-).

The probe hasn't changed significantly in -current since rev.1.135.

>I recently fixed a modem detection problem from someone by inserting 
>"DELAY(1000);"'s in sioprobe() everywhere the /* EXTRA DELAY? */ comment
>appeared.  It's a hack, but clearly some portion of that code is running 

The delays in rev.1.135 are in slightly different places.  They are
probably necessary if the UART is actually a bunch of i/o ports under
software control.  The software can reasonably take a long time to
complete a sequence of events that it initiates.  OTOH, for events
initiated by the host cpu, such as writes to control registers, the
UART needs to respond withing a few hundred nsec to preserve 16550
compatibility.  Otherwise back to back writes to a control register
might lose the intermediate steps...  I added delays in exactly the
cases where it seems reasonable for the UART to be slow.

Bruce