[PATCH 2.4] rewritable USB DVD-RAM vs. mode sense op choice

[PATCH 2.4] rewritable USB DVD-RAM vs. mode sense op choice

[Pat LaVarre]

Jens A:

2.4.26 and 2.4.27 strace of dd of=, mount -w, etc. chokes via EROFS for
USB DVD-RAM.  2.4.25 I have not tried.

This small patch substitutes the MMC op x5A "MODE SENSE (10)" for the op
x1A that in t10.org PDT x05 is vendor-specific.  Such consideration
persuades a standard DVD-RAM drive to admit it rewrites DVD-RAM discs.

Revising the CDB alone of course does not suffice: we also have to step
past a different size of data in header.

Pat LaVarre

diff -urp linux-2.4.27/drivers/scsi/sr.c linux-2.4.27-pel/drivers/scsi/sr.c
--- linux-2.4.27/drivers/scsi/sr.c	2003-06-13 08:51:36.000000000 -0600
+++ linux-2.4.27-pel/drivers/scsi/sr.c	2004-08-16 10:08:37.000000000 -0600
@@ -691,7 +691,7 @@ void get_sectorsize(int i)
 
 void get_capabilities(int i)
 {
-	unsigned char cmd[6];
+	unsigned char cmd[16];
 	unsigned char *buffer;
 	int rc, n;
 
@@ -713,12 +713,12 @@ void get_capabilities(int i)
 		printk(KERN_ERR "sr: out of memory.\n");
 		return;
 	}
-	cmd[0] = MODE_SENSE;
+	memset(cmd, '\0', sizeof cmd);
+	cmd[0] = MODE_SENSE_10;
 	cmd[1] = (scsi_CDs[i].device->scsi_level <= SCSI_2) ?
 		 ((scsi_CDs[i].device->lun << 5) & 0xe0) : 0;
 	cmd[2] = 0x2a;
-	cmd[4] = 128;
-	cmd[3] = cmd[5] = 0;
+	cmd[8] = 128;
 	rc = sr_do_ioctl(i, cmd, buffer, 128, 1, SCSI_DATA_READ, NULL);
 
 	if (rc) {
@@ -731,7 +731,7 @@ void get_capabilities(int i)
 		printk("sr%i: scsi-1 drive\n", i);
 		return;
 	}
-	n = buffer[3] + 4;
+	n = 8 + ((buffer[6] << 8) | buffer[7]); /* 8 = sizeof MODE_SENSE_10 header */
 	scsi_CDs[i].cdi.speed = ((buffer[n + 8] << 8) + buffer[n + 9]) / 176;
 	scsi_CDs[i].readcd_known = 1;
 	scsi_CDs[i].readcd_cdda = buffer[n + 5] & 0x01;

Re: [PATCH 2.4] rewritable USB DVD-RAM vs. mode sense op choice

[Jens Axboe]

On Mon, Aug 16 2004, Pat LaVarre wrote:
> Jens A:
> 
> 2.4.26 and 2.4.27 strace of dd of=, mount -w, etc. chokes via EROFS for
> USB DVD-RAM.  2.4.25 I have not tried.
> 
> This small patch substitutes the MMC op x5A "MODE SENSE (10)" for the op
> x1A that in t10.org PDT x05 is vendor-specific.  Such consideration
> persuades a standard DVD-RAM drive to admit it rewrites DVD-RAM discs.
> 
> Revising the CDB alone of course does not suffice: we also have to step
> past a different size of data in header.
> 
> Pat LaVarre
> 
> diff -urp linux-2.4.27/drivers/scsi/sr.c linux-2.4.27-pel/drivers/scsi/sr.c
> --- linux-2.4.27/drivers/scsi/sr.c	2003-06-13 08:51:36.000000000 -0600
> +++ linux-2.4.27-pel/drivers/scsi/sr.c	2004-08-16 10:08:37.000000000 -0600
> @@ -691,7 +691,7 @@ void get_sectorsize(int i)
>  
>  void get_capabilities(int i)
>  {
> -	unsigned char cmd[6];
> +	unsigned char cmd[16];
>  	unsigned char *buffer;
>  	int rc, n;
>  
> @@ -713,12 +713,12 @@ void get_capabilities(int i)
>  		printk(KERN_ERR "sr: out of memory.\n");
>  		return;
>  	}
> -	cmd[0] = MODE_SENSE;
> +	memset(cmd, '\0', sizeof cmd);

	memset(cmd, 0, sizeof(cmd));

> +	cmd[0] = MODE_SENSE_10;
>  	cmd[1] = (scsi_CDs[i].device->scsi_level <= SCSI_2) ?
>  		 ((scsi_CDs[i].device->lun << 5) & 0xe0) : 0;
>  	cmd[2] = 0x2a;
> -	cmd[4] = 128;
> -	cmd[3] = cmd[5] = 0;
> +	cmd[8] = 128;
>  	rc = sr_do_ioctl(i, cmd, buffer, 128, 1, SCSI_DATA_READ, NULL);

This gives me a bad vibe - I'm assuming your device is failing the
6-byte mode sense? This has to work with devices that don't support
MODE_SENSE_10, if you want it to work for you as well, then make the
MODE_SENSE_10 a fall back when MODE_SENSE fails. You cannot rely on the
change you made.

-- 
Jens Axboe

Re: [PATCH 2.4] rewritable USB DVD-RAM vs. mode sense op choice

[Pat LaVarre]

Jens A:

>> -	cmd[0] = MODE_SENSE;
>> +	memset(cmd, '\0', sizeof cmd);
>
> 	memset(cmd, 0, sizeof(cmd));
>
>> +	cmd[0] = MODE_SENSE_10;
>>  	cmd[1] = (scsi_CDs[i].device->scsi_level <= SCSI_2) ?
>>  		 ((scsi_CDs[i].device->lun << 5) & 0xe0) : 0;
>>  	cmd[2] = 0x2a;
>> -	cmd[4] = 128;
>> -	cmd[3] = cmd[5] = 0;
>> +	cmd[8] = 128;
>>  	rc = sr_do_ioctl(i, cmd, buffer, 128, 1, SCSI_DATA_READ, NULL);
>
> This gives me a bad vibe - I'm assuming your device is failing the
> 6-byte mode sense? This has to work with devices that don't support
> MODE_SENSE_10,

Clear design goal, thank you.

>  if you want it to work for you as well, then make the
> MODE_SENSE_10 a fall back when MODE_SENSE fails. You cannot rely on the
> change you made.

Clear instruction, thank you, I will do.

> the MODE_SENSE_10 a fall back when MODE_SENSE fails

I believe the specs on the web instead tell us to try MODE_SENSE_10 
first and then fall back to MODE_SENSE.  I hear you requesting the 
reverse, I will deliver what I hear you request.

> your device is failing ... ?

Help, I have more than one device.

My Iomega REV drive works here because that device accepts both ops, 
implementing the SFF/ ANSI MMC specification for op x5A and the 
incompatible ANSI SPC specification for op x1A.  To achieve 
compatibility, I believe every host should try both ops and every 
device should accept both ops.

I mean only to say that I see Linux 2.4 sr_mod mischaracterises the 
many DVD/ CD devices that do reject op x1A while accepting only op x5A 
MODE_SENSE_10.

I hesitate to accept the Linux name MODE_SENSE for the op x1A, because 
I do not find that claim well-founded in the web for PDT x05 = DVD/ CD 
= MMC.  I remember Mt Fuji in particular neglects to name op x1A.

> your device is failing ... ?

In this thread I meant to share the example of 2.4 sr_mod 
mischaracterising a USB DVD-RAM drive that rejects op x1A.

I hear of PATAPI DVD/CD devices that reject op x1A also.  I imagine 
ide-cd works only by trying op x5A, and not just x1A.  Want me to 
check?  I don't yet know how to trace in Linux the plain hex of the 
CDB's that ide-cd sends.

Pat LaVarre

Re: [PATCH 2.4] rewritable USB DVD-RAM vs. mode sense op choice

[Jens Axboe]

On Mon, Aug 23 2004, Pat LaVarre wrote:
> >the MODE_SENSE_10 a fall back when MODE_SENSE fails
> 
> I believe the specs on the web instead tell us to try MODE_SENSE_10 
> first and then fall back to MODE_SENSE.  I hear you requesting the 
> reverse, I will deliver what I hear you request.

That's what I would do as well, actually. But since this is 2.4 it's
safe to keep old behaviour and only try something new if that fails.

> >your device is failing ... ?
> 
> Help, I have more than one device.

Doesn't matter

> My Iomega REV drive works here because that device accepts both ops, 
> implementing the SFF/ ANSI MMC specification for op x5A and the 
> incompatible ANSI SPC specification for op x1A.  To achieve 
> compatibility, I believe every host should try both ops and every 
> device should accept both ops.
> 
> I mean only to say that I see Linux 2.4 sr_mod mischaracterises the 
> many DVD/ CD devices that do reject op x1A while accepting only op x5A 
> MODE_SENSE_10.
> 
> I hesitate to accept the Linux name MODE_SENSE for the op x1A, because 
> I do not find that claim well-founded in the web for PDT x05 = DVD/ CD 
> = MMC.  I remember Mt Fuji in particular neglects to name op x1A.

That's the classical naming, since the 6-byte variant was the original
(and surely people would have found it stupid to name it MODE_SENSE_6
back then). So experience usually tell people that when you see READ and
READ_10, the former is the old 6-byte variant.

Mt Fuji doesn't name any of the 6-byte variants, since they are long
deprecated for that class of devices.

> >your device is failing ... ?
> 
> In this thread I meant to share the example of 2.4 sr_mod 
> mischaracterising a USB DVD-RAM drive that rejects op x1A.
> 
> I hear of PATAPI DVD/CD devices that reject op x1A also.  I imagine 
> ide-cd works only by trying op x5A, and not just x1A.  Want me to 
> check?  I don't yet know how to trace in Linux the plain hex of the 
> CDB's that ide-cd sends.

Only sr issues 6-byte commands, I don't think support for them was ever
required for ATAPI devices.

So if you add a fallback to issue MODE_SENSE_10 when _6 fails, you
should be golden.

-- 
Jens Axboe

Re: [PATCH 2.4] rewritable USB DVD-RAM vs. mode sense op choice

[Pat LaVarre]

Jens A:

>> I believe the specs on the web instead tell us to try MODE_SENSE_10
>> first and then fall back to MODE_SENSE.  I hear you requesting the
>> reverse, I will deliver what I hear you request.
>
> That's what I would do as well, actually. But since this is 2.4 it's
> safe to keep old behaviour and only try something new if that fails.

Clear design goal, thank you.

> Only sr issues 6-byte commands, I don't think support for them was ever
> required for ATAPI devices.
>
> So if you add a
USB
> fallback to issue MODE_SENSE_10 when _6 fails, you
> should be golden.

Clear instruction, will do, thank you.

Ack, ack, ack, we're in sync now, thank you!

Pat LaVarre

Re: [PATCH 2.4] rewritable USB DVD-RAM vs. mode sense op choice

[Pat LaVarre]

> add a fallback to issue MODE_SENSE_10 when _6 fails, ...
> should be golden.

Jens A:

This 2.4 patch, as you suggested, makes sr_mod try op x5A MODE_SENSE_10
if op x1A MODE_SENSE fails in any way.

As you know, the 2.4.27 sr_mod without this patch complains "scsi-1
drive", rather than discovering "scsi3-mmc drive: ... dvd-ram ...", if
plugged into a USB DVD-RAM drive that implements only SFF/ MMC x5A and
not SPC x1A.

Do you like this patch?

Want people to run any tests in particular?

Already, with rewritable DVD-RAM discs, in dd of= rewritability and USB
CDB traces, I see this makes the USB DVD-RAM "HL-DT-ST" "DVDRAM" "A100"
rewritable and has no effect on the USB DVD-RAM "MATSHITA" "DVD-RAM"
"A111".

Pat LaVarre

--- linux-2.4.27/drivers/scsi/sr.c	2003-06-13 08:51:36.000000000 -0600
+++ linux-2.4.27-pel/drivers/scsi/sr.c	2004-08-23 14:07:49.000000000 -0600
@@ -689,9 +689,42 @@ void get_sectorsize(int i)
 	scsi_free(buffer, 512);
 }
 
-void get_capabilities(int i)
+static int sr_mode_sense_10(int * n,
+	int i, unsigned char * buffer, unsigned buflength,
+	int quiet, int readwrite, struct request_sense * sense)
+{
+	unsigned char cmd[16];
+	int rc;
+	memset(cmd, '\0', sizeof cmd);
+	cmd[0] = MODE_SENSE_10;
+	cmd[1] = (scsi_CDs[i].device->scsi_level <= SCSI_2) ?
+		 ((scsi_CDs[i].device->lun << 5) & 0xe0) : 0;
+	cmd[2] = 0x2a;
+	cmd[8] = 128;
+	rc = sr_do_ioctl(i, cmd, buffer, buflength, quiet, readwrite, sense);
+	*n = 8 + ((buffer[6] << 8) | buffer[7]);
+	return rc;
+}
+
+static int sr_mode_sense_6(int * n,
+	int i, unsigned char * buffer, unsigned buflength,
+	int quiet, int readwrite, struct request_sense * sense)
 {
 	unsigned char cmd[6];
+	int rc;
+	cmd[0] = MODE_SENSE;
+	cmd[1] = (scsi_CDs[i].device->scsi_level <= SCSI_2) ?
+		 ((scsi_CDs[i].device->lun << 5) & 0xe0) : 0;
+	cmd[2] = 0x2a;
+	cmd[4] = 128;
+	cmd[3] = cmd[5] = 0;
+	rc = sr_do_ioctl(i, cmd, buffer, buflength, quiet, readwrite, sense);
+	*n = buffer[3] + 4;
+	return rc;
+}
+
+void get_capabilities(int i)
+{
 	unsigned char *buffer;
 	int rc, n;
 
@@ -713,13 +746,18 @@ void get_capabilities(int i)
 		printk(KERN_ERR "sr: out of memory.\n");
 		return;
 	}
-	cmd[0] = MODE_SENSE;
-	cmd[1] = (scsi_CDs[i].device->scsi_level <= SCSI_2) ?
-		 ((scsi_CDs[i].device->lun << 5) & 0xe0) : 0;
-	cmd[2] = 0x2a;
-	cmd[4] = 128;
-	cmd[3] = cmd[5] = 0;
-	rc = sr_do_ioctl(i, cmd, buffer, 128, 1, SCSI_DATA_READ, NULL);
+
+	/* SFF/ MMC op x5A MODE_SENSE_10 should work,
+	 * and SPC op x1A MODE_SENSE might work,
+	 * so we try both except we try x1A first to match Linux 2.4.27.
+	 */
+
+	rc = sr_mode_sense_6(&n,
+		i, buffer, 128, 1, SCSI_DATA_READ, NULL);
+	if (rc) {
+		rc = sr_mode_sense_10(&n,
+			i, buffer, 128, 1, SCSI_DATA_READ, NULL);
+	}
 
 	if (rc) {
 		/* failed, drive doesn't have capabilities mode page */
@@ -731,7 +769,6 @@ void get_capabilities(int i)
 		printk("sr%i: scsi-1 drive\n", i);
 		return;
 	}
-	n = buffer[3] + 4;
 	scsi_CDs[i].cdi.speed = ((buffer[n + 8] << 8) + buffer[n + 9]) / 176;
 	scsi_CDs[i].readcd_known = 1;
 	scsi_CDs[i].readcd_cdda = buffer[n + 5] & 0x01;