public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: "Desai, Kashyap" <Kashyap.Desai@lsi.com>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"Moore, Eric" <Eric.Moore@lsi.com>,
	"Prakash, Sathya" <Sathya.Prakash@lsi.com>
Subject: RE: [PATCH 2/6] mpt fusion: Firmware Event implementation using seperate WorkQueue
Date: Mon, 06 Apr 2009 14:45:35 +0000	[thread overview]
Message-ID: <1239029135.3641.3.camel@mulgrave> (raw)
In-Reply-To: <0D1E8821739E724A86F4D16902CE275C1410F4CA52@inbmail01.lsi.com>

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



  reply	other threads:[~2009-04-06 14:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-03 11:50 [PATCH 2/6] mpt fusion: Firmware Event implementation using seperate WorkQueue Kashyap, Desai
2009-04-03 18:21 ` James Bottomley
2009-04-06  8:17   ` Desai, Kashyap
2009-04-06 14:45     ` James Bottomley [this message]
2009-04-07 13:48       ` Desai, Kashyap
2009-04-07 15:46         ` James Bottomley
2009-04-06  8:44 ` Jesper Krogh
2009-04-06  9:06   ` Desai, Kashyap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1239029135.3641.3.camel@mulgrave \
    --to=james.bottomley@hansenpartnership.com \
    --cc=Eric.Moore@lsi.com \
    --cc=Kashyap.Desai@lsi.com \
    --cc=Sathya.Prakash@lsi.com \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox