What is SCSI command 0xa0 ?

What is SCSI command 0xa0 ?

[Alan Stern]

Can anybody tell me what this CDB is supposed to do, when issued to a 
direct-access device (a disk drive)?

	a0 00 00 00 00 00 00 00 10 00 00 00

It's crashing the firmware on Samuel's disk and generally causing 
problems.  The command gets sent right after the partition table is 
read.

Equally important, can someone suggest how to suppress the command?

Thanks,

Alan Stern

P.S.: Samuel, that one command seems to be causing all your problems.  
For some reason it gets sent to the lacie1 disk and not to the lacieroot
disk.  I think the USB controller is working okay and has nothing to do 
with this.  Maybe the command is sent by some daemon running on the 
openbrick system, like hald.  Is there a hald process, and if you kill the 
process does the disk then start working?

Re: What is SCSI command 0xa0 ?

[Doug Maxey]

On Mon, 14 Feb 2005 16:07:05 EST, Alan Stern wrote:
>Can anybody tell me what this CDB is supposed to do, when issued to a 
>direct-access device (a disk drive)?
>
>	a0 00 00 00 00 00 00 00 10 00 00 00

Looks like an ATAPI TUR.

>
>It's crashing the firmware on Samuel's disk and generally causing 
>problems.  The command gets sent right after the partition table is 
>read.
>
>Equally important, can someone suggest how to suppress the command?
>
>Thanks,
>
>Alan Stern
>
>P.S.: Samuel, that one command seems to be causing all your problems.  
>For some reason it gets sent to the lacie1 disk and not to the lacieroot
>disk.  I think the USB controller is working okay and has nothing to do 
>with this.  Maybe the command is sent by some daemon running on the 
>openbrick system, like hald.  Is there a hald process, and if you kill the 
>process does the disk then start working?
>
>-
>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
>

Re: What is SCSI command 0xa0 ?

[Matthias Andree]

Alan Stern <stern@rowland.harvard.edu> writes:

> Can anybody tell me what this CDB is supposed to do, when issued to a 
> direct-access device (a disk drive)?
>
> 	a0 00 00 00 00 00 00 00 10 00 00 00
>
> It's crashing the firmware on Samuel's disk and generally causing 
> problems.  The command gets sent right after the partition table is 
> read.

"REPORT LUNS". This is probably only useful on media changers and
perhaps disk arrays.

-- 
Matthias Andree

Re: What is SCSI command 0xa0 ?

[Patrick Mansfield]

On Mon, Feb 14, 2005 at 10:27:46PM +0100, Matthias Andree wrote:

> "REPORT LUNS". This is probably only useful on media changers and
> perhaps disk arrays.

Yes. 

You can disable it completely or just for the broken device.

BLIST_NOREPORTLUN is 0x40000. On boot or scsi_mod loading, to disable for
all devices:

        [scsi_mod.]default_dev_flags=0x40000

Or for one device:

        [scsi_mod.]dev_flags="vendor:model:0x40000"

Or for one device via /proc after scsi_mod is running:

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

-- Patrick Mansfield

Re: What is SCSI command 0xa0 ?

[Douglas Gilbert]

Matthias Andree wrote:
> Alan Stern <stern@rowland.harvard.edu> writes:
> 
> 
>>Can anybody tell me what this CDB is supposed to do, when issued to a 
>>direct-access device (a disk drive)?
>>
>>	a0 00 00 00 00 00 00 00 10 00 00 00
>>
>>It's crashing the firmware on Samuel's disk and generally causing 
>>problems.  The command gets sent right after the partition table is 
>>read.
> 
> 
> "REPORT LUNS". This is probably only useful on media changers and
> perhaps disk arrays.

... and current SCSI drafts flag support for REPORT LUNS
as mandatory for _all_ device types. I suspect that some
members of t10.org would prefer support to be optional.

Doug Gilbert

Re: What is SCSI command 0xa0 ?

[Samuel Colin]

The Mon, 14 Feb 2005 16:34:39 -0500 (EST)
Alan Stern <stern@rowland.harvard.edu> wrote:

> kernel:   Vendor: WDC WD25  Model: 00JB-00FUA0       Rev: 15.0
> kernel:   Type:   Direct-Access                      ANSI SCSI revision:
> 04
> 
> Since it claims to be SCSI revision 04, the command was sent.  But your 
> drive couldn't handle it and choked.
> 
> It's possible to prevent the SCSI driver from sending the REPORT_LUNS 
> command to your drive.  You can try this out by typing (as root):
> 
> 	echo 'WDC WD25:00JB-00FUA0:0x01' >/proc/scsi/device_info
> 
> before plugging in the drive.  If that solves the problem, it can be added
> permanently into the SCSI driver source code.
> 
OK, I just made the following tests :
- Plugged the disk and booted the openbrick
- Did the echo above
- Modprobed ehci-hcd and usb-storage
- Mounted the disk
- Made the copy of an iso image from /home (who is nfs mounted) to
/mnt/lacie1...

Absolutely no error, no odd display on the command line. Thus I guess we can
say the problem is solved so far.

You guys are wizards, you save my (geeky :-) life. I would hug you if I
could ! Also, realize that these openbricks can't have an IDE disk, and are
sometimes sold with lacie disks, so that might help other people.
What puzzles me is that a 2.6.8 kernel didn't exhibit this behaviour for the
same disk on another machine (and thus another usb2 chipset, but as that
wasn't the cause of the problem...)

In conclusion, I think that the patches from usb-devel I had applied solved
usb2 problems that had really happened (but now are solved), but some code
change introduced scsi errors (hence the working 2.6.8 kernel I tell about
above)... I don't really know, after all you're the experts.

USB devel and SCSI dev lists in Cc:

Many thanks,
Samuel Colin

Re: What is SCSI command 0xa0 ?

[Alan Stern]

On Mon, 14 Feb 2005, Samuel Colin wrote:

> OK, I just made the following tests :
> - Plugged the disk and booted the openbrick
> - Did the echo above
> - Modprobed ehci-hcd and usb-storage
> - Mounted the disk
> - Made the copy of an iso image from /home (who is nfs mounted) to
> /mnt/lacie1...
> 
> Absolutely no error, no odd display on the command line. Thus I guess we can
> say the problem is solved so far.

Good.  The patch below ought to accomplish the same thing as that "echo" 
command.  You can try patching your kernel and make sure that it really 
works.  If it does, I'll submit the patch for official inclusion in the 
kernel.

> What puzzles me is that a 2.6.8 kernel didn't exhibit this behaviour for the
> same disk on another machine (and thus another usb2 chipset, but as that
> wasn't the cause of the problem...)

I don't know why.  Do you want to turn on usb-storage verbose debugging in
the 2.6.8 kernel, and run it on that other machine?

> In conclusion, I think that the patches from usb-devel I had applied solved
> usb2 problems that had really happened (but now are solved), but some code
> change introduced scsi errors (hence the working 2.6.8 kernel I tell about
> above)... I don't really know, after all you're the experts.

It's hard to say, since there are so many things being changed all the
time.  But if the REPORT_LUNS command worked under 2.6.8 and failed under
2.6.11, it would be worthwhile to know why.

Alan Stern


===== drivers/scsi/scsi_devinfo.c 1.14 vs edited =====
--- 1.14/drivers/scsi/scsi_devinfo.c	2004-12-10 11:54:56 -05:00
+++ edited/drivers/scsi/scsi_devinfo.c	2005-02-16 11:30:56 -05:00
@@ -201,6 +201,7 @@
 	{"WangDAT", "Model 2600", "01.7", BLIST_SELECT_NO_ATN},
 	{"WangDAT", "Model 3200", "02.2", BLIST_SELECT_NO_ATN},
 	{"WangDAT", "Model 1300", "02.4", BLIST_SELECT_NO_ATN},
+	{"WDC WD25", "00JB-00FUA0", NULL, BLIST_NOREPORTLUN},
 	{"XYRATEX", "RS", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
 	{"Zzyzx", "RocketStor 500S", NULL, BLIST_SPARSELUN},
 	{"Zzyzx", "RocketStor 2000", NULL, BLIST_SPARSELUN},

Re: What is SCSI command 0xa0 ?

[Samuel Colin]

The Wed, 16 Feb 2005 11:42:18 -0500 (EST)
Alan Stern <stern@rowland.harvard.edu> wrote:

> Good.  The patch below ought to accomplish the same thing as that "echo" 
> command.  You can try patching your kernel and make sure that it really 
> works.  If it does, I'll submit the patch for official inclusion in the 
> kernel.
> 
I recompiled the kernel with the patch, and deactivated the debugging (to
avoid any possible slowing of the tests). After modprobing the needed
modules (ehci-hcd and usb-storage), I mounted the disks (no error, as
expected) and did the following :
- Copied about 12 Go of datas from lacie1 to lacieroot (at at least 20Mo/s,
so it didn't take long)
- Made an md5sum for all the copied files at the same time on lacie1 and
lacieroot. The resulting sums were exactly the same.
So if it doesn't look like a successful test, I don't know what does.

> I don't know why.  Do you want to turn on usb-storage verbose debugging in
> the 2.6.8 kernel, and run it on that other machine?
> [...]
> It's hard to say, since there are so many things being changed all the
> time.  But if the REPORT_LUNS command worked under 2.6.8 and failed under
> 2.6.11, it would be worthwhile to know why.
> 
OK, I will do and send the debug logs asap.

linux-usb-devel and linux-scsi (as they might be interested in the test
results for the 2.6.8 kernel) in Cc:

Regards,
Samuel Colin

Magical ansi scsi revision (was Re: [linux-usb-devel] Re: What is SCSI command 0xa0 ?)

[Samuel Colin]

The Thu, 17 Feb 2005 16:59:40 +0100
Samuel Colin <Samuel.Colin3@wanadoo.fr> wrote:

> > I don't know why.  Do you want to turn on usb-storage verbose debugging
> > in the 2.6.8 kernel, and run it on that other machine?
> > [...]
> > It's hard to say, since there are so many things being changed all the
> > time.  But if the REPORT_LUNS command worked under 2.6.8 and failed
> > under 2.6.11, it would be worthwhile to know why.
> > 
> OK, I will do and send the debug logs asap.
> 
> linux-usb-devel and linux-scsi (as they might be interested in the test
> results for the 2.6.8 kernel) in Cc:
> 
OK, I put the logs here : 
http://sjdcolin.free.fr/tmp/scsi-problem.tgz
Actually the different logs are inclusive (I did not erase the previous log
informations :-/ ). I made the test with 2.6.8-test (thus the 2.6.8 with
debugging on) and 2.6.10-test. These kernels are Debian ones, but I don't
think there are patches that would parasite the results. 
The results surprised me, thus I did a test with 2.6.8 on the openbrick, and
actually lacie1 (the disk that caused problems). Thus I guess that my
machine hanged back then because both disks were usb and debugging was
turned on. Hence, any "big" test (a big copy) could cause problems related
to overloading of the disk where the root mount point was located.

Anyway, I have interesting results for the scsi devel list : 


Feb 17 21:19:09 gnondpom kernel: scsi0 : SCSI emulation for USB Mass Storage
devices 
Feb 17 21:19:09 gnondpom kernel:   Vendor: WDC WD25  Model:
00JB-00FUA0       Rev: 15.0 
Feb 17 21:19:09 gnondpom kernel:   Type:  
Direct-Access                      ANSI SCSI revision: 02


Feb 17 21:26:10 gnondpom kernel: scsi0 : SCSI emulation for USB Mass Storage
devices 
Feb 17 21:26:15 gnondpom kernel:   Vendor: WDC WD25  Model:
00JB-00FUA0       Rev: 15.0 
Feb 17 21:26:15 gnondpom kernel:   Type:  
Direct-Access                      ANSI SCSI revision: 04

It means that for a 2.6.8 kernel, the revision is 02 (then no report_luns
causing problems), while for a 2.6.10, the revision is 04. As I don't think
the firmware of the disk upgrades itself magically depending on the running
kernel, does anyone have an idea why the numbers reported are different ?

I only put scsi-dev in Cc:, as nothing is really of concern for the
usb-devel list (I guess).

Regards,
Samuel Colin

Re: Magical ansi scsi revision (was Re: [linux-usb-devel] Re: What is SCSI command 0xa0 ?)

[Alan Stern]

On Thu, 17 Feb 2005, Samuel Colin wrote:

> Anyway, I have interesting results for the scsi devel list : 
> 
> 
> Feb 17 21:19:09 gnondpom kernel: scsi0 : SCSI emulation for USB Mass Storage
> devices 
> Feb 17 21:19:09 gnondpom kernel:   Vendor: WDC WD25  Model:
> 00JB-00FUA0       Rev: 15.0 
> Feb 17 21:19:09 gnondpom kernel:   Type:  
> Direct-Access                      ANSI SCSI revision: 02
> 
> 
> Feb 17 21:26:10 gnondpom kernel: scsi0 : SCSI emulation for USB Mass Storage
> devices 
> Feb 17 21:26:15 gnondpom kernel:   Vendor: WDC WD25  Model:
> 00JB-00FUA0       Rev: 15.0 
> Feb 17 21:26:15 gnondpom kernel:   Type:  
> Direct-Access                      ANSI SCSI revision: 04
> 
> It means that for a 2.6.8 kernel, the revision is 02 (then no report_luns
> causing problems), while for a 2.6.10, the revision is 04. As I don't think
> the firmware of the disk upgrades itself magically depending on the running
> kernel, does anyone have an idea why the numbers reported are different ?

Well, that explains why you had problems starting with 2.6.10!

The explanation is simple enough, and it can be found in a line from your 
logs:

Feb 17 21:19:09 gnondpom kernel: usb-storage: Fixing INQUIRY data to show SCSI rev 2 - was 4

Back in 2.6.8, the usb-storage driver would automatically change the SCSI 
revision of any device to 2.  In 2.6.10 it doesn't do that if the actual 
revision is > 2.

Alan Stern

[PATCH as470] Add a NOREPORTLUN blacklist flag

[Alan Stern]

James:

This patch adds a NOREPORTLUN blacklist flag for a disk made by "WDC" 
(Winchester?).  The drive's firmware crashes when it receives REPORT_LUNS, 
even though it claims to be SCSI rev 04.

Alan Stern



Signed-off-by: Alan Stern <stern@rowland.harvard.edu>

===== drivers/scsi/scsi_devinfo.c 1.14 vs edited =====
--- 1.14/drivers/scsi/scsi_devinfo.c	2004-12-10 11:54:56 -05:00
+++ edited/drivers/scsi/scsi_devinfo.c	2005-02-16 11:30:56 -05:00
@@ -201,6 +201,7 @@
 	{"WangDAT", "Model 2600", "01.7", BLIST_SELECT_NO_ATN},
 	{"WangDAT", "Model 3200", "02.2", BLIST_SELECT_NO_ATN},
 	{"WangDAT", "Model 1300", "02.4", BLIST_SELECT_NO_ATN},
+	{"WDC WD25", "00JB-00FUA0", NULL, BLIST_NOREPORTLUN},
 	{"XYRATEX", "RS", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
 	{"Zzyzx", "RocketStor 500S", NULL, BLIST_SPARSELUN},
 	{"Zzyzx", "RocketStor 2000", NULL, BLIST_SPARSELUN},

Re: Magical ansi scsi revision (was Re: [linux-usb-devel] Re: What is SCSI command 0xa0 ?)

[Samuel Colin]

The Thu, 17 Feb 2005 17:23:54 -0500 (EST)
Alan Stern <stern@rowland.harvard.edu> wrote:

> Well, that explains why you had problems starting with 2.6.10!
> 
> The explanation is simple enough, and it can be found in a line from your 
> logs:
> 
> Feb 17 21:19:09 gnondpom kernel: usb-storage: Fixing INQUIRY data to show
> SCSI rev 2 - was 4
> 
> Back in 2.6.8, the usb-storage driver would automatically change the SCSI 
> revision of any device to 2.  In 2.6.10 it doesn't do that if the actual 
> revision is > 2.
> 
Then it explains a lot. I see you have sent a patch for the REPORT_LUNS
problems. On my part all seem to work well so I can not do much more :-).
Here is the product page of the offending disk : 

http://www.lacie.com/products/product.htm?pid=10025

As usb (and firewire) disks will become more popular, I guess the scsi-dev
list should expect more problems of this kind :-(

Anyway, many thanks for your kindness and your reactivity (you and both
lists) :-)

Regards,
Samuel Colin

Re: [PATCH as470] Add a NOREPORTLUN blacklist flag

[Sergey Vlasov]

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

On Thu, 17 Feb 2005 17:31:04 -0500 (EST) Alan Stern wrote:

> James:
> 
> This patch adds a NOREPORTLUN blacklist flag for a disk made by "WDC" 
> (Winchester?).  The drive's firmware crashes when it receives
> REPORT_LUNS,  even though it claims to be SCSI rev 04.
> 
> Alan Stern
> 
> 
> 
> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> 
> ===== drivers/scsi/scsi_devinfo.c 1.14 vs edited =====
> --- 1.14/drivers/scsi/scsi_devinfo.c	2004-12-10 11:54:56 -05:00
> +++ edited/drivers/scsi/scsi_devinfo.c	2005-02-16 11:30:56 -05:00
> @@ -201,6 +201,7 @@
>  	{"WangDAT", "Model 2600", "01.7", BLIST_SELECT_NO_ATN},
>  	{"WangDAT", "Model 3200", "02.2", BLIST_SELECT_NO_ATN},
>  	{"WangDAT", "Model 1300", "02.4", BLIST_SELECT_NO_ATN},
> +	{"WDC WD25", "00JB-00FUA0", NULL, BLIST_NOREPORTLUN},

This does not look like a right solution.  WD2500JB is an IDE disk made
by Western Digital:

http://www.wdc.com/en/products/Products.asp?DriveID=42

Therefore the problematic LaCie device is really an USB/Firewire-to-IDE
adapter with the WD2500JB drive in a box.  And it is the USB-IDE part
which fails on the REPORT_LUNS command, not the IDE disk.  Probably
there are other LaCie devices with the same adapter but different disks
inside; adding all such IDE disks to the SCSI blacklist does not seem
like a good solution.  The usb-storage blacklist seems like a better
place for such entry.

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

Re: [PATCH as470] Add a NOREPORTLUN blacklist flag

[Alan Stern]

On Sun, 20 Feb 2005, Sergey Vlasov wrote:

> On Thu, 17 Feb 2005 17:31:04 -0500 (EST) Alan Stern wrote:
> 
> > James:
> > 
> > This patch adds a NOREPORTLUN blacklist flag for a disk made by "WDC" 
> > (Winchester?).  The drive's firmware crashes when it receives
> > REPORT_LUNS,  even though it claims to be SCSI rev 04.
> > 
> > Alan Stern
> > 
> > 
> > 
> > Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> > 
> > ===== drivers/scsi/scsi_devinfo.c 1.14 vs edited =====
> > --- 1.14/drivers/scsi/scsi_devinfo.c	2004-12-10 11:54:56 -05:00
> > +++ edited/drivers/scsi/scsi_devinfo.c	2005-02-16 11:30:56 -05:00
> > @@ -201,6 +201,7 @@
> >  	{"WangDAT", "Model 2600", "01.7", BLIST_SELECT_NO_ATN},
> >  	{"WangDAT", "Model 3200", "02.2", BLIST_SELECT_NO_ATN},
> >  	{"WangDAT", "Model 1300", "02.4", BLIST_SELECT_NO_ATN},
> > +	{"WDC WD25", "00JB-00FUA0", NULL, BLIST_NOREPORTLUN},
> 
> This does not look like a right solution.  WD2500JB is an IDE disk made
> by Western Digital:
> 
> http://www.wdc.com/en/products/Products.asp?DriveID=42
> 
> Therefore the problematic LaCie device is really an USB/Firewire-to-IDE
> adapter with the WD2500JB drive in a box.  And it is the USB-IDE part
> which fails on the REPORT_LUNS command, not the IDE disk.  Probably
> there are other LaCie devices with the same adapter but different disks
> inside; adding all such IDE disks to the SCSI blacklist does not seem
> like a good solution.  The usb-storage blacklist seems like a better
> place for such entry.

You are quite correct.  In fact, another user with a different brand of 
USB-IDE converter just wrote in with exactly the same problem.

James, please withdraw the patch above.

Matt, it looks like the best way to solve this problem is to go back to
the old strategy of always setting the SCSI revision to 2 (no matter what
it might actually be), at least for Direct Access devices.  That would
suppress the REPORT_LUNS command.  Would we lose anything by doing this?

Alan Stern

Re: [PATCH as470] Add a NOREPORTLUN blacklist flag

[Matthew Dharm]

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

On Sun, Feb 20, 2005 at 10:44:21PM -0500, Alan Stern wrote:
> On Sun, 20 Feb 2005, Sergey Vlasov wrote:
> 
> > On Thu, 17 Feb 2005 17:31:04 -0500 (EST) Alan Stern wrote:
> > 
> > > James:
> > > 
> > > This patch adds a NOREPORTLUN blacklist flag for a disk made by "WDC" 
> > > (Winchester?).  The drive's firmware crashes when it receives
> > > REPORT_LUNS,  even though it claims to be SCSI rev 04.
> > > 
> > > Alan Stern
> > > 
> > > 
> > > 
> > > Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> > > 
> > > ===== drivers/scsi/scsi_devinfo.c 1.14 vs edited =====
> > > --- 1.14/drivers/scsi/scsi_devinfo.c	2004-12-10 11:54:56 -05:00
> > > +++ edited/drivers/scsi/scsi_devinfo.c	2005-02-16 11:30:56 -05:00
> > > @@ -201,6 +201,7 @@
> > >  	{"WangDAT", "Model 2600", "01.7", BLIST_SELECT_NO_ATN},
> > >  	{"WangDAT", "Model 3200", "02.2", BLIST_SELECT_NO_ATN},
> > >  	{"WangDAT", "Model 1300", "02.4", BLIST_SELECT_NO_ATN},
> > > +	{"WDC WD25", "00JB-00FUA0", NULL, BLIST_NOREPORTLUN},
> > 
> > This does not look like a right solution.  WD2500JB is an IDE disk made
> > by Western Digital:
> > 
> > http://www.wdc.com/en/products/Products.asp?DriveID=42
> > 
> > Therefore the problematic LaCie device is really an USB/Firewire-to-IDE
> > adapter with the WD2500JB drive in a box.  And it is the USB-IDE part
> > which fails on the REPORT_LUNS command, not the IDE disk.  Probably
> > there are other LaCie devices with the same adapter but different disks
> > inside; adding all such IDE disks to the SCSI blacklist does not seem
> > like a good solution.  The usb-storage blacklist seems like a better
> > place for such entry.
> 
> You are quite correct.  In fact, another user with a different brand of 
> USB-IDE converter just wrote in with exactly the same problem.
> 
> James, please withdraw the patch above.
> 
> Matt, it looks like the best way to solve this problem is to go back to
> the old strategy of always setting the SCSI revision to 2 (no matter what
> it might actually be), at least for Direct Access devices.  That would
> suppress the REPORT_LUNS command.  Would we lose anything by doing this?

Besides the use of REPORT_LUNS on devices which actually support it?  I
don't think so...

I wonder if printing a warning if sdev->scsi_level > SCSI_2 would be
useful...

Matt

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

You are needink to look more evil.  You likink very strong coffee?
					-- Pitr to Dust Puppy
User Friendly, 10/16/1998

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

Re: [PATCH as470] Add a NOREPORTLUN blacklist flag

[Patrick Mansfield]

On Sun, Feb 20, 2005 at 10:47:09PM -0800, Matthew Dharm wrote:
> On Sun, Feb 20, 2005 at 10:44:21PM -0500, Alan Stern wrote:

> > Matt, it looks like the best way to solve this problem is to go back to
> > the old strategy of always setting the SCSI revision to 2 (no matter what
> > it might actually be), at least for Direct Access devices.  That would
> > suppress the REPORT_LUNS command.  Would we lose anything by doing this?
> 
> Besides the use of REPORT_LUNS on devices which actually support it?  I
> don't think so...

It would only matter if the device had sparse luns (multiple luns/disks
that are not consecutively numbered).

You can always dynamically add it to the black list to force REPORT LUN
usage (for SCSI_2 devices) via BLIST_REPORTLUN2, and if it did not support
REPORT LUNS add it as sparse lun via BLIST_SPARSELUN.

Samuel or other owners of the hardware: did you check for firmware
updates? You should make sure the hardware vendor at least knows about the
problem.

The bridge hardware (USB/firewire to ide) should probably mark it as SCSI
2, and it should be fixed to handle and fail the REPORT LUN in a sane way. 

> I wonder if printing a warning if sdev->scsi_level > SCSI_2 would be
> useful...

Probably not.

-- Patrick Mansfield

Re: [PATCH as470] Add a NOREPORTLUN blacklist flag

[Alan Stern]

On Sun, 20 Feb 2005, Matthew Dharm wrote:

> > Matt, it looks like the best way to solve this problem is to go back to
> > the old strategy of always setting the SCSI revision to 2 (no matter what
> > it might actually be), at least for Direct Access devices.  That would
> > suppress the REPORT_LUNS command.  Would we lose anything by doing this?
> 
> Besides the use of REPORT_LUNS on devices which actually support it?  I
> don't think so...

That doesn't sound like much of a loss, especially since these devices do
implement Get_Max_LUN.  Or if they don't, I can't believe they would
implement REPORT_LUNS either.

I'll send in a patch for this soon.

Alan Stern

Re: [PATCH as470] Add a NOREPORTLUN blacklist flag

[James Bottomley]

On Sun, 2005-02-20 at 22:44 -0500, Alan Stern wrote:
> James, please withdraw the patch above.

Actually, I already have this in the tree.  Could you just do an
incremental to remove the blacklist line since I think the IBM people
still want their shark fix?

Thanks,

James

Re: [PATCH as470] Add a NOREPORTLUN blacklist flag

[Alan Stern]

On Mon, 28 Feb 2005, James Bottomley wrote:

> On Sun, 2005-02-20 at 22:44 -0500, Alan Stern wrote:
> > James, please withdraw the patch above.
> 
> Actually, I already have this in the tree.  Could you just do an
> incremental to remove the blacklist line since I think the IBM people
> still want their shark fix?

You have confused two different patches.  The one I asked you to withdraw 
(labelled as470) does nothing but add a single line to the scsi_devinfo.c 
blacklist.  The reversal patch for it is below.

The other patch, the one you're thinking of, is the one that adds retries
for Hardware Error sense keys; it's labelled as468.  In addition to the
IBM Shark stuff it contains a blacklist entry for a USB mass storage
device with vendor name ST650211 (marketed as an "HS200").  Although I'm
not certain, I think this device is not a USB-IDE converter -- perhaps
Radovan can clear this up for us.  Anyway, there's no easy way to get the
same effect as the blacklist entry by modifying usb-storage, since the
code only looks at the blacklist setting and not anything in the
scsi_device.  So I think patch as468 should remain as it stands.

Alan Stern



Signed-off-by: Alan Stern <stern@rowland.harvard.edu>

===== drivers/scsi/scsi_devinfo.c 1.14 vs edited =====
--- 1.14/drivers/scsi/scsi_devinfo.c	2004-12-10 11:54:56 -05:00
+++ edited/drivers/scsi/scsi_devinfo.c	2005-02-16 11:30:56 -05:00
@@ -201,7 +201,6 @@
 	{"WangDAT", "Model 2600", "01.7", BLIST_SELECT_NO_ATN},
 	{"WangDAT", "Model 3200", "02.2", BLIST_SELECT_NO_ATN},
 	{"WangDAT", "Model 1300", "02.4", BLIST_SELECT_NO_ATN},
-	{"WDC WD25", "00JB-00FUA0", NULL, BLIST_NOREPORTLUN},
 	{"XYRATEX", "RS", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
 	{"Zzyzx", "RocketStor 500S", NULL, BLIST_SPARSELUN},
 	{"Zzyzx", "RocketStor 2000", NULL, BLIST_SPARSELUN},