Re: [linux-usb-devel] Re: USB storage problems on OHCI..

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Pat LaVarre]

> From: Linus Torvalds <torvalds () osdl ! org>
> Date: 2003-09-22 19:55:30
> ...
> How about just trusting the size ...
> and capping it at 20?

Besides dramatic overestimates of mode sense additional length, I've
also seen the off-by-one slight overestimate and the high-byte-zeroed
dramatic underestimate.

> General MODE SENSE stuff is in:
> http://www.t10.org/ftp/t10/drafts/spc3/spc3r15.pdf

Yes, but t10 mmc often quietly contradicts & overrides t10 spc for pdt
x05 dvd/cd and for atapi pdt x00 hdd/rmb.  For t10 newbies wanting to
fetch the bleeding edge, latest final draft, oldest still available,
etc. I sometimes recommend the index:

http://www.t10.org/scsi-3.htm

> > A scsi device declares its level of scsi compliance.
> ...
> From: Matthew Dharm <mdharm-scsi () one-eyed-alien ! net>
> Date: 2003-09-22 20:51:59
> ...
> reporting of 0, 1, 2, or something random ...
> appears ... unrelated to the capabilities of the device ...

The pernicious idea of zeroing the scsi revision in byte 2 of op x12
inquiry forms part of how mmc quietly redefines spc.  Misapplying the
sff precursor of the pdt x05 mmc spec to pdt x00 devices is part of how
msft whql qualified atapi pdt x00 devices for sale thru oem's in the
late 1990's.

> > > > From: Alan Stern <stern () rowland ! harvard ! edu>
> > > > Date: 2003-09-22 14:25:28
> > > > ...
> > > > many, many USB storage devices.  
> > > > They just don't handle MODE-SENSE page 8 correctly.
> > >
> > > From: Linus Torvalds <torvalds () osdl ! org>
> > > Date: 2003-09-22 16:09:47
> > > ...
> > > How about just making the sd.c layer more robust? 
> >
> > From: Alan Stern <stern () rowland ! harvard ! edu>
> > Date: 2003-09-22 16:42:52
> > ...
> > variety of ways ... fail ... truly amazing.
>
> From:  Christoph Hellwig <hch () infradead ! org>
> Date: 2003-09-22 17:21:42
> ...
> for those usb-storage devices where ...
> nothing that isn't excercised by the windows drivers
> has the slightest chance of working..

In the sd world, usb hdd/rmb (pdt x00) may handle specifically the mode
sense of page 8 that win sends.

For usb bInterfaceSubClass = x06 TransparentScsi that cdb might be:
x 1A 00:08:00 18 00

For usb bInterfaceSubClass != x06 TransparentScsi that cdb might be:
x 5A 00 08:00:00:00 00 00:1C 00

usb dvd/cd (pdt x05) sell into the sr/ide-cd world instead, of course.

Tell me we care to hear specifically what some win sends to some of my
usb hdd/rmb, and I'll go collect a few sample usb bus traces.  I do NOT
know that the above cdb's are correct.  Those are just my guesses,
summing up little clues from years of messing around near here.  I hear
in particular that win 9x/me differs from win 2k/xp near hear.

> Subject:  Re: [linux-usb-devel] Re: USB storage problems on OHCI..
> From: Linus Torvalds <torvalds () osdl ! org>
> Date: 2003-09-22 17:41:47
> ...
> is it saner to try to read just the bytes we need
> (3 bytes: page code, page size and the cache bits),
> or the full 20 bytes?

I thought "everyone knew" sanest was to always fetch header + block
descriptors + whole pages?

Trouble is, that's a circular definition in that the host can't know
whether the device will volunteer an optional block descriptor or not. 
mmc says shall not, spc says maybe not but should.

We only have to care if we have to know how many Data bytes to expect to
copy In.

> From: Andries.Brouwer () cwi ! nl
> Date: 2003-09-22 18:55:22
> ...
> Similarly, USB storage devices tend to ...
> only systematically work
> if one does precisely what Windows does.

Yes, what ain't tested don't work.

> USB is hot pluggable,
> so it should not be necessary
> to send a flush cache command at shutdown.

Who has tested this rule?  I know I've seen ata hdd lose data in
response to a pin 1 reset issued without op x35 sync cache.  I've heard
same of dvd.  And loss of bus power can kill any write cache in a drive,
of course.

> From: James Bottomley <James.Bottomley () steeleye ! com>
> Date: 2003-09-22 17:55:09 ...
> ...
> I think we could try 4 bytes

We know that isn't talk like windows.  msdn.microsoft.com tells us the
win 2k kernel crashes if a root-privileged app asks for just the 4 byte
header from devices for which Win translates to x5A MODE_SENSE_10 from
x1A MODE_SENSE  Because the win 2k kernel crashes so reliably, we can
confidently guess no working win 2k apps talk that way.

> From: James Bottomley <James.Bottomley () steeleye ! com>
> Date: 2003-09-22 19:28:56
> ...
> sd? ... the most conservative ..., we could probably
> dump spin up, read write protect, and read cache type ...

Aye, although in sr/ide-cd we have a default of not writable to overcome
somehow.

Pat LaVarre

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Pat LaVarre]

> From: Linus Torvalds <torvalds () osdl ! org>
> Date: 2003-09-23 15:46:21
>
> Normal users consider hot-pluggable
> to be "I can rip the thing out by hand".

Yes.

Meanwhile, much (all except flash?) actual usb-storage now commercially
available is Not hot-pluggable in this sense.  Instead, "ata hdd lose
data in response to a pin 1 reset issued without op x35
"SYNCHRONIZE_CACHE". I've heard same of" writeable "dvd.  And loss of
bus power can kill any write cache in a drive, of course."

Pat LaVarre

2 KiB/block loopback found where

[Pat LaVarre]

I want a 2 KiB/block loopback device to help debug udf.ko.

I get 0.5 KiB/block.  Did I fail to find an option or an appropriate
kernel patch, I do I have to write my own patch?  I'm guessing I'll find
2 KiB/block easy to fake, since 0.5 KiB divides evenly into 2 KiB.

Specifically, I want to see 2048 where now I see 512 in response to my
query `blockdev --getss`.  A more complete example console log follows:

Pat LaVarre

$
$ dd of=dd.bin bs=1M count=1 if=/dev/zero
1+0 records in
1+0 records out
$
$ ls -l dd.bin
-rw-rw-r--    1 pat      pat       1048576 Sep 29 09:43 dd.bin
$
$ sudo /sbin/losetup /dev/loop0 dd.bin
$
$ sudo blockdev --getss /dev/loop0
512
$

Re: 2 KiB/block loopback found where

[Jens Axboe]

On Mon, Sep 29 2003, Pat LaVarre wrote:
> 
> I want a 2 KiB/block loopback device to help debug udf.ko.
> 
> I get 0.5 KiB/block.  Did I fail to find an option or an appropriate
> kernel patch, I do I have to write my own patch?  I'm guessing I'll find
> 2 KiB/block easy to fake, since 0.5 KiB divides evenly into 2 KiB.
> 
> Specifically, I want to see 2048 where now I see 512 in response to my
> query `blockdev --getss`.  A more complete example console log follows:
> 
> Pat LaVarre
> 
> $
> $ dd of=dd.bin bs=1M count=1 if=/dev/zero
> 1+0 records in
> 1+0 records out
> $
> $ ls -l dd.bin
> -rw-rw-r--    1 pat      pat       1048576 Sep 29 09:43 dd.bin
> $
> $ sudo /sbin/losetup /dev/loop0 dd.bin
> $
> $ sudo blockdev --getss /dev/loop0
> 512
> $

Add a quick hack to loop to set 2kb block size, grep for set_blocksize.

-- 
Jens Axboe

Re: 2 KiB/block loopback found where

[Pat LaVarre]

> > I want a 2 KiB/block loopback device ...
> > I get 0.5 KiB/block ...
> > 0.5 KiB divides evenly into 2 KiB.
>
> Add a quick hack to loop
> to set 2kb block size,
> grep for set_blocksize.

Great hint forward, thanks.  My first guess at what we mean follows,
I'll report back to say how this goes.

Pat LaVarre

diff -Nur linux-2.6.0-test6/drivers/block/loop.c linux/drivers/block/loop.c 

--- linux-2.6.0-test6/drivers/block/loop.c	2003-09-27 18:50:29.000000000 -0600
+++ linux/drivers/block/loop.c	2003-09-29 11:06:50.057826432 -0600
@@ -732,7 +732,7 @@
 	mapping_set_gfp_mask(inode->i_mapping,
 			     lo->old_gfp_mask & ~(__GFP_IO|__GFP_FS));
 
-	set_blocksize(bdev, lo_blocksize);
+	set_blocksize(bdev, 0x800); // not lo_blocksize);
 
 	lo->lo_bio = lo->lo_biotail = NULL; 

Re: 2 KiB/block loopback found where

[Pat LaVarre]

> > > Subject: 2 KiB/block loopback found where
> > ...
> > Subject: udf folders pointing to self and above
> ...
> Subject: Re: zip of GiB cross-platform
> This kind of question
> does not belong on this list.

I wonder if this "2 KiB/block loopback found where" thread belongs on
linux-kernel, rather than on linux-scsi, since the code involved seems
to be drivers/block/loop.c

Pat LaVarre

Re: max GiB written per boot

[Pat LaVarre]

I wish in the Subject line had mentioned so far I've tried writing GiB
only via usb where it dies, not elsewhere.  Today I returned after
leaving a drive idle for some days.  Nothing had appeared in the `dmesg`
meanwhile, but trying to talk to the drive provoked:

scsi: Device offlined - not ready after error recovery: host 0 channel 0
id 0 lun 0

Time to reboot I guess.  Pat LaVarre

writable mmc profiles actually are writable

[Pat LaVarre]

> Newsgroups: mlist.linux.scsi
> Date: 2003-09-10 16:00:27 PST
> Subject: Re: [PATCH] mount -w of dvd+rw etc. in vanilla 2.6
> From: Patrick Mansfield (patmans@us.ibm.com)
>
> Should sd.c and sr.c be calling set_device_ro?
> (after adding a read only block device, or
> changing back to read/write)?

That good question stands open, I think.

The following inline plain text, now revved for -test6 & posted here,
allows modprobe to overcome such uncooperative attitudes as:

$ sudo dd if=/dev/scd2 bs=2k count=1 | wc
1+0 records in
1+0 records out
      0       0    2048
$
$ sudo dd of=/dev/scd2 bs=2k count=1 if=/dev/zero
dd: opening `/dev/scd2': Read-only file system
$

Allowing dd, mkudffs, etc. are the good consequences.  The evil
consequences I do not yet know.  I do notice we have achieved
writability without extending the enumeration that `cat
/proc/sys/dev/cdrom/info` dumps:

Can write CD-R:         0
Can write CD-RW:        0
Can read DVD:           0
Can write DVD-R:        0
Can write DVD-RAM:      0

Pat LaVarre

diff -ur linux-2.6.0-test6/drivers/cdrom/cdrom.c linux/drivers/cdrom/cdrom.c
--- linux-2.6.0-test6/drivers/cdrom/cdrom.c	2003-09-27 18:50:10.000000000 -0600
+++ linux/drivers/cdrom/cdrom.c	2003-10-06 11:53:41.826299728 -0600
@@ -426,8 +426,8 @@
 	if ((fp->f_flags & O_NONBLOCK) && (cdi->options & CDO_USE_FFLAGS))
 		ret = cdi->ops->open(cdi, 1);
 	else {
-		if ((fp->f_mode & FMODE_WRITE) && !CDROM_CAN(CDC_DVD_RAM))
-			return -EROFS;
+//		if ((fp->f_mode & FMODE_WRITE) && !CDROM_CAN(CDC_DVD_RAM))
+//			return -EROFS;
 
 		ret = open_for_data(cdi);
 	}
diff -ur linux-2.6.0-test6/drivers/scsi/sr.c linux/drivers/scsi/sr.c
--- linux-2.6.0-test6/drivers/scsi/sr.c	2003-09-27 18:50:13.000000000 -0600
+++ linux/drivers/scsi/sr.c	2003-10-06 11:51:59.655832000 -0600
@@ -327,8 +327,8 @@
 	}
 
 	if (rq_data_dir(SCpnt->request) == WRITE) {
-		if (!cd->device->writeable)
-			return 0;
+//		if (!cd->device->writeable)
+//			return 0;
 		SCpnt->cmnd[0] = WRITE_10;
 		SCpnt->sc_data_direction = SCSI_DATA_WRITE;
 	} else if (rq_data_dir(SCpnt->request) == READ) {

Re: writable mmc profiles actually are writable

[Jens Axboe]

On Mon, Oct 06 2003, Pat LaVarre wrote:
> > Newsgroups: mlist.linux.scsi
> > Date: 2003-09-10 16:00:27 PST
> > Subject: Re: [PATCH] mount -w of dvd+rw etc. in vanilla 2.6
> > From: Patrick Mansfield (patmans@us.ibm.com)
> >
> > Should sd.c and sr.c be calling set_device_ro?
> > (after adding a read only block device, or
> > changing back to read/write)?
> 
> That good question stands open, I think.
> 
> The following inline plain text, now revved for -test6 & posted here,
> allows modprobe to overcome such uncooperative attitudes as:
> 
> $ sudo dd if=/dev/scd2 bs=2k count=1 | wc
> 1+0 records in
> 1+0 records out
>       0       0    2048
> $
> $ sudo dd of=/dev/scd2 bs=2k count=1 if=/dev/zero
> dd: opening `/dev/scd2': Read-only file system
> $
> 
> Allowing dd, mkudffs, etc. are the good consequences.  The evil
> consequences I do not yet know.  I do notice we have achieved
> writability without extending the enumeration that `cat
> /proc/sys/dev/cdrom/info` dumps:
> 
> Can write CD-R:         0
> Can write CD-RW:        0
> Can read DVD:           0
> Can write DVD-R:        0
> Can write DVD-RAM:      0

And the device isn't writable, so...?

> diff -ur linux-2.6.0-test6/drivers/cdrom/cdrom.c linux/drivers/cdrom/cdrom.c
> --- linux-2.6.0-test6/drivers/cdrom/cdrom.c	2003-09-27 18:50:10.000000000 -0600
> +++ linux/drivers/cdrom/cdrom.c	2003-10-06 11:53:41.826299728 -0600
> @@ -426,8 +426,8 @@
>  	if ((fp->f_flags & O_NONBLOCK) && (cdi->options & CDO_USE_FFLAGS))
>  		ret = cdi->ops->open(cdi, 1);
>  	else {
> -		if ((fp->f_mode & FMODE_WRITE) && !CDROM_CAN(CDC_DVD_RAM))
> -			return -EROFS;
> +//		if ((fp->f_mode & FMODE_WRITE) && !CDROM_CAN(CDC_DVD_RAM))
> +//			return -EROFS;
>  
>  		ret = open_for_data(cdi);
>  	}
> diff -ur linux-2.6.0-test6/drivers/scsi/sr.c linux/drivers/scsi/sr.c
> --- linux-2.6.0-test6/drivers/scsi/sr.c	2003-09-27 18:50:13.000000000 -0600
> +++ linux/drivers/scsi/sr.c	2003-10-06 11:51:59.655832000 -0600
> @@ -327,8 +327,8 @@
>  	}
>  
>  	if (rq_data_dir(SCpnt->request) == WRITE) {
> -		if (!cd->device->writeable)
> -			return 0;
> +//		if (!cd->device->writeable)
> +//			return 0;
>  		SCpnt->cmnd[0] = WRITE_10;
>  		SCpnt->sc_data_direction = SCSI_DATA_WRITE;
>  	} else if (rq_data_dir(SCpnt->request) == READ) {

This is obviously wrong. What are you trying to do? The uniform layer
uses CDC_DVD_RAM as meaning randomly writable media, the only thing the
kernel supports out of the box. So that is what the test is for.

Honestly, I have no idea what your are trying to pull. Calling read-only
media failing to be opened read-write as "uncooperative" is confusing,
borderline amusing :). Explain yourself in clear text, thanks.

-- 
Jens Axboe

Re: writable mmc profiles actually are writable

[Jens Axboe]

On Mon, Oct 06 2003, Jens Axboe wrote:
> Honestly, I have no idea what your are trying to pull. Calling read-only
> media failing to be opened read-write as "uncooperative" is confusing,
> borderline amusing :). Explain yourself in clear text, thanks.

Ok, first clue: don't start a new post by replying to your old message,
it screws threading of decent mailers. I didn't see your subject because
of that, for instance.

Second, assuming the subject and body of the email are connected (no
clear clues there), I'm assuming this has to do with misdetected
hardware? If yes, then you should probably be fixing that instead.

-- 
Jens Axboe

Re: writable mmc profiles actually are writable

[Pat LaVarre]

> assuming this has to do with misdetected hardware?

Seemingly so, aye.

> hardware?

I'm plugging in a pre-production sample of a new device.

Seemingly I cannot mkudffs its disks except by patching the kernel.

That's normal for yet another new kind of dvd/cd, yes?

Via sg I see 35 GB of 64 KiB/block writes, 2 KiB/block reads, with
writable profile x0002 removable_disk of the 1999 mmc 2 standard.  Yes
pdt x05 dvd/cd, yes feature x0020 random_writable, no not the cd_r,
cd_rw, dvd, dvd_r, and dvd_ram enumerated in the obsolete legacy 1997
mmc 1 mode page x2A Capabilities.

Previously near here we discussed some as-yet-ineffective alternatives
to my patch: the Andy Polyakov patch for mount -w of dvd+rw, the Jens
Axboe patch for mount -w of cd-rw, and blockdev --setrw.

> The uniform layer uses CDC_DVD_RAM as meaning
> randomly writable media,

When I try setting CDC_DVD_RAM for a device, I see
/proc/sys/dev/cdrom/info erroneously reports:

Can write DVD-RAM:      1

I conclude we wish to express the discovery of feature x0020
random_writable differently.  Wrong?

In weak confirmation, earlier I did see the usb-storage folk reject a
patch to tweak mode page x2A to appear to have mode page x2A byte 3 mask
x20 dvd_ram_write set.  Should I submit a patch like that for sr_mod.ko
and ide-cd.ko?

> Calling read-only media failing to be opened
> read-write as "uncooperative" is confusing,

Clear now?  I mean to say, sg_dd shows the real disk of the real device
is randomly rewritable.  But cdrom.ko and sr_mod.ko refuse to pass
writes thru.

> screws threading of decent mailers

Sorry.  I'm pleased to mention people have kindly volunteered offline to
help me avoid repeating that.

Pat LaVarre

Re: writable mmc profiles actually are writable

[Jens Axboe]

On Mon, Oct 06 2003, Pat LaVarre wrote:
> > assuming this has to do with misdetected hardware?
> 
> Seemingly so, aye.
> 
> > hardware?
> 
> I'm plugging in a pre-production sample of a new device.
> 
> Seemingly I cannot mkudffs its disks except by patching the kernel.
> 
> That's normal for yet another new kind of dvd/cd, yes?

Completely.

> Via sg I see 35 GB of 64 KiB/block writes, 2 KiB/block reads, with
> writable profile x0002 removable_disk of the 1999 mmc 2 standard.  Yes
> pdt x05 dvd/cd, yes feature x0020 random_writable, no not the cd_r,
> cd_rw, dvd, dvd_r, and dvd_ram enumerated in the obsolete legacy 1997
> mmc 1 mode page x2A Capabilities.
> 
> Previously near here we discussed some as-yet-ineffective alternatives
> to my patch: the Andy Polyakov patch for mount -w of dvd+rw, the Jens
> Axboe patch for mount -w of cd-rw, and blockdev --setrw.

blockdev --setrw is the same bypass again. dvd+rw patch and cd-rw patch
are two different beasts. The latter should probably be allowed to die
given the hideousness of that hardware, I haven't even looked at the
dvd+rw patch to pass any judgement on that (but I presume dvd+rw design
is saner and doesn't include software supported read-modify-write cycles
and defect management).

> > The uniform layer uses CDC_DVD_RAM as meaning
> > randomly writable media,
> 
> When I try setting CDC_DVD_RAM for a device, I see
> /proc/sys/dev/cdrom/info erroneously reports:
> 
> Can write DVD-RAM:      1
> 
> I conclude we wish to express the discovery of feature x0020
> random_writable differently.  Wrong?

Correct.

> In weak confirmation, earlier I did see the usb-storage folk reject a
> patch to tweak mode page x2A to appear to have mode page x2A byte 3 mask
> x20 dvd_ram_write set.  Should I submit a patch like that for sr_mod.ko
> and ide-cd.ko?

I'd propose just adding better detection of new devices, and adding a
specific "randomly writable" flag instead of abusing CDC_DVD_RAM.

> > Calling read-only media failing to be opened
> > read-write as "uncooperative" is confusing,
> 
> Clear now?  I mean to say, sg_dd shows the real disk of the real device
> is randomly rewritable.  But cdrom.ko and sr_mod.ko refuse to pass
> writes thru.

Well yes, now that you explain what the issue actually is rather than
show up with an obscure "patch" :)

-- 
Jens Axboe

Re: writable mmc profiles actually are writable

[Pat LaVarre]

> patches to make the detection more modern ...

Below appears a copy of an old patch to try op x46 get_configuration any
time mode page x2a doesn't already say the pdt x05 dvd/cd device is
writable.

> I'd propose just adding better detection of
> new devices, and adding a specific "randomly
> writable" flag instead of abusing CDC_DVD_RAM.

Ah, did that, see below.  With this remark to motivate me, I will rev
this -test5 patch to fit with -test6 and then repost.

> I haven't yet had to deal with dvd+rw or
> ddcd_rw (is this like mtr?

Sorry I do not know mtr.

> mo and dvd-ram have been supported for a long
> time and should be set with CDC_DVD_RAM,

Sorry I do not understand.  I remember noticing CDC_MO_DRIVE appears
only drivers/ide/ not in drivers/scsi/.  Weakly I conclude mo doesn't
work the same in atapi and usb-storage.

> the disk profiles aren't driven by ide-cd or
> sr.

Sorry I do not understand.

In drivers/scsi/sr.c I find:
cd->cdi.mask |= CDC_DVD_RAM;

In drivers/ide/ide-cd.c I find:
devinfo->mask |= CDC_DVD_RAM;

I conclude sr and ide-cd tell cdrom whether the device "profile" is
writable or not.  Is that wrong?

> you should have done

Thanks again for finding the time to clue me in.

Pat LaVarre

diff -Nur linux-2.6.0-test5/include/scsi/scsi.h linux/include/scsi/scsi.h
diff -Nur linux-2.6.0-test5/include/linux/cdrom.h linux/include/linux/cdrom.h
diff -Nur linux-2.6.0-test5/drivers/cdrom/cdrom.c linux/drivers/cdrom/cdrom.c
diff -Nur linux-2.6.0-test5/drivers/scsi/sr.c linux/drivers/scsi/sr.c
--- linux-2.6.0-test5/include/scsi/scsi.h	2003-09-08 13:50:41.000000000 -0600
+++ linux/include/scsi/scsi.h	2003-09-10 17:05:37.000000000 -0600
@@ -81,6 +81,7 @@
 #define CHANGE_DEFINITION     0x40
 #define WRITE_SAME            0x41
 #define READ_TOC              0x43
+#define GET_CONFIGURATION     0x46
 #define LOG_SELECT            0x4c
 #define LOG_SENSE             0x4d
 #define MODE_SELECT_10        0x55
--- linux-2.6.0-test5/include/linux/cdrom.h	2003-09-08 13:49:51.000000000 -0600
+++ linux/include/linux/cdrom.h	2003-09-10 17:05:37.000000000 -0600
@@ -388,6 +388,7 @@
 #define CDC_DVD_R		0x10000	/* drive can write DVD-R */
 #define CDC_DVD_RAM		0x20000	/* drive can write DVD-RAM */
 #define CDC_MO_DRIVE		0x40000 /* drive is an MO device */
+#define CDC_MMC_RW		0x80000 /* drive is other mmc "writable" "profile" */
 
 /* drive status possibilities returned by CDROM_DRIVE_STATUS ioctl */
 #define CDS_NO_INFO		0	/* if not implemented */
--- linux-2.6.0-test5/drivers/cdrom/cdrom.c	2003-09-08 13:49:53.000000000 -0600
+++ linux/drivers/cdrom/cdrom.c	2003-09-10 17:05:37.000000000 -0600
@@ -426,7 +426,7 @@
 	if ((fp->f_flags & O_NONBLOCK) && (cdi->options & CDO_USE_FFLAGS))
 		ret = cdi->ops->open(cdi, 1);
 	else {
-		if ((fp->f_mode & FMODE_WRITE) && !CDROM_CAN(CDC_DVD_RAM))
+		if ((fp->f_mode & FMODE_WRITE) && !CDROM_CAN(CDC_DVD_RAM|CDC_MMC_RW))
 			return -EROFS;
 
 		ret = open_for_data(cdi);
@@ -2456,6 +2456,10 @@
 	for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi->next)
 	    pos += sprintf(info+pos, "\t%d", CDROM_CAN(CDC_DVD_RAM) != 0);
 
+	pos += sprintf(info+pos, "\nCan write other MMC-RW:");
+	for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi->next)
+	    pos += sprintf(info+pos, "\t%d", CDROM_CAN(CDC_MMC_RW) != 0);
+
 	strcpy(info+pos,"\n\n");
 		
         return proc_dostring(ctl, write, filp, buffer, lenp);
--- linux-2.6.0-test5/drivers/scsi/sr.c	2003-09-08 13:49:58.000000000 -0600
+++ linux/drivers/scsi/sr.c	2003-09-10 17:13:08.000000000 -0600
@@ -67,7 +67,8 @@
 	(CDC_CLOSE_TRAY|CDC_OPEN_TRAY|CDC_LOCK|CDC_SELECT_SPEED| \
 	 CDC_SELECT_DISC|CDC_MULTI_SESSION|CDC_MCN|CDC_MEDIA_CHANGED| \
 	 CDC_PLAY_AUDIO|CDC_RESET|CDC_IOCTLS|CDC_DRIVE_STATUS| \
-	 CDC_CD_R|CDC_CD_RW|CDC_DVD|CDC_DVD_R|CDC_DVD_RAM|CDC_GENERIC_PACKET)
+	 CDC_CD_R|CDC_CD_RW|CDC_DVD|CDC_DVD_R|CDC_DVD_RAM|CDC_GENERIC_PACKET| \
+	 CDC_MMC_RW)
 
 static int sr_probe(struct device *);
 static int sr_remove(struct device *);
@@ -92,6 +93,10 @@
 static void get_sectorsize(struct scsi_cd *);
 static void get_capabilities(struct scsi_cd *);
 
+static void get_configuration(struct scsi_cd *);
+static int scsi_get_configuration(struct scsi_device *sdev,
+	unsigned char *buffer, int len, int timeout, int retries);
+
 static int sr_media_change(struct cdrom_device_info *, int);
 static int sr_packet(struct cdrom_device_info *, struct cdrom_generic_command *);
 
@@ -755,6 +760,7 @@
 	rc = scsi_mode_sense(cd->device, 0, 0x2a, buffer, 128,
 			     SR_TIMEOUT, 3, &data);
 
+	cd->cdi.mask |= CDC_MMC_RW;
 	if (!scsi_status_is_good(rc)) {
 		/* failed, drive doesn't have capabilities mode page */
 		cd->cdi.speed = 1;
@@ -817,6 +823,83 @@
 
 	scsi_release_request(SRpnt);
 	kfree(buffer);
+
+	if (!cd->device->writeable) {
+		printk("%s: scsi3-mmc maybe not writeable\n",
+		       cd->cdi.name);
+		get_configuration(cd);
+	}
+}
+
+static void get_configuration(struct scsi_cd *cd)
+{
+	unsigned char *buffer;
+	int rc, mmc_profile;
+
+	buffer = kmalloc(512, GFP_KERNEL | GFP_DMA);
+	if (!buffer) {
+		printk(KERN_ERR "sr: out of memory.\n");
+		return;
+	}
+
+	rc = scsi_get_configuration(cd->device, buffer, 8,
+			     SR_TIMEOUT, 1);
+	if (!scsi_status_is_good(rc)) {
+		kfree(buffer);
+		return;
+	}
+
+	mmc_profile = ((buffer[6] << 8) + buffer[7]);
+	switch (mmc_profile) {
+	case 0x0001: /* Non-Removable Disk */
+	case 0x0002: /* Removable Disk */
+	case 0x0003: /* Magneto-Optical Erasable */
+	case 0x0005: /* AS-MO */
+	case 0x0012: /* DVD-RAM */
+	case 0x001A: /* DVD+RW */
+	case 0x0022: /* DDCD-RW */
+		printk("%s: scsi3-mmc writable profile: 0x%04x\n",
+		       cd->cdi.name, mmc_profile);
+		cd->device->writeable = 1;
+		if (mmc_profile != 0x001A) { /* != DVD+RW */
+			cd->cdi.mask &= ~CDC_MMC_RW;
+		}
+		break;
+	default:
+		break;
+	}
+
+	kfree(buffer);
+}
+
+/* intended to be block-copy-edit of scsi.lib.c scsi_mode_sense */
+static int
+scsi_get_configuration(struct scsi_device *sdev,
+		  unsigned char *buffer, int len, int timeout, int retries)
+{
+	struct scsi_request *sreq = scsi_allocate_request(sdev, GFP_KERNEL);
+	unsigned char cmd[MAX_COMMAND_SIZE];
+	int ret;
+
+	if (!sreq)
+		return -1;
+
+	memset(&cmd[0], 0, MAX_COMMAND_SIZE);
+	cmd[0] = GET_CONFIGURATION;
+	cmd[8] = len;
+
+	sreq->sr_cmd_len = 0;
+	sreq->sr_sense_buffer[0] = 0;
+	sreq->sr_sense_buffer[2] = 0;
+	sreq->sr_data_direction = DMA_FROM_DEVICE;
+
+	memset(buffer, 0, len);
+
+	scsi_wait_req(sreq, cmd, buffer, len, timeout, retries);
+
+	ret = sreq->sr_result;
+	scsi_release_request(sreq);
+	return ret;
 }
 
 /*

Re: writable mmc profiles actually are writable

[Pat LaVarre]

> diff -Nur linux-2.6.0-test5/include/scsi/scsi.h linux/include/scsi/scsi.h
> diff -Nur linux-2.6.0-test5/include/linux/cdrom.h linux/include/linux/cdrom.h
> diff -Nur linux-2.6.0-test5/drivers/cdrom/cdrom.c linux/drivers/cdrom/cdrom.c
> diff -Nur linux-2.6.0-test5/drivers/scsi/sr.c linux/drivers/scsi/sr.c

Trying that -test5 patch in -test6 I get:

patching file include/scsi/scsi.h
Hunk #1 succeeded at 74 (offset -7 lines).
patching file include/linux/cdrom.h
patching file drivers/cdrom/cdrom.c
Hunk #2 succeeded at 2465 (offset 9 lines).
patching file drivers/scsi/sr.c
Hunk #3 succeeded at 759 (offset -1 lines).

I will study this result and report back.

Pat LaVarre

Re: writable mmc profiles actually are writable

[Pat LaVarre]

Yep, still happy, same in -test6 as in -test5 e.g.

$ dmesg | grep ^sr
sr0: scsi3-mmc drive: 125x/125x caddy
sr0: scsi3-mmc maybe not writeable
sr0: scsi3-mmc writable profile: 0x0002
$
$ grep MMC /proc/sys/dev/cdrom/info
Can write other MMC-RW: 1 ...
$

Pat LaVarre

diff -ur linux-2.6.0-test6/include/scsi/scsi.h linux/include/scsi/scsi.h
--- linux-2.6.0-test6/include/scsi/scsi.h	2003-09-27 18:51:13.000000000 -0600
+++ linux/include/scsi/scsi.h	2003-10-06 16:11:52.000000000 -0600
@@ -74,6 +74,7 @@
 #define CHANGE_DEFINITION     0x40
 #define WRITE_SAME            0x41
 #define READ_TOC              0x43
+#define GET_CONFIGURATION     0x46
 #define LOG_SELECT            0x4c
 #define LOG_SENSE             0x4d
 #define MODE_SELECT_10        0x55
diff -ur linux-2.6.0-test6/include/linux/cdrom.h linux/include/linux/cdrom.h
--- linux-2.6.0-test6/include/linux/cdrom.h	2003-09-27 18:50:06.000000000 -0600
+++ linux/include/linux/cdrom.h	2003-10-06 16:11:52.000000000 -0600
@@ -388,6 +388,7 @@
 #define CDC_DVD_R		0x10000	/* drive can write DVD-R */
 #define CDC_DVD_RAM		0x20000	/* drive can write DVD-RAM */
 #define CDC_MO_DRIVE		0x40000 /* drive is an MO device */
+#define CDC_MMC_RW		0x80000 /* drive is other mmc "writable" "profile" */
 
 /* drive status possibilities returned by CDROM_DRIVE_STATUS ioctl */
 #define CDS_NO_INFO		0	/* if not implemented */
diff -ur linux-2.6.0-test6/drivers/cdrom/cdrom.c linux/drivers/cdrom/cdrom.c
--- linux-2.6.0-test6/drivers/cdrom/cdrom.c	2003-09-27 18:50:10.000000000 -0600
+++ linux/drivers/cdrom/cdrom.c	2003-10-06 17:50:21.934425152 -0600
@@ -426,7 +426,7 @@
 	if ((fp->f_flags & O_NONBLOCK) && (cdi->options & CDO_USE_FFLAGS))
 		ret = cdi->ops->open(cdi, 1);
 	else {
-		if ((fp->f_mode & FMODE_WRITE) && !CDROM_CAN(CDC_DVD_RAM))
+		if ((fp->f_mode & FMODE_WRITE) && !CDROM_CAN(CDC_DVD_RAM|CDC_MMC_RW))
 			return -EROFS;
 
 		ret = open_for_data(cdi);
@@ -2465,6 +2465,10 @@
 	for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi->next)
 	    pos += sprintf(info+pos, "\t%d", CDROM_CAN(CDC_DVD_RAM) != 0);
 
+	pos += sprintf(info+pos, "\nCan write other MMC-RW:");
+	for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi->next)
+	    pos += sprintf(info+pos, "\t%d", CDROM_CAN(CDC_MMC_RW) != 0);
+
 	strcpy(info+pos,"\n\n");
 		
         return proc_dostring(ctl, write, filp, buffer, lenp);
diff -ur linux-2.6.0-test6/drivers/scsi/sr.c linux/drivers/scsi/sr.c
--- linux-2.6.0-test6/drivers/scsi/sr.c	2003-09-27 18:50:13.000000000 -0600
+++ linux/drivers/scsi/sr.c	2003-10-06 17:50:15.781360560 -0600
@@ -67,7 +67,8 @@
 	(CDC_CLOSE_TRAY|CDC_OPEN_TRAY|CDC_LOCK|CDC_SELECT_SPEED| \
 	 CDC_SELECT_DISC|CDC_MULTI_SESSION|CDC_MCN|CDC_MEDIA_CHANGED| \
 	 CDC_PLAY_AUDIO|CDC_RESET|CDC_IOCTLS|CDC_DRIVE_STATUS| \
-	 CDC_CD_R|CDC_CD_RW|CDC_DVD|CDC_DVD_R|CDC_DVD_RAM|CDC_GENERIC_PACKET)
+	 CDC_CD_R|CDC_CD_RW|CDC_DVD|CDC_DVD_R|CDC_DVD_RAM|CDC_GENERIC_PACKET| \
+	 CDC_MMC_RW)
 
 static int sr_probe(struct device *);
 static int sr_remove(struct device *);
@@ -92,6 +93,10 @@
 static void get_sectorsize(struct scsi_cd *);
 static void get_capabilities(struct scsi_cd *);
 
+static void get_configuration(struct scsi_cd *);
+static int scsi_get_configuration(struct scsi_device *sdev,
+	unsigned char *buffer, int len, int timeout, int retries);
+
 static int sr_media_change(struct cdrom_device_info *, int);
 static int sr_packet(struct cdrom_device_info *, struct cdrom_generic_command *);
 
@@ -754,6 +759,7 @@
 	rc = scsi_mode_sense(cd->device, 0, 0x2a, buffer, 128,
 			     SR_TIMEOUT, 3, &data);
 
+	cd->cdi.mask |= CDC_MMC_RW;
 	if (!scsi_status_is_good(rc)) {
 		/* failed, drive doesn't have capabilities mode page */
 		cd->cdi.speed = 1;
@@ -816,6 +822,83 @@
 
 	scsi_release_request(SRpnt);
 	kfree(buffer);
+
+	if (!cd->device->writeable) {
+		printk("%s: scsi3-mmc maybe not writeable\n",
+		       cd->cdi.name);
+		get_configuration(cd);
+	}
+}
+
+static void get_configuration(struct scsi_cd *cd)
+{
+	unsigned char *buffer;
+	int rc, mmc_profile;
+
+	buffer = kmalloc(512, GFP_KERNEL | GFP_DMA);
+	if (!buffer) {
+		printk(KERN_ERR "sr: out of memory.\n");
+		return;
+	}
+
+	rc = scsi_get_configuration(cd->device, buffer, 8,
+			     SR_TIMEOUT, 1);
+	if (!scsi_status_is_good(rc)) {
+		kfree(buffer);
+		return;
+	}
+
+	mmc_profile = ((buffer[6] << 8) + buffer[7]);
+	switch (mmc_profile) {
+	case 0x0001: /* Non-Removable Disk */
+	case 0x0002: /* Removable Disk */
+	case 0x0003: /* Magneto-Optical Erasable */
+	case 0x0005: /* AS-MO */
+	case 0x0012: /* DVD-RAM */
+	case 0x001A: /* DVD+RW */
+	case 0x0022: /* DDCD-RW */
+		printk("%s: scsi3-mmc writable profile: 0x%04x\n",
+		       cd->cdi.name, mmc_profile);
+		cd->device->writeable = 1;
+		if (mmc_profile != 0x001A) { /* != DVD+RW */
+			cd->cdi.mask &= ~CDC_MMC_RW;
+		}
+		break;
+	default:
+		break;
+	}
+
+	kfree(buffer);
+}
+
+/* intended to be block-copy-edit of scsi_lib.c scsi_mode_sense */
+static int
+scsi_get_configuration(struct scsi_device *sdev,
+		  unsigned char *buffer, int len, int timeout, int retries)
+{
+	struct scsi_request *sreq = scsi_allocate_request(sdev, GFP_KERNEL);
+	unsigned char cmd[MAX_COMMAND_SIZE];
+	int ret;
+
+	if (!sreq)
+		return -1;
+
+	memset(&cmd[0], 0, MAX_COMMAND_SIZE);
+	cmd[0] = GET_CONFIGURATION;
+	cmd[8] = len;
+
+	sreq->sr_cmd_len = 0;
+	sreq->sr_sense_buffer[0] = 0;
+	sreq->sr_sense_buffer[2] = 0;
+	sreq->sr_data_direction = DMA_FROM_DEVICE;
+
+	memset(buffer, 0, len);
+
+	scsi_wait_req(sreq, cmd, buffer, len, timeout, retries);
+
+	ret = sreq->sr_result;
+	scsi_release_request(sreq);
+	return ret;
 }
 
 /*

Re: writable mmc profiles actually are writable

[Jens Axboe]

On Mon, Oct 06 2003, Pat LaVarre wrote:
> Yep, still happy, same in -test6 as in -test5 e.g.
> 
> $ dmesg | grep ^sr
> sr0: scsi3-mmc drive: 125x/125x caddy
> sr0: scsi3-mmc maybe not writeable
> sr0: scsi3-mmc writable profile: 0x0002
> $
> $ grep MMC /proc/sys/dev/cdrom/info
> Can write other MMC-RW: 1 ...

I don't quite agree with this patch. Please add the GET_CONFIGURATION
stuff to cdrom.c instead so it works with ide-cd as well (ide-scsi is
basically dead, and the number of scsi drives out there isn't exactly
big and increasing). GPCMD_GET_CONFIGURATION already exists. Also, make
DVD-RAM drives set CDC_MMC_RW as well and only check for that at open.

-- 
Jens Axboe

Re: writable mmc profiles actually are writable

[Matthew Dharm]

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

On Tue, Oct 07, 2003 at 07:38:58AM +0200, Jens Axboe wrote:
> On Mon, Oct 06 2003, Pat LaVarre wrote:
> > Yep, still happy, same in -test6 as in -test5 e.g.
> > 
> > $ dmesg | grep ^sr
> > sr0: scsi3-mmc drive: 125x/125x caddy
> > sr0: scsi3-mmc maybe not writeable
> > sr0: scsi3-mmc writable profile: 0x0002
> > $
> > $ grep MMC /proc/sys/dev/cdrom/info
> > Can write other MMC-RW: 1 ...
> 
> I don't quite agree with this patch. Please add the GET_CONFIGURATION
> stuff to cdrom.c instead so it works with ide-cd as well (ide-scsi is
> basically dead, and the number of scsi drives out there isn't exactly
> big and increasing). GPCMD_GET_CONFIGURATION already exists. Also, make
> DVD-RAM drives set CDC_MMC_RW as well and only check for that at open.

While the number of SCSI CD-ROM drives may be shrinking, the ATAPI drives
behind a USB/ATAPI bridge is skyrocketing.

Matt

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

Somebody call an exorcist!
					-- Dust Puppy
User Friendly, 5/16/1998

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

Re: writable mmc profiles actually are writable

[Jens Axboe]

On Mon, Oct 06 2003, Matthew Dharm wrote:
> On Tue, Oct 07, 2003 at 07:38:58AM +0200, Jens Axboe wrote:
> > On Mon, Oct 06 2003, Pat LaVarre wrote:
> > > Yep, still happy, same in -test6 as in -test5 e.g.
> > > 
> > > $ dmesg | grep ^sr
> > > sr0: scsi3-mmc drive: 125x/125x caddy
> > > sr0: scsi3-mmc maybe not writeable
> > > sr0: scsi3-mmc writable profile: 0x0002
> > > $
> > > $ grep MMC /proc/sys/dev/cdrom/info
> > > Can write other MMC-RW: 1 ...
> > 
> > I don't quite agree with this patch. Please add the GET_CONFIGURATION
> > stuff to cdrom.c instead so it works with ide-cd as well (ide-scsi is
> > basically dead, and the number of scsi drives out there isn't exactly
> > big and increasing). GPCMD_GET_CONFIGURATION already exists. Also, make
> > DVD-RAM drives set CDC_MMC_RW as well and only check for that at open.
> 
> While the number of SCSI CD-ROM drives may be shrinking, the ATAPI drives
> behind a USB/ATAPI bridge is skyrocketing.

Doesn't change the picture, if you put it in cdrom.c it will work for
both.

-- 
Jens Axboe

Re: writable mmc profiles actually are writable

[Matthew Dharm]

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

On Tue, Oct 07, 2003 at 08:48:29AM +0200, Jens Axboe wrote:
> On Mon, Oct 06 2003, Matthew Dharm wrote:
> > On Tue, Oct 07, 2003 at 07:38:58AM +0200, Jens Axboe wrote:
> > > On Mon, Oct 06 2003, Pat LaVarre wrote:
> > > > Yep, still happy, same in -test6 as in -test5 e.g.
> > > > 
> > > > $ dmesg | grep ^sr
> > > > sr0: scsi3-mmc drive: 125x/125x caddy
> > > > sr0: scsi3-mmc maybe not writeable
> > > > sr0: scsi3-mmc writable profile: 0x0002
> > > > $
> > > > $ grep MMC /proc/sys/dev/cdrom/info
> > > > Can write other MMC-RW: 1 ...
> > > 
> > > I don't quite agree with this patch. Please add the GET_CONFIGURATION
> > > stuff to cdrom.c instead so it works with ide-cd as well (ide-scsi is
> > > basically dead, and the number of scsi drives out there isn't exactly
> > > big and increasing). GPCMD_GET_CONFIGURATION already exists. Also, make
> > > DVD-RAM drives set CDC_MMC_RW as well and only check for that at open.
> > 
> > While the number of SCSI CD-ROM drives may be shrinking, the ATAPI drives
> > behind a USB/ATAPI bridge is skyrocketing.
> 
> Doesn't change the picture, if you put it in cdrom.c it will work for
> both.

It will?  I'll have to take your word for that, as I don't immediately see
how that works... then again, much of the higher layers of SCSI are a
mystery to me.

I think I see how this work.... sr.c registers with cdrom.c, and cdrom.c
actually provides the interface to the /dev/scdN node, right?

If that's the case, why is there so much code in sr.c anyway?  The
get_capabilities() function really should be moved, as well as media-change
detection, much of the probe function (dealing with initialization of the
new structre), reading sector sizes, and sr_ioctl.c should probably be
renamed (as it doesn't really do IOCTL processing).

Am I on the right track?  That seems like an awfully long list of things
that suggest against my interpretation....

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: writable mmc profiles actually are writable

[Jens Axboe]

On Tue, Oct 07 2003, Matthew Dharm wrote:
> On Tue, Oct 07, 2003 at 08:48:29AM +0200, Jens Axboe wrote:
> > On Mon, Oct 06 2003, Matthew Dharm wrote:
> > > On Tue, Oct 07, 2003 at 07:38:58AM +0200, Jens Axboe wrote:
> > > > On Mon, Oct 06 2003, Pat LaVarre wrote:
> > > > > Yep, still happy, same in -test6 as in -test5 e.g.
> > > > > 
> > > > > $ dmesg | grep ^sr
> > > > > sr0: scsi3-mmc drive: 125x/125x caddy
> > > > > sr0: scsi3-mmc maybe not writeable
> > > > > sr0: scsi3-mmc writable profile: 0x0002
> > > > > $
> > > > > $ grep MMC /proc/sys/dev/cdrom/info
> > > > > Can write other MMC-RW: 1 ...
> > > > 
> > > > I don't quite agree with this patch. Please add the GET_CONFIGURATION
> > > > stuff to cdrom.c instead so it works with ide-cd as well (ide-scsi is
> > > > basically dead, and the number of scsi drives out there isn't exactly
> > > > big and increasing). GPCMD_GET_CONFIGURATION already exists. Also, make
> > > > DVD-RAM drives set CDC_MMC_RW as well and only check for that at open.
> > > 
> > > While the number of SCSI CD-ROM drives may be shrinking, the ATAPI drives
> > > behind a USB/ATAPI bridge is skyrocketing.
> > 
> > Doesn't change the picture, if you put it in cdrom.c it will work for
> > both.
> 
> It will?  I'll have to take your word for that, as I don't immediately see
> how that works... then again, much of the higher layers of SCSI are a
> mystery to me.
> 
> I think I see how this work.... sr.c registers with cdrom.c, and cdrom.c
> actually provides the interface to the /dev/scdN node, right?

Precisely.

> If that's the case, why is there so much code in sr.c anyway?  The
> get_capabilities() function really should be moved, as well as media-change
> detection, much of the probe function (dealing with initialization of the
> new structre), reading sector sizes, and sr_ioctl.c should probably be
> renamed (as it doesn't really do IOCTL processing).
> 
> Am I on the right track?  That seems like an awfully long list of things
> that suggest against my interpretation....

Yes you are essentially correct. Some things have been killed from sr a
long time ago, but I generally resist adding new things to sr and ide-cd
unless I really have to. And I've been doing so since 2.2, so I really
don't want to reverse that right now.

It's also confusing why then some things only work if you have ide-cd
loaded, or if you use ide-scsi and sr. It's just a bad idea.

-- 
Jens Axboe

Re: writable mmc profiles actually are writable

[Pat LaVarre]

> From: Jens Axboe ...
> Please add the GET_CONFIGURATION stuff to cdrom.c
> instead so it works with ide-cd as well ...

Help!  I do not know Where to add this code.

Tell me again where is the one place I can patch to add discovery of
more capability in both sr and ide-cd devices?

Closer study now again seemingly tells me that ide-cd and sr
independently work to try the op x5A Mode Sense of page x2A Capabilities
and not op x46 Get Configuration.

On this point do we agree?

drivers/ide/ide.cd ide_cdrom_get_capabilities speaks thru
drivers/cdrom/cdrom.c cdrom_mode_sense, aye.

drivers/scsi/sr.c get_capabilities speaks instead thru
drivers/scsi/scsi_lib.c scsi_mode_sense.

printk tells me with a usb-storage.ko drive I get as far as 'dd: opening
`/dev/scd0': Read-only file system' without cdrom.c cdrom_mode_sense
ever being called.  With an ide-cd.ko driver, I do see cdrom_mode_sense
called.  The ide-cd command is -x 5A 00 2A:00:00:00 00 00:18 00 -i x18,
rather than the less polite -x 5A 00 2A:00:00:00 00 00:80 00 -i x80 of
sr.

Does a place exist in drivers/cdrom where I can insert code to run after
ide-cd and sr finish their op x5A Mode Sense?

Have I misunderstood your request?  Did you actually mean to tell me to
go so far as to move the op x5A Mode Sense out of ide-cd and out of sr
and into cdrom?  If indeed I should move those out, to where should I
move them?

> The ->generic_packet() hook and
> cdrom_generic_command was invented to solve
> this code duplication.

Found, thank you:

I see cdrom.c cdrom_mode_sense speaks thru cdo->generic_packet.

I see include/linux/cdrom.h defines a struct cdrom_generic_command that
field-for-field matches other simplifications of scsi/sg.h sg_io_hdr
that appear on the web, such as my own plscsi and gccscsi.

> [op x46] GPCMD_GET_CONFIGURATION already exists.

Found, thank you.

Also op x5A GPCMD_MODE_SENSE_10 and page x2A GPMODE_CAPABILITIES_PAGE in
ide-cd.

Also op x5A MODE_SENSE_10 and anonymous x2a in sr.

> make DVD-RAM drives set CDC_MMC_RW as well
> and only check for that at open.

This part I still think I understand how to do.

> why then some things only work if you have ide-cd
> loaded, or if you use ide-scsi and sr ... a bad idea.

Aye.

Pat LaVarre

Re: writable mmc profiles actually are writable

[Pat LaVarre]

> > Help!  I do not know Where to add this code.

Just now I weakly concluded somewhere I need to add:

op x46 GPCMD_GET_CONFIGURATION
op x5A GPCMD_MODE_SENSE_10 of page x2A GPMODE_CAPABILITIES_PAGE

To let me proceed to write source without yet knowing where to insert
it, I will insert it to a known wrong place that mostly works.

Specifically, I will add code to drivers/cdrom/cdrom.c cdrom_open, to
try to clear the CDROM_CAN(CDC_MMC_WR) incapability only after some
tries cdrom_open with (fp->f_mode & FMODE_WRITE).

I believe this won't actually work.  I believe this will teach only
cdrom.ko to pass thru the writes, but then sr_mod.ko will still refuse
them.  But I will now go prove or disprove that theory.

Pat LaVarre

Re: writable mmc profiles actually are writable

[Pat LaVarre]

Ouch.

make reminds me cdi->ops->capability is a "read-only-member".

I interpret that gcc warning to mean we intend to write the ->capability
when we allot it, and never again thereafter.

I'm therefore now guessing the patch we want is:

We add a ->capability of CDC_MMC_WR to both ide-cd and sr.  We teach
both of those lower level drivers to ->mask this capability by default,
but sometime thereafter we have cdrom author a few cdb's to decide to
unmask that capability for any device with one of the seven standard mmc
profiles that by definition imply feature x0020 random-writable.

Pat LaVarre

Re: writable mmc profiles actually are writable

[Pat LaVarre]

May our review recommence!

The patch here changes four source files.

Please tell me if I have or I have not correctly patched as many as
three of the four source files:

include/linux/cdrom.h
drivers/ide/ide-cd.c
drivers/scsi/sr.c

I'm confident I have not correctly patched the source file:

drivers/cdrom/cdrom.c

I plead for review by eye of this patch, but I do Not recommend applying
this patch.  As yet this patch erroneously makes all /dev/scd*
writeable, just like the four-line patch that began this thread.

Pat LaVarre

diff -Nur linux-2.6.0-test7/include/linux/cdrom.h linux/include/linux/cdrom.h
--- linux-2.6.0-test7/include/linux/cdrom.h	2003-10-08 13:24:00.000000000 -0600
+++ linux/include/linux/cdrom.h	2003-10-10 15:37:16.000000000 -0600
@@ -388,6 +388,7 @@
 #define CDC_DVD_R		0x10000	/* drive can write DVD-R */
 #define CDC_DVD_RAM		0x20000	/* drive can write DVD-RAM */
 #define CDC_MO_DRIVE		0x40000 /* drive is an MO device */
+#define CDC_MMC_WR		0x80000	/* profile includes random write */
 
 /* drive status possibilities returned by CDROM_DRIVE_STATUS ioctl */
 #define CDS_NO_INFO		0	/* if not implemented */
diff -Nur linux-2.6.0-test7/drivers/ide/ide-cd.c linux/drivers/ide/ide-cd.c
--- linux-2.6.0-test7/drivers/ide/ide-cd.c	2003-10-08 13:24:04.000000000 -0600
+++ linux/drivers/ide/ide-cd.c	2003-10-10 15:36:33.000000000 -0600
@@ -2822,7 +2822,7 @@
 				CDC_MEDIA_CHANGED | CDC_PLAY_AUDIO | CDC_RESET |
 				CDC_IOCTLS | CDC_DRIVE_STATUS | CDC_CD_R |
 				CDC_CD_RW | CDC_DVD | CDC_DVD_R| CDC_DVD_RAM |
-				CDC_GENERIC_PACKET | CDC_MO_DRIVE,
+				CDC_GENERIC_PACKET | CDC_MO_DRIVE | CDC_MMC_WR,
 	.generic_packet		= ide_cdrom_packet,
 };
 
@@ -2832,7 +2832,7 @@
 	struct cdrom_device_info *devinfo = &info->devinfo;
 
 	devinfo->ops = &ide_cdrom_dops;
-	devinfo->mask = 0;
+	devinfo->mask = CDC_MMC_WR;
 	devinfo->speed = CDROM_STATE_FLAGS(drive)->current_speed;
 	devinfo->capacity = nslots;
 	devinfo->handle = (void *) drive;
diff -Nur linux-2.6.0-test7/drivers/scsi/sr.c linux/drivers/scsi/sr.c
--- linux-2.6.0-test7/drivers/scsi/sr.c	2003-10-08 13:24:03.000000000 -0600
+++ linux/drivers/scsi/sr.c	2003-10-10 15:48:12.322686720 -0600
@@ -67,7 +67,8 @@
 	(CDC_CLOSE_TRAY|CDC_OPEN_TRAY|CDC_LOCK|CDC_SELECT_SPEED| \
 	 CDC_SELECT_DISC|CDC_MULTI_SESSION|CDC_MCN|CDC_MEDIA_CHANGED| \
 	 CDC_PLAY_AUDIO|CDC_RESET|CDC_IOCTLS|CDC_DRIVE_STATUS| \
-	 CDC_CD_R|CDC_CD_RW|CDC_DVD|CDC_DVD_R|CDC_DVD_RAM|CDC_GENERIC_PACKET)
+	 CDC_CD_R|CDC_CD_RW|CDC_DVD|CDC_DVD_R|CDC_DVD_RAM|CDC_GENERIC_PACKET| \
+	 CDC_MMC_WR)
 
 static int sr_probe(struct device *);
 static int sr_remove(struct device *);
@@ -327,8 +328,12 @@
 	}
 
 	if (rq_data_dir(SCpnt->request) == WRITE) {
-		if (!cd->device->writeable)
-			return 0;
+		if (!cd->device->writeable) {
+			if ((cd->cdi.mask & CDC_MMC_WR) != 0) {
+				return 0;
+			}
+			cd->device->writeable = 1;
+		}
 		SCpnt->cmnd[0] = WRITE_10;
 		SCpnt->sc_data_direction = SCSI_DATA_WRITE;
 	} else if (rq_data_dir(SCpnt->request) == READ) {
@@ -550,7 +555,7 @@
 
 	cd->cdi.ops = &sr_dops;
 	cd->cdi.handle = cd;
-	cd->cdi.mask = 0;
+	cd->cdi.mask = CDC_MMC_WR;
 	cd->cdi.capacity = 1;
 	sprintf(cd->cdi.name, "sr%d", minor);
 
diff -Nur linux-2.6.0-test7/drivers/cdrom/cdrom.c linux/drivers/cdrom/cdrom.c
--- linux-2.6.0-test7/drivers/cdrom/cdrom.c	2003-10-08 13:24:02.000000000 -0600
+++ linux/drivers/cdrom/cdrom.c	2003-10-10 15:45:59.648856208 -0600
@@ -408,6 +408,24 @@
 	return 0;
 }
 
+/* Say if profile includes random write or not.
+ */
+static int cdrom_cdc_mmc_wr(struct cdrom_device_info *cdi)
+{
+	printk(KERN_INFO "cdrom_cdc_mmc_wr\n");
+	if (CDROM_CAN(CDC_DVD_RAM)) {
+		return 1;
+	}
+#if 0 /* FIXME */
+#error "try op x5A GPCMD_MODE_SENSE_10 of page x2A GPMODE_CAPABILITIES_PAGE"
+#error "return 0 if failed"
+#error "try op x46 GPGPCMD_GET_CONFIGURATION"
+#error "return 0 if failed"
+#error "return 0 if not random writable profile"
+#endif
+	return 1;
+}
+
 /* We use the open-option O_NONBLOCK to indicate that the
  * purpose of opening is only for subsequent ioctl() calls; no device
  * integrity checks are performed.
@@ -426,8 +444,12 @@
 	if ((fp->f_flags & O_NONBLOCK) && (cdi->options & CDO_USE_FFLAGS))
 		ret = cdi->ops->open(cdi, 1);
 	else {
-		if ((fp->f_mode & FMODE_WRITE) && !CDROM_CAN(CDC_DVD_RAM))
-			return -EROFS;
+		if ((fp->f_mode & FMODE_WRITE) && !CDROM_CAN(CDC_MMC_WR)) {
+			if (!cdrom_cdc_mmc_wr(cdi)) {
+				return -EROFS;
+			}
+			cdi->mask &= ~CDC_MMC_WR;
+		}
 
 		ret = open_for_data(cdi);
 	}
@@ -2406,6 +2428,10 @@
 	for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi->next)
 	    pos += sprintf(info+pos, "\t%d", CDROM_CAN(CDC_DVD_RAM) != 0);
 
+	pos += sprintf(info+pos, "\nTolerates random write:");
+	for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi->next)
+	    pos += sprintf(info+pos, "\t%d", CDROM_CAN(CDC_MMC_WR) != 0);
+
 	strcpy(info+pos,"\n\n");
 		
         return proc_dostring(ctl, write, filp, buffer, lenp);

Re: writable mmc profiles actually are writable

[Pat LaVarre]

I have a new guess of precisely when we want cdrom to probe for
capabilities beyond those discovered by ide-cd and sr.

I'm now guessing we want to author additional cdb's at the end of
register_cdrom, just after such optional messages as 'cdrom: drive
"/dev/sr0" registered'.

To leap to that conclusion, I reasoned as follows.  Somebody tell me how
wrong I am?

Pat LaVarre

1)

I found cdrom.c ERRLOGMASK.  I see our default is to pass thru just the
CD_WARNING cdrom: messages.  I see the last commented-out #define means
pass thru all the defined types of cdrom: messages.

2)

I see with usb cdb's unmasked, hot plug spews the dmesg:

Initializing USB Mass Storage driver...
scsi0 : SCSI emulation for USB Mass Storage devices
x 12 00 00 00 24 00
x 12 00 00 00 C0 00
  Vendor: Iomega    Model: RRD               Rev: 36.D
  Type:   CD-ROM                             ANSI SCSI revision: 02
WARNING: USB Mass Storage data integrity not assured
USB Mass Storage device found at 2
drivers/usb/core/usb.c: registered new driver usb-storage
USB Mass Storage support registered.
updfstab: numerical sysctl 1 23 is obsolete.

3)

I see with cdrom messages also unmasked, the one block write `sudo dd
of=/dev/scd0 bs=2K count=1 if=/dev/zero` provokes the spew:

x 00 00 00 00 00 00
x 03 00 00 00 12 00
x 00 00 00 00 00 00
x 5A 00 2A 00 00 00 00 00 80 00
sr0: scsi3-mmc drive: 125x/125x caddy
cdrom: entering register_cdrom
Uniform CD-ROM driver Revision: 3.12
cdrom: drive "/dev/sr0" registered
Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
cdrom: entering cdrom_open
cdrom_cdc_mmc_wr
cdrom: entering open_for_data
x 00 00 00 00 00 00
cdrom: drive_status=4
cdrom: entering cdrom_count_tracks
x 43 00 00 00 00 00 00 00 0C 00
x 43 02 00 00 00 00 01 00 0C 00
cdrom: track 1: format=2, ctrl=4
cdrom: disc has 1 tracks: 0=audio 1=data 0=Cd-I 0=XA
cdrom: all seems well, opening the device.
x 25 00 00 00 00 00 00 00 00 00
cdrom: opening the device gave me 0.
x 1E 00 00 00 01 00
cdrom: door locked.
cdrom: device opened successfully.
cdrom: Use count for "/dev/sr0" now 1
x 00 00 00 00 00 00
x 43 00 00 00 00 00 00 00 0C 40
x 43 00 00 00 00 00 00 00 0C 00
x 43 00 00 00 00 00 01 00 0C 00
x 28 00 00 00 00 00 00 00 02 00
x 2A 00 00 00 00 00 00 00 02 00
cdrom: entering cdrom_release
cdrom: Use count for "/dev/sr0" now zero
cdrom: Unlocking door!
x 1E 00 00 00 00 00

Re: writable mmc profiles actually are writable

[Pat LaVarre]

I have begun again with the new patch you saw me almost finish
developing here.

List: linux-scsi
Subject: [PATCH] CDC_MMC_WR
http://marc.theaimsgroup.com/?l=linux-scsi&m=106583271114657

Pat LaVarre

Re: writable mmc profiles actually are writable

[Pat LaVarre]

> From: Jens Axboe ...

Thanks again for your immediate & careful review.

> so it works with ide-cd as well

I do have both usb & atapi sample drives to test, I haven't yet tried
atapi.

> Please add ...
> to cdrom.c instead ... GPCMD_GET_CONFIGURATION

Happily will do.  I'll continue to reply as I progress or not.

Before now, I did not know I could find any one place in the kernel
source to tweak CDC decisions.  To my confused newbie eye, ide-cd.c and
sr.c appeared coded independently to fetch mode page x2A Capabilities
and neglect op x46 Get Configuration in slightly different ways.  I
erroneously had planned to develop an ide-cd.c patch after the sr.c
patch.

> Also, make DVD-RAM drives set CDC_MMC_RW ...

Will do.

> ...

Already I have one reaction to share ...

I'm now vague on how we want /proc/sys/dev/cdrom/info to change?

I see:

In -test6 for dvd_ram we have:

Can write CD-R:         0
Can write CD-RW:        0
Can read DVD:           0
Can write DVD-R:        0
Can write DVD-RAM:      1

I ask:

What do we want the new CDC_MMC_RW line to look like?

Should our new line be a CDC_MMC_RW &~ CDC_DVD_RAM line?  That would
give us the same appearance as the last patch I posted i.e. commonly
different devices would provoke only the two exclusive combinations: 

Can write DVD-RAM:      1
Can write other MMC-RW: 0

Can write DVD-RAM:      0
Can write other MMC-RW: 1

Or should our new line look very different, and appear explicitly set
for any CDC_MMC_RW, perhaps:

Tolerates random write: 1

Or do we prefer some other alternative?

Pat LaVarre

Re: writable mmc profiles actually are writable

[Jens Axboe]

On Tue, Oct 07 2003, Pat LaVarre wrote:
> > Please add ...
> > to cdrom.c instead ... GPCMD_GET_CONFIGURATION
> 
> Happily will do.  I'll continue to reply as I progress or not.

Great, thanks.

> Before now, I did not know I could find any one place in the kernel
> source to tweak CDC decisions.  To my confused newbie eye, ide-cd.c and
> sr.c appeared coded independently to fetch mode page x2A Capabilities
> and neglect op x46 Get Configuration in slightly different ways.  I
> erroneously had planned to develop an ide-cd.c patch after the sr.c
> patch.

You'd end up adding about the same code in both places. The
->generic_packet() hook and cdrom_generic_command was invented to solve
this code duplication. So in cdrom.c you just setup the cgc as needed,
and pass it down to ide-cd or sr. See cdrom_mode_sense() for one of the
many examples.

> Already I have one reaction to share ...
> 
> I'm now vague on how we want /proc/sys/dev/cdrom/info to change?
> 
> I see:
> 
> In -test6 for dvd_ram we have:
> 
> Can write CD-R:         0
> Can write CD-RW:        0
> Can read DVD:           0
> Can write DVD-R:        0
> Can write DVD-RAM:      1
> 
> I ask:
> 
> What do we want the new CDC_MMC_RW line to look like?
> 
> Should our new line be a CDC_MMC_RW &~ CDC_DVD_RAM line?  That would

I think CDC_MMC_RW should be independent of that. The idea was to make
CDC_DVD_RAM really be the hardware type indication and not the pseudo
randomly writable flag that it is now.

> give us the same appearance as the last patch I posted i.e. commonly
> different devices would provoke only the two exclusive combinations: 
> 
> Can write DVD-RAM:      1
> Can write other MMC-RW: 0
> 
> Can write DVD-RAM:      0
> Can write other MMC-RW: 1
> 
> Or should our new line look very different, and appear explicitly set
> for any CDC_MMC_RW, perhaps:
> 
> Tolerates random write: 1
> 
> Or do we prefer some other alternative?

No that is what I had in mind as well, although I would probably have
worded it a bit differently :). But that's detail, please proceed, I
think you are on the right track.

-- 
Jens Axboe

Re: writable mmc profiles actually are writable

[Pat LaVarre]

> > Before now, I did not know I could find any
> > one place in the kernel source to tweak CDC
> > decisions.  To my confused newbie eye,
> > ide-cd.c and sr.c appeared coded
> > independently to fetch mode page x2A
> > Capabilities and neglect op x46 ...
>
> The ->generic_packet() hook and
> cdrom_generic_command was invented to solve
> this code duplication.

News to me, thanks.

> So in cdrom.c you just setup the cgc as
> needed, and pass it down to ide-cd or sr. See
> cdrom_mode_sense() for one of the many
> examples ...
> ...
> The idea ... make CDC_DVD_RAM really be the
> hardware type indication and not the pseudo
> randomly writable flag that it is now ...
> ...
> please proceed ...

Will do, now diff'ing against 2.6.0-test7.

> > > I haven't yet had to deal with dvd+rw or
> > > ddcd_rw (is this like mtr?
> > 
> > Sorry I do not know mtr.
> 
> mt rainier, different in spirit

Eh?  Different in spirit than what & how?

> mt rainier, different in spirit but allows the same 2kb
> writes and handles the rest in hardware.

Ah.  Yes some of the buzz re Mt Rainier has reached me before now.  But
I had not heard that writes work well unless actually aligned to more
like 64 KiB boundaries.  I had only heard that the hardware tolerated
misaligned writes, not that misaligned writes work well.

> > mo and dvd-ram have been supported for a long
> > > time and should be set with CDC_DVD_RAM,
> > 
> > ... CDC_MO_DRIVE appears only drivers/ide/ not in
> > drivers/scsi/.  Weakly I conclude mo doesn't
> > work the same in atapi and usb-storage.
> 
> IIRC, scsi mo drives are handled by sd, not sr.

Cluelessly I wonder.  I see if scsi mo works via scsi/sd.c, it works
without benefit of CDC_MO_DRIVE, which makes me wonder why drivers/ide
has a use for CDC_MO_DRIVE.  If I hear no reply, I will assume grep
CDC_MO_DRIVE drivers/ide/* would answer my question for me.  I have no
mo drive, so I do not find the question compelling.

> > > the disk profiles aren't driven by ide-cd or
> > > sr.
> > 
> > In drivers/scsi/sr.c I find: ...
> > In drivers/ide/ide-cd.c I find:
> > ...mask |= CDC_DVD_RAM;
> 
> ->mask is an inverted capability mask, so if you set
> CDC_DVD_RAM you mask that capability.

Ouch, that detail I actually did know already.

Sorry I was unclear.

I meant to say I find a default of & CDC_DVD_RAM == 0 and then the |= to
1 executed only conditionally e.g. sr.c:

        ... [fetch mode page x2A Capabilities] ...
        ...
        if ((buffer[n + 3] & 0x20) == 0) {
                /* can't write DVD-RAM media */
                cd->cdi.mask |= CDC_DVD_RAM;
        } else {
                cd->device->writeable = 1;
        }

In my newbie ignorance, that made me guess that sr_mod.ko, not cdrom.ko,
was deciding whether my usb-storage.ko drive was writable.

Pat LaVarre

Re: writable mmc profiles actually are writable

[Jens Axboe]

On Mon, Oct 06 2003, Pat LaVarre wrote:
> > patches to make the detection more modern ...
> 
> Below appears a copy of an old patch to try op x46 get_configuration any
> time mode page x2a doesn't already say the pdt x05 dvd/cd device is
> writable.

See my comments in another mail.

> > I haven't yet had to deal with dvd+rw or
> > ddcd_rw (is this like mtr?
> 
> Sorry I do not know mtr.

mt rainier, different in spirit but allows the same 2kb writes and
handles the rest in hardware.

> > mo and dvd-ram have been supported for a long
> > time and should be set with CDC_DVD_RAM,
> 
> Sorry I do not understand.  I remember noticing CDC_MO_DRIVE appears
> only drivers/ide/ not in drivers/scsi/.  Weakly I conclude mo doesn't
> work the same in atapi and usb-storage.

IIRC, scsi mo drives are handled by sd, not sr.

> > the disk profiles aren't driven by ide-cd or
> > sr.
> 
> Sorry I do not understand.
> 
> In drivers/scsi/sr.c I find:
> cd->cdi.mask |= CDC_DVD_RAM;
> 
> In drivers/ide/ide-cd.c I find:
> devinfo->mask |= CDC_DVD_RAM;
> 
> I conclude sr and ide-cd tell cdrom whether the device "profile" is
> writable or not.  Is that wrong?

->mask is an inverted capability mask, so if you set CDC_DVD_RAM you
mask that capability.

-- 
Jens Axboe

Re: writable mmc profiles actually are writable

[Pat LaVarre]

> > +//   if ((fp->f_mode & FMODE_WRITE) && !CDROM_CAN(CDC_DVD_RAM))
> > +//           return -EROFS;
> > +//   if (!cd->device->writeable)
> > +//           return 0;
>
> ... obviously wrong

May I ask why this patch is obviously wrong?

What actually breaks?

How do we benefit from having cdrom.ko and sr_mod.ko redundantly refuse
writes?

I figure I should try mount of a cd-rom with this patch.  Maybe I get
mount -w when I wanted mount -r and then life goes downhill from there. 
Or maybe iso fs doesn't try to write.  Or ...

Pat LaVarre

Re: writable mmc profiles actually are writable

[Jens Axboe]

On Mon, Oct 06 2003, Pat LaVarre wrote:
> > > +//   if ((fp->f_mode & FMODE_WRITE) && !CDROM_CAN(CDC_DVD_RAM))
> > > +//           return -EROFS;
> > > +//   if (!cd->device->writeable)
> > > +//           return 0;
> >
> > ... obviously wrong
> 
> May I ask why this patch is obviously wrong?

Allowing write open of a read-only device.

> What actually breaks?

Lots of stuff. As I mentioned, only DVD-RAM "type" media will work with
sending random writes, things like cd-rw require special treatment.

> How do we benefit from having cdrom.ko and sr_mod.ko redundantly refuse
> writes?
> 
> I figure I should try mount of a cd-rom with this patch.  Maybe I get
> mount -w when I wanted mount -r and then life goes downhill from there. 

> Or maybe iso fs doesn't try to write.  Or ...

iso fs doesn't support writing.

-- 
Jens Axboe

Re: writable mmc profiles actually are writable

[Pat LaVarre]

> CDC_DVD_RAM ...
> the only thing the kernel supports out of the box.

Do we understand this choice?  I'm new to linux, new to t10 mmc, old to
unix, old to t10 scsi.  I think I see:

1) In mmc, seven of the standard profiles imply feature x0020
random_writable, specifically profiles x 0001 0002 0003 0005 0012 001A
0022 i.e. non_removable_disk, removable_disk, magneto_optical_erasable,
as_mo, dvd_ram, dvd+rw, ddcd_rw.

2) In sr_mod.ko and ide-cd.ko, we conservatively fetch only mode page
x2A Capabilities.  Specifically we do not yet try the op x46 Get
Configuration of 1999 mmc 2, not even after we see mode page x2A.

3) Omitting op x46 by definition precludes linux from distinguishing
from legacy cd_rom all the new writable kinds of pdt x05 dvd/cd,
excepting only the 1997 mmc 1 choices that /proc/sys/dev/cdrom already
offers i.e. cd_r, cd_rw, dvd, dvd_r, and dvd_ram.

How wrong am I?

Pat LaVarre

Re: writable mmc profiles actually are writable

[Jens Axboe]

On Mon, Oct 06 2003, Pat LaVarre wrote:
> > CDC_DVD_RAM ...
> > the only thing the kernel supports out of the box.
> 
> Do we understand this choice?  I'm new to linux, new to t10 mmc, old to
> unix, old to t10 scsi.  I think I see:

You conviniently snipped the rest of the message. I said that media that
is _like_ DVD-RAM. I'll grant you that it isn't quite obvious, but that
is the way it was done. That covers stuff like MO drives, too.

> 1) In mmc, seven of the standard profiles imply feature x0020
> random_writable, specifically profiles x 0001 0002 0003 0005 0012 001A
> 0022 i.e. non_removable_disk, removable_disk, magneto_optical_erasable,
> as_mo, dvd_ram, dvd+rw, ddcd_rw.

the disk profiles aren't driven by ide-cd or sr. mo and dvd-ram have
been supported for a long time and should be set with CDC_DVD_RAM, I
haven't yet had to deal with dvd+rw or ddcd_rw (is this like mtr?). Feel
free to extend that to cover those, too. I know of patches for dvd+rw
floating around, they have never been sent for kernel inclusion though.
Which either means that they don't work too well (they probably do), or
that people just don't care enough for that feature.

> 2) In sr_mod.ko and ide-cd.ko, we conservatively fetch only mode page
> x2A Capabilities.  Specifically we do not yet try the op x46 Get
> Configuration of 1999 mmc 2, not even after we see mode page x2A.
>
> 3) Omitting op x46 by definition precludes linux from distinguishing
> from legacy cd_rom all the new writable kinds of pdt x05 dvd/cd,
> excepting only the 1997 mmc 1 choices that /proc/sys/dev/cdrom already
> offers i.e. cd_r, cd_rw, dvd, dvd_r, and dvd_ram.
> 
> How wrong am I?

You are not wrong, and I'd be happy to review patches to make the
detection more modern. And this is what you should have done from the
beginning, instead of just hacking around the write open. This is what
my objection was for, not supporting other devices.

-- 
Jens Axboe

Re: max GiB written per boot

[Pat LaVarre]

Now commonly in -test6 I see such seemingly spontaneous events as:

scsi: Device offlined - not ready after error recovery: host 2 channel 0 id 0 lun 0
sr2: CDROM (ioctl) error, command: 0x00 00 00 00 00 00
sr?: sense =  0  0
Non-extended sense class 0 code 0x0
Raw sense data:0x00 0x00 0x00 0x00
cdrom: open failed.
SCSI error: host 2 id 0 lun 0 return code = 6070000
        Sense class 0, sense error 0, extended sense 0

Did I change some other significant variable?  Could be ...

I will rebuild my usb trace infrastructure and report again.

Pat LaVarre

Re: max GiB written per boot

[Pat LaVarre]

With usb2 in linux 2.6.0-test6 just now, ...

I find what works well for me is /etc/grub.conf:

title Red Hat Linux (2.6.0-test6)
        root (hd0,8)
        kernel /vmlinuz-2.6.0-test6 ro root=LABEL=/
        initrd /initrd-2.6.0-test6.img

What chokes often is:

title Red Hat Linux (2.6.0-test6)
        root (hd0,8)
        kernel /vmlinuz-2.6.0-test6 ro root=LABEL=/ hdc=ide-scsi
        initrd /initrd-2.6.0-test6.img

Having hdc=ide-scsi matter I think is a clue.

I don't yet know if this apparent correlation will hold up or not.

Pat LaVarre

Re: max GiB written per boot

[Jens Axboe]

On Mon, Oct 06 2003, Pat LaVarre wrote:
> With usb2 in linux 2.6.0-test6 just now, ...
> 
> I find what works well for me is /etc/grub.conf:
> 
> title Red Hat Linux (2.6.0-test6)
>         root (hd0,8)
>         kernel /vmlinuz-2.6.0-test6 ro root=LABEL=/
>         initrd /initrd-2.6.0-test6.img
> 
> What chokes often is:
> 
> title Red Hat Linux (2.6.0-test6)
>         root (hd0,8)
>         kernel /vmlinuz-2.6.0-test6 ro root=LABEL=/ hdc=ide-scsi
>         initrd /initrd-2.6.0-test6.img
> 
> Having hdc=ide-scsi matter I think is a clue.
> 
> I don't yet know if this apparent correlation will hold up or not.

Yeah, ide-scsi is broken so you probably shouldn't be using it.

-- 
Jens Axboe

Re: max GiB written per boot

[Randy.Dunlap]

On Tue, 7 Oct 2003 07:57:14 +0200 Jens Axboe <axboe@suse.de> wrote:

| > 
| > Having hdc=ide-scsi matter I think is a clue.
| > 
| > I don't yet know if this apparent correlation will hold up or not.
| 
| Yeah, ide-scsi is broken so you probably shouldn't be using it.

Is there any sense in trying to repair it?
I could spend some time on it...

--
~Randy

Re: max GiB written per boot

[Willem Riede]

On 2003.10.07 18:12, Randy.Dunlap wrote:
> On Tue, 7 Oct 2003 07:57:14 +0200 Jens Axboe <axboe@suse.de> wrote:
> 
> | 
> | Yeah, ide-scsi is broken so you probably shouldn't be using it.
> 
> Is there any sense in trying to repair it?
> I could spend some time on it...

Yes, there is IMHO. The Onstream tape driver (osst) depends on ide-scsi
for controlling the IDE version of the drive (DI-30). 

Fixing ide-scsi is not trivial, though. I've spent some time on it
on and off and have not been all that successful. The biggest problem
I have is the error recovery -- making ide subsystem error handling
happen when the scsi error handler needs it...

Regards, Willem Riede.

Re: max GiB written per boot

[Randy.Dunlap]

On Tue, 7 Oct 2003 18:57:08 -0400 Willem Riede <wrlk@riede.org> wrote:

| On 2003.10.07 18:12, Randy.Dunlap wrote:
| > On Tue, 7 Oct 2003 07:57:14 +0200 Jens Axboe <axboe@suse.de> wrote:
| > 
| > | 
| > | Yeah, ide-scsi is broken so you probably shouldn't be using it.
| > 
| > Is there any sense in trying to repair it?
| > I could spend some time on it...
| 
| Yes, there is IMHO. The Onstream tape driver (osst) depends on ide-scsi
| for controlling the IDE version of the drive (DI-30). 
| 
| Fixing ide-scsi is not trivial, though. I've spent some time on it
| on and off and have not been all that successful. The biggest problem
| I have is the error recovery -- making ide subsystem error handling
| happen when the scsi error handler needs it...

Alan said (a few months back) that he was fixing ide-scsi in 2.4.x-ac
and that it should be forward-ported to 2.6.x, so that is where I
would begin...  I haven't checked it for progress yet.

--
~Randy

Re: max GiB written per boot

[Randy.Dunlap]

On Tue, 7 Oct 2003 18:27:14 -0700 "Randy.Dunlap" <rddunlap@osdl.org> wrote:

| On Tue, 7 Oct 2003 18:57:08 -0400 Willem Riede <wrlk@riede.org> wrote:
| 
| | On 2003.10.07 18:12, Randy.Dunlap wrote:
| | > On Tue, 7 Oct 2003 07:57:14 +0200 Jens Axboe <axboe@suse.de> wrote:
| | > 
| | > | 
| | > | Yeah, ide-scsi is broken so you probably shouldn't be using it.
| | > 
| | > Is there any sense in trying to repair it?
| | > I could spend some time on it...
| | 
| | Yes, there is IMHO. The Onstream tape driver (osst) depends on ide-scsi
| | for controlling the IDE version of the drive (DI-30). 
| | 
| | Fixing ide-scsi is not trivial, though. I've spent some time on it
| | on and off and have not been all that successful. The biggest problem
| | I have is the error recovery -- making ide subsystem error handling
| | happen when the scsi error handler needs it...
| 
| Alan said (a few months back) that he was fixing ide-scsi in 2.4.x-ac
| and that it should be forward-ported to 2.6.x, so that is where I
| would begin...  I haven't checked it for progress yet.

but this hasn't really happened (2.4.x-ac ide-scsi) afaict.

--
~Randy

Re: max GiB written per boot

[Jens Axboe]

On Tue, Oct 07 2003, Randy.Dunlap wrote:
> On Tue, 7 Oct 2003 18:27:14 -0700 "Randy.Dunlap" <rddunlap@osdl.org> wrote:
> 
> | On Tue, 7 Oct 2003 18:57:08 -0400 Willem Riede <wrlk@riede.org> wrote:
> | 
> | | On 2003.10.07 18:12, Randy.Dunlap wrote:
> | | > On Tue, 7 Oct 2003 07:57:14 +0200 Jens Axboe <axboe@suse.de> wrote:
> | | > 
> | | > | 
> | | > | Yeah, ide-scsi is broken so you probably shouldn't be using it.
> | | > 
> | | > Is there any sense in trying to repair it?
> | | > I could spend some time on it...
> | | 
> | | Yes, there is IMHO. The Onstream tape driver (osst) depends on ide-scsi
> | | for controlling the IDE version of the drive (DI-30). 
> | | 
> | | Fixing ide-scsi is not trivial, though. I've spent some time on it
> | | on and off and have not been all that successful. The biggest problem
> | | I have is the error recovery -- making ide subsystem error handling
> | | happen when the scsi error handler needs it...
> | 
> | Alan said (a few months back) that he was fixing ide-scsi in 2.4.x-ac
> | and that it should be forward-ported to 2.6.x, so that is where I
> | would begin...  I haven't checked it for progress yet.
> 
> but this hasn't really happened (2.4.x-ac ide-scsi) afaict.

2.4 and 2.6 also uses different error handling for ide-scsi, so it would
probably not have helped you a lot.

-- 
Jens Axboe

Re: max GiB written per boot

[Pat LaVarre]

> > > Having hdc=ide-scsi matter I think is a clue.
> > > 
> > > I don't yet know if this apparent correlation will hold up or not.
> >
> > Yeah, ide-scsi is broken so you probably shouldn't be using it.
>
> From:  Randy.Dunlap <rddunlap@osdl.org>
> Is there any sense in trying to repair it?
> I could spend some time on it...

Perhaps I may say: yes please!

As an ignorant newbie, myself I'd vote we at least apply the patch:

--- ./post-halloween-2.5.txt	2003-10-09 15:50:29.565344120 -0600
+++ post-halloween.txt	2003-10-09 15:52:28.323290168 -0600
@@ -571,6 +571,8 @@
 - Jens Axboe added the ability to use DMA for writing CDs on
   ATAPI devices. Writing CDs should be much faster than it
   was in 2.4, and also less prone to buffer underruns and the like.
+- Take care to remove ide-scsi.  Booting with hdc=ide-scsi or
+  modprobe'ing ide-scsi may disrupt your kernel.
 - With a recent cdrecord, you also no longer need ide-scsi in order to use
   an IDE CD writer.
 - Ripping audio tracks off of CDs now also uses DMA and should be

If that's not reality, I need more education.

If that is reality, but not what we want to say, then we can balance the
work involved in updating ide-scsi vs. the likely pain of answering all
the later newbies who come here saying I swapped 2.6 into my Red Hat/
etc. 2.4/ 2.5 and life went downhill from there.

Myself I gathered 2.6 experience without ide-scsi only by luck.  I have
a usb drive and an atapi drive, I had to choose one or the other to
begin with, I happened to choose the usb drive, and I happened to
dislike the idea of overriding a kernel default.

I'm no longer sure I remember exactly how I fell back into trying
hdc=ide-scsi.  I know I'm contact with other newbies who take more the
attitude of learning to change as little as possible in how Red Hat
boots, rather than the attitude of learning how to survive with as
little from Red Hat as practical.

Pat LaVarre

Re: max GiB written per boot

[Pat LaVarre]

> > > ...
> >
> > ... always ... an oops ... Must be fixed.
>
> Here's another ...

I remember now where I got the idea people don't want to hear about how
easily I can provoke "kernel NULL pointer dereference":

http://www.tux.org/lkml/#s4-3
includes such not-completely-true claims as:

"(REG) Don't even bother posting an Oops if you haven't run it through
ksymoops to decode the symbol addresses. The report will be ignored
because it contains too little useful information."

That was the convention I was trying to follow before I was told
differently.

Pat LaVarre.

Re: 2 KiB/block loopback found where

[Pat LaVarre]

Can I easily fix my --getss too?

$ sudo losetup /dev/loop0 dd.bin
$
$ dmesg | tail -2
loop: loaded (max 8 devices)
loop:to x800 from lo_blocksize = 0x1000
$
$ sudo blockdev --getss /dev/loop0
512
$ sudo blockdev --getbsz /dev/loop0
4096
$
$ sudo blockdev --getss /dev/scd0
2048
$ sudo blockdev --getbsz /dev/scd0
4096
$

I'm pleased to report, patching drivers/block/loop.c as suggested,
specifically via the patch quoted below, did confuse udf.ko as well with
a loop device as does my real 2 KiB/block device.

Certainly I could and did then relay details to
linux_udf@hpesjro.fc.hp.com in a thread titled "balloc free bit already
set and byte minus one".  But I'd of course like to make my loop device
as perfect a simulation of my real device as practical.  So I ask:

Can I easily fix my --getss too?

Pat LaVarre

diff -Nur linux-2.6.0-test6/drivers/block/loop.c linux/drivers/block/loop.c
--- linux-2.6.0-test6/drivers/block/loop.c	2003-09-27 18:50:29.000000000 -0600
+++ linux/drivers/block/loop.c	2003-10-06 18:06:20.447708984 -0600
@@ -732,7 +732,13 @@
 	mapping_set_gfp_mask(inode->i_mapping,
 			     lo->old_gfp_mask & ~(__GFP_IO|__GFP_FS));
 
+#if 0
 	set_blocksize(bdev, lo_blocksize);
+#else
+	printk(KERN_INFO "loop:"
+		"to x800 from lo_blocksize = 0x%X\n", lo_blocksize);
+	set_blocksize(bdev, 0x800);
+#endif
 
 	lo->lo_bio = lo->lo_biotail = NULL;

aligned /dev/scd$n reads less rare how

[Pat LaVarre]

Anything easy I can do to make aligned reads more common?

I ask because often thru /dev/scd$n I see seemingly pointless
misalignment, for example, if I read a 1 GiB disk:

$ sudo blockdev --flushbufs /dev/scd0
$ time sudo dd if=/dev/scd0 bs=1M
...

usb-storage:  x 43 00 00 00 00 00 00 00 0C 00
usb-storage:  x 43 02 00 00 00 00 01 00 0C 00
usb-storage:  x 1E 00 00 00 01 00
usb-storage:  x 00 00 00 00 00 00
usb-storage:  x 28 00 00 00 00 00 00 00 20 00
usb-storage:  x 28 00 00 00 00 20 00 00 24 00
usb-storage:  x 28 00 00 00 00 44 00 00 40 00
usb-storage:  x 28 00 00 00 00 84 00 00 40 00
usb-storage:  x 28 00 00 00 00 C4 00 00 40 00
...
usb-storage:  x 28 00 00 07 FE C4 00 00 40 00
usb-storage:  x 28 00 00 07 FF 04 00 00 06 00
usb-storage:  x 28 00 00 07 FF 0A 00 00 3A 00
usb-storage:  x 28 00 00 07 FF 44 00 00 40 00
usb-storage:  x 28 00 00 07 FF 84 00 00 0A 00
usb-storage:  x 28 00 00 07 FF 8E 00 00 36 00
usb-storage:  x 28 00 00 07 FF C4 00 00 3C 00
...

1024+0 records in
1024+0 records out
 
real    0m54.809s
user    0m0.015s
sys     0m9.039s
$

Pat LaVarre

P.S.

I know I can read aligned thru /dev/sg0 as follows.

$
$ time sudo sg_dd if=/dev/sg0 bs=2k bpt=512 count=524288
of=/mnt/hda11/z.bin
...
 
Attached scsi generic sg0 at scsi1, channel 0, id 0, lun 0,  type 5
usb-storage:  x 28 00 00 00 00 00 00 02 00 00
usb-storage:  x 28 00 00 00 02 00 00 02 00 00
usb-storage:  x 28 00 00 00 04 00 00 02 00 00
usb-storage:  x 28 00 00 00 06 00 00 02 00 00
...
usb-storage:  x 28 00 00 07 FA 00 00 02 00 00
usb-storage:  x 28 00 00 07 FC 00 00 02 00 00
usb-storage:  x 28 00 00 07 FE 00 00 02 00 00

524288+0 records in
524288+0 records out
 
real    0m56.567s
user    0m0.027s
sys     0m7.236s
$

I see this approach to aligning reads slowed me down a second or two.

zip of GiB cross-platform

[Pat LaVarre]

Is linux-scsi a place where folk hang out who often mail around GiB from
Linux?

I see Linux `zip -r $folder $folder` produces .zip files that Mac OS X
and Win XP can read ...

... only when the folder is small.  When the folder contains a `dd`
image of a mostly zero 1GiB disk (specifically an initially zero +
`mkudffs`) disk, then Mac OS X & Win XP choke.

`unzip -vt $folder` is happy, `unzip` produces a file that `diff` and
`cmp` say matches the original.

Did I commit some brain dead newbie error?  Reproduce a known bug? 
Discover a new bug?

Pat LaVarre

P.S. For example, Mac OS X reports:

An error has occurred while expanding the file ...zlxudf.zip"
(Unspecified StuffIt Engine internal error).

Error #17999

Re: zip of GiB cross-platform

[Matthew Wilcox]

I suggest you file a bug with your distribution (if you're using one)
or talk to the zip maintainers (if you're not).  This kind of question
does not belong on this list.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: zip of GiB cross-platform

[Pat LaVarre]

> I suggest ... zip maintainers (if you're not).
> This kind of question
> does not belong on this list.

Thanks for clueing me in, sorry to take your time.

Pat LaVarre

Re: aligned /dev/scd$n reads less rare how

[Pat LaVarre]

> Anything easy I can do
> to make aligned reads more common?

Instead we first could/ should ask:

How does Linux align write/read of cd-rw/dvd+rw?

We know 2.6 vs. 2.4 newly connects cd-rw as writeable, by
http://kniggit.net/wwol26.html of l=kernelnewbies.  And "everybody
knows" cd-rw needs 64 KiB write alignment, dvd+rw needs 32 KiB write
alignment, and both prefer write alignment in reads, right?  How then
does Linux hint at the mounted fs to align write/read to something other
than the 0.5 KiB that was optimal for legacy hdd?

> I ask because often thru /dev/scd$n
> I see seemingly pointless misalignment,
> ...
> $ sudo blockdev --flushbufs /dev/scd0
> $ time sudo dd if=/dev/scd0 bs=1M
> ...
> usb-storage:  x 28 00 00 00 00 00 00 00 20 00

Initially we see aligned in address and length to x20 blocks = 64 KiB.

> usb-storage:  x 28 00 00 00 00 20 00 00 24 00

Soon we see aligned in address but, whoops, not in length.

> usb-storage:  x 28 00 00 00 00 44 00 00 40 00
> usb-storage:  x 28 00 00 00 00 84 00 00 40 00
> usb-storage:  x 28 00 00 00 00 C4 00 00 40 00
> ...
> usb-storage:  x 28 00 00 07 FE C4 00 00 40 00

Mostly we see contiguous after a misaligned access, so not aligned in
address though yes aligned in length.  Ouch.

Pat LaVarre

Re: Re: USB storage problems on OHCI..

[Alan Stern]

On 23 Sep 2003, James Bottomley wrote:

> On Tue, 2003-09-23 at 09:37, Andries.Brouwer@cwi.nl wrote:
> 
> > Pulling out a device while it is actively reading or writing
> > will probably break something. But if a device is hot-pluggable
> > it should be OK to pull it out when it has been inactive for
> > a second or so.
> > 
> > But if that is really true, then it should not be necessary
> > to send the device any "synchronise cache" commands when we
> > shut down.
> 
> For a FC array, suprise unplug would be caveat emptor (possibly because
> fibre connection transience is going to cause it to come back), but
> notified unplug would still want to flush the cache on the assumption
> the next action might be to power down the array.

Is there any way to notify the system that you are about to unplug a 
drive?  It seems to me that the best approach is to flush the cache on an 
unmount.  People naturally assume that it's safe to unplug a device once 
it has been unmounted, and they also realize that it's unsafe to unplug a 
device containing a mounted filesystem.

That doesn't address the problem of raw device access, but perhaps 
whatever ioctl is used by blockdev --flushbufs can also flush the cache.

Is there any harm in sending a SYNCHRONIZE command to a device that
doesn't need it (write-through cache)?  Maybe doing that is less dangerous 
than trying to read mode-sense page 8 on these buggy USB devices.  
(Although I'm not aware of anyone who has tried the experiment.)

Alan Stern



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[James Bottomley]

On Tue, 2003-09-23 at 10:23, Alan Stern wrote: 
> Is there any way to notify the system that you are about to unplug a 
> drive?  It seems to me that the best approach is to flush the cache on an 
> unmount.  People naturally assume that it's safe to unplug a device once 
> it has been unmounted, and they also realize that it's unsafe to unplug a 
> device containing a mounted filesystem.
> 
> That doesn't address the problem of raw device access, but perhaps 
> whatever ioctl is used by blockdev --flushbufs can also flush the cache.

Well, a synchronize can be really expensive (minutes to flush on a large
array), you only really want to do it if absolutely necessary, so tying
it to something separate from normal OS operation seems like the best
thing to do. 

> Is there any harm in sending a SYNCHRONIZE command to a device that
> doesn't need it (write-through cache)?  Maybe doing that is less dangerous 
> than trying to read mode-sense page 8 on these buggy USB devices.  
> (Although I'm not aware of anyone who has tried the experiment.)

Devices that don't support mode page 8 invariably seem to react badly to
the SYNCHRONIZE command (I have a few of these SCSI devices)...Although,
usually they just send an ILLEGAL COMMAND sense.  I wouldn't like to try
the same thing with a USB device... 

James 

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Andries.Brouwer]

    From James.Bottomley@SteelEye.com  Tue Sep 23 16:05:21 2003

    > Also "conservative mode" sounds like a flag that describes some
    > way of being broken.
    > 
    > On the other hand "hot-pluggable" describes a positive asset,
    > and if we can conclude from that that it is unnecessary to ask
    > for mode page 8 then we achieve the same effect in a positive way.

    I disagree on this one.  hot-pluggable sounds like it should be set for
    ever hotplug device (currently that would include firewire, which may be
    iffy, and Fibre Channel, which has our highest level of SCSI compliance
    and would definitely be wrong).

Why would it be wrong?

    The design goal is that this flag makes sd assume as little SCSI
    standards compliance as it can get away with while still operating the
    device.

No, the design goal of "hot-pluggable" is that it indicates that
the device can disappear any moment. Nothing at all about SCSI
compliance.

Pulling out a device while it is actively reading or writing
will probably break something. But if a device is hot-pluggable
it should be OK to pull it out when it has been inactive for
a second or so.

But if that is really true, then it should not be necessary
to send the device any "synchronise cache" commands when we
shut down.

And if no such commands will be sent anyway, then we need not ask
the device about its type of cache.

And if we do not ask, then we need not worry whether the device
is sufficiently compliant to answer such a question.

Andries

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[James Bottomley]

On Tue, 2003-09-23 at 09:37, Andries.Brouwer@cwi.nl wrote:
> No, the design goal of "hot-pluggable" is that it indicates that
> the device can disappear any moment. Nothing at all about SCSI
> compliance.

Actually, then, these are two issues...hotplug is being worked on
separately at the moment.

I thought the problem under discussion was devices which lacked SCSI
standards compliance.

> Pulling out a device while it is actively reading or writing
> will probably break something. But if a device is hot-pluggable
> it should be OK to pull it out when it has been inactive for
> a second or so.
> 
> But if that is really true, then it should not be necessary
> to send the device any "synchronise cache" commands when we
> shut down.

For a FC array, suprise unplug would be caveat emptor (possibly because
fibre connection transience is going to cause it to come back), but
notified unplug would still want to flush the cache on the assumption
the next action might be to power down the array.

James

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Linus Torvalds]

On Tue, 23 Sep 2003 Andries.Brouwer@cwi.nl wrote:
> 
> No, the design goal of "hot-pluggable" is that it indicates that
> the device can disappear any moment. Nothing at all about SCSI
> compliance.

You're talking past each other.

Server people think that "hot-pluggable" means "I will tell the system 
before it goes away". Normal users consider hot-pluggable to be "I can rip 
the thing out by hand".

I'm with the normal users - I think the server guys are really talking 
about "controlled shutdown and insert", not "hot-pluggable", but hey, the 
fact is, there's two kinds.

Trying to enumerate three values with one bit is counterproductive.

So we should _not_ have one bit that says "hotpluggable", we should have
separate bits for "should survive a unexpected disconnect" (_real_
hotplug) and "can be disconnected with operator help" (server
"pseudo-hotplug").

USB devices are obviously supposed to be able to just be ripped out, ie
"unexpected", real hotplug.  While FC etc tends to be "pseudo-hotplug".

			Linus

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Andries.Brouwer]

> Tell me we care to hear specifically what some win sends to some of my
> usb hdd/rmb, and I'll go collect a few sample usb bus traces.

I'll collect and publish.
(Change the subject line to "USB storage traces" or so.)
Must have some old traces somewhere myself too.

Andries

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Andries.Brouwer]

    From James.Bottomley@SteelEye.com  Mon Sep 22 21:29:06 2003

    On Mon, 2003-09-22 at 13:55, Andries.Brouwer@cwi.nl wrote:
    >         if (sdkp->media_present) {
    >                 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);
    >         }
    > 
    > and I suppose we could skip sd_read_cache_type() in the
    > hot-pluggable case - a flag that USB storage could set.

    what about just having a conservative mode for sd?  This could still
    internally be a set of flags, just one single way of clearing them all
    from slave configure.  For the most conservative setting, we could
    probably dump spin up, read write protect, and read cache type.

Maybe.

[By the way - reading Write Protect is meaningful and works,
for my Smart Media card readers.]

I have seen proposals around here for flags that are far too specific
(like "do not ask for mode page 8"). If we go to that level of detail
then we'll soon have fifty flags.
Black lists, and flags that describe various ways of being broken
are a bad idea in my opinion. I will not deny that they may be needed
in some cases, but they are never the preferred solution.

Also "conservative mode" sounds like a flag that describes some
way of being broken.

On the other hand "hot-pluggable" describes a positive asset,
and if we can conclude from that that it is unnecessary to ask
for mode page 8 then we achieve the same effect in a positive way.


There is another comment here.
A scsi device declares its level of scsi compliance.
Most USB storage devices are not very scsi compliant at all,
and report 0 there.
To everybody's surprise USB storage does

        US_DEBUGP("Fixing INQUIRY data to show SCSI rev 2 - was %d\n",
                  data_ptr[2] & 7);

        /* Change the SCSI revision number */
        data_ptr[2] = (data_ptr[2] & ~7) | 2;

It claims that the device is SCSI-2 compliant, even when the
device itself does not make that claim at all.


Suppose that we stop changing this compliance level.
Then getting SCSI-1 or no compliance level could be a
"conservative mode" flag.

[Of course this was done for a reason - USB storage was written
assuming the SCSI layer given. If we stop changing the SCSI level
that may require changes in the SCSI code. Probably Matt remembers
what the problems were.]

Andries

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Alan Stern]

On Mon, 22 Sep 2003 Andries.Brouwer@cwi.nl wrote:

> I have seen proposals around here for flags that are far too specific
> (like "do not ask for mode page 8"). If we go to that level of detail
> then we'll soon have fifty flags.
> Black lists, and flags that describe various ways of being broken
> are a bad idea in my opinion. I will not deny that they may be needed
> in some cases, but they are never the preferred solution.
> 
> Also "conservative mode" sounds like a flag that describes some
> way of being broken.
> 
> On the other hand "hot-pluggable" describes a positive asset,
> and if we can conclude from that that it is unnecessary to ask
> for mode page 8 then we achieve the same effect in a positive way.

Bravo! a capital plan!

(Does anybody remember _Utopia Limited_ these days?)

I will be just as pleased as the next man to see these little flags go 
away -- or rather, not arrive in the first place.  And as Andries says, 
there's no real point in trying to determine the cache type for a 
hot-pluggable device in the first place.  Furthermore, this will get rid 
of some annoying "Can't SYNCHRONIZE" messages from sd.c.

Alan Stern

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Matthew Dharm]

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

On Mon, Sep 22, 2003 at 09:56:38PM +0200, Andries.Brouwer@cwi.nl wrote:
> A scsi device declares its level of scsi compliance.
> Most USB storage devices are not very scsi compliant at all,
> and report 0 there.

Not exactly.  The reporting of 0, 1, 2, or something random in that field
appears to be completely unrelated to the capabilities of the device.  I've
found -zero- correlation between the revision level and how the device
functions.

Also, sampling my devices, I see a wide range of values reported -- saying
'most report 0' would be incorrect based on my data.

> To everybody's surprise USB storage does
> 
>         US_DEBUGP("Fixing INQUIRY data to show SCSI rev 2 - was %d\n",
>                   data_ptr[2] & 7);
> 
>         /* Change the SCSI revision number */
>         data_ptr[2] = (data_ptr[2] & ~7) | 2;
> 
> It claims that the device is SCSI-2 compliant, even when the
> device itself does not make that claim at all.
> 
> Suppose that we stop changing this compliance level.
> Then getting SCSI-1 or no compliance level could be a
> "conservative mode" flag.
> 
> [Of course this was done for a reason - USB storage was written
> assuming the SCSI layer given. If we stop changing the SCSI level
> that may require changes in the SCSI code. Probably Matt remembers
> what the problems were.]

It's been a couple of years since I looked at this.... but I positively
recall that I added this code to fix definate and clear problems.

One that is immediately obvious to me is that if the SCSI level is < 2, we
can't address anything beyond the 6-byte command limit.

Another that immediately comes to mind is that the display in
/proc/scsi/scsi would show version ffffffff

I've heard arguments from various people (including Jorge Shilling and some
device-vendor folks) that I shouldn't override this value... the argument I
used to counter that request was that things break completely if I don't
override the value; I don't have a record of what specifically breaks.

Matt

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

A:  The most ironic oxymoron wins ...
DP: "Microsoft Works"
A:  Uh, okay, you win.
					-- A.J. & Dust Puppy
User Friendly, 1/18/1998

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

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[James Bottomley]

On Mon, 2003-09-22 at 14:56, Andries.Brouwer@cwi.nl wrote:
> I have seen proposals around here for flags that are far too specific
> (like "do not ask for mode page 8"). If we go to that level of detail
> then we'll soon have fifty flags.
> Black lists, and flags that describe various ways of being broken
> are a bad idea in my opinion. I will not deny that they may be needed
> in some cases, but they are never the preferred solution.
> 
> Also "conservative mode" sounds like a flag that describes some
> way of being broken.
> 
> On the other hand "hot-pluggable" describes a positive asset,
> and if we can conclude from that that it is unnecessary to ask
> for mode page 8 then we achieve the same effect in a positive way.

I disagree on this one.  hot-pluggable sounds like it should be set for
ever hotplug device (currently that would include firewire, which may be
iffy, and Fibre Channel, which has our highest level of SCSI compliance
and would definitely be wrong).

The design goal is that this flag makes sd assume as little SCSI
standards compliance as it can get away with while still operating the
device.

So call a spade "a spade"

My thought, by the way, is that it would be a callback that would clear
all the "extras" flags, and the slave_configure routine could
selectively turn them back on again if necessary.

James

Re: Re: USB storage problems on OHCI..

[Andries.Brouwer]

> Basically, Andries Brouwer's strategy of making sd.c more conservative has
> been a very successful one in the past. Why not continue on that?

% I would be interested in hearing what Andries has to say. ...
% The variety of ways in which these things fail is truly amazing.

Yes.

We have just seen this for keyboards: keypresses work, modifier key
releases work, and as soon as one assumes anything more there turn
out to be keyboards that fail.

Similarly, USB storage devices tend to fail whatever one tries,
and only systematically work if one does precisely what Windows
does. For SCSI disks things are not nearly as bad - there are
only a few manufacturers and they mostly produce quality stuff.

This means that carefully reading the SCSI standard is a useful
activity if one writes for SCSI disks. But for USB storage it
is more productive to trace the commands the various flavours
of Windows send.

(Yes, I am willing to collect whatever people send me, and put up
a web page describing the Windows way of addressing USB storage.)

So, I agree with Linus (and with myself :-)) - in the absence of
precise knowledge about the device and about its Windows drivers
all that is left is being as conservative as possible.
And I agree with Alan - even though being careful is a very good idea,
it does not help in all cases.

There are some general things we can do - for CF cards and the like
we probably do not want to read the cache type - USB is hot pluggable,
so it should not be necessary to send a flush cache command at shutdown.
Today I see

        if (sdkp->media_present) {
                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);
        }

and I suppose we could skip sd_read_cache_type() in the
hot-pluggable case - a flag that USB storage could set.

Andries


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[James Bottomley]

On Mon, 2003-09-22 at 13:55, Andries.Brouwer@cwi.nl wrote:
>         if (sdkp->media_present) {
>                 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);
>         }
> 
> and I suppose we could skip sd_read_cache_type() in the
> hot-pluggable case - a flag that USB storage could set.

what about just having a conservative mode for sd?  This could still
internally be a set of flags, just one single way of clearing them all
from slave configure.  For the most conservative setting, we could
probably dump spin up, read write protect, and read cache type.

James

Re: Re: USB storage problems on OHCI..

[James Bottomley]

On Mon, 2003-09-22 at 12:41, Linus Torvalds wrote:
> Ok, thanks. In particular, it seems to be pointless to read anything past 
> byte 20 - nothing past there is even defined.
> 
> What's the general sense of things - for a random SCSI device with bugs 
> (and they all have _some_ sort of bugs, let's not just rain on USB here), 
> is it saner to try to read just the bytes we need (3 bytes: page code, 
> page size and the cache bits), or the full 20 bytes?

Generally, we used to do that...we did run across devices (I won't say
which) which tried to send more...i.e. there was a minimum size they
wouldn't transfer below.  By and large, I think it was the headers of
translated commands, though, so as long as we ask for the header +
minimum we need, we should be safe.

I think we could try 4 bytes for this (even to avoid wide residue
problems) and see how it goes.

James




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Linus Torvalds]

On 22 Sep 2003, James Bottomley wrote:
> 
> I think we could try 4 bytes for this (even to avoid wide residue
> problems) and see how it goes.

How about just trusting the size (and as far as I can tell from the SCSI 
specs, the size is the size _without_ the header and block descriptors), 
and capping it at 20?

If the device reports a size that is smaller than the required one (3), we 
just fail the request - instead of doing a small read and then making 
decisions on data that isn't even there, like we used to do!

(The old code would use the "size" as the read length argument, which
really looks fundamentally wrong. At the very least it should add in the
header length etc).

Can people try this attached patch? It looks bigger than it is - in order 
to do sane error handling for the "size is too small" case I re-organized 
the thing a bit. The real change is just

 - capping size at 20 (real value) instead of 128 (random crud)
 - properly add in the header and block descriptor sizes

Comments?

			Linus

-----
===== drivers/scsi/sd.c 1.134 vs edited =====
--- 1.134/drivers/scsi/sd.c	Wed Jun 25 04:47:26 2003
+++ edited/drivers/scsi/sd.c	Mon Sep 22 12:42:32 2003
@@ -1108,14 +1108,26 @@
 	/* cautiously ask */
 	res = sd_do_mode_sense(SRpnt, dbd, modepage, buffer, 4, &data);
 
-	if (scsi_status_is_good(res)) {
-		/* that went OK, now ask for the proper length */
-		len = data.length;
-		if (len > 128)
-			len = 128;
-		res = sd_do_mode_sense(SRpnt, dbd, modepage, buffer,
-				       len, &data);
-	}
+	if (!scsi_status_is_good(res))
+		goto bad_sense;
+
+	/* that went OK, now ask for the proper length */
+	len = data.length;
+
+	/*
+	 * We're only interested in the first three bytes, actually.
+	 * But the data cache page is defined for the first 20.
+	 */
+	if (len < 3)
+		goto bad_sense;
+	if (len > 20)
+		len = 20;
+
+	/* Take headers and block descriptors into account */
+	len += data.header_length + data.block_descriptor_length;
+
+	/* Get the data */
+	res = sd_do_mode_sense(SRpnt, dbd, modepage, buffer, len, &data);
 
 	if (scsi_status_is_good(res)) {
 		const char *types[] = {
@@ -1133,23 +1145,26 @@
 
 		printk(KERN_NOTICE "SCSI device %s: drive cache: %s\n",
 		       diskname, types[ct]);
+
+		return;
+	}
+
+bad_sense:
+	if ((SRpnt->sr_sense_buffer[0] & 0x70) == 0x70
+	     && (SRpnt->sr_sense_buffer[2] & 0x0f) == ILLEGAL_REQUEST
+	     /* ASC 0x24 ASCQ 0x00: Invalid field in CDB */
+	     && SRpnt->sr_sense_buffer[12] == 0x24
+	     && SRpnt->sr_sense_buffer[13] == 0x00) {
+		printk(KERN_NOTICE "%s: cache data unavailable\n",
+		       diskname);
 	} else {
-		if ((SRpnt->sr_sense_buffer[0] & 0x70) == 0x70
-		     && (SRpnt->sr_sense_buffer[2] & 0x0f) == ILLEGAL_REQUEST
-		     /* ASC 0x24 ASCQ 0x00: Invalid field in CDB */
-		     && SRpnt->sr_sense_buffer[12] == 0x24
-		     && SRpnt->sr_sense_buffer[13] == 0x00) {
-			printk(KERN_NOTICE "%s: cache data unavailable\n",
-			       diskname);
-		} else {
-			printk(KERN_ERR "%s: asking for cache data failed\n",
-			       diskname);
-		}
-		printk(KERN_ERR "%s: assuming drive cache: write through\n",
+		printk(KERN_ERR "%s: asking for cache data failed\n",
 		       diskname);
-		sdkp->WCE = 0;
-		sdkp->RCD = 0;
 	}
+	printk(KERN_ERR "%s: assuming drive cache: write through\n",
+	       diskname);
+	sdkp->WCE = 0;
+	sdkp->RCD = 0;
 }
 
 /**

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Ruud Linders]

I tried the patch but it doesn't work for me using an USB-2 Memory stick
"DiskonKey" on an USB-2 port (with uhci_hcd & ehci_hcd loaded).

After a 3 minute time-out I get
     "SCSI device sda: drive cache: write through"
and the device starts working just fine.

Unloading the ehci_hcd module doesn't make any difference.
Only when ripping out the whole mode-sense call it works immediately :-)
so it appears the device is just unhappy about the sd_do_mode_sense.

_
Regards,
	Ruud Linders

Linus Torvalds wrote:
> On 22 Sep 2003, James Bottomley wrote:
> 
>>I think we could try 4 bytes for this (even to avoid wide residue
>>problems) and see how it goes.
> 
> 
> How about just trusting the size (and as far as I can tell from the SCSI 
> specs, the size is the size _without_ the header and block descriptors), 
> and capping it at 20?
> 
> If the device reports a size that is smaller than the required one (3), we 
> just fail the request - instead of doing a small read and then making 
> decisions on data that isn't even there, like we used to do!
> 
> (The old code would use the "size" as the read length argument, which
> really looks fundamentally wrong. At the very least it should add in the
> header length etc).
> 
> Can people try this attached patch? It looks bigger than it is - in order 
> to do sane error handling for the "size is too small" case I re-organized 
> the thing a bit. The real change is just
> 
>  - capping size at 20 (real value) instead of 128 (random crud)
>  - properly add in the header and block descriptor sizes
> 
> Comments?
> 
> 			Linus
> 
> -----
> ===== drivers/scsi/sd.c 1.134 vs edited =====
> --- 1.134/drivers/scsi/sd.c	Wed Jun 25 04:47:26 2003
> +++ edited/drivers/scsi/sd.c	Mon Sep 22 12:42:32 2003
> @@ -1108,14 +1108,26 @@
>  	/* cautiously ask */
>  	res = sd_do_mode_sense(SRpnt, dbd, modepage, buffer, 4, &data);
>  
> -	if (scsi_status_is_good(res)) {
> -		/* that went OK, now ask for the proper length */
> -		len = data.length;
> -		if (len > 128)
> -			len = 128;
> -		res = sd_do_mode_sense(SRpnt, dbd, modepage, buffer,
> -				       len, &data);
> -	}
> +	if (!scsi_status_is_good(res))
> +		goto bad_sense;
> +
> +	/* that went OK, now ask for the proper length */
> +	len = data.length;
> +
> +	/*
> +	 * We're only interested in the first three bytes, actually.
> +	 * But the data cache page is defined for the first 20.
> +	 */
> +	if (len < 3)
> +		goto bad_sense;
> +	if (len > 20)
> +		len = 20;
> +
> +	/* Take headers and block descriptors into account */
> +	len += data.header_length + data.block_descriptor_length;
> +
> +	/* Get the data */
> +	res = sd_do_mode_sense(SRpnt, dbd, modepage, buffer, len, &data);
>  
>  	if (scsi_status_is_good(res)) {
>  		const char *types[] = {
> @@ -1133,23 +1145,26 @@
>  
>  		printk(KERN_NOTICE "SCSI device %s: drive cache: %s\n",
>  		       diskname, types[ct]);
> +
> +		return;
> +	}
> +
> +bad_sense:
> +	if ((SRpnt->sr_sense_buffer[0] & 0x70) == 0x70
> +	     && (SRpnt->sr_sense_buffer[2] & 0x0f) == ILLEGAL_REQUEST
> +	     /* ASC 0x24 ASCQ 0x00: Invalid field in CDB */
> +	     && SRpnt->sr_sense_buffer[12] == 0x24
> +	     && SRpnt->sr_sense_buffer[13] == 0x00) {
> +		printk(KERN_NOTICE "%s: cache data unavailable\n",
> +		       diskname);
>  	} else {
> -		if ((SRpnt->sr_sense_buffer[0] & 0x70) == 0x70
> -		     && (SRpnt->sr_sense_buffer[2] & 0x0f) == ILLEGAL_REQUEST
> -		     /* ASC 0x24 ASCQ 0x00: Invalid field in CDB */
> -		     && SRpnt->sr_sense_buffer[12] == 0x24
> -		     && SRpnt->sr_sense_buffer[13] == 0x00) {
> -			printk(KERN_NOTICE "%s: cache data unavailable\n",
> -			       diskname);
> -		} else {
> -			printk(KERN_ERR "%s: asking for cache data failed\n",
> -			       diskname);
> -		}
> -		printk(KERN_ERR "%s: assuming drive cache: write through\n",
> +		printk(KERN_ERR "%s: asking for cache data failed\n",
>  		       diskname);
> -		sdkp->WCE = 0;
> -		sdkp->RCD = 0;
>  	}
> +	printk(KERN_ERR "%s: assuming drive cache: write through\n",
> +	       diskname);
> +	sdkp->WCE = 0;
> +	sdkp->RCD = 0;
>  }
>  
>  /**
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> linux-usb-devel@lists.sourceforge.net
> To unsubscribe, use the last form field at:
> https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
> 

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Linus Torvalds]

On Tue, 23 Sep 2003, Ruud Linders wrote:
> 
> I tried the patch but it doesn't work for me using an USB-2 Memory stick
> "DiskonKey" on an USB-2 port (with uhci_hcd & ehci_hcd loaded).
> 
> After a 3 minute time-out I get
>      "SCSI device sda: drive cache: write through"
> and the device starts working just fine.

Is this different from a plain kernel _without_ the patch?

> Unloading the ehci_hcd module doesn't make any difference.
> Only when ripping out the whole mode-sense call it works immediately :-)
> so it appears the device is just unhappy about the sd_do_mode_sense.

Yes, I think we might want to mark USB devices as being write-through by 
default. That said, I think the patch is still better than what we have 
now (which just doesn't make any sense at all).

		Linus

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Ruud Linders]

Linus Torvalds wrote:
> On Tue, 23 Sep 2003, Ruud Linders wrote:
> 
>>I tried the patch but it doesn't work for me using an USB-2 Memory stick
>>"DiskonKey" on an USB-2 port (with uhci_hcd & ehci_hcd loaded).
>>
>>After a 3 minute time-out I get
>>     "SCSI device sda: drive cache: write through"
>>and the device starts working just fine.
> 
> 
> Is this different from a plain kernel _without_ the patch?
> 

No difference.

> 
>>Unloading the ehci_hcd module doesn't make any difference.
>>Only when ripping out the whole mode-sense call it works immediately :-)
>>so it appears the device is just unhappy about the sd_do_mode_sense.
> 
> 
> Yes, I think we might want to mark USB devices as being write-through by 
> default. That said, I think the patch is still better than what we have 
> now (which just doesn't make any sense at all).
> 

Fully agree here, 2.4.2x doesn't appear to do this mode_sense checking
and works with all the usb-mass-storage devices I tried.


> 		Linus
> 
> 


_
Ruud

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Linus Torvalds]

On Wed, 24 Sep 2003, Ruud Linders wrote:
> > 
> > Is this different from a plain kernel _without_ the patch?
> 
> No difference.

Ok. I committed my version as "better than what is there now", but clearly
it's not good enough.

So we should really add code to sd_read_cache_type() to default to 
write-through for USB devices. The question is, what kind of flag do we 
want to use?

We already have the combination "removable && !lockable", which would make
a lot of sense. But I don't think USB even touches those flags, and
"removable" wrt USB is actually a bit ambiguous (in the USB unplug case,
it's actually the _controller_ that is removed, not the medium).

Suggestions? Just add a new flag like the "use_10_for_ms" flag?

		Linus

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Alan Stern]

On Wed, 24 Sep 2003, Linus Torvalds wrote:

> Ok. I committed my version as "better than what is there now", but clearly
> it's not good enough.
> 
> So we should really add code to sd_read_cache_type() to default to 
> write-through for USB devices. The question is, what kind of flag do we 
> want to use?
> 
> We already have the combination "removable && !lockable", which would make
> a lot of sense. But I don't think USB even touches those flags, and
> "removable" wrt USB is actually a bit ambiguous (in the USB unplug case,
> it's actually the _controller_ that is removed, not the medium).
> 
> Suggestions? Just add a new flag like the "use_10_for_ms" flag?

Here's a suggestion.  This patch (as115) implements the concepts brought
up by Andries and Linus.  It adds a flag "randomly_unpluggable", meaning
that a host or device might be disconnected at some unknown and
uncontrollable time.  The flag is present in the host template, the host
structure (copied from the template), and the device structure (inherited
from the host), and it can be changed at will.  (Remember that a USB mass
storage device is treated as a SCSI host -- in fact, some such devices
actually _are_ hosts.)

The only place the flag gets used is in sd.c, where it prevents
sd_read_cache_type() from being called.  And the only place the flag gets 
set is in the usb-storage host template.

Although not ideal, this is one of the simplest ways of doing what we
want.  One thing that should be added is some way to SYNCHRONIZE the cache
at the appropriate times.  Unfortunately, I don't know when those times
should be -- unmount of course, but what else in addition?  (Also I don't
know how to tell at the level of sd.c when an unmount has occurred.)  And
I don't know what the effect of a SYNCHRONIZE command will be on a USB
device that doesn't like it; only experimentation with different devices
can answer that.

On the other hand, perhaps it's not necessary to worry about this.  Any
hot-unpluggable device compatible with the Windows/MacOS mass market ought
to survive an impromptu disconnect without losing any data.

This patch applies to 2.6.0-test5-bk10.

Alan Stern


===== include/scsi/scsi_device.h 1.5 vs edited =====
--- 1.5/include/scsi/scsi_device.h	Fri Sep  5 07:48:41 2003
+++ edited/include/scsi/scsi_device.h	Fri Sep 26 11:41:48 2003
@@ -85,6 +85,7 @@
 				     * because we did a bus reset. */
 	unsigned use_10_for_rw:1; /* first try 10-byte read / write */
 	unsigned use_10_for_ms:1; /* first try 10-byte mode sense/select */
+	unsigned randomly_unpluggable:1;	/* May disappear at any time */
 	unsigned no_start_on_add:1;	/* do not issue start on add */
 
 	unsigned int device_blocked;	/* Device returned QUEUE_FULL. */
===== include/scsi/scsi_host.h 1.3 vs edited =====
--- 1.3/include/scsi/scsi_host.h	Thu Aug 14 18:37:32 2003
+++ edited/include/scsi/scsi_host.h	Fri Sep 26 11:40:51 2003
@@ -312,6 +312,12 @@
 	 */
 	unsigned emulated:1;
 
+	/*
+	 * True for hosts that may be unplugged at unpredictable times
+	 * (e.g. USB)
+	 */
+	unsigned randomly_unpluggable:1;
+
 	/* 
 	 * True if the driver wishes to use the generic block layer
 	 * tag queueing functions
@@ -431,6 +437,7 @@
 	unsigned unchecked_isa_dma:1;
 	unsigned use_clustering:1;
 	unsigned highmem_io:1;
+	unsigned randomly_unpluggable:1;
 	unsigned use_blk_tcq:1;
 
 	/*
===== drivers/scsi/hosts.c 1.33 vs edited =====
--- 1.33/drivers/scsi/hosts.c	Tue Sep  2 02:15:39 2003
+++ edited/drivers/scsi/hosts.c	Fri Sep 26 11:44:41 2003
@@ -236,6 +236,7 @@
 	shost->cmd_per_lun = sht->cmd_per_lun;
 	shost->unchecked_isa_dma = sht->unchecked_isa_dma;
 	shost->use_clustering = sht->use_clustering;
+	shost->randomly_unpluggable = sht->randomly_unpluggable;
 	shost->use_blk_tcq = sht->use_blk_tcq;
 
 	if (sht->max_host_blocked)
===== drivers/scsi/sd.c 1.56 vs edited =====
--- 1.56/drivers/scsi/sd.c	Fri Sep  5 12:16:39 2003
+++ edited/drivers/scsi/sd.c	Fri Sep 26 11:51:38 2003
@@ -1206,7 +1206,9 @@
 		if (sdp->removable)
 			sd_read_write_protect_flag(sdkp, disk->disk_name,
 					sreq, buffer);
-		sd_read_cache_type(sdkp, disk->disk_name, sreq, buffer);
+		if (!sdp->randomly_unpluggable)
+			sd_read_cache_type(sdkp, disk->disk_name, sreq,
+					buffer);
 	}
 		
 	set_capacity(disk, sdkp->capacity);
===== drivers/scsi/scsi_scan.c 1.50 vs edited =====
--- 1.50/drivers/scsi/scsi_scan.c	Fri Sep  5 12:16:39 2003
+++ edited/drivers/scsi/scsi_scan.c	Fri Sep 26 11:49:14 2003
@@ -632,6 +632,7 @@
 
 	sdev->use_10_for_rw = 1;
 	sdev->use_10_for_ms = 0;
+	sdev->randomly_unpluggable = sdev->host->randomly_unpluggable;
 
 	if(sdev->host->hostt->slave_configure)
 		sdev->host->hostt->slave_configure(sdev);
===== drivers/usb/storage/scsiglue.c 1.59 vs edited =====
--- 1.59/drivers/usb/storage/scsiglue.c	Mon Jul 28 14:29:04 2003
+++ edited/drivers/usb/storage/scsiglue.c	Fri Sep 26 12:11:10 2003
@@ -324,6 +324,9 @@
 	/* emulated HBA */
 	.emulated =			TRUE,
 
+	/* may be unplugged at any time */
+	.randomly_unpluggable = 	TRUE,
+
 	/* module management */
 	.module =			THIS_MODULE
 };

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Alan Stern]

There haven't been any replies to my suggestion from a week ago

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

for a way to resolve the mode-sense page 8 problem.  One way or another, I 
wish somebody would do _something_ about this, particularly before 
2.6.0-final comes out.

Alan Stern

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[James Bottomley]

On Fri, 2003-10-03 at 09:18, Alan Stern wrote:
> There haven't been any replies to my suggestion from a week ago
> 
> http://marc.theaimsgroup.com/?l=linux-scsi&m=106462295800726&w=2
> 
> for a way to resolve the mode-sense page 8 problem.  One way or another, I 
> wish somebody would do _something_ about this, particularly before 
> 2.6.0-final comes out.

Well, the patch isn't quite correct because if it's not going to probe
the cache it should set up a write through cache (or disabled cache) as
the default.

Patrick's patch

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

Does get this right.

But my principle objection, as I've stated before, is that it isn't true
that we don't need to manage the caches of hot pluggable devices, fibre
channel being the counter example.

Even for devices whose model is always forced remove, knowing the cache
type is valuable information (especially as writeback cache type would
be a rather grave error).

The reason not to try to read the cache type for USB is that some of the
devices barf on receiving the command.  These type of devices are the
ones we don't want to make any attempt to manage the cache for, and I'd
like the flag name we settle on to reflect this.

However, if there's no further objections on the naming front, I'll put
Patrick's patch into the SCSI repository.

James

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Patrick Mansfield]

On Fri, Oct 03, 2003 at 10:05:52AM -0500, James Bottomley wrote:

> Well, the patch isn't quite correct because if it's not going to probe
> the cache it should set up a write through cache (or disabled cache) as
> the default.

Alan's original patch is included in my patch.

> Patrick's patch
> 
> http://marc.theaimsgroup.com/?l=linux-scsi&m=106366112221507
> 
> Does get this right.

I am re-rolling the patch based on current 2.6, plus a couple comments
Christoph had, I'll resend to you and linux-scsi.

> But my principle objection, as I've stated before, is that it isn't true
> that we don't need to manage the caches of hot pluggable devices, fibre
> channel being the counter example.

I agree - the type of transport does not indicate the capabilties of the
device. If connectors were free and took no space (yeh never), we would
have usb, firewire, spi, and fcp available on all disk drives.

But for some reason with USB, we are more likely to have devices that
cannot handle mode sense page 8 (cache). So shove some code into the
usb-storage driver, and make it possible to set policy allowing us to
disable page 8 for any device.

Though I do not see the utility in syncing the cache, especially given the
failure to figure out the caching method. 

High end storage won't care (probably battery backed ram, redundant
storage, and separate out-of-band monitoring facilities). 

If the cache sync fails, the best we can do is notify the user, we can't
reissue the write or even tell the user what block failed to make it to
disk, the best we can do is say "your hosed".

-- Patrick Mansfield

Re: Re: USB storage problems on OHCI..

[Linus Torvalds]

On Mon, 22 Sep 2003, David Brownell wrote:
> 
> In this case, because it's not "EHCI + USB 2.0 hub", it's still using
> the OHCI companion controller.  So that wasn't a new case.

Ok. Here's the broken case with an added usb-2 hub in between. It is 
indeed a bit different.

Again, this case worked fine with the sd.c changes, so it does seem to be 
all related to "big" transfers out of the mode page.

		Linus

---
hub 1-4.1:0: new USB device on port 1, assigned address 4

usb-storage: USB Mass Storage device detected
usb-storage: act_altsetting is 0, id_index is 76
usb-storage: -- associate_dev
usb-storage: Transport: Bulk
usb-storage: Protocol: Transparent SCSI
usb-storage: Endpoints: In: 0xe9d80140 Out: 0xe9d80154 Int: 0x00000000 (Period 0)
usb-storage: usb_stor_control_msg: rq=fe rqtype=a1 value=0000 index=00 len=1
usb-storage: GetMaxLUN command result is -32, data is 0
usb-storage: *** thread sleeping.

scsi0 : SCSI emulation for USB Mass Storage devices

usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command INQUIRY (6 bytes)
usb-storage:  12 00 00 00 24 00
usb-storage: Bulk Command S 0x43425355 T 0x1 L 36 F 128 Trg 0 LUN 0 CL 6
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_buf: xfer 36 bytes
usb-storage: Status code 0; transferred 36/36
usb-storage: -- transfer complete
usb-storage: Bulk data transfer result 0x0
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code 0; transferred 13/13
usb-storage: -- transfer complete
usb-storage: Bulk status result = 0
usb-storage: Bulk Status S 0x53425355 T 0x1 R 0 Stat 0x0
usb-storage: Fixing INQUIRY data to show SCSI rev 2 - was 0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command INQUIRY (6 bytes)
usb-storage:  12 00 00 00 25 00
usb-storage: Bulk Command S 0x43425355 T 0x2 L 37 F 128 Trg 0 LUN 0 CL 6
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_buf: xfer 37 bytes
usb-storage: Status code 0; transferred 36/37
usb-storage: -- short transfer
usb-storage: Bulk data transfer result 0x1
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code 0; transferred 13/13
usb-storage: -- transfer complete
usb-storage: Bulk status result = 0
usb-storage: Bulk Status S 0x53425355 T 0x2 R 0 Stat 0x0
usb-storage: Fixing INQUIRY data to show SCSI rev 2 - was 0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.

  Vendor: TOSHIBA   Model: THNCF1G02MA       Rev: 0811
  Type:   Direct-Access                      ANSI SCSI revision: 02

usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage:  00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x3 L 0 F 0 Trg 0 LUN 0 CL 6
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code 0; transferred 13/13
usb-storage: -- transfer complete
usb-storage: Bulk status result = 0
usb-storage: Bulk Status S 0x53425355 T 0x3 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command READ_CAPACITY (10 bytes)
usb-storage:  25 00 00 00 00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x4 L 8 F 128 Trg 0 LUN 0 CL 10
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_buf: xfer 8 bytes
usb-storage: Status code 0; transferred 8/8
usb-storage: -- transfer complete
usb-storage: Bulk data transfer result 0x0
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code 0; transferred 13/13
usb-storage: -- transfer complete
usb-storage: Bulk status result = 0
usb-storage: Bulk Status S 0x53425355 T 0x4 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.

SCSI device sda: 2000880 512-byte hdwr sectors (1024 MB)

usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command MODE_SENSE_10 (10 bytes)
usb-storage:  5a 00 3f 00 00 00 00 00 08 00
usb-storage: Bulk Command S 0x43425355 T 0x5 L 8 F 128 Trg 0 LUN 0 CL 10
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_buf: xfer 8 bytes
usb-storage: Status code 0; transferred 8/8
usb-storage: -- transfer complete
usb-storage: Bulk data transfer result 0x0
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code 0; transferred 13/13
usb-storage: -- transfer complete
usb-storage: Bulk status result = 0
usb-storage: Bulk Status S 0x53425355 T 0x5 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.

sda: Write Protect is off
sda: Mode Sense: 06 00 00 00

usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command MODE_SENSE_10 (10 bytes)
usb-storage:  5a 00 08 00 00 00 00 00 08 00
usb-storage: Bulk Command S 0x43425355 T 0x6 L 8 F 128 Trg 0 LUN 0 CL 10
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_buf: xfer 8 bytes
usb-storage: Status code 0; transferred 8/8
usb-storage: -- transfer complete
usb-storage: Bulk data transfer result 0x0
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code 0; transferred 13/13
usb-storage: -- transfer complete
usb-storage: Bulk status result = 0
usb-storage: Bulk Status S 0x53425355 T 0x6 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command MODE_SENSE_10 (10 bytes)
usb-storage:  5a 00 08 00 00 00 00 00 80 00
usb-storage: Bulk Command S 0x43425355 T 0x7 L 128 F 128 Trg 0 LUN 0 CL 10
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_buf: xfer 128 bytes
usb-storage: Status code -32; transferred 0/128
usb-storage: clearing endpoint halt for pipe 0xc0008480
usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value=0000 index=81 len=0
usb-storage: Timeout -- cancelling URB
usb-storage: usb_stor_clear_halt: result = -104
usb-storage: Bulk data transfer result 0x4
usb-storage: -- transport indicates error, resetting
usb-storage: usb_stor_Bulk_reset called
usb-storage: usb_stor_control_msg: rq=ff rqtype=21 value=0000 index=00 len=0
usb-storage: Timeout -- cancelling URB
usb-storage: Soft reset failed: -104
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command MODE_SENSE_10 (10 bytes)
usb-storage:  5a 00 08 00 00 00 00 00 80 00
usb-storage: Bulk Command S 0x43425355 T 0x8 L 128 F 128 Trg 0 LUN 0 CL 10
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_buf: xfer 128 bytes
usb-storage: Status code -32; transferred 0/128
usb-storage: clearing endpoint halt for pipe 0xc0008480
usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value=0000 index=81 len=0
usb-storage: Timeout -- cancelling URB
usb-storage: usb_stor_clear_halt: result = -104
usb-storage: Bulk data transfer result 0x4
usb-storage: -- transport indicates error, resetting
usb-storage: usb_stor_Bulk_reset called
usb-storage: usb_stor_control_msg: rq=ff rqtype=21 value=0000 index=00 len=0
usb-storage: Timeout -- cancelling URB
usb-storage: Soft reset failed: -104
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command MODE_SENSE_10 (10 bytes)
usb-storage:  5a 00 08 00 00 00 00 00 80 00
usb-storage: Bulk Command S 0x43425355 T 0x9 L 128 F 128 Trg 0 LUN 0 CL 10
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_buf: xfer 128 bytes
usb-storage: Status code -32; transferred 0/128
usb-storage: clearing endpoint halt for pipe 0xc0008480
usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value=0000 index=81 len=0
usb-storage: Timeout -- cancelling URB
usb-storage: usb_stor_clear_halt: result = -104
usb-storage: Bulk data transfer result 0x4
usb-storage: -- transport indicates error, resetting
usb-storage: usb_stor_Bulk_reset called
usb-storage: usb_stor_control_msg: rq=ff rqtype=21 value=0000 index=00 len=0
usb-storage: Timeout -- cancelling URB
usb-storage: Soft reset failed: -104
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command MODE_SENSE_10 (10 bytes)
usb-storage:  5a 00 08 00 00 00 00 00 80 00
usb-storage: Bulk Command S 0x43425355 T 0xa L 128 F 128 Trg 0 LUN 0 CL 10
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: command_abort called
usb-storage: usb_stor_stop_transport called
usb-storage: -- cancelling URB
usb-storage: Status code -104; transferred 0/31
usb-storage: -- transfer cancelled
usb-storage: Bulk command transfer result=4
usb-storage: -- command was aborted
usb-storage: usb_stor_Bulk_reset called
usb-storage: usb_stor_control_msg: rq=ff rqtype=21 value=0000 index=00 len=0
usb-storage: Timeout -- cancelling URB
usb-storage: Soft reset failed: -104
usb-storage: scsi command aborted
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage:  00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0xa L 0 F 0 Trg 0 LUN 0 CL 6
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: command_abort called
usb-storage: usb_stor_stop_transport called
usb-storage: -- cancelling URB
usb-storage: Status code -104; transferred 0/31
usb-storage: -- transfer cancelled
usb-storage: Bulk command transfer result=4
usb-storage: -- command was aborted
usb-storage: usb_stor_Bulk_reset called
usb-storage: usb_stor_control_msg: rq=ff rqtype=21 value=0000 index=00 len=0
usb-storage: Timeout -- cancelling URB
usb-storage: Soft reset failed: -104
usb-storage: scsi command aborted
usb-storage: *** thread sleeping.
usb-storage: device_reset called
usb-storage: usb_stor_Bulk_reset called
usb-storage: usb_stor_control_msg: rq=ff rqtype=21 value=0000 index=00 len=0
usb-storage: Timeout -- cancelling URB
usb-storage: Soft reset failed: -104
usb-storage: bus_reset called



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[David Brownell]

Linus Torvalds wrote:
> On Mon, 22 Sep 2003, David Brownell wrote:
> 
>>In this case, because it's not "EHCI + USB 2.0 hub", it's still using
>>the OHCI companion controller.  So that wasn't a new case.
> 
> 
> Ok. Here's the broken case with an added usb-2 hub in between. It is 
> indeed a bit different.

Yes.  Instead of getting 64/128 bytes transferred, with -EOVERFLOW
reported, it gets 0/128, with -EPIPE.  And the recovery got a bit
confused; it's a STALL but not from the device, it's from the hub.

It might be worth making EHCI use a different code in that case,
if this class of TT-related errors starts to be trouble.


> Again, this case worked fine with the sd.c changes, so it does seem to be 
> all related to "big" transfers out of the mode page.

Or at any rate, "big enough" to confuse the device.

Thanks for the additional test results.

- Dave

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Linus Torvalds]

On Mon, 22 Sep 2003, David Brownell wrote:
> > Again, this case worked fine with the sd.c changes, so it does seem to be 
> > all related to "big" transfers out of the mode page.
> 
> Or at any rate, "big enough" to confuse the device.

Yes. Additional testing (making the code just increase the size of the 
transfer until it fails) shows that a size of 63 still works, but a size 
of 64 bytes fails.

Actually - with a 64-byte transfer, we appear to get the 64 bytes ok, but 
the subsequent CSW status word read fails, so the 64-byte case seems to be 
the one that starts confusing the device.

If I remember right, USB-1 "big packets" are 64 bytes in size, and a 
64-byte bulk transfer would be two packets (one full-sized one, one 
zero-sized one). So this seems to support the notion that the device is 
fine as long as it can fit the whole bulk transfer in just one packet.

Which cleanly explains why EHCI "just worked". 

			Linus

Re: Re: USB storage problems on OHCI..

[Patrick Mansfield]

On Mon, Sep 22, 2003 at 09:09:47AM -0700, Linus Torvalds wrote:

> 
> (Btw, where are the different mode sense pages documented?)
> 

The latest SCSI 3 draft standards are online as follows, the SCSI 2 specs
are also online at www.t10.org (.ORG!).

For block (applies to some USB mass storage) specific pages:

http://www.t10.org/ftp/t10/drafts/sbc/sbc-r08c.pdf

See page 105 section 7.1.3 of the above (table 73 the "Mode page codes").

General MODE SENSE stuff is in:

http://www.t10.org/ftp/t10/drafts/spc3/spc3r15.pdf

See page 151 section 6.9.1 for MODE SENSE, page 261 section 7.4.5 or so
for page codes applying to all devices.

-- Patrick Mansfield


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Linus Torvalds]

On Mon, 22 Sep 2003, Patrick Mansfield wrote:
> On Mon, Sep 22, 2003 at 09:09:47AM -0700, Linus Torvalds wrote:
> > 
> > (Btw, where are the different mode sense pages documented?)
> 
> The latest SCSI 3 draft standards are online as follows, the SCSI 2 specs
> are also online at www.t10.org (.ORG!).
> 
> For block (applies to some USB mass storage) specific pages:
> 
> http://www.t10.org/ftp/t10/drafts/sbc/sbc-r08c.pdf
> 
> See page 105 section 7.1.3 of the above (table 73 the "Mode page codes").

Ok, thanks. In particular, it seems to be pointless to read anything past 
byte 20 - nothing past there is even defined.

What's the general sense of things - for a random SCSI device with bugs 
(and they all have _some_ sort of bugs, let's not just rain on USB here), 
is it saner to try to read just the bytes we need (3 bytes: page code, 
page size and the cache bits), or the full 20 bytes?

		Linus

Re: Re: USB storage problems on OHCI..

[David Brownell]

Linus Torvalds wrote:
> On Mon, 22 Sep 2003, Alan Stern wrote:
> 
>>This problem has been cropping up with many, many USB storage devices.  
> 
> 
> Interesting data-point: the device is a happy EHCI camper, and is totally 
> able to read codepage 8 on EHCI.
> 
> However, if I put it behind a USB-1 hub on the EHCI port, I see the same 
> problems I saw with OHCI.

Can you be more clear?  Is that

    (EHCI/OHCI) root port --> USB 2.0 hub --> USB 1.1 hub --> storage device

Or instead

    (EHCI/OHCI) root port --> USB 1.1 hub --> storage device

The former is certainly using EHCI, and the transaction translator in
that USB 2.0 hub ... but I'd expect it to give a different failure mode.
Maybe the same net result, but a different fault code (not -EOVERFLOW),
and likely different recovery procedure in usb-storage/scsi.

The latter is identical with the OHCI-only case, the only involvement
of EHCI being to hand that port over to the (OHCI) companion.


> So it is somehow related to USB-1 vs USB-2. I don't understand why the 
> device would make a difference for something like mode page 8, but it 
> looks like it transfers data fine for _small_ mode page requests under 
> USB-1, and under USB-2 it works even for big ones.

It could be some kind of logic in the device forgetting that to use
the right maxpacket setting in that specific case.

I'm a bit more used to seeing failures the other way around, where
the storage adapter doesn't quite respond correctly at high speed.

- Dave


> 
> 		Linus
> 
> 




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Linus Torvalds]

On Mon, 22 Sep 2003, David Brownell wrote:
>
> Linus Torvalds wrote:
> > Interesting data-point: the device is a happy EHCI camper, and is
> > totally able to read codepage 8 on EHCI.
> > 
> > However, if I put it behind a USB-1 hub on the EHCI port, I see the
> > same problems I saw with OHCI.
> 
> Can you be more clear?

That is with the exact same external port on the computer, but with an
added external (old) USB 1 hub in between. I have no idea how the internal
EHCI logic switching ends up working, so I'll just append the full
/proc/bus/usb/devices output for you to judge.

(this is from a kernel that actually is able to access the device
correctly, by virtue of the sd.c change I outlined in the previous email).

			Linus

----

T:  Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.0-test5 uhci-hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.2
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc= 11/900 us ( 1%), #Int=  1, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.0-test5 uhci-hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.1
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  2 Spd=12  MxCh= 4
D:  Ver= 1.00 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0451 ProdID=1446 Rev= 1.00
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=255ms

T:  Bus=03 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#=  4 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=05e3 ProdID=0703 Rev= 0.04
S:  Product=USB TO IDE
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 96mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms

T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.0-test5 uhci-hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.0
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
D:  Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=04f9 ProdID=0100 Rev= 1.00
C:* #Ifs= 3 Cfg#= 1 Atr=40 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=07(print) Sub=01 Prot=02 Driver=usblp
E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  16 Ivl=0ms
I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=03(O) Atr=02(Bulk) MxPS=  16 Ivl=0ms
E:  Ad=84(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=05(O) Atr=02(Bulk) MxPS=  16 Ivl=0ms
E:  Ad=86(I) Atr=02(Bulk) MxPS=  16 Ivl=0ms

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480 MxCh= 6
B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.0-test5 ehci_hcd
S:  Product=EHCI Host Controller
S:  SerialNumber=0000:00:1d.7
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=256ms

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Martin Diehl]

On Mon, 22 Sep 2003, David Brownell wrote:

> > So it is somehow related to USB-1 vs USB-2. I don't understand why the 
> > device would make a difference for something like mode page 8, but it 
> > looks like it transfers data fine for _small_ mode page requests under 
> > USB-1, and under USB-2 it works even for big ones.
> 
> It could be some kind of logic in the device forgetting that to use
> the right maxpacket setting in that specific case.

Just a wild guess: If the device misbehaved on HS/FS transition and would 
send packets >64 bytes in FS mode, I think it would explain the babble 
issue:

* the 128 byte read which reported babble was the first IN transfer >64 
  byte and the babble condition was reported after receiving 64 bytes, 
  i.e. at a point where the HC has stored _less_ data than expected!

* limiting the transfer length to 64 bytes made the babble disappear

* works with EHCI because HS can handle bigger packets

Unfortunately I don't see an easy way to check the sourced packed size on 
the wire - except using a bus analyzer of course.

I'm not sure how uhci behaves with packets exceeding FS max packet size - 
if it doesn't fit into the read buffer it should report babble as well - 
but what if the buffer is big enough and it's just the packet is to big? 
IIRC the TD's actlen is 11-bit anyway. Could it be this device (mis)uses 
HS maxpacket when operating at fullspeed?

Martin

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[David Brownell]

Martin Diehl wrote:

> Unfortunately I don't see an easy way to check the sourced packed size on 
> the wire - except using a bus analyzer of course.

Right.  There are not-easy ways to do this, involving tricked out
host controller drivers usable only to debug things like this, but
I wouldn't want to go there myself!  :)

- Dave

Re: Re: USB storage problems on OHCI..

[Patrick Mansfield]

On Mon, Sep 22, 2003 at 11:50:47AM -0400, Alan Stern wrote:

> Interestingly, my original patch was a lot like you describe.  It can be 
> found in
> 
> http://marc.theaimsgroup.com/?l=linux-scsi&m=106340167723122&w=2
> 
> Patrick Mansfield later beefed it up to the version you were looking at.
> 
> I don't care which version of the patch gets accepted, so long as
> _something_ is done.  Patrick, what do you think?

I would rather we can modify the flags for any broken device and override
a host's setting for known functioning devices. But let's get some patch
applied.

If there is a problem (per Linus' post) in the USB transport this isn't a
real fix.

-- Patrick Mansfield


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Alan Stern]

On Mon, 22 Sep 2003, Patrick Mansfield wrote:

> On Mon, Sep 22, 2003 at 11:50:47AM -0400, Alan Stern wrote:
> 
> > I don't care which version of the patch gets accepted, so long as
> > _something_ is done.  Patrick, what do you think?
> 
> I would rather we can modify the flags for any broken device and override
> a host's setting for known functioning devices. But let's get some patch
> applied.

Yes.  But be sure to allow host drivers to adjust the flag within
slave_config(); slave_alloc() may be too early.  (Although since sd.c is 
the only driver that uses the flag, I guess it doesn't matter.)

> If there is a problem (per Linus' post) in the USB transport this isn't a
> real fix.

The problems that Linus and many other people are seeing aren't in the USB 
transport; they are bugs in the device firmware.  These bugs manifest as 
errors reported by the transport drivers.

Alan Stern

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Alan Stern]

This problem has been cropping up with many, many USB storage devices.  
They just don't handle MODE-SENSE page 8 correctly.  Some devices are okay
with a 128-byte transfer and others aren't.  Some are okay with a 64-byte
transfer and others aren't.  Some are okay transferring the actual size of
the page (as given in the header) and others aren't.  Some are okay
transferring the minimum amount we actually need (12 bytes IIRC) and
others aren't.

Although it may not directly address all the problems that Linus observed,
a solution has been floating around in the linux-scsi and usb-storage
development lists.  It looks to me like it's ready to be merged, although
no one has done so yet.  Basically, it amounts to a per-device flag that
can be inherited by default from the host template or set/cleared
specifically by the host driver, rather like the flag for using 10-byte
READ/WRITE commands.  The flag tells sd.c not to ask for page 8 but to
assume a write-through cache.  The patch is in

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

At the moment, this MODE-SENSE page 8 is probably the most severe 
outstanding problem with the usb-storage driver.  I'm all in favor of the 
patch being adopted (hint, hint...).

I've been assuming that the "babble" problem arises because the device
either tries to send more than 128 bytes of mode-sense data or because it
tries to send the data and the subsequent 13-byte status in the same
packet.  Whether or not this would be detected as an error depends on the
maxpacket size, which depends on the speed of the USB bus.  (Maybe the
device even tries to send an over-sized packet.)  Of course, it's always
possible that reading page 8 just triggers a bug in the device firmware,
and from then on it's all over.

On Mon, 22 Sep 2003, Matthew Dharm wrote:

> You say this worked with UHCI 'some time ago'?  Perhaps that was before all
> this mode page 8 stuff got settled?

The MODE-SENSE page 8 stuff was added sometime during the 2.5 development 
cycle.  Before it was put in, quite likely the device would have worked 
fine with UHCI.

Alan Stern

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Christoph Hellwig]

On Mon, Sep 22, 2003 at 10:25:28AM -0400, Alan Stern wrote:
> http://marc.theaimsgroup.com/?l=linux-scsi&m=106366112221507&w=2
> 
> At the moment, this MODE-SENSE page 8 is probably the most severe 
> outstanding problem with the usb-storage driver.  I'm all in favor of the 
> patch being adopted (hint, hint...).

Patch looks mostly fine to me, but please all flags should be unsigned instead
of signed and scsi_devinfo.h needs some inclusion guards.

Re: Re: USB storage problems on OHCI..

[Christoph Hellwig]

On Mon, Sep 22, 2003 at 03:31:24PM +0100, Christoph Hellwig wrote:
> Patch looks mostly fine to me, but please all flags should be unsigned instead
> of signed and scsi_devinfo.h needs some inclusion guards.

Actually I think it could be made much simpler by killing the per-template
bflags and just setting the scsi_device flags from slave_alloc or
slave_configure.  Could you cook up a patch like that?



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: Re: USB storage problems on OHCI..

[Patrick Mansfield]

On Mon, Sep 22, 2003 at 04:11:04PM +0100, Christoph Hellwig wrote:
> On Mon, Sep 22, 2003 at 03:31:24PM +0100, Christoph Hellwig wrote:
> > Patch looks mostly fine to me, but please all flags should be unsigned instead
> > of signed and scsi_devinfo.h needs some inclusion guards.
> 
> Actually I think it could be made much simpler by killing the per-template
> bflags and just setting the scsi_device flags from slave_alloc or
> slave_configure.  Could you cook up a patch like that?

You mean add the flags to scsi_device rather than scsi_host?
And allow setting the sdev->flags only in slave_alloc.

I can modify the patch for that.

-- Patrick Mansfield


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Linus Torvalds]

[ Andries added to the cc ]

On Mon, 22 Sep 2003, Patrick Mansfield wrote:
> 
> I can modify the patch for that.

How about just making the sd.c layer more robust? That has worked well in 
the past, and it seems wrong to have to add more and more flags.

In particular, while hunting down the usb-1/usb-2 differences, it became
clear that all the mode sense transfers that _worked_ under usb-1 were
short. With 64 bytes than with 128 bytes it no longer babbled, and the
whole thing worked fine with 11 bytes (the minimum required to get the
caching status).

Adding some printk's showed that the initial (successful) 4-byte page read
resulted in:

 - page len=1538 (pretty obviously crap)
 - header len=8 (correct)
 - block descriptor len=0 (correct)

and the thing is, we were using the "pretty obviously crap" value for 
judging the size of the thing.

So my suggestion would be to just replace that usage (in sd.c):

	len = data.length;
	if (len > 128)
		len = 128;

with something like this instead:

	/* We need three bytes past the block descriptor length */
	len = data.header_length + data.block_descriptor_length + 3;

	/* Sanity check */
	if (len > data.len || len < 11 || len > 128)
		.. fail ..

Basically, Andries Brouwer's strategy of making sd.c more conservative has
been a very successful one in the past. Why not continue on that?

(Btw, where are the different mode sense pages documented?)

		Linus

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Christoph Hellwig]

On Mon, Sep 22, 2003 at 08:49:30AM -0700, Patrick Mansfield wrote:
> On Mon, Sep 22, 2003 at 04:11:04PM +0100, Christoph Hellwig wrote:
> > On Mon, Sep 22, 2003 at 03:31:24PM +0100, Christoph Hellwig wrote:
> > > Patch looks mostly fine to me, but please all flags should be unsigned instead
> > > of signed and scsi_devinfo.h needs some inclusion guards.
> > 
> > Actually I think it could be made much simpler by killing the per-template
> > bflags and just setting the scsi_device flags from slave_alloc or
> > slave_configure.  Could you cook up a patch like that?
> 
> You mean add the flags to scsi_device rather than scsi_host?
> And allow setting the sdev->flags only in slave_alloc.

What I meant is not adding a blist flags member at all but rather
setting skip_ms_page_8 and skip_ms_page_3f from ->slave_alloc.

But I probably missed something obvious :)

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Patrick Mansfield]

On Mon, Sep 22, 2003 at 05:37:32PM +0100, Christoph Hellwig wrote:
> 
> What I meant is not adding a blist flags member at all but rather
> setting skip_ms_page_8 and skip_ms_page_3f from ->slave_alloc.
> 
> But I probably missed something obvious :)

The current code allows us to set or clear a given bit, but not both. So
if we set them in slave_alloc, they can't be cleared without adding
other flags or code.

-- Patrick Mansfield

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Christoph Hellwig]

On Mon, Sep 22, 2003 at 09:44:04AM -0700, Patrick Mansfield wrote:
> The current code allows us to set or clear a given bit, but not both. So
> if we set them in slave_alloc, they can't be cleared without adding
> other flags or code.

If we want drivers to mess with blist flags that's the more general
solution, yes.  But the blist flags really are a target thing and
I'd prefer to keep host drivers a bit away from this.  Of course
this doesn't really work for the usb case where the host driver only
deals with emulated targets that are all completly hosed.

Maybe sdev->scsi_level should recognize a new level, SCSI_TOTALLY_B0RKED
for those usb-storage devices where the vendor somehow heard of the
spec but nothing that isn't excercised by the windows drivers has
the slightest chance of working..

> 
> -- Patrick Mansfield
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
---end quoted text---

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Alan Stern]

On Mon, 22 Sep 2003, Christoph Hellwig wrote:

> If we want drivers to mess with blist flags that's the more general
> solution, yes.  But the blist flags really are a target thing and
> I'd prefer to keep host drivers a bit away from this.  Of course
> this doesn't really work for the usb case where the host driver only
> deals with emulated targets that are all completly hosed.
> 
> Maybe sdev->scsi_level should recognize a new level, SCSI_TOTALLY_B0RKED
> for those usb-storage devices where the vendor somehow heard of the
> spec but nothing that isn't excercised by the windows drivers has
> the slightest chance of working..

Please be careful when setting this up.  The mode-sense pages are vitally
important for USB CD devices, and they all seem to work fine.  It's just
the disk-type devices that have been causing trouble.

Many of them seem to share the failure mode observed by Linus: when asked
to send 128 bytes of m-s page 8 they apparently forget that the connection
is only full-speed with a 64-byte packet maximum, and they try to send all
128 bytes in a single packet.  But other failure modes have cropped up as
well.

Alan Stern

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Alan Stern]

On Mon, 22 Sep 2003, Christoph Hellwig wrote:

> On Mon, Sep 22, 2003 at 03:31:24PM +0100, Christoph Hellwig wrote:
> > Patch looks mostly fine to me, but please all flags should be unsigned instead
> > of signed and scsi_devinfo.h needs some inclusion guards.
> 
> Actually I think it could be made much simpler by killing the per-template
> bflags and just setting the scsi_device flags from slave_alloc or
> slave_configure.  Could you cook up a patch like that?

Interestingly, my original patch was a lot like you describe.  It can be 
found in

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

Patrick Mansfield later beefed it up to the version you were looking at.

I don't care which version of the patch gets accepted, so long as
_something_ is done.  Patrick, what do you think?

Alan Stern

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[Linus Torvalds]

On Mon, 22 Sep 2003, Alan Stern wrote:
>
> This problem has been cropping up with many, many USB storage devices.  

Interesting data-point: the device is a happy EHCI camper, and is totally 
able to read codepage 8 on EHCI.

However, if I put it behind a USB-1 hub on the EHCI port, I see the same 
problems I saw with OHCI.

So it is somehow related to USB-1 vs USB-2. I don't understand why the 
device would make a difference for something like mode page 8, but it 
looks like it transfers data fine for _small_ mode page requests under 
USB-1, and under USB-2 it works even for big ones.

		Linus