It seems Matthias Schuendehuette wrote:
> > > 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?
The driver always resets the ATA channel if a command times out, thats
the only way to gain control of the device(s) again.
The driver always falls back to PIO if it encounters a DMA problem,
be it with tags or not, as chances are DMA doesn't work at all if
a problem shows up. Now this could be changed, but in 99% of the cases
it will just make the pain last longer, until it finally switches
back to PIO. I chose this route because most users prefers to
keep thier data intact at (almost) any price. However in -current
and recent -stables you can switch on DMA again with atacontrol,
if you think it was a fluke that got it set back to PIO.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message