Will the backdown to PIO mode be permanent till the next reboot of the
machine, or will the driver be able to attempt to return to DMA mode after
a timeout period. I'm only seeing these errors under really heavy disk
activity (mutlitple nfs readers and writers plus rsync/mirror jobs to the
vinum volume in question).
On the vinum front, does vinum have the ability to retry writing a block
(or whatever the correct abstration is) to the same device if an error
like this comes up from the underlying device?
Thanks,
keep up the great work
(Yes, I know I should be using scsi for something like this, but the price
of a 200GB raid0 unit built out of IDE equipment compared to the same
built out of SCSI hardware is quite shocking. Especially for a
non-mission critical role.)
On Sat, 11 Dec 1999, Andrew Gallatin wrote:
> These are UDMA CRC errors. Whatever you do, DO NOT upgrade to a
> recent current without reading the ata driver's commit logs very
> carefully.
>
> The ata-driver has recently grown recovery code where it will try to
> back down to PIO mode to fetch such blocks. As recently as last week,
> the ata driver would lock a machine solid (unpingable, reset or
> power-cycle required) when attempting to back down to PIO mode when
> the drive in question was attached to a Promise Ultra controller.
>
> Soren knows about the problem & is going to fix it.
>
>------------------------------------------------------------------------------
> Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin
> Duke University Email:[EMAIL PROTECTED]
> Department of Computer Science Phone: (919) 660-6590
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
