Date: Wed, 28 Jan 1998 23:16:32 +1030 From: Mike Smith <mike@smith.net.au> 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 Message-ID: <199801281246.XAA01110@word.smith.net.au> In-Reply-To: Your message of "Wed, 28 Jan 1998 23:29:06 %2B1100." <199801281229.XAA05384@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. \\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801281246.XAA01110>