linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian King <brking@us.ibm.com>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH] p00001_scsi_tcq_queue_lock
Date: Fri, 17 Sep 2004 12:55:52 -0500	[thread overview]
Message-ID: <414B2528.1020409@us.ibm.com> (raw)
In-Reply-To: <4117846B.7030302@us.ibm.com>

James,

Any chance of applying this patch? I think most of the issues you raised
I've answered. This patch certainly does not preclude other LLD's from
quiescing the device before changing the tcqing state if they need to.

Or would you prefer adding code to the scsi core to quiesce the device
before changing its tcqing state? The scsi core could feasibly quiesce the
device, enable or disable tagged queuing, then resume the queue. I haven't
looked at generating a patch for this yet, so I'm not sure how simple it
would be to do what I am suggesting...

Thanks

-Brian


Brian King wrote:
> James Bottomley wrote:
> 
>> On Tue, 2004-08-03 at 10:49, Brian King wrote:
>>
>>> Add locking to scsi_activate_tcq and scsi_deactivate_tcq to fix a race
>>> condition that can occur when disabling tcqing with commands in flight.
>>
>>
>>
>> It's possible to do it like this.  However, we should really quiesce the
>> SCSI device before disabling tcq.  It is not legal in the scsi spec to
>> have both tagged and untagged commands outstanding.  Most drives do the
>> right thing and return BUSY to an untagged request if they have tags in
>> flight.  
> 
> 
> Ok. I agree that we do not want both tagged and untagged requests going 
> to the device. In the case of the ipr driver, the adapter microcode 
> handles this for me. If there are tagged requests outstanding to a 
> device and an untagged request is sent, the tagged requests must first 
> finish, then the untagged request is sent to the device with no other 
> requests outstanding.
> 
>> Also, we have to wait until all tags return before freeing the
>> block layer tag structures...and there's always the devices that do
>> strange things in this situation...
> 

The block layer now handles this appropriately and does not free the tags
until blk_cleanup_queue is called.


> diff -puN include/scsi/scsi_tcq.h~blk_queue_free_tags_bug2 include/scsi/scsi_tcq.h
> --- linux-2.6.8-rc2/include/scsi/scsi_tcq.h~blk_queue_free_tags_bug2	2004-08-02 17:02:43.000000000 -0500
> +++ linux-2.6.8-rc2-bjking1/include/scsi/scsi_tcq.h	2004-08-02 17:02:43.000000000 -0500
> @@ -25,9 +25,13 @@
>   **/
>  static inline void scsi_activate_tcq(struct scsi_device *sdev, int depth)
>  {
> +        unsigned long flags;
> +
>          if (sdev->tagged_supported) {
> +		spin_lock_irqsave(sdev->request_queue->queue_lock, flags);
>  		if (!blk_queue_tagged(sdev->request_queue))
>  			blk_queue_init_tags(sdev->request_queue, depth, NULL);
> +		spin_unlock_irqrestore(sdev->request_queue->queue_lock, flags);
>  		scsi_adjust_queue_depth(sdev, MSG_ORDERED_TAG, depth);
>          }
>  }
> @@ -38,8 +42,12 @@ static inline void scsi_activate_tcq(str
>   **/
>  static inline void scsi_deactivate_tcq(struct scsi_device *sdev, int depth)
>  {
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(sdev->request_queue->queue_lock, flags);
>  	if (blk_queue_tagged(sdev->request_queue))
>  		blk_queue_free_tags(sdev->request_queue);
> +	spin_unlock_irqrestore(sdev->request_queue->queue_lock, flags);
>  	scsi_adjust_queue_depth(sdev, 0, depth);
>  }
>  
> _

-- 
Brian King
eServer Storage I/O
IBM Linux Technology Center


      parent reply	other threads:[~2004-09-17 17:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-03 17:49 [PATCH] p00001_scsi_tcq_queue_lock Brian King
2004-08-07  4:09 ` James Bottomley
2004-08-09 14:04   ` Brian King
2004-08-09 14:14     ` Brian King
2004-09-17 17:55     ` Brian King [this message]

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=414B2528.1020409@us.ibm.com \
    --to=brking@us.ibm.com \
    --cc=James.Bottomley@SteelEye.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;
as well as URLs for NNTP newsgroup(s).