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