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
-
: 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
