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. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
