On Mon, 2009-04-06 at 13:47 +0530, Desai, Kashyap wrote: > Comment #6. This routine looks like a recoding of > scsi_test_unit_ready(). Firstly, why not just use it, but secondly, > why is it necessary ... the use case is when you spot a device added > and the mid layer does inquiry and > settle checking anyway. > -> We can use scsi_test_unit_ready only if sdev is created for end > device. In some of the cases Device takes ~150secs to come up even > after sending hotplug event. If we report add device event to Scsi > Subsystem, It will inquire MAX 3 times to see weather device is > present or not. It will reject Device Add event and eventually Device > which will come up after long delay will not be seen to Scsi mid > layer. > We required similar call like scsi_test_unit_ready() for our driver so > that we can issue TUR much before reporting it to SCSI midlayer. Um, so it sounds like you're saying that hotplug has jitter problems which the mid-layer doesn't cope with (but should)? So the solution should be to fix the mid layer, not code around it in your driver. > Comment #7. OK, this is getting sillier. You send a TUR to a device, > but the device may not have a LUN 0, so now we're going to send a > report luns and fish for an actual lun to test? Again, the mid layer > does all of this when the device appears, why not just let it? > -> I accept your concern. It is not optimized way of doing TUR. We > have fix for this in SAS2 driver. Since this code is well tested I > will request you to consider this code as of now. I will resend well > tested code soon. > Why we are doing it, not allowing SCSI mid layer? Answer is same as > explanation in comment#6. Well, it's also what you're actually doing. The jitter is presumably on the line, so if you get a report luns through, that's sufficient indication that the target is responding, there's no need to do an additional test unit ready. If we pull this into the mid-layer, it seems reasonable just to probe for target readiness with report luns. Or do you have some specific array problem that comes up via hot plug (so the line is clear) but then terminates commands with errors for the 150s? James -- 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
