On Fri, Jun 22, 2007 at 07:32:44PM +0400, Sergei Shtylyov wrote:
>
> >>Reset HPT36x's DMA state machine on a DMA timeout the way it's done for
> >>HPT370.
> >>drivers/ide/pci/hpt366.c | 24 +++++++++++++++++++++++-
>
> >This worked great!
>
> I hope you meant those messages were preceeded by DMA timeouts
> (otherwise this code wouldn't come into action).
Oops, I was wrong ...
Scads of
Jun 21 20:22:30 localhost kernel: [ 434.574301] hdc: task_out_intr:
status=0x50 { DriveReady SeekComplete }
Jun 21 20:22:30 localhost kernel: [ 434.574318] ide: failed opcode was:
unknown
> >from it (I put in a printk to verify this).
>
> You mean into my ide_dma_timeout() method?
Ooops, I lied. I have so many printk's in there, that I got confused.
No, in fact, it looks like I did NOT see your handler run.
Per Alan Cox, I have to go back and see if dropping the
UDMA speeds and/or replacing the cable will help.
> What's strange is that it never seemed to be necessary before your great
> new drive... ;-)
At $70 for 320GB, how can one say "no"? Frye's had a mound of them,
shoulder-high.
MAXTOR STM3320620A
> So, providing its data certainly wouldn't hurt -- perhaps we just should
> blacklist it instead -- maybe there's a UDMA speed at which this wouldn't
> happen, and we could just limit the drive to it.
I'll experiment with the UDMA settings.
> In fact, it should be turned off after 3 DMA errors (causing PIO
> retries).
I'd like to see this turned into a rate. If the system gets one error
a month, and has been up for 3 months, the third error should not shut
things down. The room that this is in is hot; the machine might be
occasionally bumped. A low error rate is acceptable; its more acceptable
than a mysterious slow-down of performance after 3 months.
--linas
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
