[PATCH] 2.5.67+ scsi_release_request call queue next

[PATCH] 2.5.67+ scsi_release_request call queue next

[Mike Anderson]

This patch is against 2.5.67 as of 04-14 as it needs extern for
scsi_queue_next_request.

I just compiled and booted this patch. I currently do not have a setup to
check door lock post error recovery.

-andmike
--
Michael Anderson
andmike@us.ibm.com


DESC
The patch adds a call to scsi_queue_next_request from scsi_release_request. It
also removes a call in scsi_eh_lock_done to scsi_put_command.
scsi_release_request will do a call to scsi_put_command if needed.
EDESC


 drivers/scsi/scsi.c       |    2 ++
 drivers/scsi/scsi_error.c |    4 ----
 2 files changed, 2 insertions(+), 4 deletions(-)

diff -puN drivers/scsi/scsi.c~scsi-release-req drivers/scsi/scsi.c
--- sysfs-bleed-2.5/drivers/scsi/scsi.c~scsi-release-req	Mon Apr 14 15:34:14 2003
+++ sysfs-bleed-2.5-andmike/drivers/scsi/scsi.c	Mon Apr 14 15:34:14 2003
@@ -224,8 +224,10 @@ void scsi_release_request(Scsi_Request *
 {
 	if( req->sr_command != NULL )
 	{
+    		request_queue_t *q = req->sr_device->request_queue;
 		scsi_put_command(req->sr_command);
 		req->sr_command = NULL;
+		scsi_queue_next_request(q, NULL);
 	}
 
 	kfree(req);
diff -puN drivers/scsi/scsi_error.c~scsi-release-req drivers/scsi/scsi_error.c
--- sysfs-bleed-2.5/drivers/scsi/scsi_error.c~scsi-release-req	Mon Apr 14 15:34:14 2003
+++ sysfs-bleed-2.5-andmike/drivers/scsi/scsi_error.c	Mon Apr 14 15:34:14 2003
@@ -1334,10 +1334,6 @@ static void scsi_eh_lock_done(struct scs
 {
 	struct scsi_request *sreq = scmd->sc_request;
 
-	scmd->sc_request = NULL;
-	sreq->sr_command = NULL;
-
-	scsi_put_command(scmd);
 	scsi_release_request(sreq);
 }
 

_

Trivial patch for scsi logging text string

[Alan Stern]

Greg:

This patch fixes a very minor bobble in a kernel logging string (excess 
blank space following the \n).  Please apply.

Alan Stern

--- 1.34/drivers/scsi/scsi_lib.c	Mon Apr  7 06:33:23 2003
+++ edited/drivers/scsi/scsi_lib.c	Tue Apr 15 10:58:22 2003
@@ -703,7 +703,7 @@
 	if (good_sectors >= 0) {
 		SCSI_LOG_HLCOMPLETE(1, printk("%ld sectors total, %d sectors done.\n",
 					      req->nr_sectors, good_sectors));
-		SCSI_LOG_HLCOMPLETE(1, printk("use_sg is %d\n ", cmd->use_sg));
+		SCSI_LOG_HLCOMPLETE(1, printk("use_sg is %d\n", cmd->use_sg));
 
 		if (clear_errors)
 			req->errors = 0;

Re: Trivial patch for scsi logging text string

[Greg KH]

On Tue, Apr 15, 2003 at 11:01:31AM -0400, Alan Stern wrote:
> Greg:
> 
> This patch fixes a very minor bobble in a kernel logging string (excess 
> blank space following the \n).  Please apply.
> 
> Alan Stern
> 
> --- 1.34/drivers/scsi/scsi_lib.c	Mon Apr  7 06:33:23 2003
> +++ edited/drivers/scsi/scsi_lib.c	Tue Apr 15 10:58:22 2003

Hm, I don't think I can submit scsi patches to Linus :)
Why not send them to the scsi maintainers...

thanks,

greg k-h

Re: Trivial patch for scsi logging text string

[James Bottomley]

On Tue, 2003-04-15 at 12:03, Greg KH wrote:
> Hm, I don't think I can submit scsi patches to Linus :)
> Why not send them to the scsi maintainers...

The SCSI maintainers are linux-scsi@vger.kernel.org, so we've already
been copied on this one.

James

Re: Trivial patch for scsi logging text string

[Alan Stern]

On 15 Apr 2003, James Bottomley wrote:

> On Tue, 2003-04-15 at 12:03, Greg KH wrote:
> > Hm, I don't think I can submit scsi patches to Linus :)
> > Why not send them to the scsi maintainers...
> 
> The SCSI maintainers are linux-scsi@vger.kernel.org, so we've already
> been copied on this one.
> 
> James

Does that mean that linux-scsi will forward my patch to Linus?  I hope so,
because I've got another one to submit (to Marcelo), more substantive this
time.

In 2.4.21-pre7, when the scsi error-handler decides that it has cleaned 
things up and retries the original command, it neglects to zero out the 
command's sense buffer first.  In all likelihood the sense buffer will 
contain old data left over from the error recovery operations.  This 
confuses scan_scsis(), which thinks that because there is valid sense data 
its INQUIRY probe must have failed.  This patch clears the sense buffer 
before a retry.

If nobody on the linux-scsi list objects to it, this patch should be 
applied.

Alan Stern


--- 2.4.21-pre7/drivers/scsi/scsi_error.c.orig	Tue Apr 15 11:18:35 2003
+++ 2.4.21-pre7/drivers/scsi/scsi_error.c	Tue Apr 15 11:19:29 2003
@@ -393,6 +393,7 @@
 	SCpnt->cmd_len = SCpnt->old_cmd_len;
 	SCpnt->sc_data_direction = SCpnt->sc_old_data_direction;
 	SCpnt->underflow = SCpnt->old_underflow;
+	memset(SCpnt->sense_buffer, 0, sizeof(SCpnt->sense_buffer));
 
 	scsi_send_eh_cmnd(SCpnt, SCpnt->timeout_per_command);
 

Re: [PATCH] 2.5.67+ scsi_release_request call queue next

[Alan Stern]

On Mon, 14 Apr 2003, Mike Anderson wrote:

> This patch is against 2.5.67 as of 04-14 as it needs extern for
> scsi_queue_next_request.
> 
> I just compiled and booted this patch. I currently do not have a setup to
> check door lock post error recovery.

Mike:

I just tried your patch.  I had to make scsi_queue_next_request() 
non-static to get things to link properly, but after doing so it seemed to 
work just fine.  After the door-lock command finished, the request queue 
moved right along and all the data was transferred correctly.

Thanks.

Alan Stern

Re: Trivial patch for scsi logging text string

[James Bottomley]

On Tue, 2003-04-15 at 14:31, Alan Stern wrote:
> On 15 Apr 2003, James Bottomley wrote:
> 
> > On Tue, 2003-04-15 at 12:03, Greg KH wrote:
> > > Hm, I don't think I can submit scsi patches to Linus :)
> > > Why not send them to the scsi maintainers...
> > 
> > The SCSI maintainers are linux-scsi@vger.kernel.org, so we've already
> > been copied on this one.
> > 
> > James
> 
> Does that mean that linux-scsi will forward my patch to Linus?  I hope so,
> because I've got another one to submit (to Marcelo), more substantive this
> time.

Yes, for 2.5

> In 2.4.21-pre7, when the scsi error-handler decides that it has cleaned 
> things up and retries the original command, it neglects to zero out the 
> command's sense buffer first.  In all likelihood the sense buffer will 
> contain old data left over from the error recovery operations.  This 
> confuses scan_scsis(), which thinks that because there is valid sense data 
> its INQUIRY probe must have failed.  This patch clears the sense buffer 
> before a retry.
> 
> If nobody on the linux-scsi list objects to it, this patch should be 
> applied.

2.4 is more tricky.  Since fixing 2.5 is pretty much a full time job,
there's no-one really who looks after SCSI in 2.4.  It's probably best
to send it to Marcelo along with an explanation of what the problem is.

James

Re: [PATCH] 2.5.67+ scsi_release_request call queue next

[Mike Anderson]

Alan Stern [stern@rowland.harvard.edu] wrote:
> Mike:
> 
> I just tried your patch.  I had to make scsi_queue_next_request() 
> non-static to get things to link properly, but after doing so it seemed to 
> work just fine.  After the door-lock command finished, the request queue 
> moved right along and all the data was transferred correctly.

Good to see it worked. The non-static change should be in the bk current
tree already.

-andmike
--
Michael Anderson
andmike@us.ibm.com

Re: [PATCH] 2.5.67+ scsi_release_request call queue next

[Alan Stern]

Mike:

I just noticed that your patch below isn't included in 2.5.68.  It still
works just fine.  Is it going to be submitted?

Alan Stern


Date: Mon, 14 Apr 2003 23:33:03 -0700
From: Mike Anderson <andmike@us.ibm.com>
To: linux-scsi@vger.kernel.org
Cc: stern@rowland.harvard.edu
Subject: [PATCH] 2.5.67+ scsi_release_request call queue next

This patch is against 2.5.67 as of 04-14 as it needs extern for
scsi_queue_next_request.

I just compiled and booted this patch. I currently do not have a setup to
check door lock post error recovery.

-andmike
--
Michael Anderson
andmike@us.ibm.com


DESC
The patch adds a call to scsi_queue_next_request from scsi_release_request. It
also removes a call in scsi_eh_lock_done to scsi_put_command.
scsi_release_request will do a call to scsi_put_command if needed.
EDESC


 drivers/scsi/scsi.c       |    2 ++
 drivers/scsi/scsi_error.c |    4 ----
 2 files changed, 2 insertions(+), 4 deletions(-)

diff -puN drivers/scsi/scsi.c~scsi-release-req drivers/scsi/scsi.c
--- sysfs-bleed-2.5/drivers/scsi/scsi.c~scsi-release-req	Mon Apr 14 15:34:14 2003
+++ sysfs-bleed-2.5-andmike/drivers/scsi/scsi.c	Mon Apr 14 15:34:14 2003
@@ -224,8 +224,10 @@ void scsi_release_request(Scsi_Request *
 {
 	if( req->sr_command != NULL )
 	{
+    		request_queue_t *q = req->sr_device->request_queue;
 		scsi_put_command(req->sr_command);
 		req->sr_command = NULL;
+		scsi_queue_next_request(q, NULL);
 	}
 
 	kfree(req);
diff -puN drivers/scsi/scsi_error.c~scsi-release-req drivers/scsi/scsi_error.c
--- sysfs-bleed-2.5/drivers/scsi/scsi_error.c~scsi-release-req	Mon Apr 14 15:34:14 2003
+++ sysfs-bleed-2.5-andmike/drivers/scsi/scsi_error.c	Mon Apr 14 15:34:14 2003
@@ -1334,10 +1334,6 @@ static void scsi_eh_lock_done(struct scs
 {
 	struct scsi_request *sreq = scmd->sc_request;
 
-	scmd->sc_request = NULL;
-	sreq->sr_command = NULL;
-
-	scsi_put_command(scmd);
 	scsi_release_request(sreq);
 }
 

_

Re: [PATCH] 2.5.67+ scsi_release_request call queue next

[Mike Anderson]

It is already in bk current and James scsi-misc-2.5. The scsi.c file
also includes Christoph's cleanups. I do not know the change set number.


Alan Stern [stern@rowland.harvard.edu] wrote:
> Mike:
> 
> I just noticed that your patch below isn't included in 2.5.68.  It still
> works just fine.  Is it going to be submitted?
> 
> Alan Stern
> 
> 
> Date: Mon, 14 Apr 2003 23:33:03 -0700
> From: Mike Anderson <andmike@us.ibm.com>
> To: linux-scsi@vger.kernel.org
> Cc: stern@rowland.harvard.edu
> Subject: [PATCH] 2.5.67+ scsi_release_request call queue next
> 
> This patch is against 2.5.67 as of 04-14 as it needs extern for
> scsi_queue_next_request.
> 
> I just compiled and booted this patch. I currently do not have a setup to
> check door lock post error recovery.
> 
> -andmike
> --
> Michael Anderson
> andmike@us.ibm.com
> 
> 
> DESC
> The patch adds a call to scsi_queue_next_request from scsi_release_request. It
> also removes a call in scsi_eh_lock_done to scsi_put_command.
> scsi_release_request will do a call to scsi_put_command if needed.
> EDESC
> 
> 
>  drivers/scsi/scsi.c       |    2 ++
>  drivers/scsi/scsi_error.c |    4 ----
>  2 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff -puN drivers/scsi/scsi.c~scsi-release-req drivers/scsi/scsi.c
> --- sysfs-bleed-2.5/drivers/scsi/scsi.c~scsi-release-req	Mon Apr 14 15:34:14 2003
> +++ sysfs-bleed-2.5-andmike/drivers/scsi/scsi.c	Mon Apr 14 15:34:14 2003
> @@ -224,8 +224,10 @@ void scsi_release_request(Scsi_Request *
>  {
>  	if( req->sr_command != NULL )
>  	{
> +    		request_queue_t *q = req->sr_device->request_queue;
>  		scsi_put_command(req->sr_command);
>  		req->sr_command = NULL;
> +		scsi_queue_next_request(q, NULL);
>  	}
>  
>  	kfree(req);
> diff -puN drivers/scsi/scsi_error.c~scsi-release-req drivers/scsi/scsi_error.c
> --- sysfs-bleed-2.5/drivers/scsi/scsi_error.c~scsi-release-req	Mon Apr 14 15:34:14 2003
> +++ sysfs-bleed-2.5-andmike/drivers/scsi/scsi_error.c	Mon Apr 14 15:34:14 2003
> @@ -1334,10 +1334,6 @@ static void scsi_eh_lock_done(struct scs
>  {
>  	struct scsi_request *sreq = scmd->sc_request;
>  
> -	scmd->sc_request = NULL;
> -	sreq->sr_command = NULL;
> -
> -	scsi_put_command(scmd);
>  	scsi_release_request(sreq);
>  }
>  
> 
> _
> 
> 
> 
-andmike
--
Michael Anderson
andmike@us.ibm.com