2 PATCHES: fix request_tranferlength

2 PATCHES: fix request_tranferlength

[Matthew Dharm]

[-- Attachment #1: Type: text/plain, Size: 3481 bytes --]

These two BK patches fix two instances where a command is issued with an
incorrect transfer length.  The first is in the probing code... the section
where we make the second INQUIRY request for the full INQUIRY data.  The
second is in sd.c where the MODE_SENSE request is issued.

Both of these patches are requred to allow usb-storage devices to work
properly.  As a side-effect, this should reduce problems for all 'emulated
scsi' systems (ide-scsi, sbp2, etc).

Is there someone in particular I should send them to?  In the USB world,
all patches go to Greg K-H... what's the procedure here in SCSI land?

Matt

# This is a BitKeeper generated patch for the following project:
# Project Name: greg k-h's linux 2.5 USB kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.594   -> 1.595  
#	drivers/scsi/scsi_scan.c	1.9     -> 1.10   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/07/20	mdharm@zen.san.one-eyed-alien.net	1.595
# Fixed one of the INQUIRY commands used for probing SCSI devices.  This
# badly-formed command was trapped by the usb-storage driver BUG_ON() which
# is designed to stop command with a badly formed transfer_length field.
# --------------------------------------------
#
diff -Nru a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
--- a/drivers/scsi/scsi_scan.c	Sun Jul 21 00:55:37 2002
+++ b/drivers/scsi/scsi_scan.c	Sun Jul 21 00:55:37 2002
@@ -717,7 +717,7 @@
 
 		scsi_wait_req (SRpnt, (void *) scsi_cmd,
 			  (void *) scsi_result,
-			  256, SCSI_TIMEOUT+4*HZ, 3);
+			  scsi_cmd[4], SCSI_TIMEOUT+4*HZ, 3);
 		/* assume successful */
 	}
 	SDpnt->inquiry_len = possible_inq_resp_len;


# This is a BitKeeper generated patch for the following project:
# Project Name: greg k-h's linux 2.5 USB kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.595   -> 1.596  
#	   drivers/scsi/sd.c	1.22    -> 1.23   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/07/20	greg@kroah.com	1.7.2.39
# patch-2.5.27
# --------------------------------------------
# 02/07/20	greg@kroah.com	1.561.1.124
# Merge kroah.com:/home/linux/linux/linux-2.5
# into kroah.com:/home/linux/linux/tmp/linux-2.5
# --------------------------------------------
# 02/07/20	mdharm@zen.san.one-eyed-alien.net	1.596
# Modified the MODE_SENSE write-protect test in sd.c to issue a SCSI request
# with the request_bufflen the same size as the MODE_SENSE command being
# issued requests.
# --------------------------------------------
#
diff -Nru a/drivers/scsi/sd.c b/drivers/scsi/sd.c
--- a/drivers/scsi/sd.c	Sun Jul 21 00:55:44 2002
+++ b/drivers/scsi/sd.c	Sun Jul 21 00:55:44 2002
@@ -1102,7 +1102,7 @@
 	SRpnt->sr_data_direction = SCSI_DATA_READ;
 
 	scsi_wait_req(SRpnt, (void *) cmd, (void *) buffer,
-		      512, SD_TIMEOUT, MAX_RETRIES);
+		      255, SD_TIMEOUT, MAX_RETRIES);
 
 	the_result = SRpnt->sr_result;
 
-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

C:  Like the Furby?
DP: He gives me the creeps.  Think the SPCA will take him?
					-- Cobb and Dust Puppy
User Friendly, 1/2/1999

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: 2 PATCHES: fix request_tranferlength

[Willem Riede]

On 2002.07.21 18:15 Matthew Dharm wrote:
> These two BK patches fix two instances where a command is issued with an
> incorrect transfer length.  The first is in the probing code... the section
> where we make the second INQUIRY request for the full INQUIRY data.  The
> second is in sd.c where the MODE_SENSE request is issued.
> 
[snip]
> diff -Nru a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> --- a/drivers/scsi/sd.c	Sun Jul 21 00:55:44 2002
> +++ b/drivers/scsi/sd.c	Sun Jul 21 00:55:44 2002
> @@ -1102,7 +1102,7 @@
>  	SRpnt->sr_data_direction = SCSI_DATA_READ;
>  
>  	scsi_wait_req(SRpnt, (void *) cmd, (void *) buffer,
> -		      512, SD_TIMEOUT, MAX_RETRIES);
> +		      255, SD_TIMEOUT, MAX_RETRIES);
>  
>  	the_result = SRpnt->sr_result;
>  
Matt, 

is asking for an odd number of bytes a good idea? There have been problems
with doing so on OnStream tape drives...

Thanks, Willem Riede.

Re: 2 PATCHES: fix request_tranferlength

[Matthew Dharm]

[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]

We're asking for an odd number of bytes in the command... this just affects
the tranfer length field.  It doesn't actually change the command sent.

Also, this is the sd.c driver -- SCSI disks.  OnStream _tape_ drives are
unaffected by this change. :)

Matt

On Sun, Jul 21, 2002 at 06:52:33PM -0400, Willem Riede wrote:
> On 2002.07.21 18:15 Matthew Dharm wrote:
> > These two BK patches fix two instances where a command is issued with an
> > incorrect transfer length.  The first is in the probing code... the section
> > where we make the second INQUIRY request for the full INQUIRY data.  The
> > second is in sd.c where the MODE_SENSE request is issued.
> > 
> [snip]
> > diff -Nru a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> > --- a/drivers/scsi/sd.c	Sun Jul 21 00:55:44 2002
> > +++ b/drivers/scsi/sd.c	Sun Jul 21 00:55:44 2002
> > @@ -1102,7 +1102,7 @@
> >  	SRpnt->sr_data_direction = SCSI_DATA_READ;
> >  
> >  	scsi_wait_req(SRpnt, (void *) cmd, (void *) buffer,
> > -		      512, SD_TIMEOUT, MAX_RETRIES);
> > +		      255, SD_TIMEOUT, MAX_RETRIES);
> >  
> >  	the_result = SRpnt->sr_result;
> >  
> Matt, 
> 
> is asking for an odd number of bytes a good idea? There have been problems
> with doing so on OnStream tape drives...
> 
> Thanks, Willem Riede.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

I'm seen in many forms.  Now open your mouth.  It's caffeine time.
					-- Cola Man to Greg
User Friendly, 10/28/1998

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: 2 PATCHES: fix request_tranferlength

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 1284 bytes --]

Hi Matt,

On Sun, Jul 21, 2002 at 05:05:23PM -0700, Matthew Dharm wrote:
> We're asking for an odd number of bytes in the command... this just affects
> the tranfer length field.  It doesn't actually change the command sent.
> 
> Also, this is the sd.c driver -- SCSI disks.  OnStream _tape_ drives are
> unaffected by this change. :)

Sure. But Willem's remark is valid.

There has been a firmware bug in some old FW for OnStream tapes that made
them go nuts when inquired an odd length on a wide connection.
It's been fixed since long, but it may not be the only one.

According to Gérard, you can even expect error messages on a wide bus when
requesting odd numbers of bytes. Though I never agreed with his reasoning.
(IMHO: You should get an ignore wide residual message on reads; on writes you
 need to send one extra byte which the device should ignore. Neither of which
 I consider an error condition. Nor a situation where you have a residual.)

Regards,
-- 
Kurt Garloff                   <kurt@garloff.de>         [Eindhoven, NL]
Physics: Plasma simulations    <K.Garloff@TUE.NL>     [TU Eindhoven, NL]
Linux: SCSI, Security          <garloff@suse.de>    [SuSE Nuernberg, DE]
 (See mail header or public key servers for PGP2 and GPG public keys.)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 2 PATCHES: fix request_tranferlength

[Matthew Dharm]

[-- Attachment #1: Type: text/plain, Size: 4101 bytes --]

I haven't seen these patches integrated into a kernel yet... have I just
missed them, or is there some reason they have been rejected?

Matt

On Sun, Jul 21, 2002 at 03:15:23PM -0700, Matthew Dharm wrote:
> These two BK patches fix two instances where a command is issued with an
> incorrect transfer length.  The first is in the probing code... the section
> where we make the second INQUIRY request for the full INQUIRY data.  The
> second is in sd.c where the MODE_SENSE request is issued.
> 
> Both of these patches are requred to allow usb-storage devices to work
> properly.  As a side-effect, this should reduce problems for all 'emulated
> scsi' systems (ide-scsi, sbp2, etc).
> 
> Is there someone in particular I should send them to?  In the USB world,
> all patches go to Greg K-H... what's the procedure here in SCSI land?
> 
> Matt
> 
> # This is a BitKeeper generated patch for the following project:
> # Project Name: greg k-h's linux 2.5 USB kernel tree
> # This patch format is intended for GNU patch command version 2.5 or higher.
> # This patch includes the following deltas:
> #	           ChangeSet	1.594   -> 1.595  
> #	drivers/scsi/scsi_scan.c	1.9     -> 1.10   
> #
> # The following is the BitKeeper ChangeSet Log
> # --------------------------------------------
> # 02/07/20	mdharm@zen.san.one-eyed-alien.net	1.595
> # Fixed one of the INQUIRY commands used for probing SCSI devices.  This
> # badly-formed command was trapped by the usb-storage driver BUG_ON() which
> # is designed to stop command with a badly formed transfer_length field.
> # --------------------------------------------
> #
> diff -Nru a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> --- a/drivers/scsi/scsi_scan.c	Sun Jul 21 00:55:37 2002
> +++ b/drivers/scsi/scsi_scan.c	Sun Jul 21 00:55:37 2002
> @@ -717,7 +717,7 @@
>  
>  		scsi_wait_req (SRpnt, (void *) scsi_cmd,
>  			  (void *) scsi_result,
> -			  256, SCSI_TIMEOUT+4*HZ, 3);
> +			  scsi_cmd[4], SCSI_TIMEOUT+4*HZ, 3);
>  		/* assume successful */
>  	}
>  	SDpnt->inquiry_len = possible_inq_resp_len;
> 
> 
> # This is a BitKeeper generated patch for the following project:
> # Project Name: greg k-h's linux 2.5 USB kernel tree
> # This patch format is intended for GNU patch command version 2.5 or higher.
> # This patch includes the following deltas:
> #	           ChangeSet	1.595   -> 1.596  
> #	   drivers/scsi/sd.c	1.22    -> 1.23   
> #
> # The following is the BitKeeper ChangeSet Log
> # --------------------------------------------
> # 02/07/20	greg@kroah.com	1.7.2.39
> # patch-2.5.27
> # --------------------------------------------
> # 02/07/20	greg@kroah.com	1.561.1.124
> # Merge kroah.com:/home/linux/linux/linux-2.5
> # into kroah.com:/home/linux/linux/tmp/linux-2.5
> # --------------------------------------------
> # 02/07/20	mdharm@zen.san.one-eyed-alien.net	1.596
> # Modified the MODE_SENSE write-protect test in sd.c to issue a SCSI request
> # with the request_bufflen the same size as the MODE_SENSE command being
> # issued requests.
> # --------------------------------------------
> #
> diff -Nru a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> --- a/drivers/scsi/sd.c	Sun Jul 21 00:55:44 2002
> +++ b/drivers/scsi/sd.c	Sun Jul 21 00:55:44 2002
> @@ -1102,7 +1102,7 @@
>  	SRpnt->sr_data_direction = SCSI_DATA_READ;
>  
>  	scsi_wait_req(SRpnt, (void *) cmd, (void *) buffer,
> -		      512, SD_TIMEOUT, MAX_RETRIES);
> +		      255, SD_TIMEOUT, MAX_RETRIES);
>  
>  	the_result = SRpnt->sr_result;
>  
> -- 
> Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
> Maintainer, Linux USB Mass Storage Driver
> 
> C:  Like the Furby?
> DP: He gives me the creeps.  Think the SPCA will take him?
> 					-- Cobb and Dust Puppy
> User Friendly, 1/2/1999



-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

I say, what are all those naked people doing?
					-- Big client to Stef
User Friendly, 12/14/1997

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: 2 PATCHES: fix request_tranferlength

[Alan Cox]

On Sat, 2002-07-27 at 23:07, Matthew Dharm wrote:
> >  	scsi_wait_req(SRpnt, (void *) cmd, (void *) buffer,
> > -		      512, SD_TIMEOUT, MAX_RETRIES);
> > +		      255, SD_TIMEOUT, MAX_RETRIES);

Adjust it and the buffer size to be even and I'll test run it in -ac

Re: 2 PATCHES: fix request_tranferlength

[Randy.Dunlap]

On 29 Jul 2002, Alan Cox wrote:

| On Sat, 2002-07-27 at 23:07, Matthew Dharm wrote:
| > >  	scsi_wait_req(SRpnt, (void *) cmd, (void *) buffer,
| > > -		      512, SD_TIMEOUT, MAX_RETRIES);
| > > +		      255, SD_TIMEOUT, MAX_RETRIES);
|
| Adjust it and the buffer size to be even and I'll test run it in -ac

One of the earlier emails quoted a 252 max. size from a newer spec.

-- 
~Randy

Re: 2 PATCHES: fix request_tranferlength

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]

On Mon, Jul 29, 2002 at 09:00:21AM -0700, Randy.Dunlap wrote:
> On 29 Jul 2002, Alan Cox wrote:
> 
> | On Sat, 2002-07-27 at 23:07, Matthew Dharm wrote:
> | > >  	scsi_wait_req(SRpnt, (void *) cmd, (void *) buffer,
> | > > -		      512, SD_TIMEOUT, MAX_RETRIES);
> | > > +		      255, SD_TIMEOUT, MAX_RETRIES);
> |
> | Adjust it and the buffer size to be even and I'll test run it in -ac
> 
> One of the earlier emails quoted a 252 max. size from a newer spec.

252 is also what I used in my sd-many patches
http://www.suse.de/~garloff/scsi-many/

It does not incur a IGNORE_WIDE_RESIDUAL even on wide32 buses. Probably
that's why this size was specified for some transfers.

Regards,
-- 
Kurt Garloff                   <kurt@garloff.de>         [Eindhoven, NL]
Physics: Plasma simulations    <K.Garloff@TUE.NL>     [TU Eindhoven, NL]
Linux: SCSI, Security          <garloff@suse.de>    [SuSE Nuernberg, DE]
 (See mail header or public key servers for PGP2 and GPG public keys.)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]