Subject: Re: kern/22869: Slave IDE drive not detected
To: Charles M. Hannum <abuse@spamalicious.com>
From: Manuel Bouyer <bouyer@antioche.lip6.fr>
List: tech-kern
Date: 09/22/2003 13:51:09
On Mon, Sep 22, 2003 at 01:24:45PM +0200, Manuel Bouyer wrote:
> On Mon, Sep 22, 2003 at 04:56:47AM +0000, Charles M. Hannum wrote:
> > [...]
> > At any rate, proper detection of drives without 15- or 30-second
> > stalls is very important, and it *will* be fixed.  It's not even
> > vaguely correct to say that detecting the ghosting "won't speed up the
> > probe" -- it has a huge and extremely obvious impact on many machines.

To give more details on this:
detecting the ghosting *before the reset* should't speed up the reset.
If we have only one master, it will also handle registers read for the
slave and both drives will appear ready at the same time.
If we have a master+slave, we have to wait for both drives.
The case with only one slave is harder, because ATA doesn't clearly specify
the behavior in this case, and I've seen all sorts of thing happen when
we try to talk to the master (one raison may be that the pciide controller
also does weird things with registers).
In the case were we don't have any drives, the registers tests you added
should help.

Now, it's true that some devices require several seconds after a reset.
We can't make them go faster, the only thing I can see that can be done is
to reset the channels in parallel.
Some drives also needs several seconds to handle an inquiry after reset.
But for ghost drives, the command should be aborted immediatly.

Hum, there is probably something to look at here; __wdccommand_start()
should probably check for an aborted command right after writing the
command registers, I'm not sure we'd get an interrupt in this case.
I'll look at this this evening.

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
     NetBSD: 24 ans d'experience feront toujours la difference
--