Re: [RFT] hpt366: reset DMA state machine on timeouts

[linas@austin.ibm.com (Linas Vepstas)]

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