Am Donnerstag, 18. April 2002 16:44 schrieb Søren Schmidt:
> It seems Terry Lambert wrote:
> > "Søren Schmidt" wrote:
> > > It seems Terry Lambert wrote:
> > > > My other hunch is that there will need to be a channel reserved
> > > > for "reset" commands to be queued to the disk, so that you can
> > > > queue more commands to it later (e.g. can't connect to send the
> > > > reset because of the already disconnected commands in
> > > > progress).
> > >
> > > Terry, read the ATA spec, it doesn't work that way, tags on
> > > ATA is very different from tags on SCSI, and beside a reset
> > > is not a command, but a bit in a HW port..
> >
> > I didn't mean for the reset itself, I meant for the process.  You
> > can't "take back" writes that are in progress and not acknowledged,
> > in order to retry them after the reset, so as to not lose data.
> Oh yes you can, the ATA driver does just that in case of the drive
> loosing its marbels.

Does that mean that the driver isn't aware of the 'tags-problem'? If I 
understand you right, it should be possible to reset the drive and 
continue, maybe without tags or at a reduced UDMA-Speed or whatever 
actions seem appropriate...

...ahh, I mean, the driver *does* take an action (it/he(?) switches 
back to PIO4), but why is any UDMA-Mode no longer usable afterwards? Is 
the drive been reset or just switched back? What is the impact of a 
reset compared to a switch back?

Well, just my thoghts, I'm no specialist at all....
Ciao/BSD - Matthias

Matthias Schuendehuette <[EMAIL PROTECTED]>, Berlin (Germany)
Powered by FreeBSD 4.5-STABLE

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to