What is SCSI command 0xa0 ?
A message that is not in the archive (sent off-list or not yet received): 20050214160210.6c7e7e52@hebus
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?
Quoted 4 lines · 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
Looks like an ATAPI TUR.
Quoted 23 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
The Mon, 14 Feb 2005 16:34:39 -0500 (EST)
Quoted 7 lines · Alan Stern
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.
Quoted 8 lines
It's possible to prevent the SCSI driver from sending the
REPORT_LUNScommand to your drive. You can try this out by typing (as root):echo 'WDC WD25:00JB-00FUA0:0x01' >/proc/scsi/device_infobefore 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
Quoted 10 lines · Samuel Colin
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.
Quoted 3 lines
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?
Quoted 4 lines
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 =====
drivers/scsi/scsi_devinfo.c +1 -0
@@ -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},
The Wed, 16 Feb 2005 11:42:18 -0500 (EST)
Quoted 5 lines · Alan Stern
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.
Quoted 7 lines
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 theREPORT_LUNScommand 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 ?)
The Thu, 17 Feb 2005 16:59:40 +0100
Quoted 7 lines · Samuel Colin
Quoted 7 lines
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 theREPORT_LUNScommand worked under 2.6.8 and failed under 2.6.11, it would be worthwhile to know why.
Quoted 5 lines
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 ?)
Quoted 16 lines · Samuel Colin
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:
Quoted 6 lines
Direct-Access ANSI SCSI revision: 04
It means that for a 2.6.8 kernel, the revision is 02 (then no
report_lunscausing 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
Re: Magical ansi scsi revision (was Re: [linux-usb-devel] Re: What is SCSI command 0xa0 ?)
The Thu, 17 Feb 2005 17:23:54 -0500 (EST)
Quoted 5 lines · Alan Stern
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:
Quoted 7 lines
Feb 17 21:19:09 gnondpom kernel: usb-storage: Fixing INQUIRY data to showSCSI 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
PATCH 1/1 Add a NOREPORTLUN blacklist flag
In reply to Samuel ColinJames:
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
===== drivers/scsi/scsi_devinfo.c 1.14 vs edited =====
drivers/scsi/scsi_devinfo.c +1 -0
@@ -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: [PATCH as470] Add a NOREPORTLUN blacklist flag
Quoted 16 lines · 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 <[email protected]>=====
drivers/scsi/scsi_devinfo.c1.14 vs edited =====
drivers/scsi/scsi_devinfo.c line 204
Quoted 4 lines
drivers/scsi/scsi_devinfo.c +1
-0@@ -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.
Re: [PATCH as470] Add a NOREPORTLUN blacklist flag
Quoted 28 lines · Sergey Vlasov
Quoted 16 lines · 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 <[email protected]>=====
drivers/scsi/scsi_devinfo.c1.14 vs edited =====drivers/scsi/scsi_devinfo.c line 204
Quoted 4 lines
drivers/scsi/scsi_devinfo.c +1
-0@@ -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:
Quoted 7 lines
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_LUNScommand, 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
Quoted 41 lines · Alan Stern
Quoted 28 lines · Sergey Vlasov
Quoted 16 lines · 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 <[email protected]>=====
drivers/scsi/scsi_devinfo.c1.14 vs edited =====drivers/scsi/scsi_devinfo.c line 204
Quoted 4 lines
drivers/scsi/scsi_devinfo.c +1
-0@@ -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:
Quoted 7 lines
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_LUNScommand, 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.
Quoted 6 lines
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_LUNScommand. 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
Signature · 6 lines
Matthew Dharm Home: [email protected] 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
Re: [PATCH as470] Add a NOREPORTLUN blacklist flag
Quoted 9 lines · Matthew Dharm
Quoted 4 lines · Alan Stern
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_LUNScommand. Would we lose anything by doing this?Besides the use of
REPORT_LUNSon 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.
Quoted 2 lines
I wonder if printing a warning if
sdev->scsi_level>SCSI_2would be useful...
Probably not.
-- Patrick Mansfield
Re: [PATCH as470] Add a NOREPORTLUN blacklist flag
In reply to Matthew DharmQuoted 7 lines · Matthew Dharm
Quoted 4 lines
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_LUNScommand. Would we lose anything by doing this?Besides the use of
REPORT_LUNSon 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
In reply to Alan SternQuoted 1 line · Alan Stern
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
Quoted 6 lines · James Bottomley
Quoted 1 line · Alan Stern
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
===== drivers/scsi/scsi_devinfo.c 1.14 vs edited =====
drivers/scsi/scsi_devinfo.c +0 -1
@@ -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},
Quoted 8 lines · 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 00It'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.
Signature · 1 line
Matthias Andree
Quoted 2 lines · Matthias Andree
"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
Quoted 5 lines · Matthias Andree
Quoted 2 lines · Alan Stern
Can anybody tell me what this CDB is supposed to do, when issued to a direct-access device (a disk drive)?
Quoted 7 lines
Quoted 3 lines
a0 00 00 00 00 00 00 00 10 00 00 00It'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