Re: Problem with an USB Stick and kernel 2.6.1

Re: Problem with an USB Stick and kernel 2.6.1

[Alan Stern]

Help!  This is a problem in the interface between usb-storage and the SCSI
core (or maybe the block layer core).  The core thinks there is an error
when in fact there isn't.

On Fri, 16 Jan 2004, Florian Lohoff wrote:

> On Fri, Jan 16, 2004 at 12:48:00PM +0100, Alexander Motzkau wrote:
> > Hello,
> > 
> > I've got some problem with an USB Stick ("Floppy-on-Disc" Vendor=0ea0
> > ProdID=6828 Rev=1.10). It's an USB2 Stick, but I'm using it on an
> > USB 1.1-Controller (Intel 82801BA/BAM, Intel 815 Chipset).
> > 
> > The problem does occur with Kernel 2.6.1-rc1 (and 2.6.1), but not with
> > Kernel 2.6.0 (an 2.4.21).
> 
> I am having the same problem with the same Stick - For me the problem
> started with 2.6.0-test11 IIRC and is still valid for 2.6.1. All 2.4 kernel
> work - Mine is a
<snip>
> Here is my usb-storage debugging:

> usb-storage: Command READ_10 (10 bytes)
> usb-storage:  28 00 00 00 00 20 00 00 01 00
> usb-storage: Bulk Command S 0x43425355 T 0x1f L 512 F 128 Trg 0 LUN 0 CL 10
> usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
> usb-storage: Status code 0; transferred 31/31
> usb-storage: -- transfer complete
> usb-storage: Bulk command transfer result=0
> usb-storage: usb_stor_bulk_transfer_sglist: xfer 512 bytes, 1 entries
> usb-storage: Status code 0; transferred 512/512
> usb-storage: -- transfer complete
> usb-storage: Bulk data transfer result 0x0
> usb-storage: Attempting to get CSW...
> usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
> usb-storage: Status code 0; transferred 13/13
> usb-storage: -- transfer complete
> usb-storage: Bulk status result = 0
> usb-storage: Bulk Status S 0x53425355 T 0x1f R 512 Stat 0x0

The READ completes successfully and transfers all 512 bytes, but the 
device reports a residue of 512 (probably a bug in the firmware).  Seeing 
a positive residue for the read, usb-storage does an auto-sense:

> usb-storage: -- unexpectedly short transfer
> usb-storage: Issuing auto-REQUEST_SENSE
<...>
> usb-storage: -- Result from auto-sense is 0
> usb-storage: -- code: 0x70, key: 0x0, ASC: 0x0, ASCQ: 0x0
> usb-storage: No Sense: No additional sense information
> usb-storage: scsi cmd done, result=0x0
> usb-storage: *** thread sleeping.

Seeing no sense key, usb-storage returns 0 indicating the command
succeeded.  But scsi_finish_command() sees that valid sense data is
present and sets the driver_byte to DRIVER_SENSE.

> SCSI error : <1 0 0 0> return code = 0x8000000
> Current sda: sense key No Sense

This causes scsi_io_completion() to call scsi_end_request() with uptodate 
= 0 and results in this error:

> end_request: I/O error, dev sda, sector 32
> FAT: unable to read boot sector

How should we handle this?  Should we zero out sense_buffer[0] when 
auto-sense shows sense key = NO_SENSE?

Alan Stern



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: Problem with an USB Stick and kernel 2.6.1

[Mike Anderson]

Alan Stern [stern@rowland.harvard.edu] wrote:
> 
> Seeing no sense key, usb-storage returns 0 indicating the command
> succeeded.  But scsi_finish_command() sees that valid sense data is
> present and sets the driver_byte to DRIVER_SENSE.
> 
> > SCSI error : <1 0 0 0> return code = 0x8000000
> > Current sda: sense key No Sense
> 
> This causes scsi_io_completion() to call scsi_end_request() with uptodate 
> = 0 and results in this error:
> 
> > end_request: I/O error, dev sda, sector 32
> > FAT: unable to read boot sector
> 
> How should we handle this?  Should we zero out sense_buffer[0] when 
> auto-sense shows sense key = NO_SENSE?
> 

I would think the upper level driver should handle this. We decode
RECOVERED_ERROR in sd. sd could just handle NO_SENSE the same with /
without the print_sense. I noticed that st and osst under some
circumstances look at the NO_SENSE case (the tape people will need to
comment as this looks like a EOM workaround) so it would seem incorrect
for the LLDD as a general policy to say it received no sense when it
did.

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

Re: Problem with an USB Stick and kernel 2.6.1

[Alan Stern]

On Fri, 16 Jan 2004, Mike Anderson wrote:

> Alan Stern [stern@rowland.harvard.edu] wrote:
> > 
> > Seeing no sense key, usb-storage returns 0 indicating the command
> > succeeded.  But scsi_finish_command() sees that valid sense data is
> > present and sets the driver_byte to DRIVER_SENSE.
> > 
> > > SCSI error : <1 0 0 0> return code = 0x8000000
> > > Current sda: sense key No Sense
> > 
> > This causes scsi_io_completion() to call scsi_end_request() with uptodate 
> > = 0 and results in this error:
> > 
> > > end_request: I/O error, dev sda, sector 32
> > > FAT: unable to read boot sector
> > 
> > How should we handle this?  Should we zero out sense_buffer[0] when 
> > auto-sense shows sense key = NO_SENSE?
> > 
> 
> I would think the upper level driver should handle this. We decode
> RECOVERED_ERROR in sd. sd could just handle NO_SENSE the same with /
> without the print_sense. I noticed that st and osst under some
> circumstances look at the NO_SENSE case (the tape people will need to
> comment as this looks like a EOM workaround) so it would seem incorrect
> for the LLDD as a general policy to say it received no sense when it
> did.

Florian and Alexander, does this patch fix your problem?  Mike, how does 
it look to you?

Alan Stern


===== sd.c 1.59 vs edited =====
--- 1.59/drivers/scsi/sd.c	Fri Oct 24 14:53:37 2003
+++ edited/drivers/scsi/sd.c	Fri Jan 16 15:49:48 2004
@@ -730,6 +730,14 @@
 			 * hard error.
 			 */
 			print_sense("sd", SCpnt);
+			/* FALLS THROUGH */
+
+		case NO_SENSE:
+			/*
+			 * The low-level driver got the sense data but
+			 * everything was all right.  Don't treat this
+			 * an an error.
+			 */
 			SCpnt->result = 0;
 			SCpnt->sense_buffer[0] = 0x0;
 			good_sectors = this_count;

Re: Problem with an USB Stick and kernel 2.6.1

[Mike Anderson]

This matches what I thought should be added to sd, but I did not hear an
answer from James / others if this is the way we should handle it.

Alan Stern [stern@rowland.harvard.edu] wrote:
> On Fri, 16 Jan 2004, Mike Anderson wrote:
> 
> > Alan Stern [stern@rowland.harvard.edu] wrote:
> > > 
> > > Seeing no sense key, usb-storage returns 0 indicating the command
> > > succeeded.  But scsi_finish_command() sees that valid sense data is
> > > present and sets the driver_byte to DRIVER_SENSE.
> > > 
> > > > SCSI error : <1 0 0 0> return code = 0x8000000
> > > > Current sda: sense key No Sense
> > > 
> > > This causes scsi_io_completion() to call scsi_end_request() with uptodate 
> > > = 0 and results in this error:
> > > 
> > > > end_request: I/O error, dev sda, sector 32
> > > > FAT: unable to read boot sector
> > > 
> > > How should we handle this?  Should we zero out sense_buffer[0] when 
> > > auto-sense shows sense key = NO_SENSE?
> > > 
> > 
> > I would think the upper level driver should handle this. We decode
> > RECOVERED_ERROR in sd. sd could just handle NO_SENSE the same with /
> > without the print_sense. I noticed that st and osst under some
> > circumstances look at the NO_SENSE case (the tape people will need to
> > comment as this looks like a EOM workaround) so it would seem incorrect
> > for the LLDD as a general policy to say it received no sense when it
> > did.
> 
> Florian and Alexander, does this patch fix your problem?  Mike, how does 
> it look to you?
> 
> Alan Stern
> 
> 
> ===== sd.c 1.59 vs edited =====
> --- 1.59/drivers/scsi/sd.c	Fri Oct 24 14:53:37 2003
> +++ edited/drivers/scsi/sd.c	Fri Jan 16 15:49:48 2004
> @@ -730,6 +730,14 @@
>  			 * hard error.
>  			 */
>  			print_sense("sd", SCpnt);
> +			/* FALLS THROUGH */
> +
> +		case NO_SENSE:
> +			/*
> +			 * The low-level driver got the sense data but
> +			 * everything was all right.  Don't treat this
> +			 * an an error.
> +			 */
>  			SCpnt->result = 0;
>  			SCpnt->sense_buffer[0] = 0x0;
>  			good_sectors = this_count;
> 
-andmike
--
Michael Anderson
andmike@us.ibm.com



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: Problem with an USB Stick and kernel 2.6.1

[James Bottomley]

On Fri, 2004-01-16 at 16:27, Mike Anderson wrote:
> This matches what I thought should be added to sd, but I did not hear an
> answer from James / others if this is the way we should handle it.

Actually, perhaps we should treat it *exactly* the same as
RECOVERED_ERROR (i.e. do the print_sense) so that if something goes
wrong with ignoring NO_SENSE returns, we have a trace that it happened.

otherwise I'm fine with this.

James




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: Problem with an USB Stick and kernel 2.6.1

[Alexander Motzkau]

Alan Stern wrote:
> Florian and Alexander, does this patch fix your problem?  Mike, how does
> it look to you?

Works for me. (Kernel 2.6.1)

Thank you!
Alex


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: Problem with an USB Stick and kernel 2.6.1

[Alan Stern]

Regarding DRIVER_SENSE with NO_SENSE data:

On 16 Jan 2004, James Bottomley wrote:

> On Fri, 2004-01-16 at 16:27, Mike Anderson wrote:
> > This matches what I thought should be added to sd, but I did not hear an
> > answer from James / others if this is the way we should handle it.
> 
> Actually, perhaps we should treat it *exactly* the same as
> RECOVERED_ERROR (i.e. do the print_sense) so that if something goes
> wrong with ignoring NO_SENSE returns, we have a trace that it happened.

I'm concerned that these devices will provoke a driver sense on _every_
read or write, since they report an incorrect residue.  Is it reasonable
to print_sense on every I/O operation?

Also, in sd.c the code tests DRIVER_SENSE in a number of places, not all 
of which appear appropriate.  It looks like that test is used where 
SCSI_SENSE_VALID would be better.  Is this something that ought to be 
fixed?

Alan Stern

Re: Problem with an USB Stick and kernel 2.6.1

[Florian Lohoff]

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


Hi,
better late than never - Yes - this fixes the no sense problem for
me. Patch still applied to 2.6.3 without offset and fixes the problem. 

Mainline please !

Flo

On Fri, Jan 16, 2004 at 03:53:18PM -0500, Alan Stern wrote:
> 
> Florian and Alexander, does this patch fix your problem?  Mike, how does 
> it look to you?
> 
> Alan Stern
> 
> 
> ===== sd.c 1.59 vs edited =====
> --- 1.59/drivers/scsi/sd.c	Fri Oct 24 14:53:37 2003
> +++ edited/drivers/scsi/sd.c	Fri Jan 16 15:49:48 2004
> @@ -730,6 +730,14 @@
>  			 * hard error.
>  			 */
>  			print_sense("sd", SCpnt);
> +			/* FALLS THROUGH */
> +
> +		case NO_SENSE:
> +			/*
> +			 * The low-level driver got the sense data but
> +			 * everything was all right.  Don't treat this
> +			 * an an error.
> +			 */
>  			SCpnt->result = 0;
>  			SCpnt->sense_buffer[0] = 0x0;
>  			good_sectors = this_count;

-- 
Florian Lohoff                  flo@rfc822.org             +49-171-2280134
                        Heisenberg may have been here.

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

Re: Problem with an USB Stick and kernel 2.6.1

[Alan Stern]

On Sun, 29 Feb 2004, Florian Lohoff wrote:

> 
> Hi,
> better late than never - Yes - this fixes the no sense problem for
> me. Patch still applied to 2.6.3 without offset and fixes the problem. 
> 
> Mainline please !

A change for this has been submitted, but it's different from the one 
you're talking about.  It should appear in 2.6.4.

Alan Stern



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel