James, It is actually for some customer specific array. They are using multi pathing with LSI HBA. When switch over from one path to other path happens TUR request for that device won't reply immediately. It normally took ~150 seconds. Since it is customer specific solution and they are planning to use upstream driver in future instead of LSI's inbox driver, I have posted it to upstream. Well, I will remove it once that specific need is no more required in future. Thanks Kashyap -----Original Message----- From: James Bottomley [mailto:James.Bottomley@xxxxxxxxxxxxxxxxxxxxx] Sent: Monday, April 06, 2009 8:16 PM To: Desai, Kashyap Cc: linux-scsi@xxxxxxxxxxxxxxx; Moore, Eric; Prakash, Sathya Subject: RE: [PATCH 2/6] mpt fusion: Firmware Event implementation using seperate WorkQueue 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
