[PATCH] fix Sony USB mass storage - pass larger receive buffer

[PATCH] fix Sony USB mass storage - pass larger receive buffer

[Patrick Mansfield]

James - can you please apply? This should not affect other devices since
we are not changing the requested length, just the size of the receive
buffer.

This patch against a recent 2.6 bk fixes problems with Sony USB mass
storage devices: they are sending back 10 bytes even when we ask for 8
bytes (USB babble).

Just use a larger receive buffer for MODE SENSE even though we are
requesting 8 bytes.

Tested by Ronald Kuetemei with his Sony camera, also tested with a USB CF
card reader.

diff -uprN -X /home/patman/dontdiff bl-25/drivers/scsi/scsi_lib.c modesense-bufflen-bk-2.5/drivers/scsi/scsi_lib.c
--- bl-25/drivers/scsi/scsi_lib.c	Mon Sep 29 12:21:09 2003
+++ modesense-bufflen-bk-2.5/drivers/scsi/scsi_lib.c	Mon Nov 10 15:42:03 2003
@@ -1348,8 +1348,9 @@ void scsi_exit_queue(void)
  *	@sreq:	SCSI request to fill in with the MODE_SENSE
  *	@dbd:	set if mode sense will allow block descriptors to be returned
  *	@modepage: mode page being requested
- *	@buffer: request buffer (may not be smaller than eight bytes)
- *	@len:	length of request buffer.
+ *	@buffer: request buffer
+ *	@len:	length passed in to scsi command
+ *	@buf_len: length of request buffer (may not be smaller than eight)
  *	@timeout: command timeout
  *	@retries: number of retries before failing
  *	@data: returns a structure abstracting the mode header data
@@ -1357,15 +1358,24 @@ void scsi_exit_queue(void)
  *	Returns zero if unsuccessful, or the header offset (either 4
  *	or 8 depending on whether a six or ten byte command was
  *	issued) if successful.
+ *
+ *	Note: buf_len is passed in as a separate value because some
+ *	devices return more data than requested.
  **/
 int
 __scsi_mode_sense(struct scsi_request *sreq, int dbd, int modepage,
-		  unsigned char *buffer, int len, int timeout, int retries,
-		  struct scsi_mode_data *data) {
+		  unsigned char *buffer, int len, int buf_len, int timeout,
+		  int retries, struct scsi_mode_data *data) {
 	unsigned char cmd[12];
 	int use_10_for_ms;
 	int header_length;
 
+	WARN_ON((buf_len < 8) || (buf_len < len));
+	if (buf_len > 255)
+		buf_len = 255;
+	if (len > 255)
+		len = 255;
+
 	memset(data, 0, sizeof(*data));
 	memset(&cmd[0], 0, 12);
 	cmd[1] = dbd & 0x18;	/* allows DBD and LLBA bits */
@@ -1395,9 +1405,9 @@ __scsi_mode_sense(struct scsi_request *s
 	sreq->sr_sense_buffer[2] = 0;
 	sreq->sr_data_direction = DMA_FROM_DEVICE;
 
-	memset(buffer, 0, len);
+	memset(buffer, 0, buf_len);
 
-	scsi_wait_req(sreq, cmd, buffer, len, timeout, retries);
+	scsi_wait_req(sreq, cmd, buffer, buf_len, timeout, retries);
 
 	/* This code looks awful: what it's doing is making sure an
 	 * ILLEGAL REQUEST sense return identifies the actual command
@@ -1439,8 +1449,9 @@ __scsi_mode_sense(struct scsi_request *s
  *	@sdev:	scsi device to send command to.
  *	@dbd:	set if mode sense will disable block descriptors in the return
  *	@modepage: mode page being requested
- *	@buffer: request buffer (may not be smaller than eight bytes)
- *	@len:	length of request buffer.
+ *	@buffer: request buffer
+ *	@len:	length passed in to scsi command
+ *	@buf_len: length of request buffer (may not be smaller than eight)
  *	@timeout: command timeout
  *	@retries: number of retries before failing
  *
@@ -1450,8 +1461,8 @@ __scsi_mode_sense(struct scsi_request *s
  **/
 int
 scsi_mode_sense(struct scsi_device *sdev, int dbd, int modepage,
-		unsigned char *buffer, int len, int timeout, int retries,
-		struct scsi_mode_data *data)
+		unsigned char *buffer, int len, int buf_len, int timeout,
+		int retries, struct scsi_mode_data *data)
 {
 	struct scsi_request *sreq = scsi_allocate_request(sdev, GFP_KERNEL);
 	int ret;
@@ -1459,7 +1470,7 @@ scsi_mode_sense(struct scsi_device *sdev
 	if (!sreq)
 		return -1;
 
-	ret = __scsi_mode_sense(sreq, dbd, modepage, buffer, len,
+	ret = __scsi_mode_sense(sreq, dbd, modepage, buffer, len, buf_len,
 				timeout, retries, data);
 
 	scsi_release_request(sreq);
diff -uprN -X /home/patman/dontdiff bl-25/drivers/scsi/sd.c modesense-bufflen-bk-2.5/drivers/scsi/sd.c
--- bl-25/drivers/scsi/sd.c	Mon Oct 27 14:28:18 2003
+++ modesense-bufflen-bk-2.5/drivers/scsi/sd.c	Mon Nov 10 15:38:06 2003
@@ -1073,19 +1073,21 @@ got_data:
 /* called with buffer of length 512 */
 static inline int
 sd_do_mode_sense(struct scsi_request *SRpnt, int dbd, int modepage,
-		 unsigned char *buffer, int len, struct scsi_mode_data *data)
+		 unsigned char *buffer, int len, int buf_len,
+		 struct scsi_mode_data *data)
 {
-	return __scsi_mode_sense(SRpnt, dbd, modepage, buffer, len,
+	return __scsi_mode_sense(SRpnt, dbd, modepage, buffer, len, buf_len,
 				 SD_TIMEOUT, SD_MAX_RETRIES, data);
 }
 
 /*
  * read write protect setting, if possible - called only in sd_revalidate_disk()
- * called with buffer of length 512
  */
 static void
 sd_read_write_protect_flag(struct scsi_disk *sdkp, char *diskname,
-		   struct scsi_request *SRpnt, unsigned char *buffer) {
+		   struct scsi_request *SRpnt, unsigned char *buffer,
+		   int buf_len) 
+{
 	int res;
 	struct scsi_mode_data data;
 
@@ -1099,7 +1101,7 @@ sd_read_write_protect_flag(struct scsi_d
 	 * We have to start carefully: some devices hang if we ask
 	 * for more than is available.
 	 */
-	res = sd_do_mode_sense(SRpnt, 0, 0x3F, buffer, 4, &data);
+	res = sd_do_mode_sense(SRpnt, 0, 0x3F, buffer, 4, buf_len, &data);
 
 	/*
 	 * Second attempt: ask for page 0
@@ -1107,13 +1109,14 @@ sd_read_write_protect_flag(struct scsi_d
 	 * Sense Key 5: Illegal Request, Sense Code 24: Invalid field in CDB.
 	 */
 	if (!scsi_status_is_good(res))
-		res = sd_do_mode_sense(SRpnt, 0, 0, buffer, 4, &data);
+		res = sd_do_mode_sense(SRpnt, 0, 0, buffer, 4, buf_len, &data);
 
 	/*
 	 * Third attempt: ask 255 bytes, as we did earlier.
 	 */
 	if (!scsi_status_is_good(res))
-		res = sd_do_mode_sense(SRpnt, 0, 0x3F, buffer, 255, &data);
+		res = sd_do_mode_sense(SRpnt, 0, 0x3F, buffer, 255, buf_len,
+				       &data);
 
 	if (!scsi_status_is_good(res)) {
 		printk(KERN_WARNING
@@ -1129,11 +1132,12 @@ sd_read_write_protect_flag(struct scsi_d
 
 /*
  * sd_read_cache_type - called only from sd_revalidate_disk()
- * called with buffer of length 512
  */
 static void
 sd_read_cache_type(struct scsi_disk *sdkp, char *diskname,
-		   struct scsi_request *SRpnt, unsigned char *buffer) {
+		   struct scsi_request *SRpnt, unsigned char *buffer,
+		   int buf_len) 
+{
 	int len = 0, res;
 
 	const int dbd = 0;	   /* DBD */
@@ -1144,7 +1148,7 @@ sd_read_cache_type(struct scsi_disk *sdk
 		goto defaults;
 
 	/* cautiously ask */
-	res = sd_do_mode_sense(SRpnt, dbd, modepage, buffer, 4, &data);
+	res = sd_do_mode_sense(SRpnt, dbd, modepage, buffer, 4, buf_len, &data);
 
 	if (!scsi_status_is_good(res))
 		goto bad_sense;
@@ -1165,7 +1169,8 @@ sd_read_cache_type(struct scsi_disk *sdk
 	len += data.header_length + data.block_descriptor_length;
 
 	/* Get the data */
-	res = sd_do_mode_sense(SRpnt, dbd, modepage, buffer, len, &data);
+	res = sd_do_mode_sense(SRpnt, dbd, modepage, buffer, len, buf_len,
+			       &data);
 
 	if (scsi_status_is_good(res)) {
 		const char *types[] = {
@@ -1260,8 +1265,8 @@ static int sd_revalidate_disk(struct gen
 		sd_read_capacity(sdkp, disk->disk_name, sreq, buffer);
 		if (sdp->removable)
 			sd_read_write_protect_flag(sdkp, disk->disk_name,
-					sreq, buffer);
-		sd_read_cache_type(sdkp, disk->disk_name, sreq, buffer);
+					sreq, buffer, 512);
+		sd_read_cache_type(sdkp, disk->disk_name, sreq, buffer, 512);
 	}
 		
 	set_capacity(disk, sdkp->capacity);
diff -uprN -X /home/patman/dontdiff bl-25/drivers/scsi/sr.c modesense-bufflen-bk-2.5/drivers/scsi/sr.c
--- bl-25/drivers/scsi/sr.c	Wed Oct 22 13:30:58 2003
+++ modesense-bufflen-bk-2.5/drivers/scsi/sr.c	Mon Nov 10 15:32:16 2003
@@ -751,7 +751,7 @@ static void get_capabilities(struct scsi
 		   SRpnt->sr_sense_buffer[2] == UNIT_ATTENTION)));
 
 	/* ask for mode page 0x2a */
-	rc = scsi_mode_sense(cd->device, 0, 0x2a, buffer, 128,
+	rc = scsi_mode_sense(cd->device, 0, 0x2a, buffer, 128, 512,
 			     SR_TIMEOUT, 3, &data);
 
 	if (!scsi_status_is_good(rc)) {
diff -uprN -X /home/patman/dontdiff bl-25/include/scsi/scsi_device.h modesense-bufflen-bk-2.5/include/scsi/scsi_device.h
--- bl-25/include/scsi/scsi_device.h	Mon Oct 27 14:28:18 2003
+++ modesense-bufflen-bk-2.5/include/scsi/scsi_device.h	Mon Nov 10 15:28:43 2003
@@ -123,6 +123,6 @@ extern int scsi_track_queue_full(struct 
 extern int scsi_set_medium_removal(struct scsi_device *, char);
 
 extern int scsi_mode_sense(struct scsi_device *sdev, int dbd, int modepage,
-			   unsigned char *buffer, int len, int timeout,
-			   int retries, struct scsi_mode_data *data);
+			   unsigned char *buffer, int len, int buf_len,
+			   int timeout, int retries, struct scsi_mode_data *data);
 #endif /* _SCSI_SCSI_DEVICE_H */
diff -uprN -X /home/patman/dontdiff bl-25/include/scsi/scsi_request.h modesense-bufflen-bk-2.5/include/scsi/scsi_request.h
--- bl-25/include/scsi/scsi_request.h	Mon Sep 22 13:09:11 2003
+++ modesense-bufflen-bk-2.5/include/scsi/scsi_request.h	Mon Nov 10 15:26:51 2003
@@ -66,7 +66,7 @@ struct scsi_mode_data {
 
 extern int __scsi_mode_sense(struct scsi_request *SRpnt, int dbd,
 			     int modepage, unsigned char *buffer, int len,
-			     int timeout, int retries,
+			     int buf_len, int timeout, int retries,
 			     struct scsi_mode_data *data);
 
 

Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Matthew Dharm]

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

On Wed, Nov 12, 2003 at 03:50:29PM -0800, Patrick Mansfield wrote:
> James - can you please apply? This should not affect other devices since
> we are not changing the requested length, just the size of the receive
> buffer.

This is a terrible idea.

There is a large number of devices which choke if those two values do not
match.

Matt

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

Hi.  I have my back hairs caught in my computer fan.
					-- Customer
User Friendly, 8/20/1998

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

Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Patrick Mansfield]

On Wed, Nov 12, 2003 at 04:09:21PM -0800, Matthew Dharm wrote:
> On Wed, Nov 12, 2003 at 03:50:29PM -0800, Patrick Mansfield wrote:
> > James - can you please apply? This should not affect other devices since
> > we are not changing the requested length, just the size of the receive
> > buffer.
> 
> This is a terrible idea.
> 
> There is a large number of devices which choke if those two values do not
> match.

This is what we do in 2.4 - does USB fix it up for 2.4?

Oh well.

-- Patrick Mansfield

Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Patrick Mansfield]

On Wed, Nov 12, 2003 at 04:13:10PM -0800, Patrick Mansfield wrote:
> On Wed, Nov 12, 2003 at 04:09:21PM -0800, Matthew Dharm wrote:
> > On Wed, Nov 12, 2003 at 03:50:29PM -0800, Patrick Mansfield wrote:
> > > James - can you please apply? This should not affect other devices since
> > > we are not changing the requested length, just the size of the receive
> > > buffer.
> > 
> > This is a terrible idea.
> > 
> > There is a large number of devices which choke if those two values do not
> > match.
> 
> This is what we do in 2.4 - does USB fix it up for 2.4?
> 
> Oh well.

I think see the 2.4 fixups - it looks like it sets the buffer cmd_len to
12, but is (for usb_stor_ufi_command?) setting MODE SENSE 10 to a 8 byte
length (cmd[8] = 8).

Can we use a minium buffer length of 12 for any requests of less than 13
bytes?

Else, I give up on any other methods, and we should add them to the static
black list as BLIST_MS_SKIP_PAGE_3F (skip_ms_page_3f) and probably
BLIST_MS_SKIP_PAGE_08 just to be safe.

-- Patrick Mansfield

Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Matthew Dharm]

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

On Wed, Nov 12, 2003 at 04:44:05PM -0800, Patrick Mansfield wrote:
> On Wed, Nov 12, 2003 at 04:13:10PM -0800, Patrick Mansfield wrote:
> > On Wed, Nov 12, 2003 at 04:09:21PM -0800, Matthew Dharm wrote:
> > > On Wed, Nov 12, 2003 at 03:50:29PM -0800, Patrick Mansfield wrote:
> > > > James - can you please apply? This should not affect other devices since
> > > > we are not changing the requested length, just the size of the receive
> > > > buffer.
> > > 
> > > This is a terrible idea.
> > > 
> > > There is a large number of devices which choke if those two values do not
> > > match.
> > 
> > This is what we do in 2.4 - does USB fix it up for 2.4?
> > 
> > Oh well.
> 
> I think see the 2.4 fixups - it looks like it sets the buffer cmd_len to
> 12, but is (for usb_stor_ufi_command?) setting MODE SENSE 10 to a 8 byte
> length (cmd[8] = 8).

Basically, yes.  It's tweaked in a couple of places in 2.4, including some
awful heuristics....

> Can we use a minium buffer length of 12 for any requests of less than 13
> bytes?

You can try.... I don't know if it will work.

> Else, I give up on any other methods, and we should add them to the static
> black list as BLIST_MS_SKIP_PAGE_3F (skip_ms_page_3f) and probably
> BLIST_MS_SKIP_PAGE_08 just to be safe.

I'm starting to think that this may be the best solution -- blacklist all
MODE_SENSE[_10] commands from all Direct-Access devices.

Matt

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

Why am I talking to a toilet brush?
					-- CEO
User Friendly, 4/30/1998

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

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Alan Stern]

On Wed, 12 Nov 2003, Matthew Dharm wrote:

> I'm starting to think that this may be the best solution -- blacklist all
> MODE_SENSE[_10] commands from all Direct-Access devices.

I was just going to suggest that myself -- or rather, blacklist all 
MODE-SENSE(x) commands from all USB disk-type devices.

Is there any strong reason not to do this?  Bear in mind that Windows 
apparently does not use these commands.  I don't see how not knowing the 
true read-write status or caching type will hurt anything.  (And the 
read-write status can be adjusted, if necessary, when a WRITE command 
fails with Medium Error: Write Protected sense.)

Alan Stern

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Pat LaVarre]

> > I'm starting to think that this may be the best solution --
> > blacklist all MODE_SENSE[_10] commands from all Direct-Access
> > devices.
> 
> I was just going to suggest that myself -- or rather, blacklist all 
> MODE-SENSE(x) commands from all USB disk-type devices.

We may as well fix SCSI over IDE and SCSI over 1394/FireWire/iLink at
the same time we fix SCSI over USB, yes?

> Is there any strong reason not to do this?

Have we yet begun to experiment with disks that we can write protect?

> Bear in mind that Windows apparently does not use these commands.

Rather, Windows either does not use the variations in these commands
that we have tried or else uses a different variation of reset that
works.

We could blacklist just USB MSC CBI/CB, for example, thus fixing the
Sony without making connections, especially SG_IO connections, to USB
MSC BBB more opaque.

> I don't see how not knowing the true read-write status or caching type
> will hurt anything.

Anybody know why Jens Axboe so vehemently rejected my suggestion that
that we teach cdrom.ko and sr_mod.ko to pass writes thru to all PDT x05
DVD/CD?

> (And the read-write status can be adjusted, if necessary, when a WRITE
> command fails with Medium Error: Write Protected sense.)

Aye.  But will the layers above cope well with such a late error?  I've
seen dmesg spew when playing with mounting udf.ko writable on top of a
read-only disc.

Pat LaVarre

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Alan Stern]

On 13 Nov 2003, Pat LaVarre wrote:

> > I was just going to suggest that myself -- or rather, blacklist all 
> > MODE-SENSE(x) commands from all USB disk-type devices.
> 
> We may as well fix SCSI over IDE and SCSI over 1394/FireWire/iLink at
> the same time we fix SCSI over USB, yes?

Are they broken?

> > Is there any strong reason not to do this?
> 
> Have we yet begun to experiment with disks that we can write protect?

Not as far as I know.  But the current code does make a provision for 
devices that don't respond to MODE-SENSE for page 0x3f correctly; it 
assumes they are read/write.  Similarly, devices that don't respond to 
page 0x08 correctly are assumed to have a write-through cache.

> > Bear in mind that Windows apparently does not use these commands.
> 
> Rather, Windows either does not use the variations in these commands
> that we have tried or else uses a different variation of reset that
> works.

I don't see what this has to do with variations of reset.  The examples of
USB traces from a Windows host that people have posted recently show no
use of MODE-SENSE.

> We could blacklist just USB MSC CBI/CB, for example, thus fixing the
> Sony without making connections, especially SG_IO connections, to USB
> MSC BBB more opaque.

Why bother to do either?  There's no need to single out CBI/CB and there's 
no need to make SG_IO at all opaque.  Just have the sd driver avoid 
issuing the MODE-SENSE commands.

> > (And the read-write status can be adjusted, if necessary, when a WRITE
> > command fails with Medium Error: Write Protected sense.)
> 
> Aye.  But will the layers above cope well with such a late error?  I've
> seen dmesg spew when playing with mounting udf.ko writable on top of a
> read-only disc.

Probably they won't cope well.  But they don't cope well with the sudden 
removal of a hot-unpluggable device either.  They will need to be updated 
to handle such problems.

Alan Stern

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Pat LaVarre]

> > > Bear in mind that Windows apparently does not use these commands.
> > 
> > Rather, Windows either does not use the variations in these commands
> > that we have tried or else uses a different variation of reset that
> > works.
> 
> I don't see what this has to do with variations of reset.  The examples of
> USB traces from a Windows host that people have posted recently show no
> use of MODE-SENSE.

I missed these, help?

In linux-scsi, I saw Andries B post an offer to collect these, I saw
myself loosely quote an op x46 Get Configuration
fetch-header-fetch-available sequence, but I never saw any traces
appear?

> > > Is there any strong reason not to do this?
> > 
> > Have we yet begun to experiment with disks that we can write protect?
> 
> Not as far as I know.

I have write-protectable disks that mount via sd e.g. WinHEC Lexar
flash, Iomega Zip.  Got any experiments you want me to try?

> But the current code does make a provision for 
> devices that don't respond to MODE-SENSE for page 0x3f correctly; it 
> assumes they are read/write.

I trust you actually know.  Me, I remember thinking that.

> Similarly, devices that don't respond to 
> page 0x08 correctly are assumed to have a write-through cache.

"I trust you actually know.  Me, I remember thinking that."

> > We could blacklist just USB MSC CBI/CB, for example, thus fixing the
> > Sony without making connections, especially SG_IO connections, to USB
> > MSC BBB more opaque.
> 
> Why bother to do either?  There's no need to single out CBI/CB and there's 
> no need to make SG_IO at all opaque.  Just have the sd driver avoid 
> issuing the MODE-SENSE commands.

Glad to hear no opaque SG_IO.

Deciding writable or not when disc arrives, rather than when device
arrives, sounds good.

Breaking write protect that works sounds bad.  Does write protect ever
work?

> > > (And the read-write status can be adjusted, if necessary, when a WRITE
> > > command fails with Medium Error: Write Protected sense.)
> > 
> > Aye.  But will the layers above cope well with such a late error?  I've
> > seen dmesg spew when playing with mounting udf.ko writable on top of a
> > read-only disc.
> 
> Probably they won't cope well.  But they don't cope well with the sudden 
> removal of a hot-unpluggable device either.  They will need to be updated 
> to handle such problems.

Yes please.

Me, I want to learn how write protect works in Linux cdrom/sr/ide-cd
because I want my USB & ATAPI write-protectable Iomega RRD to work.

Anybody know a better way for me to learn than to try write-protectable
sd discs?

So far I'm deeply confused by the concept of a device writable or not.

To ignorant newbie me, only partitions of discs are writable or not.

> > I was just going to suggest that myself -- or rather, blacklist all 
> > > MODE-SENSE(x) commands from all USB disk-type devices.
> > 
> > We may as well fix SCSI over IDE and SCSI over 1394/FireWire/iLink at
> > the same time we fix SCSI over USB, yes?
> 
> Are they broken?

Aye, in much the same way: nothing but Talk Like Windows actually works
well across a wide variety of devices.

I hear commercially available DVD/CD burning software actually resorts
to guessing behaviour by op x12 Inquiry String.  Some apps doesn't even
try to talk to an unrecognised device.  Friendlier apps gives you the
option of running a diagnostic to try to discover behaviour - you crash
or you hang or you profile the new device.

Traces tell me binary-code-only Windows XP/2K produces the first few cdb
after plug in independently by bus, but pretty early in life the
different forms of SCSI over whatever then share a common cdb author.

I'm guessing from nearly zero evidence, but as yet by guess is that the
DVD/CD driver tries politically correct speech e.g.
fetch-header-fetch-available, but the HDD/Flash driver tries a less
obvious legacy speech whose sole virtue is that it works.

Pat LaVarre

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Patrick Mansfield]

On Thu, Nov 13, 2003 at 10:24:19AM -0700, Pat LaVarre wrote:

> > I don't see what this has to do with variations of reset.  The examples of
> > USB traces from a Windows host that people have posted recently show no
> > use of MODE-SENSE.
> 
> I missed these, help?

http://marc.theaimsgroup.com/?l=linux-scsi&m=106836761130746&w=2

Showed the sequence:

	INQUIRY length 0x24 (36) bytes
	READ CAPACITY
	TEST UNIT READY
	READ CAPACITY
	READ 10

-- Patrick Mansfield

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Pat LaVarre]

> http://marc.theaimsgroup.com/?l=linux-scsi&m=106836761130746&w=2

Bingo!  Thank you.

> Showed the sequence:

Is this a CBI/CB trace?  That's not quite authentic Windows talk, as if
we had bInterfaceProtocol = x50 BBB with bInterfaceSubClass = x06
Transparent SCSI.  That's Windows opaquely filtered by the BCO
(binary-code-only) Windows CBI/CB driver.

> Showed the sequence:
> 
> 	INQUIRY length 0x24 (36) bytes
> 	READ CAPACITY
> 	TEST UNIT READY
> 	READ CAPACITY
> 	READ 10

Obsolete?

I see the comment says "win98".

I hear Win has two i/o traditions, binary incompatible.  I hear Win ME/
98SE/ etc. tries speech such as auto sense for x0E, whereas Win XP/2K
etc. tries such radically different speech as auto sense for x12.

When I choose to believe that rumour, I conclude Talk Like Massively
Distributed Consumer Windows in 2003 is Talk Like Win XP.

> Showed the sequence:
> 
> 	INQUIRY length 0x24 (36) bytes
> 	READ CAPACITY
> 	TEST UNIT READY
> 	READ CAPACITY
> 	READ 10

Did we omit auto sense from this trace?

I'm surprised to see no auto sense of unit attentions (x 6 29 Reset, x 6
28 GoneReady) early in life, after I see -i x24 -y "12 00:00:00 24 00"
// Inquiry report (!!(bytes[1] & x80 RMB)) i.e. disc removable without
removing drive.

Pat LaVarre

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Pat LaVarre]

> Is this ...?

Oi.

Here we have bInterfaceSubClass = xFF.

That's this device TELLING US THIS DEVICE DOES NOT TALK SCSI.

We shouldn't be surprised to discover this device then indeed does not
talk SCSI?

How about we blacklist all the bInterfaceSubClass that Windows does not
regard as generic.  I remember Windows does regard bInterfaceSubClass =
x06 as generic.  I think I remember there are two others.  Please stay
tuned for a moment.  Meanwhile,

> ...

At length ...

This device does NOT describe itself as generic e.g. not much like x 08
06 50 = MassStorage SCSI BBB.

We may not even have the Windows CBI/CB driver here?

Are we observing a Windows driver from a vendor other than Microsoft?

I see:

    bDeviceClass       : 0x00 (0)
    bDeviceSubClass    : 0x00 (0)
    bDeviceProtocol    : 0x00 (0)
...

  InterfaceNumber: 0x00
...

  Class             = 0x34
  SubClass          = 0x6d
  Protocol          = 0x37
...

  InterfaceNumber: 0x00
...

  Class             = 0x08
  SubClass          = 0xff
  Protocol          = 0x01

I'm guessing that SubClass lines means we have bInterfaceClass
...SubClass ...Protocol = x 08 FF 01.

Pat LaVarre

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Pat LaVarre]

> > Here we have bInterfaceSubClass = xFF ...
> > That's this device TELLING US THIS DEVICE DOES NOT TALK SCSI.
> ...
> How about we blacklist all the bInterfaceSubClass that Windows does not
> regard as generic.  I remember Windows does regard bInterfaceSubClass =
> x06 as generic.  I think I remember there are two others.

grep -i generic
in windows/inf/usbstor.inf yields, hex:

08 02 50
08 05 50
08 06 50

How about we say disk writable if we do not find bInterfaceSubClass in
the set x 02 05 06?

Pat LaVarre

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Pat LaVarre]

> > How about we blacklist all the bInterfaceSubClass that Windows does not
> > regard as generic.  I remember Windows does regard bInterfaceSubClass =
> > x06 as generic.  I think I remember there are two others.
> 
> grep -i generic
> in windows/inf/usbstor.inf yields, hex:
> 
> 08 02 50
> 08 05 50
> 08 06 50
> 
> How about we [guess] disk writable
> [without risking mode sense]
> if we do not find bInterfaceSubClass in
> the set x 02 05 06?

In short:

Or how about we only blacklist mode sense from devices that report
bInterfaceSubClass = any of the x07..FF Reserved codes?  Surely a device
sending us a formally Reserved code is a good first clue that it may not
behave robustly thereafter?  Or maybe we just blacklist mode sense from
bInterfaceSubClass = xFF FormallyReservedButInformallyVendorSpecific? 
Surely a device sending us that code is an even better first clue that
it may not behave robustly thereafter?

At length ...

usb.org --> Developers --> Documents --> USB Device Class Specifications
--> Approved yields:

http://www.usb.org/developers/devclass_docs#approved

http://www.usb.org/developers/devclass_docs/usb_msc_overview_1.2.pdf

xpdf then shows, in page 6 of 7, "Table 2.1 - SubClass Codes Mapped to
Command Block Specifications"

x01..x06 = RBC SFF-CD/MMC QIC UFI SFF-FDD SCSI
x07..xFF = "Reserved for future use."

De facto practice says xFF = vendor-specific, by analogy with other
usb.org texts.

Blacklisting mode sense from all but 02 05 06, same as Windows, means
blacklisting all but QIC SFF-FDD SCSI.  Maybe uncomfortably aggressive.

> > Here we have bInterfaceSubClass = xFF ...
> > > That's this device TELLING US THIS DEVICE DOES NOT TALK SCSI.

By the way, kudos to Dmitri Katchalov for including USB descriptors in
the trace, rather than tracing only CDB's & data.

Pat LaVarre

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Matthew Dharm]

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

On Thu, Nov 13, 2003 at 11:37:09AM -0700, Pat LaVarre wrote:
> > > How about we blacklist all the bInterfaceSubClass that Windows does not
> > > regard as generic.  I remember Windows does regard bInterfaceSubClass =
> > > x06 as generic.  I think I remember there are two others.
> > 
> > grep -i generic
> > in windows/inf/usbstor.inf yields, hex:
> > 
> > 08 02 50
> > 08 05 50
> > 08 06 50
> > 
> > How about we [guess] disk writable
> > [without risking mode sense]
> > if we do not find bInterfaceSubClass in
> > the set x 02 05 06?
> 
> In short:
> 
> Or how about we only blacklist mode sense from devices that report
> bInterfaceSubClass = any of the x07..FF Reserved codes?  Surely a device
> sending us a formally Reserved code is a good first clue that it may not
> behave robustly thereafter?  Or maybe we just blacklist mode sense from
> bInterfaceSubClass = xFF FormallyReservedButInformallyVendorSpecific? 
> Surely a device sending us that code is an even better first clue that
> it may not behave robustly thereafter?

Our experience tells us that xFF is often used because designers are one of
the following:
	(a) lazy
	(b) incompetient
	(c) driven by marketing, which wants to load an .inf so their
	device seems 'special' (custom icons, etc.)

So xFF doesn't really tell us, deterministically, anything at all.

Knowing that the device is direct-access, however, implies very strongly
that MODE_SENSE[_10] is a bad idea.

Matt

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

Okay, this isn't funny anymore! Let me down!  I'll tell Bill on you!!
					-- Microsoft Salesman
User Friendly, 4/1/1998

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

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Pat LaVarre]

> Our experience tells us that xFF is often used because designers are one of
> the following:
> 	(a) lazy
> 	(b) incompetient

Choosing to violate spec, certainly.

> 	(c) driven by marketing, which wants to load an .inf so their
> 	device seems 'special' (custom icons, etc.)
> 
> So xFF doesn't really tell us, deterministically, anything at all.

Do we here agree violently?

bInterfaceSubClass = xFF tells us Windows does not speak to the device
with Microsoft's generic driver by default.  That .inf we do not have in
Linux may then say to use the generic driver, or may say to use some
other driver.

> Knowing that the device is direct-access, however, implies very strongly
> that MODE_SENSE[_10] is a bad idea.

Anybody able to clue me in quickly as to why classifying a device as
writable or not, rather than a disc, can ever be meaningful?

Maybe guessing not writable helps only (in the vanishingly small corner
case) when a disc is write-protectable although Not removable without
also removing the drive?

Pat LaVarre

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Alan Stern]

On 13 Nov 2003, Pat LaVarre wrote:

> Anybody able to clue me in quickly as to why classifying a device as
> writable or not, rather than a disc, can ever be meaningful?

The notion makes sense for tape drives as well.

Alan Stern

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Pat LaVarre]

> > Anybody able to clue me in quickly as to why classifying a device as
> > writable or not, rather than a disc, can ever be meaningful?
> 
> The notion makes sense for tape drives as well.

Re write-protect, personally I know only of discs that have
write-protect tabs.

Are we saying some SCSI drives have write-protect switches also?  Only
tape drives or also the disk drives of sd and the disc drives of cdrom/
sr/ ide-cd?

Are we saying for some reason that we prefer detecting the write-protect
of such a drive once at plug in rather than again after each disc
insertion?  For what reason?

Pat LaVarre

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Dmitri Katchalov]

Quoting Pat LaVarre <p.lavarre@ieee.org>:

> > > Anybody able to clue me in quickly as to why classifying a device as
> > > writable or not, rather than a disc, can ever be meaningful?
> > 
> > The notion makes sense for tape drives as well.
> 
> Re write-protect, personally I know only of discs that have
> write-protect tabs.

Memory sticks have write-protect switches on them.

Regards,
Dmitri

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Pat LaVarre]

> > > > Anybody able to clue me in quickly as to why classifying a
> device as
> > > > writable or not, rather than a disc, can ever be meaningful?
> > > 
> > > The notion makes sense for tape drives as well.
> > 
> > Re write-protect, personally I know only of discs that have
> > write-protect tabs.
> 
> Memory sticks have write-protect switches on them.

Ouch again I feel confused sorry.

The memory stick is like a disc, yes?  We insert the stick into a slot,
yes?  The slot does not itself have a switch - only the stick has a
switch.  We cannot speak of the slot being write-protected, we can only
speak of the stick being write-protected, yes?

Therefore, with a memory stick as with a classic "1.44MB" floppy, we say
the "disc" has a write-protect tab but the "drive" does not?

Pat LaVarre

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Matthew Dharm]

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

On Thu, Nov 13, 2003 at 04:40:52PM -0700, Pat LaVarre wrote:
> > > Anybody able to clue me in quickly as to why classifying a device as
> > > writable or not, rather than a disc, can ever be meaningful?
> > 
> > The notion makes sense for tape drives as well.
> 
> Re write-protect, personally I know only of discs that have
> write-protect tabs.
> 
> Are we saying some SCSI drives have write-protect switches also?  Only
> tape drives or also the disk drives of sd and the disc drives of cdrom/
> sr/ ide-cd?

I've seen write-protect switches/jumpers on SCSI disks, on tapes, and even
flash-disk keychain devices.

Matt

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

C:  They kicked your ass, didn't they?
S:  They were cheating!
					-- The Chief and Stef
User Friendly, 11/19/1997

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

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Pat LaVarre]

> I've seen write-protect switches/jumpers on SCSI disks, on tapes, and even
> flash-disk keychain devices.

Sorry I'm so persistently failing to make my question clear.

I mean to say, have we ever seen a write-protect switch/ jumper on a
drive with the disc absent, or do we only see the switch/ jumper on
discs and on drives that do not let us remove their discs?

Pat LaVarre

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Matthew Dharm]

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

On Thu, Nov 13, 2003 at 06:10:53PM -0700, Pat LaVarre wrote:
> > I've seen write-protect switches/jumpers on SCSI disks, on tapes, and even
> > flash-disk keychain devices.
> 
> Sorry I'm so persistently failing to make my question clear.
> 
> I mean to say, have we ever seen a write-protect switch/ jumper on a
> drive with the disc absent, or do we only see the switch/ jumper on
> discs and on drives that do not let us remove their discs?

I have seen removeable-media devices which put the write-protect switch on
the drive, not the disc.

Matt

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

A female who groks UNIX?  My universe is collapsing.
					-- Mike
User Friendly, 10/11/1998

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

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Alan Stern]

On 13 Nov 2003, Pat LaVarre wrote:

> Deciding writable or not when disc arrives, rather than when device
> arrives, sounds good.
> 
> Breaking write protect that works sounds bad.  Does write protect ever
> work?

Your question is ambiguous.  Write protection has two aspects: detecting 
whether a device or its media is write protected, and avoiding sending any 
write commands to the device.  The first aspect doesn't work for many USB 
disk devices -- I haven't heard of any problems with USB CD/DVD devices -- 
and the second aspect works quite well (although you may want to update 
it for various CD/DVD type devices).  The only questionable point is that 
the kernel doesn't try to check commands that it doesn't generate itself, 
like commands submitted by way of the sg driver.

> Me, I want to learn how write protect works in Linux cdrom/sr/ide-cd
> because I want my USB & ATAPI write-protectable Iomega RRD to work.
> 
> Anybody know a better way for me to learn than to try write-protectable
> sd discs?

You could read through the source code.  A quick look at drivers/scsi/sr.c 
highlights the get_capabilities() routine.  Going through 
drivers/cdrom/cdrom.c shows that cdrom_open() checks for write 
capabilities.  If the drive is not marked with the CDC_DVD_RAM flag, you 
aren't allowed to open the device file for writing.

> So far I'm deeply confused by the concept of a device writable or not.
> 
> To ignorant newbie me, only partitions of discs are writable or not.

What do you find confusing?  There are basically just two issues: will the
device carry out a write request, and will the kernel allow you to send a
write request to the device.  The answer to the second may well vary
depending on what mechanism you use to send the request (sr versus sg for
example).

> > > We may as well fix SCSI over IDE and SCSI over 1394/FireWire/iLink at
> > > the same time we fix SCSI over USB, yes?
> > 
> > Are they broken?
> 
> Aye, in much the same way: nothing but Talk Like Windows actually works
> well across a wide variety of devices.
> 
> I hear commercially available DVD/CD burning software actually resorts
> to guessing behaviour by op x12 Inquiry String.  Some apps doesn't even
> try to talk to an unrecognised device.  Friendlier apps gives you the
> option of running a diagnostic to try to discover behaviour - you crash
> or you hang or you profile the new device.
> 
> Traces tell me binary-code-only Windows XP/2K produces the first few cdb
> after plug in independently by bus, but pretty early in life the
> different forms of SCSI over whatever then share a common cdb author.
> 
> I'm guessing from nearly zero evidence, but as yet by guess is that the
> DVD/CD driver tries politically correct speech e.g.
> fetch-header-fetch-available, but the HDD/Flash driver tries a less
> obvious legacy speech whose sole virtue is that it works.

Those sound like different issues from the one we've been discussing in 
this thread, namely: how should sd.c try to determine the read/write 
status and cache-type of a disk device?

Alan Stern

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Pat LaVarre]

Alan S:

> basically just two issues:
> will the device carry out a write request, and
> will the kernel allow you to send a write request to the device.

Aye.

Ouch by now I've discard two drafts of line-by-line replies.

Perhaps first I should say, yes I have studied cdrom/ ide-cd/ sr here. 
Jens Axboe & friends have taught me how those work in a tangle of recent
linux-scsi threads now paused at "Re: [PATCH] CDC_WR".

Maybe here I mean to ask: can we easily nutshell for me how well
write-protect works now in sd?  I understand that we find mode sense of
header alone and mode sense of xFF troublesome.

I'm not clear how often we try those techniques.  Do we try only soon
after plug in or also soon after each disc insertion?

Tell me that much and maybe I can more concisely make the rest of my
confusion clear.

Pat LaVarre

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Patrick Mansfield]

On Thu, Nov 13, 2003 at 04:37:12PM -0700, Pat LaVarre wrote:

> Maybe here I mean to ask: can we easily nutshell for me how well
> write-protect works now in sd?  I understand that we find mode sense of
> header alone and mode sense of xFF troublesome.
> 
> I'm not clear how often we try those techniques.  Do we try only soon
> after plug in or also soon after each disc insertion?

For removable media, we try once when found (sd_probe calls
sd_revalidate_disk), and generally on each open of the device as follows:

sd_open calls check_disk_change, calls sd_media_changed. sd_media_changed
returns 1 if media changed and if so check_disk_change calls
sd_revalidate_disk to figure out if the media is writable and whether to
set write_prot.

On open if write_prot is set and we try to open for writing the open fails
with EROFS.

write_prot can only be set for removable media.

AFAICT, the sd write_prot setting is never passed on up to the block layer.


(Verified with with an ide cd) if the mount syscall returns EROFS, the
mount command tries again with a read-only mount.

If we check after the open for a write failure to read only media, we
cannot keep the same open semantics (return EROFS on open). Is this
important? I don't know.

For file systems, the write out of page cache would get an error, but
AFAIUI those errors can't be passed back to the application since the
application thinks the write has already completed once it goes into the
page cache (I think this was a bug in 2.4, maybe just readahead, where we
did not report such write failures).

I don't have any sd removable read only media.

If you want to test with your read only media, just use the dev flags:

	echo "vendor:model:0x4000" > /proc/scsi/device_info 

Then add your device, see if it comes back as writable, and try to mount
or write it, and compare without the above (you can't remove device_info
entry without rebooting or rmmod-ing scsi).

-- Patrick Mansfield

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Pat LaVarre]

> > From: Patrick Mansfield ...
> > For removable media, we try once when found
> > (sd_probe calls sd_revalidate_disk), and
> > generally on each open of the device as follows:

Prompt & incisive, thank you.

> From: Matthew Dharm ...
> ... I think we're basically at a point where
> the only problematic command is MODE_SENSE and
> MODE_SENSE_10, so I say blacklisting them from
> USB devices should be fine.

Lost me sorry help?

If we eat those commands, how then can write-protect work in Linux for
that rare case of an actually compliant device with a write-protectab;e
disk (like the device firmware I remember shipping myself 1994..2003)?

> > If we check after the open for a write failure
> > to read only media, we cannot keep the same
> > open semantics (return EROFS on open).

Without mode sense, we will see the open for write pass thru, and we
will have to teach the fs (ext3, fat, fat32, udf, ...) to recover
gracefully from a late write error, yes?

> > From: Patrick Mansfield ...
> > I don't have any sd removable read only
> > media.

Want an Iomega Zip drive and disk shipped to you?

(I can't arrange that easily, but if I try it might happen someday,
especially if you're precisely the next person who asks me and not the
person after that.)

(You have no Iomega Zip disk already, yes?  I ask just because you can't
see the write-protect tab on a Zip disk unless you disassemble the disk
and use an electron microscope, so you might not know how to flip it.)

> > If you want to test with your read only
> > media, just use the dev flags:
> > echo "vendor:model:0x4000" > /proc/scsi/device_info 
> > Then add your device, see if it comes back
> > as writable, and try to mount or write it,
> > and compare without the above (you can't
> > remove device_info entry without rebooting
> > or rmmod-ing scsi).

Will do, again I thank you for explaining.

My first guess is that in bash syntax for me we mean to take $vendor and
$model from op x12 Inquiry data, vendor = bytes[x8:F], model =
bytes[x10:1F], so for me:

vendor = "IOMEGA   "
model = "ZIP 250          "
echo "$vendor:$model:0x4000" > /proc/scsi/device_info 

Results you describe for allowing open to write of unwritable disk sound
to me like results I've seen in cdrom/ sr/ ide-cd land.  I will try sd
and report back.

Pat LaVarre

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Matthew Dharm]

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

On Thu, Nov 13, 2003 at 06:54:16PM -0700, Pat LaVarre wrote:
> > From: Matthew Dharm ...
> > ... I think we're basically at a point where
> > the only problematic command is MODE_SENSE and
> > MODE_SENSE_10, so I say blacklisting them from
> > USB devices should be fine.
> 
> Lost me sorry help?
> 
> If we eat those commands, how then can write-protect work in Linux for
> that rare case of an actually compliant device with a write-protectab;e
> disk (like the device firmware I remember shipping myself 1994..2003)?

Presumeably, when the send a WRITE command to the device, it will refuse
with meaningful sense data.

> > > If we check after the open for a write failure
> > > to read only media, we cannot keep the same
> > > open semantics (return EROFS on open).
> 
> Without mode sense, we will see the open for write pass thru, and we
> will have to teach the fs (ext3, fat, fat32, udf, ...) to recover
> gracefully from a late write error, yes?

This should already be in place.

Matt

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

We've made a business out of making money from annoying and stupid people.
I think you fall under that category.
					-- Chief
User Friendly, 7/11/1998

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

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Pat LaVarre]

> From: Matthew Dharm ...

All clear now thanks, sorry I was slow.

> > > > If we check after the open for a write failure
> > > > to read only media, we cannot keep the same
> > > > open semantics (return EROFS on open).
> > 
> > Without mode sense, we will see the open for write pass thru, and we
> > will have to teach the fs (ext3, fat, fat32, udf, ...) to recover
> > gracefully from a late write error, yes?
> 
> This should already be in place.

In place by now in kernel but not yet above?

I will try 2.6.0-test9.  Me, I thought when last I tried something like
this I saw dd finish without error while the dmesg filled with
complaints.

> > If we eat those commands, how then can write-protect work in Linux for
> > that rare case of an actually compliant device with a write-protectab;e
> > disk (like the device firmware I remember shipping myself 1994..2003)?
> 
> Presumeably, when the send a WRITE command to the device, it will refuse
> with meaningful sense data.

Works for SCSI transports that support the Dn < Ho case of the thirteen
cases, aye.  Fun to see that trace showing Win XP SP1 requiring certain
Dn < Hi and Di < Hi to work.

> ...

I will report back (many hours from now) after next I can try what I
think Patrick M suggested for letting writable open of read-only sd pass
thru:

echo "$vendor:$model:0x4000" > /proc/scsi/device_info

(I'll try this with sr too, just in case it works.)

Pat LaVarre

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Pat LaVarre]

> I don't have any sd removable read only media.

Eh?  Does http://www.torque.net/sg/sdebug26.html
not give us all sd removable read only media?

> If you want to test with your read only media,
> just use the dev flags:
> 
> 	echo "vendor:model:0x4000" > /proc/scsi/device_info 
> 
> Then add your device, see if it comes back as writable, and try to mount
> or write it, and compare without the above (you can't remove device_info
> entry without rebooting or rmmod-ing scsi).

Thanks for kindly finding the time to share these hints, I have now
begun the work of decrypting them.

1) `find /lib/modules -name '*.ko'` says I have no scsi.ko.  If I kick
around in `make xconfig` long enough, I may find one.

2) By vendor:model I first guess we mean what bash would say as
"$vendor:$model", of 8 and x10 bytes respectively, same as in op x12
Inquiry.

> can we easily nutshell for me how well
> > write-protect works now in sd?  ...
> ...
> removable ... once when found (sd_probe ... sd_revalidate_disk), and ...
> sd_open calls check_disk_change, calls sd_media_changed ...
> sd_revalidate_disk to figure out ... write_prot ...
> write_prot ... if ... set ... the open fails with EROFS.

Prompt & cogent thank you.

> AFAICT, the sd write_prot setting is never passed on up to the block layer.

Except, of course, by way of EROFS returned from sd_open.

Pat LaVarre

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Patrick Mansfield]

[Trimmed the cc line]

On Mon, Nov 17, 2003 at 02:38:24PM -0700, Pat LaVarre wrote:
> > I don't have any sd removable read only media.
> 
> Eh?  Does http://www.torque.net/sg/sdebug26.html
> not give us all sd removable read only media?

Yes, looks like I would have to modify scsi_debug.c DEV_READONLY to make
it behave as read only.

> > If you want to test with your read only media,
> > just use the dev flags:
> > 
> > 	echo "vendor:model:0x4000" > /proc/scsi/device_info 
> > 
> > Then add your device, see if it comes back as writable, and try to mount
> > or write it, and compare without the above (you can't remove device_info
> > entry without rebooting or rmmod-ing scsi).
> 
> Thanks for kindly finding the time to share these hints, I have now
> begun the work of decrypting them.
> 
> 1) `find /lib/modules -name '*.ko'` says I have no scsi.ko.  If I kick
> around in `make xconfig` long enough, I may find one.

It is named scsi_mod.ko if you built it as a module.

Once you have a base .config it is easier to modify the .config and then
run make oldconfig and answer y/n/m.

I usually just delete the line in question from .config, and run make
oldconfig. In this case delete the line with CONFIG_SCSI and run make
oldconfig.

> 2) By vendor:model I first guess we mean what bash would say as
> "$vendor:$model", of 8 and x10 bytes respectively, same as in op x12
> Inquiry.

Yes.

-- Patrick Mansfield

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Pat LaVarre]

> If you want to test with your read only media, just use the dev flags:
> 
> 	echo "vendor:model:0x4000" > /proc/scsi/device_info 
> 
> Then add your device, see if it comes back as writable, and try to mount
> or write it, and compare without the above (you can't remove device_info
> entry without rebooting or rmmod-ing scsi).

Success!

Yes I see, same for sd as for sr/ide-cd, we can defeat write-protect in
2.6.0-test9 by root privilege so that then we can fail to write thru dd
or thru mount without bothering to notify the user loudly.

To prepare I remember I tried:

1) Make device writable.
2) mkfs
3) sync
4) Unplug.
5) Make device read-only.
6) Plug back in.

Thereafter I saw such tty logs as:

$ sudo sg_scan -i
/dev/sg0: scsi0 channel=0 id=0 lun=0 [em]  type=0
    LEXAR     DIGITAL FILM      /W1. [wide=0 sync=0 cmdq=0 sftre=0 pq=0x0]
$
$ v="LEXAR   "; m="DIGITAL FILM    "; echo "$v:$m:0x4000" | sudo dd of=/proc/scsi/device_info
0+1 records in
0+1 records out
$
$ sudo dd of=/dev/sda1 if=/dev/zero bs=512 count=1
dd: opening `/dev/sda1': Read-only file system
$
$ sudo modprobe -r usb-storage
$ sudo modprobe usb-storage
$
$ sudo dd of=/dev/sda1 if=/dev/zero bs=512 count=1
1+0 records in
1+0 records out
$
$ dmesg | tail
usb-storage:  -y "00 00 00 00 00 00"
usb-storage:  -i 0x1000 -y "28 00 00 00 00 20 00 00 08 00"
usb-storage:  -o 0x1000 -y "2A 00 00 00 00 20 00 00 08 00"
SCSI error : <4 0 0 0> return code = 0x8000002
Info fld=0x0, Current sda: sense = f0  7
ASC=27 ASCQ= 0
Raw sense data:0xf0 0x00 0x07 0x00 0x00 0x00 0x00 0x0b 0x00 0x00 0x00 0x00 0x27 0x00 0x00 0x00 0x00 0x00 0x00
end_request: I/O error, dev sda, sector 32
Buffer I/O error on device sda1, logical block 0
lost page write due to I/O error on sda1
$
$ sudo mount /dev/sda1 /mnt/sda1
$ ls /mnt/sda1
lost+found
$ sudo umount /mnt/sda1
$ dmesg | tail
 [<c010b509>] sysenter_past_esp+0x52/0x71
 
usb-storage:  -o 0x400 -y "2A 00 00 00 00 22 00 00 02 00"
SCSI error : <4 0 0 0> return code = 0x8000002
Info fld=0x0, Current sda: sense = f0  7
ASC=27 ASCQ= 0
Raw sense data:0xf0 0x00 0x07 0x00 0x00 0x00 0x00 0x0b 0x00 0x00 0x00 0x00 0x27 0x00 0x00 0x00 0x00 0x00 0x00
end_request: I/O error, dev sda, sector 34
Buffer I/O error on device sda1, logical block 1
lost page write due to I/O error on sda1
$

> [Trimmed the cc line]

Ack.

I concluded by trying:

$ egrep 'CONFIG_SCSI.*m' .config
CONFIG_SCSI=m
CONFIG_SCSI_DEBUG=m
$

Also I was helped by the dmesg:

scsi_strcpy_devinfo: vendor string 'LEXAR     ' is too long
scsi_strcpy_devinfo: model string 'DIGITAL FILM      ' is too long

And I failed to immediately grok `logger`.  Instead I correlated my
shell commands with my dmesg by patching usb-storage to trace cdb's. 

Pat LaVarre

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Matthew Dharm]

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

On Thu, Nov 13, 2003 at 04:37:12PM -0700, Pat LaVarre wrote:
> Maybe here I mean to ask: can we easily nutshell for me how well
> write-protect works now in sd?  I understand that we find mode sense of
> header alone and mode sense of xFF troublesome.

sd checks for write-protect status when it decides to 'revalidate' the
disk.  That means, basically, when the user has instructed the device to
eject media, or the device returns sense data indicating that media might
have changed.

Matt

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

What, are you one of those Microsoft-bashing Linux freaks?
					-- Customer to Greg
User Friendly, 2/10/1999

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

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Pat LaVarre]

Alan S:

> > > > We may as well fix SCSI over IDE and SCSI over 1394/FireWire/iLink at
> > > > the same time we fix SCSI over USB, yes?
> > > 
> > > Are they broken?
> > 
> > Aye, in much the same way: nothing but Talk Like Windows actually works
> > well ...
>
> Those sound like different issues from the one we've been discussing in 
> this thread, namely: how should sd.c try to determine the read/write 
> status and cache-type of a disk device?

I mean to be saying sd.c should by default send the CDB's associated
with buffer lengths that produce the same BBB CBW's as Windows XP/2K,
and then determine the read/write status and cache-type from that info
alone.

Do you agree that works for generic USB storage i.e. bInterfaceClass
...SubClass ...Protocol = x 08 (02|05|06) 50?

Do you disagree that is what we should do in sd for generic USB storage?

I'm confident Win XP/2K sometimes sends mode select to PDT x00
HDD/Flash, because I remember some months back a friend fixed some
firmware that didn't interpret mode select like Win wants nowadays.

I imagine that means Win sends mode sense too.

I haven't yet seen a trace of Win XP/2K.

Pat LaVarre

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Dmitri Katchalov]

Quoting Pat LaVarre <p.lavarre@ieee.org>:

> Alan S:
> 
> > > > > We may as well fix SCSI over IDE and SCSI over 1394/FireWire/iLink
> at
> > > > > the same time we fix SCSI over USB, yes?
> > > > 
> > > > Are they broken?
> > > 
> > > Aye, in much the same way: nothing but Talk Like Windows actually works
> > > well ...
> >
> > Those sound like different issues from the one we've been discussing in 
> > this thread, namely: how should sd.c try to determine the read/write 
> > status and cache-type of a disk device?
> 
> I mean to be saying sd.c should by default send the CDB's associated
> with buffer lengths that produce the same BBB CBW's as Windows XP/2K,
> and then determine the read/write status and cache-type from that info
> alone.
> 
> Do you agree that works for generic USB storage i.e. bInterfaceClass
> ...SubClass ...Protocol = x 08 (02|05|06) 50?
> 
> Do you disagree that is what we should do in sd for generic USB storage?
> 
> I'm confident Win XP/2K sometimes sends mode select to PDT x00
> HDD/Flash, because I remember some months back a friend fixed some
> firmware that didn't interpret mode select like Win wants nowadays.
> 
> I imagine that means Win sends mode sense too.
> 
> I haven't yet seen a trace of Win XP/2K.

I don't have W2K. I tried to get a trace on XP, it didn't work. 
USB Snoopy does not seem to work on XP. Let me know if you know 
of a better tool. 

Note that Win98 did not support my Sony Handycam Memory Stick out of 
the box, I had to install drivers from Sony installation CD. 
Obviously these drivers do not attempt to issue any commands that 
the device does not understand. XP did detect Sony out of the box but 
it is very likely that it still loaded proprietary Sony driver based 
on USB Device/Vendor ID. 

Also note: the device does not claim any SCSI compliance as indicated 
by reserved values in its device descriptor and by scsi version being 
set to 0 in reply to INQUIRY. It is a miracle it worked at all.

IMHO the solution is either or both of:
* Blacklist it
* Define an absolute bare minimum safe subset of SCSI commands and 
fall back to it whenever you see a non-compliant device like this one.

Regards,
Dmitri

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Pat LaVarre]

> I don't have W2K. I tried to get a trace on XP, it didn't work. 
> USB Snoopy does not seem to work on XP. Let me know if you know 
> of a better tool. 

Myself?  No.  My friends, yes.  Just now I tried generic x 08 06 50 =
bInterfaceClass ...SubClass ...Protocol, specifically an Iomega Zip
drive with no disk.  Transcribing the trace by hand I may have seen:

1: -i x24 -y "12 00:00:00 24 00" // standard Inquiry

2: -i xFC -y "23 00 00:00:00:00 00 00:FC 00" // Read Format Cap
residue xFC
autosense: -i x12 -y "03 00:00:00 12 00"
sk asc = x 6 29 Reset

3: -i xFC -y "23 00 00:00:00:00 00 00:FC 00" // Read Format Cap
residue xE8

4: -i x24 -y "12 00:00:00 24 00" // standard Inquiry

5: -i xFC -y "25 00 00:00:00:00 00 00:00 00" // Read Capacity
residue x08
autosense: -i x12 -y "03 00:00:00 12 00"
sk asc = x 2 04 02 Please Start

6: -y "1B 00:00:00 01 00" // Start Unit

7: -y "00 00:00:00 00 00" // Test Unit Ready
autosense: -i x12 -y "03 00:00:00 12 00"
sk asc = x 2 3A Disc Absent

8: -i xFC -y "25 00 00:00:00:00 00 00:00 00" // Read Capacity
residue x08
autosense: -i x12 -y "03 00:00:00 12 00"
sk asc = x 2 3A Disc Absent

9: -i x200 -y "28 00 00:00:00:00 00 00:01 00" // Read Blocks
residue x200
autosense: -i x12 -y "03 00:00:00 12 00"
sk asc = x 2 3A Disc Absent

10: -i xC0 -y "1A 00:1C:00 C0 00" // Mode Sense (6)
autosense: -i x12 -y "03 00:00:00 12 00"
sk asc = x 5 24 CDB Unknown

11: -i xC0 -y "1A 00:3F:00 C0 00" // Mode Sense (6)
residue x7A

12: -o x18 -y "15 10:00:00 18 00" // Mode Select (6)
residue xA8

13: -i xFC -y "25 00 00:00:00:00 00 00:00 00" // Read Capacity
residue x08
autosense: -i x12 -y "03 00:00:00 12 00"
sk asc = x 2 3A Disc Absent
14: (same as 13)
15: (same as 13)

16: (same as 7)
17: (same as 7)

18: (same as 13)
19: (same as 13)
20: (same as 13)
21: (same as 13)
22: (same as 13)

23: (same as 7)
24: (same as 7)
25: (same as 7)

26: -i x0C -y "1A 00:00:00 0C 00" // Mode Sense (6)
27: (same as 26)

28: (same as 13)
29: (same as 7)
30: (same as 26)
31: (same as 13)
32: (same as 13)
33: (same as 7)

34: -i x0C -y "1A 00:3F:00 0C 00" // Mode Sense (6)

35: (same as 13)
36: (same as 13)
37: (same as 7)
38: (same as 26)
39: (same as 7)
40: (same as 26)
...

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Matthew Dharm]

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

On Fri, Nov 14, 2003 at 11:13:16AM +1100, Dmitri Katchalov wrote:
> IMHO the solution is either or both of:
> * Blacklist it
> * Define an absolute bare minimum safe subset of SCSI commands and 
> fall back to it whenever you see a non-compliant device like this one.

How about:
	* Define an absolute bare minimum safe subset of SCSI commands and
	  use only those commands when communicating with a USB device.

Really, this is just a varient of blacklisting, but it's one I like.  I
suggested something like this a while ago -- if the emulated flag was set,
certain commands were not sent.  Linus didn't like that, but I think he
objected more to the 'emulated' flag than anything else.

Tho, I think we're basically at a point where the only problematic command
is MODE_SENSE and MODE_SENSE_10, so I say blacklisting them from USB
devices should be fine.

Matt

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

G:  Money isn't everything, A.J.
AJ: Who convinced you of that?
G:  The Chief, at my last salary review.
					-- Mike and Greg
User Friendly, 11/3/1998

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

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Pat LaVarre]

> From: Matthew Dharm ...
> How about:
> 	* Define an absolute bare minimum safe
>         subset of SCSI commands and use only
>         those commands when communicating with
>         a USB device
> ...
> a varient of blacklisting ... I like ...

Yes please, me too.

> From: Matthew Dharm ...
> I suggested something like this a while ago --
> if the emulated flag was set, certain commands
> were not sent.  Linus didn't like that, but I
> think he objected more to the 'emulated' flag
> than anything else.

Urgh.  What am I missing?

Minimum mostly safe subset works better.  Right?

Not just with SCSI over USB.  So likewise with SCSI over IDE (aka ATAPI)
and SCSI over 1394/ FireWire/ iLink (aka SBP2 Normative Annex B). 
Right?

I'm hoping we will discover for PDT x00 HDD/Flash the minimum mostly
safe subset includes such as that (transcribed-by-hand from CATC USB
Advisor) trace of Win XP SP1 once upon a time with a particular sample
device while disc absent:

> -i xC0 -y "1A 00:1C:00 C0 00" // Mode Sense (6)
> -i xC0 -y "1A 00:3F:00 C0 00" // Mode Sense (6)
> -i x0C -y "1A 00:00:00 0C 00" // Mode Sense (6)
> -i x0C -y "1A 00:3F:00 0C 00" // Mode Sense (6)

I'm not sure how Win translates to MMC op x5A GPCMD_MODE_SENSE_10 from
the SPC op x1A MODE_SENSE 6 of Win SCSI.

To be sure we'd have to trace something other than an x 08 06 50 device
(= Mass Storage, Transparent SCSI, BBB)

I'm thinking I remember seeing the length either doesn't change or else
adds four to account for the growth to 8 byte header from 4 byte header
i.e. either:

-p -i xC0 -y "5A 00 1C:00:00:00 00 00:C0 00 00:00" // Mode Sense (10)
-p -i xC0 -y "5A 00 3F:00:00:00 00 00:C0 00 00:00" // Mode Sense (10)
-p -i x0C -y "5A 00 00:00:00:00 00 00:0C 00 00:00" // Mode Sense (10)
-p -i x0C -y "5A 00 3F:00:00:00 00 00:0C 00 00:00" // Mode Sense (10)

or else:

-p -i xC4 -y "5A 00 1C:00:00:00 00 00:C4 00 00:00" // Mode Sense (10)
-p -i xC4 -y "5A 00 3F:00:00:00 00 00:C4 00 00:00" // Mode Sense (10)
-p -i x10 -y "5A 00 00:00:00:00 00 00:10 00 00:00" // Mode Sense (10)
-p -i x10 -y "5A 00 3F:00:00:00 00 00:10 00 00:00" // Mode Sense (10)

Pat LaVarre

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Pat LaVarre]

> * Define an absolute bare minimum safe subset of SCSI commands and 
> fall back to it whenever you see a non-compliant device like this one.

Did we find a kind of reset that worked with this device?

> Note that Win98 did not support my Sony Handycam Memory Stick out of 
> the box, I had to install drivers from Sony installation CD. 
> Obviously these drivers do not attempt to issue any commands that 
> the device does not understand. XP did detect Sony out of the box but 
> it is very likely that it still loaded proprietary Sony driver based 
> on USB Device/Vendor ID. 

I agree.

I guess this from seeing bInterfaceSubClass = xFF = Formally Reserved
But Informally Vendor Specific SCSI.  That pushes the bInterfaceClass
...SubClass ...Protocol outside of the tuples that Microsoft blesses as
generic usb storage i.e. outside of the set x 08 (02|05|06) 50.

> Also note: the device does not claim any SCSI compliance as indicated 
> by reserved values in its device descriptor and by scsi version being 
> set to 0 in reply to INQUIRY.

Aye.

> IMHO the solution is either or both of:
> * Blacklist it

Can we blacklist mode sense from bInterfaceSubClass = xFF?

That way we don't break as many write-protectable devices as if we
blacklisted mode sense always?

I remember today already I once proposed blacklisting only
bInterfaceSubClass = xFF, Matt said no once, I don't think I yet grok
Matt's no.

Can we blacklist only xFF if I wrote the patch myself?

I've shipped generic devices that I think comply: that gives me a
personal interest in having their write-protect work, no matter if
connected via USB.

Pat LaVarre

P.S.

> Also note: the device does not claim any SCSI compliance...
> miracle it worked at all.

Aye.  Myself, I'd like to get an academic grant to study why computers
work.  As far as I can tell, they shouldn't.  Fundamentally chaotic
design.  Try flipping a bit in an instruction stream, and watch what
happens.

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Matthew Dharm]

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

On Thu, Nov 13, 2003 at 07:10:34PM -0700, Pat LaVarre wrote:
> Can we blacklist mode sense from bInterfaceSubClass = xFF?
> 
> That way we don't break as many write-protectable devices as if we
> blacklisted mode sense always?
> 
> I remember today already I once proposed blacklisting only
> bInterfaceSubClass = xFF, Matt said no once, I don't think I yet grok
> Matt's no.
> 
> Can we blacklist only xFF if I wrote the patch myself?

Perhaps I didn't understand what you were asking....

To blacklist bInterfaceSubClass = 0xFF, you'll have to do that at the
usb-storage layer (not the SCSI layer).  I generally object to that, but
not very strongly -- I want usb-storage to be as simple/dumb as possible,
to reduce to number of places where it doesn't do what the end-user
expects.  (The principle of least suprise)

If the blacklist was implemented such that it only blacklisted
direct-access devices, and only MODE_SENSE and MODE_SENSE_10, and provided
fake sense data, then it would probably work.  Messy, but it would work.

The point is to create as narrow an exception as possible.

Matt

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

Umm, these aren't the droids you're looking for.
					-- Bill Gates
User Friendly, 11/14/1998

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

[usb-storage] mode sense blacklist how

[Pat LaVarre]

> The point is to create as narrow an exception as possible.

Yes please.

> ...

To accomodate this device are we asking Dmitri K to give one last shot
to telling us if kernel crash, boot fs crash, or other is the result of
each of the twelve:

> > -i xC0 -y "1A 00:1C:00 C0 00" // Mode Sense (6)
> > -i xC0 -y "1A 00:3F:00 C0 00" // Mode Sense (6)
> > -i x0C -y "1A 00:00:00 0C 00" // Mode Sense (6)
> > -i x0C -y "1A 00:3F:00 0C 00" // Mode Sense (6)
> ...
> -p -i xC0 -y "5A 00 1C:00:00:00 00 00:C0 00 00:00" // Mode Sense (10)
> -p -i xC0 -y "5A 00 3F:00:00:00 00 00:C0 00 00:00" // Mode Sense (10)
> -p -i x0C -y "5A 00 00:00:00:00 00 00:0C 00 00:00" // Mode Sense (10)
> -p -i x0C -y "5A 00 3F:00:00:00 00 00:0C 00 00:00" // Mode Sense (10)
> ...
> -p -i xC4 -y "5A 00 1C:00:00:00 00 00:C4 00 00:00" // Mode Sense (10)
> -p -i xC4 -y "5A 00 3F:00:00:00 00 00:C4 00 00:00" // Mode Sense (10)
> -p -i x10 -y "5A 00 00:00:00:00 00 00:10 00 00:00" // Mode Sense (10)
> -p -i x10 -y "5A 00 3F:00:00:00 00 00:10 00 00:00" // Mode Sense (10)

?

> To blacklist bInterfaceSubClass = 0xFF, you'll have to do that at the
> usb-storage layer (not the SCSI layer).  I generally object to that, but
> not very strongly -- I want usb-storage to be as simple/dumb as possible,
> to reduce to number of places where it doesn't do what the end-user
> expects.  (The principle of least suprise)
> 
> If the blacklist was implemented such that it only blacklisted
> direct-access devices, and only MODE_SENSE and MODE_SENSE_10, and provided
> fake sense data, then it would probably work.  Messy, but it would work.

I remember already in usb-storage we intercept op x12 Inquiry (to munge
bytes[2] compliance to x02 from x00).

I figure there we can flip a bit to say we saw (byte[0] & x1F) PDT = x00
HDD/Flash.  To name & allot the bit, I can follow our earlier incomplete
usb-trace efforts ... urgh, we have no googlable usb-storage archive, I
will review source and see if I remember.

Nearby I suppose we can find bInterfaceSubClass and compare to xFF.

Then if bit set and SubClass xFF and op is x1A/5A we can simulate
failure by auto sense of x12 available bytes with residue = all data and
sk asc = x 5 20 Unsupported Op.

Shall we try that next?

> ...

Ouch, one last thing: tell me again what device/interface descriptors
our usb-storage by default tries to support?

Is that bInterfaceClass ...SubClass ...Protocol = x 08 XX (00|01|50)? 
Or just x 08 (00..06|FF) (00|01|50)?  (Clearly it's not just the
formally defined x 08 (00..06) (00|01|50).)

I ask because if we're supporting bInterfaceSubClass via
drivers/usb/storage/unusual_devs.h then we might rather put the
blacklist there.  But I'm guessing this answer is: x 08 XX (00|01|50),
so we'd rather blacklist all of x 08 FF (00|01|50), rather than growing
unusual_devs.h.

Pat LaVarre

Re: [usb-storage] mode sense blacklist how

[Matthew Dharm]

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

On Thu, Nov 13, 2003 at 07:38:30PM -0700, Pat LaVarre wrote:
> Ouch, one last thing: tell me again what device/interface descriptors
> our usb-storage by default tries to support?
> 
> Is that bInterfaceClass ...SubClass ...Protocol = x 08 XX (00|01|50)? 
> Or just x 08 (00..06|FF) (00|01|50)?  (Clearly it's not just the
> formally defined x 08 (00..06) (00|01|50).)

We support x 08 (00..06) (00|01|50).) plus whatever is listed in the
unusual_devs.h file.

Matt

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

G:  Let me guess, you started on the 'net with AOL, right?
C:  WOW! d00d! U r leet!
					-- Greg and Customer 
User Friendly, 2/12/1999

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

Re: [usb-storage] mode sense blacklist how

[Pat LaVarre]

> > Ouch, one last thing: tell me again what device/interface descriptors
> > our usb-storage by default tries to support?
> > 
> > Is that bInterfaceClass ...SubClass ...Protocol = x 08 XX (00|01|50)? 
> > Or just x 08 (00..06|FF) (00|01|50)?  (Clearly it's not just the
> > formally defined x 08 (00..06) (00|01|50).)
> 
> We support x 08 (00..06) (00|01|50).) plus whatever is listed in the
> unusual_devs.h file.

Ouch.  I guessed soooo wrong.  I see already we connect automagically
only with devices that claim compliance to a published standard.  Good
to hear, thank you.  Starting again now:

I hear you saying we're talking SCSI to our failing Sony stick only
because we patched unusual_devs.h?

When we patch unusual_devs.h to say to talk to this Sony stick, how
about we simultaneously patch in a flag to say don't talk mode sense to
it?

As you can see, by now I see only the principle that we can see sd
doesn't yet quite Talk Like Windows.  I've lost track of why
specifically now we believe sd has an issue we should fix.  

Help?

Pat LaVarre

Re: [usb-storage] mode sense blacklist how

[Pat LaVarre]

> I've lost track of why
> specifically now we believe sd has an issue we should fix.  
> 
> Help?

Sorry never mind.

Answered asynchronously by patch outside of sd to
drivers/usb/storage/scsiglue.c in "Subject: [usb-storage] Re: Time to
conclude the Sony USB mass storage thread".

Pat LaVarre

Re: [usb-storage] mode sense blacklist how

[Dmitri Katchalov]

Quoting Pat LaVarre <p.lavarre@ieee.org>:

> To accomodate this device are we asking Dmitri K to give one last shot
> to telling us if kernel crash, boot fs crash, or other is the result of
> each of the twelve:
> 
> > > -i xC0 -y "1A 00:1C:00 C0 00" // Mode Sense (6)
> > > -i xC0 -y "1A 00:3F:00 C0 00" // Mode Sense (6)
> > > -i x0C -y "1A 00:00:00 0C 00" // Mode Sense (6)
> > > -i x0C -y "1A 00:3F:00 0C 00" // Mode Sense (6)
> > ...
> > -p -i xC0 -y "5A 00 1C:00:00:00 00 00:C0 00 00:00" // Mode Sense (10)
> > -p -i xC0 -y "5A 00 3F:00:00:00 00 00:C0 00 00:00" // Mode Sense (10)
> > -p -i x0C -y "5A 00 00:00:00:00 00 00:0C 00 00:00" // Mode Sense (10)
> > -p -i x0C -y "5A 00 3F:00:00:00 00 00:0C 00 00:00" // Mode Sense (10)
> > ...
> > -p -i xC4 -y "5A 00 1C:00:00:00 00 00:C4 00 00:00" // Mode Sense (10)
> > -p -i xC4 -y "5A 00 3F:00:00:00 00 00:C4 00 00:00" // Mode Sense (10)
> > -p -i x10 -y "5A 00 00:00:00:00 00 00:10 00 00:00" // Mode Sense (10)
> > -p -i x10 -y "5A 00 3F:00:00:00 00 00:10 00 00:00" // Mode Sense (10)
> 
> ?

I'll be away for the next 4 days. I'll try to test it now, 
if not I'll report when I come back. What exactly do you want me to do?

Regards,
Dmitri

Re: [usb-storage] mode sense blacklist how

[Pat LaVarre]

// Everyone:

I think I'm seeing hints that possibly we've carried this reply-to-all
convention a little too far by now.  Not sure how to fix that.

// Dmitri K:

> > To accomodate this device are we asking Dmitri K to give one last shot
> > to telling us if kernel crash, boot fs crash, or other is the result of
> > each of the twelve ...
> > ?
> 
> I'll be away for the next 4 days. I'll try to test it now, 
> if not I'll report when I come back ...
> What exactly do you want me to do?

Step-by-step instructions follow, in case you choose to try them.

I see we have committed to teaching usb-storage to blacklist mode sense,
despite thereby breaking sd devices that write-protect disks by
implementing mode sense as described in the fiction authored by t10.

Therefore I cannot know who among "we" besides me still cares that the
sample Sony stick you're sharing with us chokes over how we used to try
mode sense.

As for me, yes I remain curious.  I'd like you (and all the world's
engineers) to learn to explore such matters.

> What exactly do you want me to do?

First step in learning to explore this way is to install some tool for
trying SG_IO from the command line, such as the download/ patch/ make
instructions of:

http://groups.google.com/groups?q=plscsi+sed+make

Newsgroups: mlist.linux.scsi
Subject: Re: [PATCH/RFT] mode sense madness always use page 8
Date: 2003-10-30 16:20:20 PST

You know you've finished decrypting that post when you get as far as:

sudo ./plscsi -w

Next you can proceed to try the twelve Sony stick experiments suggested
by that Win XP SP1 trace of an Iomega Zip with disk absent.  I think I
remember translating from those experiments as posted to bash and plscsi
syntax requires just substituting -x for -y, thus yielding:

export PLSCSI=/dev/sda

sudo plscsi -i xC0 -x "1A 00:1C:00 C0 00" // Mode Sense (6)
sudo plscsi -i xC0 -x "1A 00:3F:00 C0 00" // Mode Sense (6)
sudo plscsi -i x0C -x "1A 00:00:00 0C 00" // Mode Sense (6)
sudo plscsi -i x0C -x "1A 00:3F:00 0C 00" // Mode Sense (6)

sudo plscsi -p -i xC0 -x "5A 00 1C:00:00:00 00 00:C0 00 00:00" // Mode Sense (10)
sudo plscsi -p -i xC0 -x "5A 00 3F:00:00:00 00 00:C0 00 00:00" // Mode Sense (10)
sudo plscsi -p -i x0C -x "5A 00 00:00:00:00 00 00:0C 00 00:00" // Mode Sense (10)
sudo plscsi -p -i x0C -x "5A 00 3F:00:00:00 00 00:0C 00 00:00" // Mode Sense (10)

sudo plscsi -p -i xC4 -x "5A 00 1C:00:00:00 00 00:C4 00 00:00" // Mode Sense (10)
sudo plscsi -p -i xC4 -x "5A 00 3F:00:00:00 00 00:C4 00 00:00" // Mode Sense (10)
sudo plscsi -p -i x10 -x "5A 00 00:00:00:00 00 00:10 00 00:00" // Mode Sense (10)
sudo plscsi -p -i x10 -x "5A 00 3F:00:00:00 00 00:10 00 00:00" // Mode Sense (10)

I trust already you understand, running plscsi with root or even just
device-write privilege by design can and does crash your kernel on
occasion, thus smashing automounted or manually mounted fs.

plscsi in effect gives you a way of typing out some of the code of a
module at the command line.  Entering a mistyped or misconceived line of
plscsi can hurt you as deeply as loading an untested .ko.

I wonder if already you understand, you might like the results better if
you only try talking while you device has no disk inserted, or at least
while disk not mounted, and preferably while you have no automounter
talking to your device.

> From: Dmitri Katchalov ...
> I'll be away for the next 4 days.

Soon I will discover if I replied quickly enough to catch you. :)

Pat LaVarre

Re: [usb-storage] mode sense blacklist how

[Pat LaVarre]

> [Resending, this never showed up on linux-scsi.]

us.ibm.co vs.us.ibm.com ambiguities may have entered this thread from
here, sorry ouch ouch ouch, these new-fangled protocols for mixing human
names into mailto addresses don't quite reach me everywhere I connect.

> I am not really sure what happened, I think it is waiting for a 30 hr
> timeout to complete, you ought to lower the timeout a bit ;-)

Just before we redesign this plscsi default for a different audience ...

Please tell me why Ctrl+C aka SIGINT doesn't work?

As a client of SG_IO, am I supposed to work to catch SIGINT explicitly
so I can pass that SIGINT thru sg somehow?  (And is that answer
documented anywhere?)

> I am not really sure what happened, I think it is waiting for a 30 hr
> timeout to complete, you ought to lower the timeout a bit ;-)

Thank you for saying.  You are the second host developer who has somehow
found the time to tell me this.  An override syntax that might work is:

export PLSCSI=/dev/sda -X time 5 0

I'll race you all to try and report back how accurately I'm remembering
that plscsi syntax.

The issue of a long timeout arises because personally I've lived mostly
as a developer of device firmware, rather than host software.

A long timeout was the only effective way I found to persuade the host
to let me stop a test at first weirdness.  With short timeouts, the host
would automagically attack the device with resets, destroying all
evidence of what went wrong to begin with.

To my eye, polite hosts delay the automagic attack until the next
command.  That way, I can sit at the top of the stack and ask to halt at
first weirdness.  So long as I prevent any other commands from going
down thru the stack, then so likewise do I prevent the automagic
attack.  But only if I have a host designed to be polite by default.

> The following did nothing, I am running on 2.6 current bk + only my earlier
> send oversize MODE SENSE buffer patch.
> 
> Is that expected without -v?
> 
> > sudo plscsi -p -i xC0 -x "5A 00 1C:00:00:00 00 00:C0 00 00:00" // Mode Sense (10)

Yes I now agree I should have mentioned we add -v to see a trace of what
was tried when, sorry I did not.

> Full results:

Great fun, thank you.

> + PLPROG=/home/patman/src/plscsi/plscsi
> + DEV=/dev/sda
> + /home/patman/src/plscsi/plscsi -i xC0 -x '1A 00:1C:00 C0 00' /dev/sda
> // x 5 20 sense // xC0 (192) residue
> // -x0102 = -258 = plscsi.main exit int
> + /home/patman/src/plscsi/plscsi -i xC0 -x '1A 00:3F:00 C0 00' /dev/sda
> // x 5 20 sense // xC0 (192) residue
> // -x0102 = -258 = plscsi.main exit int
> + /home/patman/src/plscsi/plscsi -i x0C -x '1A 00:00:00 0C 00' /dev/sda
> // x 5 20 sense // xC (12) residue
> // -x0102 = -258 = plscsi.main exit int
> + /home/patman/src/plscsi/plscsi -i x0C -x '1A 00:3F:00 0C 00' /dev/sda
> // x 5 20 sense // xC (12) residue
> // -x0102 = -258 = plscsi.main exit int

Cool.

Here we repeatedly see nonzero residue equal to the data byte count
asked to copy in.  That suggests we may be getting accurate reporting of
residue from the connection between you and the drive.

SK ASC = x 5 20 correlates with versions of t10.org English over time,
all of which I think I remember say op not known i.e. cdb[0] not known
i.e. apparently this device correctly reports it does not support op x1A
Mode Sense (6).

> + /home/patman/src/plscsi/plscsi -p -i xC0 -x '5A 00 1C:00:00:00 00 00:C0 00 00:00' /dev/sda
> + /home/patman/src/plscsi/plscsi -p -i xC0 -x '5A 00 3F:00:00:00 00 00:C0 00 00:00' /dev/sda
> + /home/patman/src/plscsi/plscsi -p -i x0C -x '5A 00 00:00:00:00 00 00:0C 00 00:00' /dev/sda
> + /home/patman/src/plscsi/plscsi -p -i x0C -x '5A 00 3F:00:00:00 00 00:0C 00 00:00' /dev/sda
> + /home/patman/src/plscsi/plscsi -p -i xC4 -x '5A 00 1C:00:00:00 00 00:C4 00 00:00' /dev/sda
> + /home/patman/src/plscsi/plscsi -p -i xC4 -x '5A 00 3F:00:00:00 00 00:C4 00 00:00' /dev/sda
> + /home/patman/src/plscsi/plscsi -p -i x10 -x '5A 00 00:00:00:00 00 00:10 00 00:00' /dev/sda
> + /home/patman/src/plscsi/plscsi -p -i x10 -x '5A 00 3F:00:00:00 00 00:10 00 00:00' /dev/sda

I guess here we have been reading something much like a tty log of:

#!/bin/bash -x

By that guess, this quote says all those commands completed without
error.

>From that guess we conclude, if we try talking mode sense like Windows
does, we here have found one more device supporting us.

> Following is the "breaking" command that caused the original "--babble"
> and problem.
> 
> ./plscsi /dev/sda -v -i x4 -x "5A 00 3F:00:00:00 00 00:08 00"

Ouch that's gross.

That 00:08 in the bytes[7:8] of the -x "$cdb" tells the device to copy
up to 8 bytes in, but the -i x4 tells the device to never copy more than
4 bytes in.  We throw paradox at the device, and we get back "babble". 
Shame on the device, but shame on us too.

Mind you, since here we have CBI/CB protocol rather than BBB protocol,
the device never sees the -i x4, the device sees only the 00:08.  So in
a bus trace we see no babble: only the host that tries to reconcile -i
x4 with 8 bytes in from the device sees babble.

Since the device can't see CBI/CB break this way, the device can't
help.  With CBI/CB, by design, only the host can avoid this kind of
trouble, only by more accurately guessing in advance out-of-band how the
device will actually interpret a particular cdb.

> Luckily unplugging the device completes, and I can plug it back in and
> everything is ok! That is quite nice! Thanks for all the nice hotplug and
> ref-counting code everybody.

Brilliant, aye, kudos everyone.

> Following is the usb storage debug logs for the above command, including
> "--babble" output. 
> 
> I added some messages via "logger -p kern.debug" to separate things.

Ooooh.  I've been looking to discover that `logger` command since the
day I discovered `dmesg`.  Thank you for naming it explicitly.

> Weird that we tried to send another MODE SENSE *after* I unplugged the
> device, maybe an abort or cancel of the commands caused it to retry before
> the device was actually removed, more likely usb aborted outstanding
> commands prior to a call to scsi_remove_host (that is OK).
> 
> -----------------------------------------------------------------------------
> 
> Nov 14 14:51:34 laptop patman:  NOTE pre post too short command sent
> ...
> Nov 14 14:52:39 laptop patman: NOTE unplugging device NOTE
> ...
> Nov 14 14:52:44 laptop kernel: usb-storage: -- usb_stor_release_resources finished
> ...
> Nov 14 14:52:52 laptop patman: NOTE device unplugged NOTE

I read that trace with interest, thank you.

Pat LaVarre

Re: [usb-storage] mode sense blacklist how

[Dmitri Katchalov]

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

Quoting Pat LaVarre <p.lavarre@ieee.org>:

> Step-by-step instructions follow, in case you choose to try them.

I understand that you guys must be sick and tired of those
memory sticks by now. Just in case you're still interested
here is my report:

Long version: 
  See attached kern.log

Short version:
 MODE SENSE (6): device reports STALL condition. Subsequent
 auto-REQUEST SENSE reports "Illegal Request in CDB".
 As far as I undertand the device tries to tell us that the
 command is not supported.

 MODE SENSE (10): plscsi hangs and sits there in 
 usb_stor_bulk_transfer_buf until the device is 
 physically unplugged. kill -9 has no effect.

 Another interesting "feature": the camera does not work 
 as a USB device without memory stick in its slot. That is 
 if I plug it in without the stick nothing happens. When I 
 then insert the stick it goes through the normal port 
 status change/discovery/enumeration routine. When I
 remove the stick from its slot the device pretends it 
 has been disconnected.

Regards,
Dmitri


[-- Attachment #2: kern.log.usb --]
[-- Type: application/octet-stream, Size: 54802 bytes --]

<turning the camera on>

Nov 20 07:51:40 box kernel: ehci_hcd 0000:00:1d.7: GetStatus port 3 status 003002 POWER OWNER sig=se0  CSC
Nov 20 07:51:40 box kernel: hub 5-0:1.0: port 3, status 0, change 1, 12 Mb/s
Nov 20 07:51:40 box kernel: ehci_hcd 0000:00:1d.7: GetStatus port 4 status 001002 POWER sig=se0  CSC
Nov 20 07:51:40 box kernel: hub 5-0:1.0: port 4, status 100, change 1, 12 Mb/s
Nov 20 07:51:44 box kernel: ehci_hcd 0000:00:1d.7: GetStatus port 3 status 003002 POWER OWNER sig=se0  CSC
Nov 20 07:51:44 box kernel: hub 5-0:1.0: port 3, status 0, change 1, 12 Mb/s
Nov 20 07:51:44 box kernel: ehci_hcd 0000:00:1d.7: GetStatus port 4 status 001803 POWER sig=j  CSC CONNECT
Nov 20 07:51:44 box kernel: hub 5-0:1.0: port 4, status 501, change 1, 480 Mb/s
Nov 20 07:51:44 box kernel: hub 5-0:1.0: debounce: port 4: delay 100ms stable 4 status 0x501
Nov 20 07:51:44 box kernel: ehci_hcd 0000:00:1d.7: port 4 full speed --> companion
Nov 20 07:51:44 box kernel: ehci_hcd 0000:00:1d.7: GetStatus port 4 status 003801 POWER OWNER sig=j  CONNECT
Nov 20 07:51:44 box kernel: hub 2-0:1.0: port 2, status 101, change 1, 12 Mb/s
Nov 20 07:51:44 box kernel: hub 2-0:1.0: debounce: port 2: delay 100ms stable 4 status 0x101
Nov 20 07:51:44 box kernel: hub 2-0:1.0: new USB device on port 2, assigned address 4
Nov 20 07:51:44 box kernel: usb 2-2: new device strings: Mfr=1, Product=2, SerialNumber=0
Nov 20 07:51:44 box kernel: drivers/usb/core/message.c: USB device number 4 default language ID 0x409
Nov 20 07:51:44 box kernel: usb 2-2: Product: Sony Handycam
Nov 20 07:51:44 box kernel: usb 2-2: Manufacturer: Sony
Nov 20 07:51:44 box kernel: drivers/usb/core/usb.c: usb_hotplug
Nov 20 07:51:44 box kernel: usb 2-2: registering 2-2:1.0 (config #1, interface 0)
Nov 20 07:51:44 box kernel: drivers/usb/core/usb.c: usb_hotplug
Nov 20 07:51:44 box kernel: Initializing USB Mass Storage driver...
Nov 20 07:51:44 box kernel: usb-storage 2-2:1.0: usb_probe_interface
Nov 20 07:51:44 box kernel: usb-storage 2-2:1.0: usb_probe_interface - got id
Nov 20 07:51:44 box kernel: usb-storage: USB Mass Storage device detected
Nov 20 07:51:44 box kernel: usb-storage: act_altsetting is 0, id_index is 26
Nov 20 07:51:44 box kernel: usb-storage: -- associate_dev
Nov 20 07:51:44 box kernel: usb-storage: Vendor: Sony
Nov 20 07:51:44 box kernel: usb-storage: Product: Handycam
Nov 20 07:51:44 box kernel: usb-storage: Transport: Control/Bulk
Nov 20 07:51:44 box kernel: usb-storage: Protocol: Transparent SCSI
Nov 20 07:51:44 box kernel: usb-storage: Endpoints: In: 0xe5c6cf58 Out: 0xe5c6cf44 Int: 0xe5c6cf6c (Period 255)
Nov 20 07:51:44 box kernel: usb-storage: *** thread sleeping.
Nov 20 07:51:44 box kernel: scsi1 : SCSI emulation for USB Mass Storage devices
Nov 20 07:51:44 box kernel: usb-storage: queuecommand called
Nov 20 07:51:44 box kernel: usb-storage: *** thread awakened.
Nov 20 07:51:44 box kernel: usb-storage: Command INQUIRY (6 bytes)
Nov 20 07:51:44 box kernel: usb-storage:  12 00 00 00 24 00
Nov 20 07:51:44 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:51:44 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 07:51:44 box kernel: usb-storage: -- transfer complete
Nov 20 07:51:44 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 07:51:44 box kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 36 bytes
Nov 20 07:51:44 box kernel: usb-storage: Status code 0; transferred 36/36
Nov 20 07:51:44 box kernel: usb-storage: -- transfer complete
Nov 20 07:51:44 box kernel: usb-storage: CB data stage result is 0x0
Nov 20 07:51:44 box kernel: usb-storage: -- CB transport device requiring auto-sense
Nov 20 07:51:44 box kernel: usb-storage: Issuing auto-REQUEST_SENSE
Nov 20 07:51:44 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:51:44 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 07:51:44 box kernel: usb-storage: -- transfer complete
Nov 20 07:51:44 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 07:51:44 box kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Nov 20 07:51:44 box kernel: usb-storage: Status code 0; transferred 18/18
Nov 20 07:51:44 box kernel: usb-storage: -- transfer complete
Nov 20 07:51:44 box kernel: usb-storage: CB data stage result is 0x0
Nov 20 07:51:44 box kernel: usb-storage: -- Result from auto-sense is 0
Nov 20 07:51:44 box kernel: usb-storage: -- code: 0x70, key: 0x0, ASC: 0x0, ASCQ: 0x0
Nov 20 07:51:44 box kernel: usb-storage: No Sense: No additional sense information
Nov 20 07:51:44 box kernel: usb-storage: Fixing INQUIRY data to show SCSI rev 2 - was 0
Nov 20 07:51:44 box kernel: usb-storage: scsi cmd done, result=0x0
Nov 20 07:51:44 box kernel: usb-storage: *** thread sleeping.
Nov 20 07:51:44 box kernel:   Vendor: Sony      Model: Sony DSC          Rev: 3.00
Nov 20 07:51:44 box kernel:   Type:   Direct-Access                      ANSI SCSI revision: 02
Nov 20 07:51:44 box kernel: usb-storage: queuecommand called
Nov 20 07:51:44 box kernel: usb-storage: *** thread awakened.
Nov 20 07:51:44 box kernel: usb-storage: Bad target number (1:0)
Nov 20 07:51:44 box kernel: usb-storage: scsi cmd done, result=0x40000
Nov 20 07:51:44 box kernel: usb-storage: *** thread sleeping.
Nov 20 07:51:44 box kernel: usb-storage: queuecommand called
Nov 20 07:51:44 box kernel: usb-storage: *** thread awakened.
Nov 20 07:51:44 box kernel: usb-storage: Bad target number (2:0)
Nov 20 07:51:44 box kernel: usb-storage: scsi cmd done, result=0x40000
Nov 20 07:51:44 box kernel: usb-storage: *** thread sleeping.
Nov 20 07:51:44 box kernel: usb-storage: queuecommand called
Nov 20 07:51:44 box kernel: usb-storage: *** thread awakened.
Nov 20 07:51:44 box kernel: usb-storage: Bad target number (3:0)
Nov 20 07:51:44 box kernel: usb-storage: scsi cmd done, result=0x40000
Nov 20 07:51:44 box kernel: usb-storage: *** thread sleeping.
Nov 20 07:51:44 box kernel: usb-storage: queuecommand called
Nov 20 07:51:44 box kernel: usb-storage: *** thread awakened.
Nov 20 07:51:44 box kernel: usb-storage: Bad target number (4:0)
Nov 20 07:51:44 box kernel: usb-storage: scsi cmd done, result=0x40000
Nov 20 07:51:44 box kernel: usb-storage: *** thread sleeping.
Nov 20 07:51:44 box kernel: usb-storage: queuecommand called
Nov 20 07:51:44 box kernel: usb-storage: *** thread awakened.
Nov 20 07:51:44 box kernel: usb-storage: Bad target number (5:0)
Nov 20 07:51:44 box kernel: usb-storage: scsi cmd done, result=0x40000
Nov 20 07:51:44 box kernel: usb-storage: *** thread sleeping.
Nov 20 07:51:44 box kernel: usb-storage: queuecommand called
Nov 20 07:51:44 box kernel: usb-storage: *** thread awakened.
Nov 20 07:51:44 box kernel: usb-storage: Bad target number (6:0)
Nov 20 07:51:44 box kernel: usb-storage: scsi cmd done, result=0x40000
Nov 20 07:51:44 box kernel: usb-storage: *** thread sleeping.
Nov 20 07:51:44 box kernel: usb-storage: queuecommand called
Nov 20 07:51:44 box kernel: usb-storage: *** thread awakened.
Nov 20 07:51:44 box kernel: usb-storage: Bad target number (7:0)
Nov 20 07:51:44 box kernel: usb-storage: scsi cmd done, result=0x40000
Nov 20 07:51:44 box kernel: usb-storage: *** thread sleeping.
Nov 20 07:51:44 box kernel: WARNING: USB Mass Storage data integrity not assured
Nov 20 07:51:44 box kernel: USB Mass Storage device found at 4
Nov 20 07:51:44 box kernel: drivers/usb/core/usb.c: registered new driver usb-storage
Nov 20 07:51:44 box kernel: USB Mass Storage support registered.


Nov 20 07:55:36 box kernel: usb-storage: queuecommand called
Nov 20 07:55:36 box kernel: usb-storage: *** thread awakened.
Nov 20 07:55:36 box kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
Nov 20 07:55:36 box kernel: usb-storage:  00 00 00 00 00 00
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 07:55:36 box kernel: usb-storage: -- CB transport device requiring auto-sense
Nov 20 07:55:36 box kernel: usb-storage: Issuing auto-REQUEST_SENSE
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 18/18
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: CB data stage result is 0x0
Nov 20 07:55:36 box kernel: usb-storage: -- Result from auto-sense is 0
Nov 20 07:55:36 box kernel: usb-storage: -- code: 0x70, key: 0x0, ASC: 0x0, ASCQ: 0x0
Nov 20 07:55:36 box kernel: usb-storage: No Sense: No additional sense information
Nov 20 07:55:36 box kernel: usb-storage: scsi cmd done, result=0x0
Nov 20 07:55:36 box kernel: usb-storage: *** thread sleeping.
Nov 20 07:55:36 box kernel: usb-storage: queuecommand called
Nov 20 07:55:36 box kernel: usb-storage: *** thread awakened.
Nov 20 07:55:36 box kernel: usb-storage: Command READ_CAPACITY (10 bytes)
Nov 20 07:55:36 box kernel: usb-storage:  25 00 00 00 00 00 00 00 00 00
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=10
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 10/10
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 8 bytes
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 8/8
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: CB data stage result is 0x0
Nov 20 07:55:36 box kernel: usb-storage: -- CB transport device requiring auto-sense
Nov 20 07:55:36 box kernel: usb-storage: Issuing auto-REQUEST_SENSE
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 18/18
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: CB data stage result is 0x0
Nov 20 07:55:36 box kernel: usb-storage: -- Result from auto-sense is 0
Nov 20 07:55:36 box kernel: usb-storage: -- code: 0x70, key: 0x0, ASC: 0x0, ASCQ: 0x0
Nov 20 07:55:36 box kernel: usb-storage: No Sense: No additional sense information
Nov 20 07:55:36 box kernel: usb-storage: scsi cmd done, result=0x0
Nov 20 07:55:36 box kernel: usb-storage: *** thread sleeping.
Nov 20 07:55:36 box kernel: SCSI device sda: 7904 512-byte hdwr sectors (4 MB)
Nov 20 07:55:36 box kernel: usb-storage: queuecommand called
Nov 20 07:55:36 box kernel: usb-storage: *** thread awakened.
Nov 20 07:55:36 box kernel: usb-storage: Command MODE_SENSE (6 bytes)
Nov 20 07:55:36 box kernel: usb-storage:  1a 00 3f 00 04 00
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:55:36 box kernel: usb-storage: Status code -32; transferred 6/6
Nov 20 07:55:36 box kernel: usb-storage: -- stall on control pipe
Nov 20 07:55:36 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 2
Nov 20 07:55:36 box kernel: usb-storage: -- CB transport device requiring auto-sense
Nov 20 07:55:36 box kernel: usb-storage: -- transport indicates command failure
Nov 20 07:55:36 box kernel: usb-storage: Issuing auto-REQUEST_SENSE
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 18/18
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: CB data stage result is 0x0
Nov 20 07:55:36 box kernel: usb-storage: -- Result from auto-sense is 0
Nov 20 07:55:36 box kernel: usb-storage: -- code: 0x70, key: 0x5, ASC: 0x24, ASCQ: 0x0
Nov 20 07:55:36 box kernel: usb-storage: Illegal Request: Invalid field in cdb
Nov 20 07:55:36 box kernel: usb-storage: scsi cmd done, result=0x2
Nov 20 07:55:36 box kernel: usb-storage: *** thread sleeping.
Nov 20 07:55:36 box kernel: usb-storage: queuecommand called
Nov 20 07:55:36 box kernel: usb-storage: *** thread awakened.
Nov 20 07:55:36 box kernel: usb-storage: Command MODE_SENSE (6 bytes)
Nov 20 07:55:36 box kernel: usb-storage:  1a 00 00 00 04 00
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:55:36 box kernel: usb-storage: Status code -32; transferred 6/6
Nov 20 07:55:36 box kernel: usb-storage: -- stall on control pipe
Nov 20 07:55:36 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 2
Nov 20 07:55:36 box kernel: usb-storage: -- CB transport device requiring auto-sense
Nov 20 07:55:36 box kernel: usb-storage: -- transport indicates command failure
Nov 20 07:55:36 box kernel: usb-storage: Issuing auto-REQUEST_SENSE
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 18/18
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: CB data stage result is 0x0
Nov 20 07:55:36 box kernel: usb-storage: -- Result from auto-sense is 0
Nov 20 07:55:36 box kernel: usb-storage: -- code: 0x70, key: 0x5, ASC: 0x24, ASCQ: 0x0
Nov 20 07:55:36 box kernel: usb-storage: Illegal Request: Invalid field in cdb
Nov 20 07:55:36 box kernel: usb-storage: scsi cmd done, result=0x2
Nov 20 07:55:36 box kernel: usb-storage: *** thread sleeping.
Nov 20 07:55:36 box kernel: usb-storage: queuecommand called
Nov 20 07:55:36 box kernel: usb-storage: *** thread awakened.
Nov 20 07:55:36 box kernel: usb-storage: Command MODE_SENSE (6 bytes)
Nov 20 07:55:36 box kernel: usb-storage:  1a 00 3f 00 ff 00
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:55:36 box kernel: usb-storage: Status code -32; transferred 6/6
Nov 20 07:55:36 box kernel: usb-storage: -- stall on control pipe
Nov 20 07:55:36 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 2
Nov 20 07:55:36 box kernel: usb-storage: -- CB transport device requiring auto-sense
Nov 20 07:55:36 box kernel: usb-storage: -- transport indicates command failure
Nov 20 07:55:36 box kernel: usb-storage: Issuing auto-REQUEST_SENSE
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 18/18
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: CB data stage result is 0x0
Nov 20 07:55:36 box kernel: usb-storage: -- Result from auto-sense is 0
Nov 20 07:55:36 box kernel: usb-storage: -- code: 0x70, key: 0x5, ASC: 0x24, ASCQ: 0x0
Nov 20 07:55:36 box kernel: usb-storage: Illegal Request: Invalid field in cdb
Nov 20 07:55:36 box kernel: usb-storage: scsi cmd done, result=0x2
Nov 20 07:55:36 box kernel: usb-storage: *** thread sleeping.
Nov 20 07:55:36 box kernel: sda: test WP failed, assume Write Enabled
Nov 20 07:55:36 box kernel: usb-storage: queuecommand called
Nov 20 07:55:36 box kernel: usb-storage: *** thread awakened.
Nov 20 07:55:36 box kernel: usb-storage: Command MODE_SENSE (6 bytes)
Nov 20 07:55:36 box kernel: usb-storage:  1a 00 08 00 04 00
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:55:36 box kernel: usb-storage: Status code -32; transferred 6/6
Nov 20 07:55:36 box kernel: usb-storage: -- stall on control pipe
Nov 20 07:55:36 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 2
Nov 20 07:55:36 box kernel: usb-storage: -- CB transport device requiring auto-sense
Nov 20 07:55:36 box kernel: usb-storage: -- transport indicates command failure
Nov 20 07:55:36 box kernel: usb-storage: Issuing auto-REQUEST_SENSE
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 18/18
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: CB data stage result is 0x0
Nov 20 07:55:36 box kernel: usb-storage: -- Result from auto-sense is 0
Nov 20 07:55:36 box kernel: usb-storage: -- code: 0x70, key: 0x5, ASC: 0x24, ASCQ: 0x0
Nov 20 07:55:36 box kernel: usb-storage: Illegal Request: Invalid field in cdb
Nov 20 07:55:36 box kernel: usb-storage: scsi cmd done, result=0x2
Nov 20 07:55:36 box kernel: usb-storage: *** thread sleeping.
Nov 20 07:55:36 box kernel: sda: cache data unavailable
Nov 20 07:55:36 box kernel: sda: assuming drive cache: write through
Nov 20 07:55:36 box kernel: usb-storage: queuecommand called
Nov 20 07:55:36 box kernel: usb-storage: *** thread awakened.
Nov 20 07:55:36 box kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
Nov 20 07:55:36 box kernel: usb-storage:  00 00 00 00 00 00
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 07:55:36 box kernel: usb-storage: -- CB transport device requiring auto-sense
Nov 20 07:55:36 box kernel: usb-storage: Issuing auto-REQUEST_SENSE
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 18/18
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: CB data stage result is 0x0
Nov 20 07:55:36 box kernel: usb-storage: -- Result from auto-sense is 0
Nov 20 07:55:36 box kernel: usb-storage: -- code: 0x70, key: 0x0, ASC: 0x0, ASCQ: 0x0
Nov 20 07:55:36 box kernel: usb-storage: No Sense: No additional sense information
Nov 20 07:55:36 box kernel: usb-storage: scsi cmd done, result=0x0
Nov 20 07:55:36 box kernel: usb-storage: *** thread sleeping.
Nov 20 07:55:36 box kernel: usb-storage: queuecommand called
Nov 20 07:55:36 box kernel: usb-storage: *** thread awakened.
Nov 20 07:55:36 box kernel: usb-storage: Command ALLOW_MEDIUM_REMOVAL (6 bytes)
Nov 20 07:55:36 box kernel: usb-storage:  1e 00 00 00 01 00
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:55:36 box kernel: usb-storage: Status code -32; transferred 6/6
Nov 20 07:55:36 box kernel: usb-storage: -- stall on control pipe
Nov 20 07:55:36 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 2
Nov 20 07:55:36 box kernel: usb-storage: -- CB transport device requiring auto-sense
Nov 20 07:55:36 box kernel: usb-storage: -- transport indicates command failure
Nov 20 07:55:36 box kernel: usb-storage: Issuing auto-REQUEST_SENSE
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 18/18
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: CB data stage result is 0x0
Nov 20 07:55:36 box kernel: usb-storage: -- Result from auto-sense is 0
Nov 20 07:55:36 box kernel: usb-storage: -- code: 0x70, key: 0x5, ASC: 0x20, ASCQ: 0x0
Nov 20 07:55:36 box kernel: usb-storage: Illegal Request: Invalid command operation code
Nov 20 07:55:36 box kernel: usb-storage: scsi cmd done, result=0x2
Nov 20 07:55:36 box kernel: usb-storage: *** thread sleeping.
Nov 20 07:55:36 box kernel:  sda:<7>usb-storage: queuecommand called
Nov 20 07:55:36 box kernel: usb-storage: *** thread awakened.
Nov 20 07:55:36 box kernel: usb-storage: Command READ_10 (10 bytes)
Nov 20 07:55:36 box kernel: usb-storage:  28 00 00 00 00 00 00 00 08 00
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=10
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 10/10
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_bulk_transfer_sglist: xfer 4096 bytes, 1 entries
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 4096/4096
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: CB data stage result is 0x0
Nov 20 07:55:36 box kernel: usb-storage: -- CB transport device requiring auto-sense
Nov 20 07:55:36 box kernel: usb-storage: Issuing auto-REQUEST_SENSE
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 18/18
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: CB data stage result is 0x0
Nov 20 07:55:36 box kernel: usb-storage: -- Result from auto-sense is 0
Nov 20 07:55:36 box kernel: usb-storage: -- code: 0x70, key: 0x0, ASC: 0x0, ASCQ: 0x0
Nov 20 07:55:36 box kernel: usb-storage: No Sense: No additional sense information
Nov 20 07:55:36 box kernel: usb-storage: scsi cmd done, result=0x0
Nov 20 07:55:36 box kernel: usb-storage: *** thread sleeping.
Nov 20 07:55:36 box kernel:  sda1
Nov 20 07:55:36 box kernel: Attached scsi removable disk sda at scsi1, channel 0, id 0, lun 0
Nov 20 07:55:36 box kernel: usb-storage: queuecommand called
Nov 20 07:55:36 box kernel: usb-storage: *** thread awakened.
Nov 20 07:55:36 box kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
Nov 20 07:55:36 box kernel: usb-storage:  00 00 00 00 00 00
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 07:55:36 box kernel: usb-storage: -- CB transport device requiring auto-sense
Nov 20 07:55:36 box kernel: usb-storage: Issuing auto-REQUEST_SENSE
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 18/18
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: CB data stage result is 0x0
Nov 20 07:55:36 box kernel: usb-storage: -- Result from auto-sense is 0
Nov 20 07:55:36 box kernel: usb-storage: -- code: 0x70, key: 0x0, ASC: 0x0, ASCQ: 0x0
Nov 20 07:55:36 box kernel: usb-storage: No Sense: No additional sense information
Nov 20 07:55:36 box kernel: usb-storage: scsi cmd done, result=0x0
Nov 20 07:55:36 box kernel: usb-storage: *** thread sleeping.
Nov 20 07:55:36 box kernel: usb-storage: queuecommand called
Nov 20 07:55:36 box kernel: usb-storage: *** thread awakened.
Nov 20 07:55:36 box kernel: usb-storage: Command MODE_SENSE (6 bytes)
Nov 20 07:55:36 box kernel: usb-storage:  1a 00 1c 00 c0 00
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:55:36 box kernel: usb-storage: Status code -32; transferred 6/6
Nov 20 07:55:36 box kernel: usb-storage: -- stall on control pipe
Nov 20 07:55:36 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 2
Nov 20 07:55:36 box kernel: usb-storage: -- CB transport device requiring auto-sense
Nov 20 07:55:36 box kernel: usb-storage: -- transport indicates command failure
Nov 20 07:55:36 box kernel: usb-storage: Issuing auto-REQUEST_SENSE
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 07:55:36 box kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Nov 20 07:55:36 box kernel: usb-storage: Status code 0; transferred 18/18
Nov 20 07:55:36 box kernel: usb-storage: -- transfer complete
Nov 20 07:55:36 box kernel: usb-storage: CB data stage result is 0x0
Nov 20 07:55:36 box kernel: usb-storage: -- Result from auto-sense is 0
Nov 20 07:55:36 box kernel: usb-storage: -- code: 0x70, key: 0x5, ASC: 0x24, ASCQ: 0x0
Nov 20 07:55:36 box kernel: usb-storage: Illegal Request: Invalid field in cdb
Nov 20 07:55:36 box kernel: usb-storage: scsi cmd done, result=0x2
Nov 20 07:55:36 box kernel: usb-storage: *** thread sleeping.

// x 5 24 sense // xC0 (192) residue
// -x0102 = -258 = plscsi,main exit int

  ./plscsi -i xC0 -x "1A 00:3F:00 C0 00"

Nov 20 07:58:09 box kernel: usb-storage: queuecommand called
Nov 20 07:58:09 box kernel: usb-storage: *** thread awakened.
Nov 20 07:58:09 box kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
Nov 20 07:58:09 box kernel: usb-storage:  00 00 00 00 00 00
Nov 20 07:58:09 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:58:09 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 07:58:09 box kernel: usb-storage: -- transfer complete
Nov 20 07:58:09 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 07:58:09 box kernel: usb-storage: -- CB transport device requiring auto-sense
Nov 20 07:58:09 box kernel: usb-storage: Issuing auto-REQUEST_SENSE
Nov 20 07:58:09 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:58:09 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 07:58:09 box kernel: usb-storage: -- transfer complete
Nov 20 07:58:09 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 07:58:09 box kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Nov 20 07:58:09 box kernel: usb-storage: Status code 0; transferred 18/18
Nov 20 07:58:09 box kernel: usb-storage: -- transfer complete
Nov 20 07:58:09 box kernel: usb-storage: CB data stage result is 0x0
Nov 20 07:58:09 box kernel: usb-storage: -- Result from auto-sense is 0
Nov 20 07:58:09 box kernel: usb-storage: -- code: 0x70, key: 0x0, ASC: 0x0, ASCQ: 0x0
Nov 20 07:58:09 box kernel: usb-storage: No Sense: No additional sense information
Nov 20 07:58:09 box kernel: usb-storage: scsi cmd done, result=0x0
Nov 20 07:58:09 box kernel: usb-storage: *** thread sleeping.
Nov 20 07:58:09 box kernel: usb-storage: queuecommand called
Nov 20 07:58:09 box kernel: usb-storage: *** thread awakened.
Nov 20 07:58:09 box kernel: usb-storage: Command MODE_SENSE (6 bytes)
Nov 20 07:58:09 box kernel: usb-storage:  1a 00 3f 00 c0 00
Nov 20 07:58:09 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:58:09 box kernel: usb-storage: Status code -32; transferred 6/6
Nov 20 07:58:09 box kernel: usb-storage: -- stall on control pipe
Nov 20 07:58:09 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 2
Nov 20 07:58:09 box kernel: usb-storage: -- CB transport device requiring auto-sense
Nov 20 07:58:09 box kernel: usb-storage: -- transport indicates command failure
Nov 20 07:58:09 box kernel: usb-storage: Issuing auto-REQUEST_SENSE
Nov 20 07:58:09 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:58:09 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 07:58:09 box kernel: usb-storage: -- transfer complete
Nov 20 07:58:09 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 07:58:09 box kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Nov 20 07:58:09 box kernel: usb-storage: Status code 0; transferred 18/18
Nov 20 07:58:09 box kernel: usb-storage: -- transfer complete
Nov 20 07:58:09 box kernel: usb-storage: CB data stage result is 0x0
Nov 20 07:58:09 box kernel: usb-storage: -- Result from auto-sense is 0
Nov 20 07:58:09 box kernel: usb-storage: -- code: 0x70, key: 0x5, ASC: 0x24, ASCQ: 0x0
Nov 20 07:58:09 box kernel: usb-storage: Illegal Request: Invalid field in cdb
Nov 20 07:58:09 box kernel: usb-storage: scsi cmd done, result=0x2
Nov 20 07:58:09 box kernel: usb-storage: *** thread sleeping.

// x 5 24 sense // xC0 (192) residue
// -x0102 = -258 = plscsi,main exit int

  ./plscsi -i x0C -x "1A 00:00:00 0C 00"

Nov 20 07:59:27 box kernel: usb-storage: queuecommand called
Nov 20 07:59:27 box kernel: usb-storage: *** thread awakened.
Nov 20 07:59:27 box kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
Nov 20 07:59:27 box kernel: usb-storage:  00 00 00 00 00 00
Nov 20 07:59:27 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:59:27 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 07:59:27 box kernel: usb-storage: -- transfer complete
Nov 20 07:59:27 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 07:59:27 box kernel: usb-storage: -- CB transport device requiring auto-sense
Nov 20 07:59:27 box kernel: usb-storage: Issuing auto-REQUEST_SENSE
Nov 20 07:59:27 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:59:27 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 07:59:27 box kernel: usb-storage: -- transfer complete
Nov 20 07:59:27 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 07:59:27 box kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Nov 20 07:59:27 box kernel: usb-storage: Status code 0; transferred 18/18
Nov 20 07:59:27 box kernel: usb-storage: -- transfer complete
Nov 20 07:59:27 box kernel: usb-storage: CB data stage result is 0x0
Nov 20 07:59:27 box kernel: usb-storage: -- Result from auto-sense is 0
Nov 20 07:59:27 box kernel: usb-storage: -- code: 0x70, key: 0x0, ASC: 0x0, ASCQ: 0x0
Nov 20 07:59:27 box kernel: usb-storage: No Sense: No additional sense information
Nov 20 07:59:27 box kernel: usb-storage: scsi cmd done, result=0x0
Nov 20 07:59:27 box kernel: usb-storage: *** thread sleeping.
Nov 20 07:59:27 box kernel: usb-storage: queuecommand called
Nov 20 07:59:27 box kernel: usb-storage: *** thread awakened.
Nov 20 07:59:27 box kernel: usb-storage: Command MODE_SENSE (6 bytes)
Nov 20 07:59:27 box kernel: usb-storage:  1a 00 00 00 0c 00
Nov 20 07:59:27 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:59:27 box kernel: usb-storage: Status code -32; transferred 6/6
Nov 20 07:59:27 box kernel: usb-storage: -- stall on control pipe
Nov 20 07:59:27 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 2
Nov 20 07:59:27 box kernel: usb-storage: -- CB transport device requiring auto-sense
Nov 20 07:59:27 box kernel: usb-storage: -- transport indicates command failure
Nov 20 07:59:27 box kernel: usb-storage: Issuing auto-REQUEST_SENSE
Nov 20 07:59:27 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 07:59:27 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 07:59:27 box kernel: usb-storage: -- transfer complete
Nov 20 07:59:27 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 07:59:27 box kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Nov 20 07:59:27 box kernel: usb-storage: Status code 0; transferred 18/18
Nov 20 07:59:27 box kernel: usb-storage: -- transfer complete
Nov 20 07:59:27 box kernel: usb-storage: CB data stage result is 0x0
Nov 20 07:59:27 box kernel: usb-storage: -- Result from auto-sense is 0
Nov 20 07:59:27 box kernel: usb-storage: -- code: 0x70, key: 0x5, ASC: 0x24, ASCQ: 0x0
Nov 20 07:59:27 box kernel: usb-storage: Illegal Request: Invalid field in cdb
Nov 20 07:59:27 box kernel: usb-storage: scsi cmd done, result=0x2
Nov 20 07:59:27 box kernel: usb-storage: *** thread sleeping.

// x 5 24 sense // xC (12) residue
// -x0102 = -258 = plscsi,main exit int

  ./plscsi -i x0C -x "1A 00:3F:00 0C 00"

Nov 20 08:00:25 box kernel: usb-storage: queuecommand called
Nov 20 08:00:25 box kernel: usb-storage: *** thread awakened.
Nov 20 08:00:25 box kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
Nov 20 08:00:25 box kernel: usb-storage:  00 00 00 00 00 00
Nov 20 08:00:25 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 08:00:25 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 08:00:25 box kernel: usb-storage: -- transfer complete
Nov 20 08:00:25 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 08:00:25 box kernel: usb-storage: -- CB transport device requiring auto-sense
Nov 20 08:00:25 box kernel: usb-storage: Issuing auto-REQUEST_SENSE
Nov 20 08:00:25 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 08:00:25 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 08:00:25 box kernel: usb-storage: -- transfer complete
Nov 20 08:00:25 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 08:00:25 box kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Nov 20 08:00:25 box kernel: usb-storage: Status code 0; transferred 18/18
Nov 20 08:00:25 box kernel: usb-storage: -- transfer complete
Nov 20 08:00:25 box kernel: usb-storage: CB data stage result is 0x0
Nov 20 08:00:25 box kernel: usb-storage: -- Result from auto-sense is 0
Nov 20 08:00:25 box kernel: usb-storage: -- code: 0x70, key: 0x0, ASC: 0x0, ASCQ: 0x0
Nov 20 08:00:25 box kernel: usb-storage: No Sense: No additional sense information
Nov 20 08:00:25 box kernel: usb-storage: scsi cmd done, result=0x0
Nov 20 08:00:25 box kernel: usb-storage: *** thread sleeping.
Nov 20 08:00:25 box kernel: usb-storage: queuecommand called
Nov 20 08:00:25 box kernel: usb-storage: *** thread awakened.
Nov 20 08:00:25 box kernel: usb-storage: Command MODE_SENSE (6 bytes)
Nov 20 08:00:25 box kernel: usb-storage:  1a 00 3f 00 0c 00
Nov 20 08:00:25 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 08:00:25 box kernel: usb-storage: Status code -32; transferred 6/6
Nov 20 08:00:25 box kernel: usb-storage: -- stall on control pipe
Nov 20 08:00:25 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 2
Nov 20 08:00:25 box kernel: usb-storage: -- CB transport device requiring auto-sense
Nov 20 08:00:25 box kernel: usb-storage: -- transport indicates command failure
Nov 20 08:00:25 box kernel: usb-storage: Issuing auto-REQUEST_SENSE
Nov 20 08:00:25 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 08:00:25 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 08:00:25 box kernel: usb-storage: -- transfer complete
Nov 20 08:00:25 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 08:00:25 box kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Nov 20 08:00:25 box kernel: usb-storage: Status code 0; transferred 18/18
Nov 20 08:00:25 box kernel: usb-storage: -- transfer complete
Nov 20 08:00:25 box kernel: usb-storage: CB data stage result is 0x0
Nov 20 08:00:25 box kernel: usb-storage: -- Result from auto-sense is 0
Nov 20 08:00:25 box kernel: usb-storage: -- code: 0x70, key: 0x5, ASC: 0x24, ASCQ: 0x0
Nov 20 08:00:25 box kernel: usb-storage: Illegal Request: Invalid field in cdb
Nov 20 08:00:25 box kernel: usb-storage: scsi cmd done, result=0x2
Nov 20 08:00:25 box kernel: usb-storage: *** thread sleeping.

// x 5 24 sense // xC (12) residue
// -x0102 = -258 = plscsi,main exit int

  ./plscsi -p -i xC0 -x "5A 00 1C:00:00:00 00 00:C0 00 00:00"

Nov 20 08:03:08 box kernel: usb-storage: queuecommand called
Nov 20 08:03:08 box kernel: usb-storage: *** thread awakened.
Nov 20 08:03:08 box kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
Nov 20 08:03:08 box kernel: usb-storage:  00 00 00 00 00 00
Nov 20 08:03:08 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 08:03:08 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 08:03:08 box kernel: usb-storage: -- transfer complete
Nov 20 08:03:08 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 08:03:08 box kernel: usb-storage: -- CB transport device requiring auto-sense
Nov 20 08:03:08 box kernel: usb-storage: Issuing auto-REQUEST_SENSE
Nov 20 08:03:08 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=6
Nov 20 08:03:08 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 20 08:03:08 box kernel: usb-storage: -- transfer complete
Nov 20 08:03:08 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 08:03:08 box kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Nov 20 08:03:08 box kernel: usb-storage: Status code 0; transferred 18/18
Nov 20 08:03:08 box kernel: usb-storage: -- transfer complete
Nov 20 08:03:08 box kernel: usb-storage: CB data stage result is 0x0
Nov 20 08:03:08 box kernel: usb-storage: -- Result from auto-sense is 0
Nov 20 08:03:08 box kernel: usb-storage: -- code: 0x70, key: 0x0, ASC: 0x0, ASCQ: 0x0
Nov 20 08:03:08 box kernel: usb-storage: No Sense: No additional sense information
Nov 20 08:03:08 box kernel: usb-storage: scsi cmd done, result=0x0
Nov 20 08:03:08 box kernel: usb-storage: *** thread sleeping.
Nov 20 08:03:08 box kernel: usb-storage: queuecommand called
Nov 20 08:03:08 box kernel: usb-storage: *** thread awakened.
Nov 20 08:03:08 box kernel: usb-storage: Command MODE_SENSE_10 (10 bytes)
Nov 20 08:03:08 box kernel: usb-storage:  5a 00 1c 00 00 00 00 00 c0 00
Nov 20 08:03:08 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=10
Nov 20 08:03:08 box kernel: usb-storage: Status code 0; transferred 10/10
Nov 20 08:03:08 box kernel: usb-storage: -- transfer complete
Nov 20 08:03:08 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 20 08:03:08 box kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 192 bytes

<plscsi hangs at this point. kill -9 does not work. pulling thew plug now>

Nov 20 08:05:19 box kernel: usb-storage: Status code -71; transferred 0/192
Nov 20 08:05:19 box kernel: usb-storage: -- unknown error
Nov 20 08:05:19 box kernel: usb-storage: CB data stage result is 0x4
Nov 20 08:05:19 box kernel: usb-storage: -- transport indicates error, resetting
Nov 20 08:05:19 box kernel: usb-storage: usb_stor_CB_reset called
Nov 20 08:05:19 box kernel: usb-storage: usb_stor_control_msg: rq=00 rqtype=21 value=0000 index=00 len=12
Nov 20 08:05:19 box kernel: drivers/usb/host/uhci-hcd.c: uhci_result_control() failed with status 440000
Nov 20 08:05:19 box kernel: [e5f4b270] link (25f4b1e2) element (25aef540)
Nov 20 08:05:19 box kernel:   0: [e5aef540] link (25aef580) e0 Stalled CRC/Timeo Length=7 MaxLen=7 DT0 EndPt=0 Dev=4, PID=2d(SETUP) (buf=37c29020)
Nov 20 08:05:19 box kernel:   1: [e5aef580] link (25aefa00) e3 SPD Active Length=0 MaxLen=7 DT1 EndPt=0 Dev=4, PID=e1(OUT) (buf=2522b000)
Nov 20 08:05:19 box kernel:   2: [e5aefa00] link (25aefa40) e3 SPD Active Length=0 MaxLen=3 DT0 EndPt=0 Dev=4, PID=e1(OUT) (buf=2522b008)
Nov 20 08:05:19 box kernel:   3: [e5aefa40] link (00000001) e3 IOC Active Length=0 MaxLen=7ff DT1 EndPt=0 Dev=4, PID=69(IN) (buf=00000000)
Nov 20 08:05:19 box kernel: 
Nov 20 08:05:19 box kernel: usb-storage: Soft reset failed: -110
Nov 20 08:05:19 box kernel: usb-storage: scsi cmd done, result=0x70000
Nov 20 08:05:19 box kernel: usb-storage: *** thread sleeping.
Nov 20 08:05:19 box kernel: usb-storage: queuecommand called
Nov 20 08:05:19 box kernel: usb-storage: *** thread awakened.
Nov 20 08:05:19 box kernel: usb-storage: Command MODE_SENSE_10 (10 bytes)
Nov 20 08:05:19 box kernel: usb-storage:  5a 00 1c 00 00 00 00 00 c0 00
Nov 20 08:05:19 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=10
Nov 20 08:05:19 box kernel: drivers/usb/host/uhci-hcd.c: uhci_result_control() failed with status 440000
Nov 20 08:05:19 box kernel: [e5f4b240] link (25f4b1e2) element (25aef000)
Nov 20 08:05:19 box kernel:   0: [e5aef000] link (25aef140) e0 Stalled CRC/Timeo Length=7 MaxLen=7 DT0 EndPt=0 Dev=4, PID=2d(SETUP) (buf=37c29020)
Nov 20 08:05:19 box kernel:   1: [e5aef140] link (25aef180) e3 SPD Active Length=0 MaxLen=7 DT1 EndPt=0 Dev=4, PID=e1(OUT) (buf=26152224)
Nov 20 08:05:19 box kernel:   2: [e5aef180] link (25aefa80) e3 SPD Active Length=0 MaxLen=1 DT0 EndPt=0 Dev=4, PID=e1(OUT) (buf=2615222c)
Nov 20 08:05:19 box kernel:   3: [e5aefa80] link (00000001) e3 IOC Active Length=0 MaxLen=7ff DT1 EndPt=0 Dev=4, PID=69(IN) (buf=00000000)
Nov 20 08:05:19 box kernel: 
Nov 20 08:05:19 box kernel: usb-storage: Status code -110; transferred 0/10
Nov 20 08:05:19 box kernel: usb-storage: -- timeout or NAK
Nov 20 08:05:19 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 4
Nov 20 08:05:19 box kernel: usb-storage: -- transport indicates error, resetting
Nov 20 08:05:19 box kernel: usb-storage: usb_stor_CB_reset called
Nov 20 08:05:19 box kernel: usb-storage: usb_stor_control_msg: rq=00 rqtype=21 value=0000 index=00 len=12
Nov 20 08:05:19 box kernel: drivers/usb/host/uhci-hcd.c: uhci_result_control() failed with status 440000
Nov 20 08:05:19 box kernel: [e5f4b270] link (25f4b1e2) element (25aef540)
Nov 20 08:05:19 box kernel:   0: [e5aef540] link (25aef580) e0 Stalled CRC/Timeo Length=7 MaxLen=7 DT0 EndPt=0 Dev=4, PID=2d(SETUP) (buf=37c29020)
Nov 20 08:05:19 box kernel:   1: [e5aef580] link (25aefa00) e3 SPD Active Length=0 MaxLen=7 DT1 EndPt=0 Dev=4, PID=e1(OUT) (buf=2522b000)
Nov 20 08:05:19 box kernel:   2: [e5aefa00] link (25aefa40) e3 SPD Active Length=0 MaxLen=3 DT0 EndPt=0 Dev=4, PID=e1(OUT) (buf=2522b008)
Nov 20 08:05:19 box kernel:   3: [e5aefa40] link (00000001) e3 IOC Active Length=0 MaxLen=7ff DT1 EndPt=0 Dev=4, PID=69(IN) (buf=00000000)
Nov 20 08:05:19 box kernel: 
Nov 20 08:05:19 box kernel: usb-storage: Soft reset failed: -110
Nov 20 08:05:19 box kernel: usb-storage: scsi cmd done, result=0x70000
Nov 20 08:05:19 box kernel: usb-storage: *** thread sleeping.
Nov 20 08:05:19 box kernel: usb-storage: queuecommand called
Nov 20 08:05:19 box kernel: usb-storage: *** thread awakened.
Nov 20 08:05:19 box kernel: usb-storage: Command MODE_SENSE_10 (10 bytes)
Nov 20 08:05:19 box kernel: usb-storage:  5a 00 1c 00 00 00 00 00 c0 00
Nov 20 08:05:19 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=10
Nov 20 08:05:19 box kernel: drivers/usb/host/uhci-hcd.c: uhci_result_control() failed with status 440000
Nov 20 08:05:19 box kernel: [e5f4b240] link (25f4b1e2) element (25aef000)
Nov 20 08:05:19 box kernel:   0: [e5aef000] link (25aef140) e0 Stalled CRC/Timeo Length=7 MaxLen=7 DT0 EndPt=0 Dev=4, PID=2d(SETUP) (buf=37c29020)
Nov 20 08:05:19 box kernel:   1: [e5aef140] link (25aef180) e3 SPD Active Length=0 MaxLen=7 DT1 EndPt=0 Dev=4, PID=e1(OUT) (buf=26152224)
Nov 20 08:05:19 box kernel:   2: [e5aef180] link (25aefa80) e3 SPD Active Length=0 MaxLen=1 DT0 EndPt=0 Dev=4, PID=e1(OUT) (buf=2615222c)
Nov 20 08:05:19 box kernel:   3: [e5aefa80] link (00000001) e3 IOC Active Length=0 MaxLen=7ff DT1 EndPt=0 Dev=4, PID=69(IN) (buf=00000000)
Nov 20 08:05:19 box kernel: 
Nov 20 08:05:19 box kernel: usb-storage: Status code -110; transferred 0/10
Nov 20 08:05:19 box kernel: usb-storage: -- timeout or NAK
Nov 20 08:05:19 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 4
Nov 20 08:05:19 box kernel: usb-storage: -- transport indicates error, resetting
Nov 20 08:05:19 box kernel: usb-storage: usb_stor_CB_reset called
Nov 20 08:05:19 box kernel: usb-storage: usb_stor_control_msg: rq=00 rqtype=21 value=0000 index=00 len=12
Nov 20 08:05:19 box kernel: drivers/usb/host/uhci-hcd.c: uhci_result_control() failed with status 440000
Nov 20 08:05:19 box kernel: [e5f4b270] link (25f4b1e2) element (25aef540)
Nov 20 08:05:19 box kernel:   0: [e5aef540] link (25aef580) e0 Stalled CRC/Timeo Length=7 MaxLen=7 DT0 EndPt=0 Dev=4, PID=2d(SETUP) (buf=37c29020)
Nov 20 08:05:19 box kernel:   1: [e5aef580] link (25aefa00) e3 SPD Active Length=0 MaxLen=7 DT1 EndPt=0 Dev=4, PID=e1(OUT) (buf=2522b000)
Nov 20 08:05:19 box kernel:   2: [e5aefa00] link (25aefa40) e3 SPD Active Length=0 MaxLen=3 DT0 EndPt=0 Dev=4, PID=e1(OUT) (buf=2522b008)
Nov 20 08:05:19 box kernel:   3: [e5aefa40] link (00000001) e3 IOC Active Length=0 MaxLen=7ff DT1 EndPt=0 Dev=4, PID=69(IN) (buf=00000000)
Nov 20 08:05:19 box kernel: 
Nov 20 08:05:19 box kernel: usb-storage: Soft reset failed: -110
Nov 20 08:05:19 box kernel: usb-storage: scsi cmd done, result=0x70000
Nov 20 08:05:19 box kernel: usb-storage: *** thread sleeping.
Nov 20 08:05:19 box kernel: usb-storage: queuecommand called
Nov 20 08:05:19 box kernel: usb-storage: *** thread awakened.
Nov 20 08:05:19 box kernel: usb-storage: Command MODE_SENSE_10 (10 bytes)
Nov 20 08:05:19 box kernel: usb-storage:  5a 00 1c 00 00 00 00 00 c0 00
Nov 20 08:05:19 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=10
Nov 20 08:05:19 box kernel: drivers/usb/host/uhci-hcd.c: uhci_result_control() failed with status 440000
Nov 20 08:05:19 box kernel: [e5f4b240] link (25f4b1e2) element (25aef000)
Nov 20 08:05:19 box kernel:   0: [e5aef000] link (25aef140) e0 Stalled CRC/Timeo Length=7 MaxLen=7 DT0 EndPt=0 Dev=4, PID=2d(SETUP) (buf=37c29020)
Nov 20 08:05:19 box kernel:   1: [e5aef140] link (25aef180) e3 SPD Active Length=0 MaxLen=7 DT1 EndPt=0 Dev=4, PID=e1(OUT) (buf=26152224)
Nov 20 08:05:19 box kernel:   2: [e5aef180] link (25aefa80) e3 SPD Active Length=0 MaxLen=1 DT0 EndPt=0 Dev=4, PID=e1(OUT) (buf=2615222c)
Nov 20 08:05:19 box kernel:   3: [e5aefa80] link (00000001) e3 IOC Active Length=0 MaxLen=7ff DT1 EndPt=0 Dev=4, PID=69(IN) (buf=00000000)
Nov 20 08:05:19 box kernel: 
Nov 20 08:05:19 box kernel: usb-storage: Status code -110; transferred 0/10
Nov 20 08:05:19 box kernel: usb-storage: -- timeout or NAK
Nov 20 08:05:19 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 4
Nov 20 08:05:19 box kernel: usb-storage: -- transport indicates error, resetting
Nov 20 08:05:19 box kernel: usb-storage: usb_stor_CB_reset called
Nov 20 08:05:19 box kernel: usb-storage: usb_stor_control_msg: rq=00 rqtype=21 value=0000 index=00 len=12
Nov 20 08:05:19 box kernel: drivers/usb/host/uhci-hcd.c: uhci_result_control() failed with status 440000
Nov 20 08:05:19 box kernel: [e5f4b270] link (25f4b1e2) element (25aef540)
Nov 20 08:05:19 box kernel:   0: [e5aef540] link (25aef580) e0 Stalled CRC/Timeo Length=7 MaxLen=7 DT0 EndPt=0 Dev=4, PID=2d(SETUP) (buf=37c29020)
Nov 20 08:05:19 box kernel:   1: [e5aef580] link (25aefa00) e3 SPD Active Length=0 MaxLen=7 DT1 EndPt=0 Dev=4, PID=e1(OUT) (buf=2522b000)
Nov 20 08:05:19 box kernel:   2: [e5aefa00] link (25aefa40) e3 SPD Active Length=0 MaxLen=3 DT0 EndPt=0 Dev=4, PID=e1(OUT) (buf=2522b008)
Nov 20 08:05:19 box kernel:   3: [e5aefa40] link (00000001) e3 IOC Active Length=0 MaxLen=7ff DT1 EndPt=0 Dev=4, PID=69(IN) (buf=00000000)
Nov 20 08:05:19 box kernel: 
Nov 20 08:05:19 box kernel: usb-storage: Soft reset failed: -110
Nov 20 08:05:19 box kernel: usb-storage: scsi cmd done, result=0x70000
Nov 20 08:05:19 box kernel: usb-storage: *** thread sleeping.
Nov 20 08:05:19 box kernel: usb-storage: queuecommand called
Nov 20 08:05:19 box kernel: usb-storage: *** thread awakened.
Nov 20 08:05:19 box kernel: usb-storage: Command MODE_SENSE_10 (10 bytes)
Nov 20 08:05:19 box kernel: usb-storage:  5a 00 1c 00 00 00 00 00 c0 00
Nov 20 08:05:19 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21 value=0000 index=00 len=10
Nov 20 08:05:19 box kernel: drivers/usb/host/uhci-hcd.c: uhci_result_control() failed with status 440000
Nov 20 08:05:19 box kernel: [e5f4b240] link (25f4b1e2) element (25aef000)
Nov 20 08:05:19 box kernel:   0: [e5aef000] link (25aef140) e0 Stalled CRC/Timeo Length=7 MaxLen=7 DT0 EndPt=0 Dev=4, PID=2d(SETUP) (buf=37c29020)
Nov 20 08:05:19 box kernel:   1: [e5aef140] link (25aef180) e3 SPD Active Length=0 MaxLen=7 DT1 EndPt=0 Dev=4, PID=e1(OUT) (buf=26152224)
Nov 20 08:05:19 box kernel:   2: [e5aef180] link (25aefa80) e3 SPD Active Length=0 MaxLen=1 DT0 EndPt=0 Dev=4, PID=e1(OUT) (buf=2615222c)
Nov 20 08:05:19 box kernel:   3: [e5aefa80] link (00000001) e3 IOC Active Length=0 MaxLen=7ff DT1 EndPt=0 Dev=4, PID=69(IN) (buf=00000000)
Nov 20 08:05:19 box kernel: 
Nov 20 08:05:19 box kernel: usb-storage: Status code -110; transferred 0/10
Nov 20 08:05:19 box kernel: usb-storage: -- timeout or NAK
Nov 20 08:05:19 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 4
Nov 20 08:05:19 box kernel: usb-storage: -- transport indicates error, resetting
Nov 20 08:05:19 box kernel: usb-storage: usb_stor_CB_reset called
Nov 20 08:05:19 box kernel: usb-storage: usb_stor_control_msg: rq=00 rqtype=21 value=0000 index=00 len=12
Nov 20 08:05:19 box kernel: drivers/usb/host/uhci-hcd.c: uhci_result_control() failed with status 440000
Nov 20 08:05:19 box kernel: [e5f4b270] link (25f4b1e2) element (25aef540)
Nov 20 08:05:19 box kernel:   0: [e5aef540] link (25aef580) e0 Stalled CRC/Timeo Length=7 MaxLen=7 DT0 EndPt=0 Dev=4, PID=2d(SETUP) (buf=37c29020)
Nov 20 08:05:19 box kernel:   1: [e5aef580] link (25aefa00) e3 SPD Active Length=0 MaxLen=7 DT1 EndPt=0 Dev=4, PID=e1(OUT) (buf=2522b000)
Nov 20 08:05:19 box kernel:   2: [e5aefa00] link (25aefa40) e3 SPD Active Length=0 MaxLen=3 DT0 EndPt=0 Dev=4, PID=e1(OUT) (buf=2522b008)
Nov 20 08:05:19 box kernel:   3: [e5aefa40] link (00000001) e3 IOC Active Length=0 MaxLen=7ff DT1 EndPt=0 Dev=4, PID=69(IN) (buf=00000000)
Nov 20 08:05:19 box kernel: 
Nov 20 08:05:19 box kernel: usb-storage: Soft reset failed: -110
Nov 20 08:05:19 box kernel: usb-storage: scsi cmd done, result=0x70000
Nov 20 08:05:19 box kernel: usb-storage: *** thread sleeping.
Nov 20 08:05:19 box kernel: hub 2-0:1.0: port 2, status 100, change 3, 12 Mb/s
Nov 20 08:05:19 box kernel: usb 2-2: USB disconnect, address 4
Nov 20 08:05:19 box kernel: usb 2-2: usb_disable_device nuking all URBs
Nov 20 08:05:19 box kernel: usb 2-2: unregistering interface 2-2:1.0
Nov 20 08:05:19 box kernel: usb-storage: storage_disconnect() called
Nov 20 08:05:19 box kernel: usb-storage: usb_stor_stop_transport called
Nov 20 08:05:19 box kernel: usb-storage: -- dissociate_dev
Nov 20 08:05:19 box kernel: usb-storage: -- sending exit command to thread
Nov 20 08:05:20 box kernel: usb-storage: *** thread awakened.
Nov 20 08:05:20 box kernel: usb-storage: -- exit command received
Nov 20 08:05:20 box kernel: usb-storage: -- usb_stor_release_resources finished
Nov 20 08:05:20 box kernel: drivers/usb/core/usb.c: usb_hotplug
Nov 20 08:05:20 box kernel: usb 2-2: unregistering device
Nov 20 08:05:20 box kernel: drivers/usb/core/usb.c: usb_hotplug
Nov 20 08:05:20 box kernel: ehci_hcd 0000:00:1d.7: GetStatus port 3 status 003002 POWER OWNER sig=se0  CSC
Nov 20 08:05:20 box kernel: hub 5-0:1.0: port 3, status 0, change 1, 12 Mb/s
Nov 20 08:05:20 box kernel: ehci_hcd 0000:00:1d.7: GetStatus port 4 status 001002 POWER sig=se0  CSC
Nov 20 08:05:20 box kernel: hub 5-0:1.0: port 4, status 100, change 1, 12 Mb/s
Nov 20 08:05:20 box kernel: hub 2-0:1.0: port 2 enable change, status 100

// 192 = xC0 = plscsi.main exit int

< similar results with other MODE SENSE (10) commands >

Re: [usb-storage] mode sense blacklist how

[Pat LaVarre]

I'm writing this e-mail only to say:


I'm hereafter trimming this cc line.


Also here now I'm correctly substituting @us.ibm.com for @us.ibm.co

Next I will reply substantively, but only to: Dmitri Katchalov, cc:
linux-scsi.

Why trim the cc line?

Well, a complicating factor is that some of us post in ways that Google
does not archive & index.

And another complicating factor is that some of us sometimes don't
clearly receive attachments and email addresses mixed with names e.g. I
confused ibm.com with ibm.co and I didn't notice that last kern.log.usb
attachment from Dmitri here til I forwarded this message to myself.

But apart from all that, we have the recent history:

> Subject: Re: [usb-storage] mode sense blacklist how
>
> > > From: Pat LaVarre ...
> > > ...
> > > I think I'm seeing hints that possibly
> > > we've carried this reply-to-all convention
> > > a little too far by now.  Not sure how to
> > > fix that.
> >
> > From: Patrick Mansfield ...
> > ...
> > I have seen worse cc: lines. They can always
> > kill the thread or asked to be removed.
>
> From: Dmitri Katchalov ...
> ...
> I understand that you guys must be sick and
> tired of those memory sticks by now ...

Yes, thank you for continuing our investigation, yes I still do want to
learn more here.

> Subject: Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer
> From: Patrick Mansfield ...
> [Trimmed the cc line]

I see sometimes indeed we do trim cc lines.

Personally I'm too much of a newbie to have a clue when we do and when
we do not.

Pat LaVarre

Re: [usb-storage] mode sense blacklist how

[Pat LaVarre]

Apologies in advance for each reboot these experiments force on you.

>  MODE SENSE (10): plscsi hangs and sits there in 
>  usb_stor_bulk_transfer_buf until the device is 
>  physically unplugged. kill -9 has no effect.

Yes why `kill -9` has no effect on SG_IO in progress remains an open
question here at linux-scsi.

Meanwhile people have suggested the plscsi workaround: -X time 5 0. 
Does that work for you?  That option overrides a default something like
-X time 100800 0.  You can include that option in your `export PLSCSI`
setup, if you like.

For device folk working to explain why the device hangs, how to suppress
automagic resets despite short timeouts also remains an open question
here at linux-scsi.

> kill -9 has no effect.

Have you tried `modprobe -r usb-storage`?

>  MODE SENSE (10): plscsi hangs and sits there

I see in the log you say what plscsi line you tried:

./plscsi -p -i xC0 -x "5A 00 1C:00:00:00 00 00:C0 00 00:00"

Adding -v might tell us more.

In the log I see this command repeated, time and again.  Did you ask for
this command repeatedly yourself, or is it the code of SG_IO and below
that is so helpfully retrying?

>  Another interesting "feature": the camera does not work 
>  as a USB device without memory stick in its slot. That is 
>  if I plug it in without the stick nothing happens. When I 
>  then insert the stick it goes through the normal port 
>  status change/discovery/enumeration routine. When I
>  remove the stick from its slot the device pretends it 
>  has been disconnected.

Aye, USB storage varies here.  In byte 1 mask x80 of the op x12 Inquiry
data the device has to say if the disk can be removed without removing
the drive.  A device that clears that bit to say the disk and drive do
plug and unplug together has to virtually unplug USB when you
mechanically remove the disk.  Other devices may virtually unplug USB
when you mechanically remove the disk.

> Short version:
>  MODE SENSE (6): ...

Can you easily share the tty log of plscsi -v?  I ask because for me the
extra detail of a standard kernel log helps explain the plscsi tty log
without easily yielding an equally concise summary.

> Short version:
>  MODE SENSE (6): device reports STALL condition.

Stall is normal in mass storage, because provoking failure and
tolerating partial success is normal in mass storage.

Here the device design choice of bInterfaceProtocol = x01 = CB =
"Transport: Control/Bulk" makes control stall normal, rather than the
bulk stall of generic usb mass storage (bInterfaceProtocol = x50 =
*"Pat").

>  Subsequent
>  auto-REQUEST SENSE reports "Illegal Request in CDB".
>  As far as I undertand the device tries to tell us that the
>  command is not supported.

SCSI as defined by t10.org makes a subtle distinction.

Here we see "auto-sense" "code: 0x70, key: 0x5, ASC: 0x24, ASCQ: 0x0".

In the t10.org English, x 5 24 means cdb[0] opcode understood, but whole
cdb not understood.  x 5 20 means cdb[0] opcode not understood.

This result suggests, without guaranteeing, that the vendor-specific
bInterfaceSubClass = xFF SCSI of this device includes some cdb's that
begin with op x1A Mode Sense (6).

> here is my report ... Long version ... attached ...

Yes to interpret the English report and plscsi tty logs confidently, I
need the kernel log, thank you.

> in case you're still interested

Yes!

Pat LaVarre

Re: [usb-storage] mode sense blacklist how

[Douglas Gilbert]

Pat LaVarre wrote:
> Apologies in advance for each reboot these experiments force on you.
> 
> 
>> MODE SENSE (10): plscsi hangs and sits there in 
>> usb_stor_bulk_transfer_buf until the device is 
>> physically unplugged. kill -9 has no effect.
> 
> 
> Yes why `kill -9` has no effect on SG_IO in progress remains an open
> question here at linux-scsi.

The SG_IO ioctl is implemented in 2 places (in lk 2.6):
    a) block/scsi_ioctl.c [for block devices]
    b) sg.c [for sg devices]

In case b) the SG_IO ioctl is interruptible between the point
of command submission and the response arriving. [When testing
with lk 2.4 I found there were out-of-resource situations which
would block interminably prior to command submission, but I
doubt this is what you are seeing.] It is worth noting that
coping with orphaned SCSI responses from user killed processes
requires a lot of logic in the sg driver.

I suspect in case a) the user cannot interrupt the sg_io()'s
invocation of blk_do_rq(). Perhaps someone could enlighten me
(and I could document it).

Further it looks like the SCSI_IOCTL_SEND_COMMAND is not
interruptible either. See scsi_wait_req() in scsi_lib.c .

Doug Gilbert

Re: [usb-storage] mode sense blacklist how

[Pat LaVarre]

> > > The only really important question IMHO is
> > > how come SG_IO is not interruptible.
> >
> > Yes, now being pursued by Doug G in this thread.
>
> block/scsi_ioctl.c...
> I suspect ... cannot interrupt the sg_io... blk_do_rq...
> Perhaps someone could enlighten me (and I could document it).
>
> Further it looks like the SCSI_IOCTL_SEND_COMMAND is not
> interruptible either. See scsi_wait_req() in scsi_lib.c .

Open question I see.

> Apologies in advance for each reboot these experiments force on you.
> ...
> sg.c .... coping with orphaned SCSI responses from user killed
> processes requires a lot of logic ...

Ouch.

Designing an lk 2.6 user app to recommend more prominent devie names
like /dev/hdd and /dev/scd0 in place of less prominent /dev/sg$n names
thereby steers people into using the less robust pass thru of SG_IO via
block/scsi_ioctl.c.

> I suspect ... cannot interrupt ...

Sorry I'm too much of a kernelnewbie to guess confidently the full
implications of "not interruptible".  Does "not interruptible" mean
timeouts don't work, or does "not interruptible" mean that only timeouts
work, or does "not interruptible" mean that only timeouts and resets but
not SIGINT of the calling process works ...

I will return here with answers if I find them faster than people here
give them to me.

Pat LaVarre

P.S. Another open netiquette question is when we rename this thread.

SG_IO ioctl (was: mode sense blacklist how)

[Douglas Gilbert]

Pat LaVarre wrote:
>>>>The only really important question IMHO is
>>>>how come SG_IO is not interruptible.
>>>
>>>Yes, now being pursued by Doug G in this thread.
>>
>>block/scsi_ioctl.c...
>>I suspect ... cannot interrupt the sg_io... blk_do_rq...
>>Perhaps someone could enlighten me (and I could document it).
>>
>>Further it looks like the SCSI_IOCTL_SEND_COMMAND is not
>>interruptible either. See scsi_wait_req() in scsi_lib.c .
> 
> 
> Open question I see.
> 
> 
>>Apologies in advance for each reboot these experiments force on you.
>>...
>>sg.c .... coping with orphaned SCSI responses from user killed
>>processes requires a lot of logic ...
> 
> 
> Ouch.
> 
> Designing an lk 2.6 user app to recommend more prominent devie names
> like /dev/hdd and /dev/scd0 in place of less prominent /dev/sg$n names
> thereby steers people into using the less robust pass thru of SG_IO via
> block/scsi_ioctl.c.

Pat,
Well it's a trade-off. If you use the SG_IO in
the block layer then:

Pros:
   - convenience (for block devices)
   - no device mapping problems (sd <-> sg) **

Cons:
   - no help for "non-block" devices: tapes, enclosures,
     OSD, etc
   - inherit block layer policy (e.g. 128 KB xfer limit,
     direct IO alignment)
   - unable to interrupt a SCSI command in progress with
     a signal
   - associated ioctls are dummies or not there, hence unable
     to reset device/bus/host (for example)
   - no driver or host error reporting (only SCSI status)

I'm sure more "cons" will come to light and some will be
addressed. There is probably enough there already to give
the cdrecord author pause for thought.

>>I suspect ... cannot interrupt ...
> 
> 
> Sorry I'm too much of a kernelnewbie to guess confidently the full
> implications of "not interruptible".  Does "not interruptible" mean
> timeouts don't work, or does "not interruptible" mean that only timeouts
> work, or does "not interruptible" mean that only timeouts and resets but
> not SIGINT of the calling process works ...

"Linux Kernel Development" Robert Love ISBN 0-672-32512-8 covers
lk 2.6 pretty well including these issues. [Note in passing: the
book makes no mention of the SCSI or ATA subsystems or aio:-(]

"not interruptible" in this context means that signals (e.g.
control-C from the keyboard or kill-9) have no effect while
waiting for the SCSI response. The SCSI command timeout should
bring things back but often at the expense of a bus reset (on
SPI) which can have some nasty side effects (e.g. if your root
file system is on a disk on the same SPI bus).


** The sd/sr/st <-> sg mapping problem would be much simpler
in lk 2.6 if sg (plus st + osst) had sysfs visibility. Perhaps
udev could work out this mapping but this would still rely
on polling through sg, st and osst file descriptors with the
attendant problems that brings (e.g. blocking, O_EXCL, O(n)).

Doug Gilbert

Re: SG_IO ioctl (was: mode sense blacklist how)

[Willem Riede]

On 2003.11.20 20:17, Douglas Gilbert wrote:
> 
> ** The sd/sr/st <-> sg mapping problem would be much simpler
> in lk 2.6 if sg (plus st + osst) had sysfs visibility. Perhaps
> udev could work out this mapping but this would still rely
> on polling through sg, st and osst file descriptors with the
> attendant problems that brings (e.g. blocking, O_EXCL, O(n)).

If I'm not mistaken, Kai posted an initial patch to add sysfs
support to st. If that works, and this mapping is important,
I'll be happy to do the same for osst.

Regards, Willem Riede.

Re: SG_IO ioctl (was: mode sense blacklist how)

[Pat LaVarre]

Doug G:

> The SCSI command timeout should bring things back but often at the
> expense of a bus reset (on SPI) which can have some nasty side effects
> (e.g. if your root file system is on a disk on the same SPI bus).

Aye.  From reset-issued-Before-next-command I get nasty side effects in
SCSI over IDE (aka ATAPI), SCSI over USB, SCSI over FireWire ...

> > more prominent device names like /dev/hdd and /dev/scd0
> > in place of less prominent /dev/sg$n names ...
> ...
> trade-off ...
> Pros: ... - ... - ...
> Cons: ... - ... - ... - ... - ... - ...
> more "cons" will come to light ...
> probably enough ... to give the cdrecord author pause for thought.

Wow.  Prompt, incisive.  Thank you offline to this doc I will link folk.

http://marc.theaimsgroup.com/?l=linux-scsi&m=106937826522932

List:     linux-scsi
Subject:  SG_IO ioctl (was: mode sense blacklist how)
Date:     2003-11-21 1:17:16
 
> > Sorry I'm too much of a kernelnewbie to guess confidently the full
> > implications of "not interruptible".  Does "not interruptible" mean
> > timeouts don't work, or does "not interruptible" mean that only timeouts
> > work, or does "not interruptible" mean that only timeouts and resets but
> > not SIGINT of the calling process works ...
> 
> "Linux Kernel Development" Robert Love ISBN 0-672-32512-8 covers
> lk 2.6 pretty well including these issues. [Note in passing: the
> book makes no mention of the SCSI or ATA subsystems or aio:-(]

Thanks for the link, I will look again, I should manage to click thru to
hardcopies of same or similar title within twenty-four hours.

Perhaps I should have mentioned I am only a Linux kernelnewbie, not a
nano"kernel newbie", so I've found a few much-linked Linux books
frustratingly waste many words telling me again what I already know.

> "not interruptible" in this context means that signals (e.g.
> control-C from the keyboard or kill-9) have no effect while
> waiting for the SCSI response.

My Terminal Ctrl+C becomes SIGINT and kills my main user thread and user
process but doesn't affect the kernel thread serving me?  Ever?  Or only
no effect til that thread tries to return?

> ** ... if sg (plus st + osst) had sysfs visibility ...

This I'm too new to grok but I see others answering already.

Pat LaVarre

Re: SG_IO ioctl (was: mode sense blacklist how)

[Pat LaVarre]

> From: http://marc.theaimsgroup.com/?l=linux-scsi&m=106937826522932
> Date: 2003-11-21 1:17:16
>
> "Linux Kernel Development" Robert Love
> ISBN 0-672-32512-8 covers lk 2.6 pretty well
> including these issues. [Note in passing: the
> book makes no mention of the SCSI or ATA
> subsystems or aio:-(]

Thanks for the link, will pursue.

So far in hardcopy I have read only the obsolete lk 2.0 Linux Kernel
Internals M. Beck et al.

http://www.amazon.com/exec/obidos/ASIN/0201331438

>From my first reading I gathered Two facts that I then mentioned in
linux-fsdevel.  1) Kconfig files contain much of the `make xconfig`
text.  2) `gdb /usr/src/linux/vmlinux /proc/kcore` may start working for
me if I try CONFIG_DEBUG_KERNEL=y, CONFIG_DEBUG_INFO=y.

At amazon, that obsolete lk 2.0 second edition links to an lk 2.4.4
retitled third edition, "Linux Kernel Programming", also to the lk 2.6
US$31.49 "Linux Kernel Development" you mention:

http://www.amazon.com/exec/obidos/ASIN/0672325128

Pat LaVarre

Re: SG_IO ioctl (was: mode sense blacklist how)

[Pat LaVarre]

> obsolete lk 2.0 Linux Kernel Internals M. Beck et al. ...
> http://www.amazon.com/exec/obidos/ASIN/0201331438

I notice, the Amazon reviews of the lk 2.0 edition happen to include:

'When writing a Linux device driver, there is a "how", but there is,
perhaps more important, a "how _not_" (for instance, don't do
noninterruptible blocking system calls)'

Serendipity.  Pat LaVarre

Re: SG_IO ioctl (was: mode sense blacklist how)

[Pat LaVarre]

> > "Linux Kernel Development" Robert Love
> > ISBN 0-672-32512-8 covers lk 2.6
> ...
> US$31.49 ...
> http://www.amazon.com/exec/obidos/ASIN/0672325128

Ouch.  Buy one now ... and estimated ship date is no sooner than 12 Dec
i.e. 14 days away.  Gratis shipping then adds 5 to 9 days, adding US$16
or so cuts that to one day of delay.

Pat LaVarre

Re: SG_IO ioctl (was: mode sense blacklist how)

[Pat LaVarre]

> > Does "not interruptible" mean
> > timeouts don't work, or ...
> > only timeouts work, or ...
> > only timeouts and resets but not SIGINT ...
>
> From: http://marc.theaimsgroup.com/?l=linux-scsi&m=106937826522932
> Date: 2003-11-21 1:17:16 ...
>
> "not interruptible" in this context means ...
> The SCSI command timeout should bring things
> back but often at the expense ...

I hear you say: timeouts do cancel ioctl SG_IO but only by way of an
automagic reset of the target device that may disrupt contemporaneous
talk with other devices nearby.

I guess asynchronous reset by a parallel thread not yet mentioned
because that service does not yet exist.

Right?

In 2.6.0-test10 we have no way for another thread of the process trying
ioctl SG_IO to ask to cancel the ioctl of the first thread?

ioctl SG_IO runs to completion or to timeout or to reboot always?

> signals (e.g. control-C from the keyboard or
> kill-9) have no effect while waiting for the
> SCSI response.

I hear you say: SIGINT does not cancel ioctl SG_IO.

> The SCSI command timeout should bring things
> back but often at the expense ... can have
> some nasty side effects (e.g. if your root
> file system is on a disk on the same SPI bus).

Aye.

Pat LaVarre

Re: SG_IO ioctl (was: mode sense blacklist how)

[Pat LaVarre]

Offline kindly I'm reminded to distinguish a compelling third "pro" for
SG_IO via block/scsi_ioctl.c:

> > Designing an lk 2.6 user app to recommend more prominent device names
> > like /dev/hdd and /dev/scd0 in place of less prominent /dev/sg$n names
> > thereby steers people into using the less robust pass thru of SG_IO via
> > block/scsi_ioctl.c.
> 
> Pat,
> Well it's a trade-off. If you use the SG_IO in
> the block layer then:
> 
> Pros:
+ -- - works with ide-cd kernels, not just with ide-scsi kernels
>    - convenience (for block devices)
>    - no device mapping problems (sd <-> sg) **
> Cons:
>    - no help for "non-block" devices: tapes, enclosures,
>      OSD, etc
>    - inherit block layer policy (e.g. 128 KB xfer limit,
>      direct IO alignment)
>    - unable to interrupt a SCSI command in progress with
>      a signal
>    - associated ioctls are dummies or not there, hence unable
>      to reset device/bus/host (for example)
>    - no driver or host error reporting (only SCSI status)
> 
> I'm sure more "cons" will come to light and some will be
> addressed. There is probably enough there already to give
> the cdrecord author pause for thought.

Pat LaVarre

Re: [usb-storage] mode sense blacklist how

[Dmitri Katchalov]

Quoting Pat LaVarre <p.lavarre@ieee.org>:

> >  MODE SENSE (10): plscsi hangs and sits there in 
> >  usb_stor_bulk_transfer_buf until the device is 
> >  physically unplugged. kill -9 has no effect.
> 
> Yes why `kill -9` has no effect on SG_IO in progress remains an open
> question here at linux-scsi.
> 
> Meanwhile people have suggested the plscsi workaround: -X time 5 0. 
> Does that work for you?  

Yes, it does, thanks. Still, when plscsi comes back after a timeout the device
no longer responds and must be unplugged:

Nov 21 08:54:21 box kernel: usb-storage: Command MODE_SENSE_10 (10 bytes)
Nov 21 08:54:21 box kernel: usb-storage:  5a 00 00 00 00 00 00 00 c0 00
Nov 21 08:54:21 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21
value=0000 index=00 len=10
Nov 21 08:54:21 box kernel: usb-storage: Status code 0; transferred 10/10
Nov 21 08:54:21 box kernel: usb-storage: -- transfer complete
Nov 21 08:54:21 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 21 08:54:21 box kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 192 bytes

<note the delay here>

Nov 21 08:54:31 box kernel: usb-storage: command_abort called
Nov 21 08:54:31 box kernel: usb-storage: usb_stor_stop_transport called
Nov 21 08:54:31 box kernel: usb-storage: -- cancelling URB
Nov 21 08:54:31 box kernel: usb-storage: Status code -104; transferred 0/192
Nov 21 08:54:31 box kernel: usb-storage: -- transfer cancelled
Nov 21 08:54:31 box kernel: usb-storage: CB data stage result is 0x4
Nov 21 08:54:31 box kernel: usb-storage: -- command was aborted
Nov 21 08:54:31 box kernel: usb-storage: scsi command aborted
Nov 21 08:54:31 box kernel: usb-storage: *** thread sleeping.
Nov 21 08:54:31 box kernel: usb-storage: queuecommand called
Nov 21 08:54:31 box kernel: usb-storage: *** thread awakened.
Nov 21 08:54:31 box kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
Nov 21 08:54:31 box kernel: usb-storage:  00 00 00 00 00 00
Nov 21 08:54:31 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21
value=0000 index=00 len=6
Nov 21 08:54:31 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 21 08:54:31 box kernel: usb-storage: -- transfer complete
Nov 21 08:54:31 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 21 08:54:31 box kernel: usb-storage: -- CB transport device requiring auto-sense
Nov 21 08:54:31 box kernel: usb-storage: Issuing auto-REQUEST_SENSE
Nov 21 08:54:31 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21
value=0000 index=00 len=6
Nov 21 08:54:31 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 21 08:54:31 box kernel: usb-storage: -- transfer complete
Nov 21 08:54:31 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 21 08:54:31 box kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Nov 21 08:54:41 box kernel: usb-storage: command_abort called
Nov 21 08:54:41 box kernel: usb-storage: usb_stor_stop_transport called
Nov 21 08:54:41 box kernel: usb-storage: -- cancelling URB
Nov 21 08:54:41 box kernel: usb-storage: Status code -104; transferred 0/18
Nov 21 08:54:41 box kernel: usb-storage: -- transfer cancelled
Nov 21 08:54:41 box kernel: usb-storage: CB data stage result is 0x4
Nov 21 08:54:41 box kernel: usb-storage: -- auto-sense aborted
Nov 21 08:54:41 box kernel: usb-storage: scsi command aborted
Nov 21 08:54:41 box kernel: usb-storage: *** thread sleeping.
Nov 21 08:54:41 box kernel: usb-storage: device_reset called
Nov 21 08:54:41 box kernel: usb-storage: usb_stor_CB_reset called
Nov 21 08:54:41 box kernel: usb-storage: usb_stor_control_msg: rq=00 rqtype=21
value=0000 index=00 len=12
Nov 21 08:54:41 box kernel: usb-storage: Soft reset failed: -32
Nov 21 08:54:41 box kernel: usb-storage: bus_reset called
Nov 21 08:54:41 box kernel: hub 2-0:1.0: port 2 enable change, status 110
Nov 21 08:54:42 box kernel: usb-storage: usb_reset_device returns 0
Nov 21 08:54:52 box kernel: usb-storage: queuecommand called
Nov 21 08:54:52 box kernel: usb-storage: *** thread awakened.
Nov 21 08:54:52 box kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
Nov 21 08:54:52 box kernel: usb-storage:  00 00 00 00 00 00
Nov 21 08:54:52 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21
value=0000 index=00 len=6
Nov 21 08:54:52 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 21 08:54:52 box kernel: usb-storage: -- transfer complete
Nov 21 08:54:52 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 21 08:54:52 box kernel: usb-storage: -- CB transport device requiring auto-sense
Nov 21 08:54:52 box kernel: usb-storage: Issuing auto-REQUEST_SENSE
Nov 21 08:54:52 box kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=21
value=0000 index=00 len=6
Nov 21 08:54:52 box kernel: usb-storage: Status code 0; transferred 6/6
Nov 21 08:54:52 box kernel: usb-storage: -- transfer complete
Nov 21 08:54:52 box kernel: usb-storage: Call to usb_stor_ctrl_transfer() returned 0
Nov 21 08:54:52 box kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Nov 21 08:54:52 box kernel: usb-storage: Status code -19; transferred 0/18
Nov 21 08:54:52 box kernel: usb-storage: -- unknown error
Nov 21 08:54:52 box kernel: usb-storage: CB data stage result is 0x4
Nov 21 08:54:52 box kernel: usb-storage: -- auto-sense failure
Nov 21 08:54:52 box kernel: usb-storage: usb_stor_CB_reset called
Nov 21 08:54:52 box kernel: usb-storage: usb_stor_control_msg: rq=00 rqtype=21
value=0000 index=00 len=12
Nov 21 08:54:52 box kernel: usb-storage: Soft reset failed: -32
Nov 21 08:54:52 box kernel: usb-storage: scsi cmd done, result=0x70000
Nov 21 08:54:52 box kernel: usb-storage: *** thread sleeping.
Nov 21 08:54:52 box kernel: scsi: Device offlined - not ready after error
recovery: host 13 channel 0 id 0 lun 0

Using the timeout flag I was able to try more MODE SENSE(10) commands
and I finally found some that work:

./plscsi /dev/sg1 -v -p -X time 10 0 -i xC0 -x "5A 00 3F 00 00 00 00 00 C0 00"
produces the following output:

x 00000000 5A 00 3F:00:00:00 00 00:C0 00 .. .. .. .. .. .. "Z@?@@@@@@@"
x 00000000 00:32:00:00 00:00:00:00 05:1E:00:12 04:20:02:00 "@2@@@@@@E^@RD B@"
x 00000010 01:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "A@@@@@@@@@@@@@@@"
x 00000020 00:00:00:00 00:B4:00:00 1B:0A:C0:00 00:00:00:00 "@@@@@4@@[J@@@@@@"
x 00000030 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
...
x 000000B0 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
// 0 = plscsi.main exit int

It looks like the device does support MODE SENSE(10) for pages 5 and 1B only.
"5A 00 05 00 00 00 00 00 C0 00" and "5A 00 1B 00 00 00 00 00 C0 00" also work.

There is not much useful info on those 2 pages, what was the point 
of implementing them I wonder?

> Have you tried `modprobe -r usb-storage`?
"Module in use"
Not entirely unexpected since plscsi holds an open handle at this point.
 
> >  MODE SENSE (10): plscsi hangs and sits there
> 
> I see in the log you say what plscsi line you tried:
> 
> ./plscsi -p -i xC0 -x "5A 00 1C:00:00:00 00 00:C0 00 00:00"
> 
> Adding -v might tell us more.
Not really:) It just shows the command going down and that's it.

> In the log I see this command repeated, time and again.  Did you ask for
> this command repeatedly yourself, or is it the code of SG_IO and below
> that is so helpfully retrying?

That wasn't me. I see these commands were sent *after* the device has 
been unplugged. It must've been SCSI layer.

> Here we see "auto-sense" "code: 0x70, key: 0x5, ASC: 0x24, ASCQ: 0x0".
> 
> In the t10.org English, x 5 24 means cdb[0] opcode understood, but whole
> cdb not understood.  x 5 20 means cdb[0] opcode not understood.
> 
> This result suggests, without guaranteeing, that the vendor-specific
> bInterfaceSubClass = xFF SCSI of this device includes some cdb's that
> begin with op x1A Mode Sense (6).

Hmm, I tried MODE SENSE(6) with the same pages (5,1B and 3F) that worked 
with MODE SENSE(10) and I've got the same error: x 5 24.

Anyway, it must be obvious by now that the device is broken or shall we say
proprietary. There is a quick workaround already in place. I'd say blacklist 
it in unusual_devs and be done with it.

The only really important question IMHO is how come SG_IO is not interruptible.

Regards,
Dmitri

Re: [usb-storage] mode sense blacklist how

[Pat LaVarre]

> The only really important question IMHO is
> how come SG_IO is not interruptible.

Yes, now being pursued by Doug G in this thread.

> > In the log I see this command repeated, time and again.  Did you ask for
> > this command repeatedly yourself, or is it the code of SG_IO and below
> > that is so helpfully retrying?
> 
> That wasn't me. I see these commands were sent *after* the device has 
> been unplugged. It must've been SCSI layer.

This also could matter.  In our kernel code who wrongly thinks we gave
permission to retry SG_IO?  This evidence echoes someone else's - may
have been Patrick M - who saw mode sense stuttering.  I don't remember
if that was different (rude mode sense from the kernel) or the same
(rude mode sense via SG_IO from plscsi).

> Anyway, it must be obvious by now that the device is broken or shall
> we say proprietary. There is a quick workaround already in place. I'd
> say blacklist it in unusual_devs and be done with it.

Not broken.

This device explicitly self-identifies itself as a proprietary kind of
SCSI via bInterfaceSubClass = xFF and also the almost-proprietary kind
of SCSI over USB that is bInterfaceProtocol != x50.

No separate blacklist needed.  Recently near here I think I heard:

We of usb-storage are instead choosing to blacklist all the reserved
bInterfaceSubClass codes altogether.  Already we blacklist such devices
in that we don't try talking unless they appear in unusual_devs.  Now
also we won't try non-Microsoft mode sense even if they do appear in
unusual_devs.

> > the plscsi workaround: -X time 5 0. 
> > Does that work for you?  
> 
> Yes, ... Still, ... device ... must be unplugged ...

Curious.  If the mode senses that work aren't the first mode senses that
Windows tries, then the resets of Windows must be working ...

> try more MODE SENSE(10) ... finally found some that work:
> 
> ./plscsi /dev/sg1 -v -p -X time 10 0 -i xC0 -x "5A 00 3F 00 00 00 00 00 C0 00"
> produces the following output:
> 
> x 00000000 5A 00 3F:00:00:00 00 00:C0 00 .. .. .. .. .. .. "Z@?@@@@@@@"
> x 00000000 00:32:00:00 00:00:00:00 05:1E:00:12 04:20:02:00 "@2@@@@@@E^@RD B@"
> x 00000010 01:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "A@@@@@@@@@@@@@@@"
> x 00000020 00:00:00:00 00:B4:00:00 1B:0A:C0:00 00:00:00:00 "@@@@@4@@[J@@@@@@"
> x 00000030 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
> ...
> x 000000B0 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"

Ah.  Eight byte header claiming x34 bytes available.  No optional block
descriptor.  x20 bytes of page x05 for boot H:S:C.  x0C bytes of page
x1B to please Windows.    x 8 + 20 + 0C = 34, good.

> // 0 = plscsi.main exit int
> 
> It looks like the device does support MODE SENSE(10) for pages 5 and 1B only.

Perhaps that is all that PC boot BIOS and Windows require.  This could
be a sample of design-by-test: edit, compile, test, ship when it does
not crash.  Do you know if the device firmware is upgradable?

> "5A 00 05 00 00 00 00 00 C0 00" and "5A 00 1B 00 00 00 00 00 C0 00" also work.
> 
> There is not much useful info on those 2 pages, what was the point 
> of implementing them I wonder?

t10.org as we speak is hashing over the value or not of reporting a
fictional C:H:S geometry in the mode page x05 that can report C:H:S up
to about 8 GiB.

Page x1B I don't remember the t10.org name of but it appears in Windows
traces, so someone on Earth thinks it can be useful.  Name might be
something like "power conditions".

> > Have you tried `modprobe -r usb-storage`?
> "Module in use"
> Not entirely unexpected since plscsi holds an open handle at this point.

I'm sure I'm enough of a kernelnewbie to be deeply confused here, but I
don't understand why we can kill the plscsi process without gaining
permission to kill the SG_IO.
 
> > Adding -v might tell us more.
>
> Not really:) It just shows the command going down and that's it.

Thanks for saying, now I feel less bad about not suggesting -v to begin
with.

> > Here we see "auto-sense" "code: 0x70, key: 0x5, ASC: 0x24, ASCQ: 0x0".
> > 
> > In the t10.org English, x 5 24 means cdb[0] opcode understood, but whole
> > cdb not understood.  x 5 20 means cdb[0] opcode not understood.
> > 
> > This result suggests, without guaranteeing, that the vendor-specific
> > bInterfaceSubClass = xFF SCSI of this device includes some cdb's that
> > begin with op x1A Mode Sense (6).
> 
> Hmm, I tried MODE SENSE(6) with the same pages (5,1B and 3F) that worked 
> with MODE SENSE(10) and I've got the same error: x 5 24.

Ouch, maybe this device is creatively reporting x 5 24 to mean x 5 20.

Pat LaVarre

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Matthew Dharm]

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

On Thu, Nov 13, 2003 at 04:44:09PM -0700, Pat LaVarre wrote:
> Alan S:
> > Those sound like different issues from the one we've been discussing in 
> > this thread, namely: how should sd.c try to determine the read/write 
> > status and cache-type of a disk device?
> 
> I mean to be saying sd.c should by default send the CDB's associated
> with buffer lengths that produce the same BBB CBW's as Windows XP/2K,
> and then determine the read/write status and cache-type from that info
> alone.

I would go for this approach, but nobody has been able to figure out what
that CDB is.  There is even some suggestion that Win doesn't send any such
CDBs at all.

> I haven't yet seen a trace of Win XP/2K.

To my knowledge, nobody has.

Matt

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

Sir, for the hundreth time, we do NOT carry 600-round boxes of belt-fed 
suction darts!
					-- Salesperson to Greg
User Friendly, 12/30/1997

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

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Alan Stern]

On 13 Nov 2003, Pat LaVarre wrote:

> I mean to be saying sd.c should by default send the CDB's associated
> with buffer lengths that produce the same BBB CBW's as Windows XP/2K,
> and then determine the read/write status and cache-type from that info
> alone.
> 
> Do you agree that works for generic USB storage i.e. bInterfaceClass
> ...SubClass ...Protocol = x 08 (02|05|06) 50?
> 
> Do you disagree that is what we should do in sd for generic USB storage?
> 
> I'm confident Win XP/2K sometimes sends mode select to PDT x00
> HDD/Flash, because I remember some months back a friend fixed some
> firmware that didn't interpret mode select like Win wants nowadays.
> 
> I imagine that means Win sends mode sense too.
> 
> I haven't yet seen a trace of Win XP/2K.

Trying to rely too heavily on Talk Like Windows may be a mistake, since 
Windows itself seems to use different dialects in its different versions.
It reminds me of the mess Microsoft had with their SMB file-sharing 
network protocol; different versions of Windows were so incompatible they 
often couldn't communicate among themselves.

CDs, DVDs, etc. present their own set of problems.  For the moment I'm
just concerned about disk-type devices, and the only reliable way I can
see to deal with them is to avoid sending any MODE-SENSE commands over
USB.

Unfortunately that does mean we lose the ability to tell if a compliant
device/media is write-protected.  You suggested allowing MODE-SENSE
commands for devices that present certain standard SubClass and Protocol
values, or disallowing them only for devices that present vendor-specific
values.  I'm not so sure that will work -- I haven't kept good records of
users' reports, but it wouldn't be at all surprising to find that some
apparently-compliant devices (bInterfaceSubClass = x06, Protocol = x50)
still have problems with MODE-SENSE.

Alan Stern

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Matthew Dharm]

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

On Fri, Nov 14, 2003 at 11:14:08AM -0500, Alan Stern wrote:
> Unfortunately that does mean we lose the ability to tell if a compliant
> device/media is write-protected.  You suggested allowing MODE-SENSE
> commands for devices that present certain standard SubClass and Protocol
> values, or disallowing them only for devices that present vendor-specific
> values.  I'm not so sure that will work -- I haven't kept good records of
> users' reports, but it wouldn't be at all surprising to find that some
> apparently-compliant devices (bInterfaceSubClass = x06, Protocol = x50)
> still have problems with MODE-SENSE.

I _know_ that some 'apparently-compliant' devices have trouble with
MODE_SENSE.

Matt

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

It was a new hope.
					-- Dust Puppy
User Friendly, 12/25/1998

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

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Pat LaVarre]

All clear now, thanks.

> we lose the ability to tell if a compliant
> device/media is write-protected.

Yes.

> different versions of Windows were so incompatible they 
> often couldn't communicate among themselves.

Yes.

> CDs, DVDs, etc. present their own set of problems.  For the moment I'm
> just concerned about disk-type devices, and the only reliable way I can
> see to deal with them is to avoid sending any MODE-SENSE commands over
> USB.

I'll stay tuned to see if eventually we choose to break sd write-protect
for the sake of blacklisting mode sense in ATAPI and 1394 as well.

Pat LaVarre

Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Douglas Gilbert]

Patrick Mansfield wrote:
> James - can you please apply? This should not affect other devices since
> we are not changing the requested length, just the size of the receive
> buffer.
> 
> This patch against a recent 2.6 bk fixes problems with Sony USB mass
> storage devices: they are sending back 10 bytes even when we ask for 8
> bytes (USB babble).
> 
> Just use a larger receive buffer for MODE SENSE even though we are
> requesting 8 bytes.
> 
> Tested by Ronald Kuetemei with his Sony camera, also tested with a USB CF
> card reader.
> 
> diff -uprN -X /home/patman/dontdiff bl-25/drivers/scsi/scsi_lib.c modesense-bufflen-bk-2.5/drivers/scsi/scsi_lib.c
> --- bl-25/drivers/scsi/scsi_lib.c	Mon Sep 29 12:21:09 2003
> +++ modesense-bufflen-bk-2.5/drivers/scsi/scsi_lib.c	Mon Nov 10 15:42:03 2003

<snip>

>  
> +	WARN_ON((buf_len < 8) || (buf_len < len));
> +	if (buf_len > 255)
> +		buf_len = 255;
> +	if (len > 255)
> +		len = 255;

Patrick,
SPC-3 section 6.25 (REQUEST SENSE command) [spc3r15.pdf]
says the maximum allocation length should be 252 (not
255). They are steering alway from odd numbers and preferring
the next lower modulo 4 number.

<snip>

>  	if (!scsi_status_is_good(res))
> -		res = sd_do_mode_sense(SRpnt, 0, 0x3F, buffer, 255, &data);
> +		res = sd_do_mode_sense(SRpnt, 0, 0x3F, buffer, 255, buf_len,
> +				       &data);

dito


Doug Gilbert

Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Pat LaVarre]

> > .../drivers/scsi/scsi_lib.c
> ...
> SPC-3 section 6.25 (REQUEST SENSE command) [spc3r15.pdf]
> says the maximum allocation length should be 252 (not
> 255). They are steering alway from odd numbers and preferring
> the next lower modulo 4 number.
> ...
> sd_do_mode_sense(SRpnt, 0, 0x3F, buffer, 255, &data);
> ...
> dito

Intriguing, thank you.

I see you quote that 252 = xFC but then I resist these implications as
follows:

1)

While focused in sd, I apply t10 SPC only to ops like x 03 1A.  I favour
the slightly binary incompatible, competing definitions of t10 MMC for
ops like x 12 5A.

2)

xC0 may often be Windows max for GPCMD_MODE_SENSE_10.

When the actual available max is larger, choosing xC0 rather than xFC
will produce aligned results on 64-bit (and on 128-bit) hardware.

By contrast we see aligned only for 32-bit hardware at the data of a
standard -i x24 -y "12 00:00:00 24 00" Inquiry does, and we see aligned
only for 64-bit hardware at the data of a standard -i 8 -y "25 00
00:00:00:00 00 00:00 00" Read Capacity.

I hope already we always have bothered to allot only whole machine words
for SCSI data.  Then transports that round up to the next aligned
boundary can't hurt us.

3)

Win XP/2K max for x03 GPCMD_REQUEST_SENSE often is x12.  Win ME/9X often
is x0E.  We might work better if we pushed an aligned-to-32-bit standard
like x18 or x10, or we might work worse.

I can't easily know.  Anybody else on Earth care?

Pat LaVarre

Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Pat LaVarre]

 > This is a terrible idea.
 > There is a large number of devices
 > which choke if those two values do not match.

Did I miss our record of the search for plscsi parameters that Sony's 
USB mass storage would accept?

I remember seeing we did try mode sense of header and whole page, but 
not being convinced we had tried every reasonably variation of that.

 > > should not affect other devices since
 > > we are not changing the requested length,
 > > just the size of the receive
 > > buffer.

Sorry.  The size of the receive buffer crosses the bus at least to USB 
and to FireWire devices.  Assaulting devices with noise then finds 
hits, yes.

Also in a robust SCSI over whatever host, the bytes per buffer 
parameter also alters the behaviour of ATAPI PIO drivers, though I do 
not yet know myself if Linux ATAPI is robust in that way.

 > > Can we use a minium buffer length of 12 for
 > > any requests of less than 13 bytes?
 >
 > You can try.... I don't know if it will work.

Me neither.

A device refusing to agree to copy as few bytes as a header is a device 
telling us we're not talking like Windows.  From the thread "usb 
storage traces" we know Windows does sometimes fetch header, calculate 
available length, fetch whole ... but apparently not for mode page x08 
from this Sony device.

 > > Else, I give up ...

We can give up on PDT x00 HDD/Flash that is writable except when the 
write-protect tab is flipped ... without necessarily giving up on the 
PDT x05 DVD/CD where those "usb storage traces" show us Windows 
actually bothering to try the politically correct speech we see 
implicitly blessed at t10.org.

Pat LaVarre

P.S. If this mail appears in the correct thread and appears labelled 
"Pat LaVarre" rather than "Steve Jobs", I will have achieved a new high 
in my understanding of `nslookup -q=mx $domain` etc.

Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Pat LaVarre]

P.S.

Another thought: have we yet begun to experiment with disks that we can 
write protect?

I am, I have an Iomega Zip disk - all those have soft write-protect 
tabs inside.

For the sake of experimenting with other kinds of disks I'm thinking we 
could easily write a small patch to add a virtual write protect tab 
inside Linux to any usb-storage PDT x00 HDD/Flash.  I think the change 
is as small as catching mode sense headers to flip the Writable bit of 
the device-specific-parameter, and catching write ops to fail via SK 
ASC ASCQ = x 7 27 00 NotWritable.

Pat LaVarre