From owner-cvs-all  Wed Jan 28 04:53:38 1998
Return-Path: <owner-cvs-all@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id EAA24452
          for cvs-all-outgoing; Wed, 28 Jan 1998 04:53:38 -0800 (PST)
          (envelope-from owner-cvs-all@FreeBSD.ORG)
Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA24431;
          Wed, 28 Jan 1998 04:53:25 -0800 (PST)
          (envelope-from mike@word.smith.net.au)
Received: from word (localhost [127.0.0.1])
	by word.smith.net.au (8.8.8/8.8.5) with ESMTP id XAA01110;
	Wed, 28 Jan 1998 23:16:33 +1030 (CST)
Message-Id: <199801281246.XAA01110@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Bruce Evans <bde@zeta.org.au>
cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-sys@FreeBSD.ORG,
        msmith@FreeBSD.ORG
Subject: Re: cvs commit: src/sys/i386/isa atapi.c 
In-reply-to: Your message of "Wed, 28 Jan 1998 23:29:06 +1100."
             <199801281229.XAA05384@godzilla.zeta.org.au> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 28 Jan 1998 23:16:32 +1030
From: Mike Smith <mike@smith.net.au>
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk

> >  Modified files:
> >    sys/i386/isa         atapi.c 
> >  Log:
> >  Check the status port after waiting for DRQ; some drives seem to be very
> >  slow coming off the bus (eg. Iomega's ATAPI Zip).  Failure to do
> >  this results in a false probe of an ATAPI device with garbage
> >  data.
> >  
> >  Revision  Changes    Path
> >  1.22      +9 -0      src/sys/i386/isa/atapi.c
> 
> How can this help?  The status port has been checked about 1 usec before
> and has been found to have a value that would pass the new check
> (ARS_CHECK was clear on the previous read, and ARS_BUSY was clear on a
> read before that, so the bits are unlikely to be all 1).

The Zip is, as I said, slow off the bus.  At least on the P6 I was 
using, it goes like this (PC98 junk elided):

        /* Wait for controller not busy. */
        outb (port + AR_DRIVE, unit ? ARD_DRIVE1 : ARD_DRIVE0);
        if (atapi_wait (port, 0) < 0) {

## Zip is still on the bus here; atapi_wait() returns happily thinking 
## there is a device present and ready.  A possibly better fix would be 
## to have the 10us delay earlier in the loop in atapi_wait().

        /* Issue ATAPI IDENTIFY command. */
        outb (port + AR_DRIVE, unit ? ARD_DRIVE1 : ARD_DRIVE0);
        outb (port + AR_COMMAND, ATAPIC_IDENTIFY);

        /* Check that device is present. */
        if (inb (port + AR_STATUS) == 0xff) {

## Zip is going off the bus at this point, but not gone.
## Read returns 0xa1.

        /* Wait for data ready. */
        if (atapi_wait (port, ARS_DRQ) != 0) {

## Zip eventually goes off the bus, and thus DRQ reads high.

At this point the probe thinks it has a device that's responded to the 
IDENTIFY.  The Zip is off having a beer, and the result is a garbage 
probe.  The easiest fix at the time was to simply catch the obviously 
nonsense case where the status register reads 0xff *after* waiting for 
DRQ.

> Perhaps the problem is earlier.  According to an old draft version of
> the ATA spec, the timing for issueing a polled-mode input command is:
> 
> 	driver				drive
> 	------				-----
> 1.	Write to command register.
> 2.					"sets BSY within 400 nsec".
...

I am inclined to suspect that the problem is actually with step 0.5, 
where:

0.0	Select the target
0.5	Wait XXX<units) for drive to respond to selection, or poll 
	(some register) to indicate drive is selected.

(You can tell I'm in the wrong office.)

-- 
\\  Sometimes you're ahead,       \\  Mike Smith
\\  sometimes you're behind.      \\  mike@smith.net.au
\\  The race is long, and in the  \\  msmith@freebsd.org
\\  end it's only with yourself.  \\