From owner-freebsd-hackers  Tue Dec  2 23:39:22 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA17879
          for hackers-outgoing; Tue, 2 Dec 1997 23:39:22 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA17861;
          Tue, 2 Dec 1997 23:39:15 -0800 (PST)
          (envelope-from sos@sos.freebsd.dk)
Received: (from sos@localhost)
	by sos.freebsd.dk (8.8.8/8.8.8) id IAA01569;
	Wed, 3 Dec 1997 08:39:56 +0100 (MET)
	(envelope-from sos)
Message-Id: <199712030739.IAA01569@sos.freebsd.dk>
Subject: Re: Fix for slow reacting ATAPI CD-ROM
In-Reply-To: <199712030408.WAA11699@iworks.InterWorks.org> from "Daniel M. Eischen" at "Dec 2, 97 10:08:48 pm"
To: deischen@iworks.interworks.org (Daniel M. Eischen)
Date: Wed, 3 Dec 1997 08:39:55 +0100 (MET)
Cc: sos@FreeBSD.dk, freebsd-hackers@FreeBSD.ORG, freebsd-mobile@FreeBSD.ORG
From: Søren Schmidt <sos@FreeBSD.dk>
Reply-to: sos@FreeBSD.dk
X-Mailer: ELM [version 2.4ME+ PL30 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

In reply to Daniel M. Eischen who wrote:
> 
> I was able to lower the wait time to 75 usec for my CD-ROM drive,
> but anything <= 70 usecs would not work.
> 
> According to the comments in atapi.h:
> 
>   #define AT_DRQT_MPROC  0  /* microprocessor DRQ - 3 msec delay */
>   #define AT_DRQT_INTR   1  /* interrupt DRQ - 10 msec delay */
>   #define AT_DRQT_ACCEL  2  /* accelerated DRQ - 50 usec delay */
> 
> my CD-ROM drive should have a 50usec delay.  The code in atapi.c
> uses these numbers without any tolerance.  I assume these numbers
> come from some sort of ATAPI spec, but shouldn't we allow some
> tolerance?  Increasing these waits will not affect drives that
> conform to the times, so I don't see why they can't be larger.

Hmm, I *think* the above values are directly from the spec, but
havn't checked. I'll go check when I get home, and changing it to
100usec really shouldn't be a problem, and should provide you
with a safe margin...

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Søren Schmidt               (sos@FreeBSD.org)               FreeBSD Core Team
                Even more code to hack -- will it ever end
..