Re: [PATCH 11/16] libata-eh-fw: implement new EH scheduling via timeout

[Jeff Garzik <jgarzik@pobox.com>]

Tejun Heo wrote:
> The problem is that the timeout handler doesn't have anyway to determine 
> whether the timeout is from real timeout or from DMA error, and the 

Not true at all.  Just read BMDMA status.  Take a look at what 
drivers/ide does.


> timeout handler is responsible for transferring the ownership the failed 
> port to EH.  EH, on entry, must be guaranteed that it owns the port if 
> it's not frozen.
> 
> One way around this would be making a new callback, say, 
> ->timeout_autopsy and let it decide whether the port needs freezing or 
> not, but it would be an overkill.  The only side effect of being frozen 
> is that the port will get a softreset to thaw it, which isn't so bad - I 
> want my controller to get a good spanking in the ass after sitting idle 
> for 30secs.

When presented with standard, documented DMA error behavior, a reset is 
inappropriate.  Just ACK the DMA error and move on with life.  If 
continuous DMA errors occur, reset and/or step down the speed as was 
discussed many months ago.

Get the user back up and talking to their disk as fast as possible.

	Jeff