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
