Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Sep 1998 16:57:08 -0700
From:      Mike Smith <mike@smith.net.au>
To:        Kevin Day <toasty@home.dragondata.com>
Cc:        karl@Denninger.Net (Karl Denninger), tom@uniserve.com, dnelson@emsphone.com, bright@hotjobs.com, current@FreeBSD.ORG
Subject:   Re: Long IDE probes? 
Message-ID:  <199809302357.QAA04228@dingo.cdrom.com>
In-Reply-To: Your message of "Wed, 30 Sep 1998 16:29:39 CDT." <199809302129.QAA18323@home.dragondata.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
> > > > Are the delay lengths reasonable?  I don't know.  Aren't there specs on
> > > > this stuff from the IDE and SCSI camps?
> > > 
> > >   The IDE delays just don't exist if you don't bother probing for devices
> > > that aren't there.
> > 
> > The IDE delays are far, far too long, unless someone can convince me that
> > *after booting* a device would require *another* 30 seconds to come ready
> > (remember, we're talking after power-on, not from the time the kernel is
> > done loading).
> 
> To shed some light.... This is all according to the ATA specs:
> 
> We throw a hardware reset.
> 
> The device must set the BSY flag within 400ns, after RESET- is turned off.
> If we can see BSY, the device is there.  We should be able to stop at this
> point, as suposedly this is a yes/no test for a device being present.

You're looking at the hardware reset protocol.  Wrong page. 8)

The idealised process is this:

 1) Check for BSY clear.  If set, fail the probe.
 2) Set SRST.
 3) Wait 400ns
 4) Check for BSY set.  If clear, fail the probe
 5) Clear SRST.
 6) Wait for 31s for BSY to clear.  If still set, fail the probe.

Unfortunately, we use the generic wdreset() function which is intended 
to always reset the drive, regardless.  It sets SRST for 10 seconds and 
then waits for the drive to come ready.

This (like much of the ATA code) calls for a complete rewrite.  Which 
is underway.  But for now, it's difficult to work around it "properly" 
without risking breaking support for older or nonconformant hardware.

-- 
\\  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.  \\  msmith@cdrom.com



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809302357.QAA04228>