On Tuesday, May 29, 2007 4:03 PM, James Bottomley wrote: > The device is presumably returning BUSY when you try to send a second > command when it's already processing the first ... that should be > propagated back to the mid-layer causing it to throttle the > queue ... it > seems this wasn't happening for some reason to get such a massive > slowdown. Is this a more generic problem in the fusion or is it a > simple issue only affecting the untagged case? > Right, probably SELECTION_TIMEOUT. Or command timeout with error handling threads getting called. Either way, the customer hasn't provided a dmesg log or scsi bus trace, so we don't know for sure. But is this analysis really required? Dont' you think the driver should return that it doens't support queued commands when sdev->tagged_supported (look at scsi_scan.c function scsi_add_lun) is set to zero? It appears that is what other drivers in the kernel tree do. When I reorganized the code in a patch I provided back in February, I moved analyzing the sdev->tagged_supported flag to after I set the queue depth, not before. Eric - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
