On Mon, 2007-02-05 at 15:50 -0600, James Bottomley wrote: > On Mon, 2007-02-05 at 12:49 -0800, Mark Haverkamp wrote: > > James, > > > > Some months ago, I had problems with a mis-behaving disk that failed > > domain validation on a fusion card resulting in an infinite loop of > > domain validation. At the time Eric proposed a patch to the mptspi > > driver to reload devices with parameters previously negotiated when a > > reset occurred. You indicated that a more generic solution should be > > done. > > > > This patch updates spi_dv_device_internal() to check if domain > > validation has already been performed on a device and just sets it > > previously negotiated parameters. This solved the "infinite domain > > validation" loop for me when a reset is performed as a result of command > > timeout with the mis-behaving device. > > Er,but this code basically disabled domain revalidation after a reset, > doesn't it?
Yes it does. The problem I am seeing is that a device that fails validation can cause a reset to occur. If it does, then all devices are now re-validated. Including any that have failed validation previously. Which can cause another reset and another validation, etc. forever. I'm not sure how else to break out of this cycle. > If we could do it that way, we could simply take the calls > to spi_dv_device() out of the fusion driver and instead set the > parameters up in its place without having to modify the transport class. If I understand your comment, I believe that is what Eric proposed at one point. But it seems other drivers/adapters could have a similar problem. Mark. -- Mark Haverkamp <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
