on integrating SMART/ATA-Security in usb-storage driver
Subsystems (4)
Quoted 38 lines · James Bottomley
Quoted 10 lines · Matthew Dharm
Quoted 9 lines · Timothy Thelin
Quoted 7 lines
If you had time to spare, instead of touching usb-storage, it might be better spent resurecting
SG_FLAG_LUN_INHIBITto stop the above behavior so thatSG_IOcdbs can be passed through untouched.
(SG_FLAG_FUN_INHIBITwas a flagSG_IOused to support a long time ago, and I have no idea why it was dropped, but it was)Quoted 2 lines
Quoted 2 lines
I didn't realize that had been removed. Anyone that sends a vendor-specific command to a device needs this flag to
make sure it goes
Quoted 3 lines
Quoted 3 lines
through unmangled.
Perhaps someone on linux-scsi can comment on why this was
removed and how
Quoted 5 lines
Quoted 1 line
we might get it back?
I've no distinct recollection of someone removing this, but if I remember correctly what it used to do, it was a hack to stop us from mangling SCSI-3 CDB's. We fixed the mid-layer not to
require the hack
Quoted 1 line
by only setting the CDB[1] lun field for SCSI-1 and SCSI-2
devices (as
Quoted 1 line
the standards mandate). What's the actual problem? No
SCSI-1 or SCSI-2
Quoted 2 lines
device should have any vendor specific CDBs that uses these bits in CDB[1].
Unfortunately, reality appears to disagree with the last "should". I've
personally seen devices with vendor-specific commands that want to control
CDB[1] in SCSI-2.
Quoted 5 lines
I didn't know it was removed; I only know what Timothy Thelin told me. Can
we get the feature back?Matt
And for an even more concrete example:
The CY7C68300B cypress bridge board (has various siblings as well on their site that act very similar) implements SCSI spec 0 (ie it doesn't claim to support any scsi spec). Now usb-storage sees this in inquiry, and decides to export the device as a scsi2 device since based on the usb-storage devs' experience most usb devices really want scsi2 cdbs. So SCSI core thinks this is a scsi2 device and procedes to mangle the cdbs as they're going through.
The problem then is with vendor specific commands as SCSI core mangles those as well. The vendor specific command I had issues with is the "ATACB" ATA passthru cdb that cypress boards understand. CDB[1] is a signature byte that must be 0x24. Needless to say, that leading 2 gets masked off to a 0, and the drive aborts the ATACB. Now cypress could have been smarter about designing their cdb, but they wern't, and so there really needs to be a way to tell SCSI core "hands off the cdb".
This is also going to be an issue with USB devices that implement SAT passthru but state they implement SCSI spec 0, as SAT passthru CDB[1] can't afford to be mangled either.
I started this conversation a little over a month ago, but it died.
http://marc.theaimsgroup.com/?l=linux-scsi&m=112714917116713&w=2
Regards,
Tim Thelin
Quoted 8 lines · Timothy Thelin
And for an even more concrete example:
The CY7C68300B cypress bridge board (has various siblings as well on their site that act very similar) implements SCSI spec 0 (ie it doesn't claim to support any scsi spec). Now usb-storage sees this in inquiry, and decides to export the device as a scsi2 device since based on the usb-storage devs' experience most usb devices really want scsi2 cdbs. So SCSI core thinks this is a scsi2 device and procedes to mangle the cdbs as they're going through.
What happens if you prevent USB mangling the scsi_level? I think, for the most part, we would handle 0 in about the same way as we handle 2. However, we could gate the if around the CDB[1] mangling as
if (scsi_level != SCSI_UNKNOWN && scsi_level <= SCSI_2)
which should fix your problem, I think.
James
Quoted 10 lines · James Bottomley
Quoted 8 lines · Timothy Thelin
And for an even more concrete example:
The CY7C68300B cypress bridge board (has various siblings as well on their site that act very similar) implements SCSI spec 0 (ie it doesn't claim to support any scsi spec). Now usb-storage sees this in inquiry, and decides to export the device as a scsi2 device since based on the usb-storage devs' experience most usb devices really want scsi2 cdbs. So SCSI core thinks this is a scsi2 device and procedes to mangle the cdbs as they're going through.
Quoted 7 lines
What happens if you prevent USB mangling the
scsi_level? I think, for the most part, we would handle 0 in about the same way as we handle 2. However, we could gate the if around the CDB[1] mangling asif (
scsi_level!=SCSI_UNKNOWN&&scsi_level<=SCSI_2)which should fix your problem, I think.
A long time ago, usb-storage didn't mangle the scsi_level. And almost nothing worked. Without a SCSI level, 6-byte commands get sent; only 10-byte commands will do.
Matt
Signature · 6 lines
Matthew Dharm Home: [email protected] Maintainer, Linux USB Mass Storage Driver I see you've been reading alt.sex.chubby.sheep voraciously. -- Tanya User Friendly, 11/24/97
Quoted 11 lines · Matthew Dharm
Quoted 7 lines
What happens if you prevent USB mangling the
scsi_level? I think, for the most part, we would handle 0 in about the same way as we handle 2. However, we could gate the if around the CDB[1] mangling asif (
scsi_level!=SCSI_UNKNOWN&&scsi_level<=SCSI_2)which should fix your problem, I think.
A long time ago, usb-storage didn't mangle the
scsi_level. And almost nothing worked. Without a SCSI level, 6-byte commands get sent; only 10-byte commands will do.
That area of the scsi subsystem has been changed significantly ... mainly for usb storage. I don't believe your assertion about SCSI_UNKOWN only producing 6 byte CDBs to be correct, the behaviour is now governed by two scsi_device flags: use_10_for_rw and use_10_for_ms which you can control in slave configure.
Can you just try it with a modern kernel and see if anything still breaks?
Thanks,
James
Quoted 13 lines · James Bottomley
Quoted 11 lines · Matthew Dharm
Quoted 7 lines
What happens if you prevent USB mangling the
scsi_level? I think, for the most part, we would handle 0 in about the same way as we handle 2. However, we could gate the if around the CDB[1] mangling asif (
scsi_level!=SCSI_UNKNOWN&&scsi_level<=SCSI_2)which should fix your problem, I think.
A long time ago, usb-storage didn't mangle the
scsi_level. And almost nothing worked. Without a SCSI level, 6-byte commands get sent; only 10-byte commands will do.
Quoted 8 lines
That area of the scsi subsystem has been changed significantly ... mainly for usb storage. I don't believe your assertion about
SCSI_UNKOWNonly producing 6 byte CDBs to be correct, the behaviour is now governed by twoscsi_deviceflags:use_10_for_rwanduse_10_for_mswhich you can control in slave configure.Can you just try it with a modern kernel and see if anything still breaks?
I just realized this plan has a problem...
The reported SCSI level of a device is mostly garbage, but not always. I've seen 0, 1, 2, 3, and 0xff all reported. HOWEVER, the reported value seems independent of what devices have vendor-specific commands (and thus need the CDB[1] not messed with).
It is an interesting experiment to remove the force-to-SCSI_2 part of the usb-storage code (on the general principal of "we shouldn't be messing with the data passed through the driver), but it doesn't solve the original question of needing a way to pass commands without CDB[1] getting altered.
Matt
Signature · 6 lines
Matthew Dharm Home: [email protected] Maintainer, Linux USB Mass Storage Driver Pitr! That's brilliant! Funded by Microsoft refunds. What sweet irony! -- A.J. User Friendly, 2/15/1999
Quoted 11 lines · Matthew Dharm
Quoted 2 lines · James Bottomley
Can you just try it with a modern kernel and see if anything still breaks?
I just realized this plan has a problem...
The reported SCSI level of a device is mostly garbage, but not always. I've seen 0, 1, 2, 3, and
0xffall reported. HOWEVER, the reported value seems independent of what devices have vendor-specific commands (and thus need the CDB[1] not messed with).
Quoted 4 lines
It is an interesting experiment to remove the force-to-SCSI_2 part of the usb-storage code (on the general principal of "we shouldn't be messing with the data passed through the driver), but it doesn't solve the original question of needing a way to pass commands without CDB[1] getting altered.
Well, that might be a problem if it weren't for the fact that this LUN_INHIBIT flag was removed in 2002. If it's taken three years to find a device that has a problem with it, I don't really think it's a particularly widespread problem. And since the device that now shows the problem is setting the level to 0, it looks like we have a potential solution that fits all known cases.
Anyway, the goal should be to handle devices in a standards compliant manner first and then worry about quirk tables when that doesn't work ... we have an incredibly broad quirk infrastructure in SCSI for this.
James
Quoted 27 lines · James Bottomley
Quoted 12 lines · Matthew Dharm
Quoted 2 lines · James Bottomley
Can you just try it with a modern kernel and see if anything still breaks?
I just realized this plan has a problem...
The reported SCSI level of a device is mostly garbage, but not always. I've seen 0, 1, 2, 3, and
0xffall reported. HOWEVER, the reported value seems independent of what devices have vendor-specific commands (and thus need the CDB[1] not messed with).Quoted 4 lines
It is an interesting experiment to remove the force-to-SCSI_2 part of the usb-storage code (on the general principal of "we shouldn't be messing with the data passed through the driver), but it doesn't solve the original question of needing a way to pass commands without CDB[1] getting altered.
Well, that might be a problem if it weren't for the fact that this
LUN_INHIBITflag was removed in 2002. If it's taken three years to find a device that has a problem with it, I don't really think it's a particularly widespread problem. And since the device that now shows the problem is setting the level to 0, it looks like we have a potential solution that fits all known cases.
Quoted 7 lines
Anyway, the goal should be to handle devices in a standards compliant manner first and then worry about quirk tables when that doesn't work ... we have an incredibly broad quirk infrastructure in SCSI for this.
James
ok, ive just ordered 2 cypress CY7C68300B samples and will replace the discont'd A type in my device. datasheet for A says nothing about ATACB and security. sheet for B does guarantee.
cypress windows driver reports no security, too.
so i will replace the chip to have a testing base.
tom
Quoted 17 lines · James Bottomley
Quoted 11 lines · Matthew Dharm
Quoted 2 lines · James Bottomley
Can you just try it with a modern kernel and see if anything still breaks?
I just realized this plan has a problem...
The reported SCSI level of a device is mostly garbage, but not always. I've seen 0, 1, 2, 3, and
0xffall reported. HOWEVER, the reported value seems independent of what devices have vendor-specific commands (and thus need the CDB[1] not messed with).Quoted 4 lines
It is an interesting experiment to remove the force-to-SCSI_2 part of the usb-storage code (on the general principal of "we shouldn't be messing with the data passed through the driver), but it doesn't solve the original question of needing a way to pass commands without CDB[1] getting altered.
Quoted 6 lines
Well, that might be a problem if it weren't for the fact that this
LUN_INHIBITflag was removed in 2002. If it's taken three years to find a device that has a problem with it, I don't really think it's a particularly widespread problem. And since the device that now shows the problem is setting the level to 0, it looks like we have a potential solution that fits all known cases.
Was it really removed that long ago? I guess there are still a lot of people using 2.4 kernels, then.
I've been recommending this flag to people as recently as 6 months ago
(i.e. the last time someone asked me). It comes up 2-3 times a year.
The last time it came up, the device set SCSI_2.
Matt
Signature · 6 lines
Matthew Dharm Home: [email protected] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998
Quoted 29 lines · Matthew Dharm
Quoted 19 lines · James Bottomley
Quoted 12 lines · Matthew Dharm
Quoted 2 lines · James Bottomley
Can you just try it with a modern kernel and see if anything still breaks?
I just realized this plan has a problem...
The reported SCSI level of a device is mostly garbage, but not always. I've seen 0, 1, 2, 3, and
0xffall reported. HOWEVER, the reported value seems independent of what devices have vendor-specific commands (and thus need the CDB[1] not messed with).Quoted 4 lines
It is an interesting experiment to remove the force-to-SCSI_2 part of the usb-storage code (on the general principal of "we shouldn't be messing with the data passed through the driver), but it doesn't solve the original question of needing a way to pass commands without CDB[1] getting altered.
Quoted 6 lines
Well, that might be a problem if it weren't for the fact that this
LUN_INHIBITflag was removed in 2002. If it's taken three years to find a device that has a problem with it, I don't really think it's a particularly widespread problem. And since the device that now shows the problem is setting the level to 0, it looks like we have a potential solution that fits all known cases.
Quoted 1 line
Was it really removed that long ago?
yes
...
- if (!(hp->flags & SG_FLAG_LUN_INHIBIT)) {
- if (sdp->device->scsi_level <= SCSI_2)
- cmnd[1] = (cmnd[1] & 0x1f) | (sdp->device->lun << 5);
- }
...
17. 2002-10-15 [RFC PATCH] consolidate SCSI-2 command lun setting linux-scs Patrick Mansfield
Quoted 5 lines · thomas schorpp
Quoted 3 lines
Was it really removed that long ago?
yes
Hmmm yeh, here is the original email with patch:
http://marc.theaimsgroup.com/?l=linux-scsi&m=103470224812028&w=2
Black listing would cover more cases than adding back the SG_IO flag.
Black listing USB devices is somewhat bad/tricky, since they often don't show up with registered vendor + model names, and use somewhat generic names, for example I have an xd reader that has vendor "Generic", model "STORAGE DEVICE".
So either the hardware is stupid, or usb-storage generates those names and maybe everything is OK (simple search finds nothing in usb storage code). We do have some of those name in the current scsi devinfo table ... I haven't looked for details on them or tried to figure out if they hurt any devices.
Other potential methods besides black list based on vendor + model:
1) If (big if, i.e. unlikely) USB devices in general don't need the LUN in the cdb, we could black list all USB to skip the storing of it.
The majority of the (single LUN) USB devices probably never look at the field, so perhaps we could refine the above to:
2) Black list all usb devices that don't have multiple LUNs, assuming the never check the cdb for a LUN value.
I don't know if you can tell (in usb code) if usb mass storage is multi-lun or not without scanning for the other LUNs (normal SCSI devices would have to be scanned or sent a REPORT LUNS, and even then, they could show up with more LUNs in the future).
3) black list via usb storage based on usb id's, kind of like the handling in usb slave_configure for USB_VENDOR_ID_GENESYS, though a more general method would be better.
All of the above methods still should have defines in linux scsi devinfo table and a corresponding new scsi_device->no_cdb_lun_setting field, and setting of it in scsi_scan.c:scsi_add_lun (calls slave_configure near the end, so then slave_configure can set no_cdb_lun_setting as required).
The slave_configure can then set sdev specific values, such as those that might be set in linux scsi core black list, see current driver/usb/storage scsiglue.c:slave_configure().
-- Patrick Mansfield
Quoted 9 lines · Patrick Mansfield
Black listing would cover more cases than adding back the
SG_IOflag.Black listing USB devices is somewhat bad/tricky, since they often don't show up with registered vendor + model names, and use somewhat generic names, for example I have an xd reader that has vendor "Generic", model "STORAGE DEVICE".
So either the hardware is stupid, or usb-storage generates those names and maybe everything is OK (simple search finds nothing in usb storage code).
The hardware is stupid. Really, I'm not that stupid, even on my worst day.
It's worse than that, actually. I've seen devices where the VID/PID is that of the USB/IDE bridge vendor, and the INQUIRY gives "Generic". There's really no way to programmatically distinguish one device from another with high reliability.
Quoted 8 lines
We do have some of those name in the current scsi devinfo table ... I haven't looked for details on them or tried to figure out if they hurt any devices.
Other potential methods besides black list based on vendor + model:
1) If (big if, i.e. unlikely) USB devices in general don't need the LUN in the cdb, we could black list all USB to skip the storing of it.
Nope. It's pretty common to see 5/6/7-in-one media readers which are multi-LUN.
Quoted 5 lines
The majority of the (single LUN) USB devices probably never look at the field, so perhaps we could refine the above to:
2) Black list all usb devices that don't have multiple LUNs, assuming the never check the cdb for a LUN value.
Iffy. Some single-LUN devices look at the LUN field, some don't. I'd say it's about a 60/40 split.
Quoted 4 lines
I don't know if you can tell (in usb code) if usb mass storage is multi-lun or not without scanning for the other LUNs (normal SCSI devices would have to be scanned or sent a REPORT LUNS, and even then, they could show up with more LUNs in the future).
For the vast majority of USB storage devices (but not all), you can determine this pretty well. BBB devices support a GetMaxLUN command -- usb-storage uses it to set an internal variable, but it could be passed elsewhere.
Quoted 3 lines
3) black list via usb storage based on usb id's, kind of like the handling in usb
slave_configureforUSB_VENDOR_ID_GENESYS, though a more general method would be better.
See my response to #1 above. Vendors are, apparently, stupid -- at least when it comes to making sure devices distinguish themselves in a nice manner.
Matt
Signature · 6 lines
Matthew Dharm Home: [email protected] Maintainer, Linux USB Mass Storage Driver We can customize our colonels. -- Tux User Friendly, 12/1/1998
Quoted 10 lines · Patrick Mansfield
Quoted 5 lines · thomas schorpp
Quoted 3 lines
Was it really removed that long ago?
yes
Hmmm yeh, here is the original email with patch:
http://marc.theaimsgroup.com/?l=linux-scsi&m=103470224812028&w=2
Okay, what am I missing?
Looking at that patch, it looks to me like if sg.c set a flag in the SCSI command block then scsi_core.c could use that flag in the test to determine if the LUN should be masked-in.
HOWEVER, I keep hearing that the changes will be extensive. What am I missing?
Matt
Signature · 6 lines
Matthew Dharm Home: [email protected] Maintainer, Linux USB Mass Storage Driver Oh great modem, why hast thou forsaken me? -- Dust Puppy User Friendly, 3/2/1998
Quoted 8 lines · Matthew Dharm
Okay, what am I missing?
Looking at that patch, it looks to me like if
sg.cset a flag in the SCSI command block thenscsi_core.ccould use that flag in the test to determine if the LUN should be masked-in.HOWEVER, I keep hearing that the changes will be extensive. What am I missing?
Not extensive AFAICT ...
The scmd/cdb is not available until we call scsi_get_command() in the request function. So you would have to add a field into scsi_request, set it in sg (in both sg.c block/scsi_ioctl.c, test via sd and sg when you are done), and add the field in scsi_cmnd, and set scmd one in scsi_init_cmd_from_req().
But as far as black listing, it does seem like a better solution in that user apps do not need special code.
Do the devices that require it (well so far) have useable vendor + model strings or usb id's?
-- Patrick Mansfield
Alan Stern
maintainerQuoted 11 lines · Patrick Mansfield
Quoted 8 lines · Matthew Dharm
Okay, what am I missing?
Looking at that patch, it looks to me like if
sg.cset a flag in the SCSI command block thenscsi_core.ccould use that flag in the test to determine if the LUN should be masked-in.HOWEVER, I keep hearing that the changes will be extensive. What am I missing?
Quoted 7 lines
Not extensive AFAICT ...
The scmd/cdb is not available until we call
scsi_get_command()in the request function. So you would have to add a field intoscsi_request, set it in sg (in bothsg.cblock/scsi_ioctl.c, test via sd and sg when you are done), and add the field inscsi_cmnd, and set scmd one inscsi_init_cmd_from_req().
Isn't it true that scsi_request is going away? Everything will have to use generic request structures.
Quoted 2 lines
But as far as black listing, it does seem like a better solution in that user apps do not need special code.
I don't think blacklisting is a good way to do this. In principle any USB mass storage device -- any SCSI device, in fact -- might have a vendor-specific pass-thru needing special handling. It doesn't have to be correlated with the vendor, the product, the SCSI level, the transport, or anything else.
Alan Stern
Quoted 8 lines · Alan Stern
On Mon, 7 Nov 2005, Patrick Mansfield wrote:
I don't think blacklisting is a good way to do this. In principle any USB mass storage device -- any SCSI device, in fact -- might have a vendor-specific pass-thru needing special handling.
no. that would be not industry best practice and uneconomical sw effort. remember this devices are mainly "designed for windows" and WHQL certification is expensive for every single driver. and ms has only one driver for all usb storage right now, all boxes and sticks i had here use it.
Quoted 3 lines
It doesn't have to be
correlated with the vendor, the product, the SCSI level, the transport, or anything else.
yes. the sheet for design recommended cypress chips state all ATACB and ATA-Security. i would be make no sense to implement different behaviuors in chips for the same purpose.
Quoted 3 lines
Alan Stern
tom schorpp
Alan Stern
maintainerQuoted 5 lines · thomas schorpp
Quoted 3 lines
I don't think blacklisting is a good way to do this. In principle any USB mass storage device -- any SCSI device, in fact -- might have a vendor-specific pass-thru needing special handling.
no. that would be not industry best practice and uneconomical sw effort.
Adding vendor-specific codes to SCSI devices isn't industry best practice? I can't argue with that, but it is very common nevertheless.
Is it an uneconomical software effort? Ridiculous -- it's not software at all, it's part of the firmware.
Quoted 3 lines
remember this devices are mainly "designed for windows" and WHQL certification is expensive for every single driver. and ms has only one driver for all usb storage right now, all boxes and sticks i had here use it.
I think you have a very limited view of how devices are "designed". Besides, I specifically said I was talking about _all_ SCSI devices, not just USB ones.
Quoted 6 lines
Quoted 3 lines
It doesn't have to be
correlated with the vendor, the product, the SCSI level, the transport, or anything else.yes. the sheet for design recommended cypress chips state all ATACB and ATA-Security. i would be make no sense to implement different behaviuors in chips for the same purpose.
That's what Cypress does, sure. But who says that other vendors have to copy Cypress? For the most part they don't. Neither does T10.
As for whether it makes no sense -- you have your point of view. Business people have a very different point of view; to them it might make excellent sense, to help secure a competitive advantage.
Alan Stern
Quoted 7 lines · Alan Stern
Quoted 4 lines · thomas schorpp
Quoted 3 lines
I don't think blacklisting is a good way to do this. In principle any USB mass storage device -- any SCSI device, in fact -- might have a vendor-specific pass-thru needing special handling.
Quoted 5 lines
Quoted 1 line
no. that would be not industry best practice and uneconomical sw effort.
Adding vendor-specific codes to SCSI devices isn't industry best practice? I can't argue with that, but it is very common nevertheless.
not for all the cheap noname consumer stuff around. maybe in your scsi-320 server world i cant afford.
Quoted 3 lines
Is it an uneconomical software effort? Ridiculous -- it's not software at all, it's part of the firmware.
i thought were speaking of OS drivers here?
Quoted 11 lines
Quoted 5 lines
remember this devices are mainly "designed for windows" and WHQL certification is expensive for every single driver. and ms has only one driver for all usb storage right now, all boxes and sticks i had here use it.
I think you have a very limited view of how devices are "designed". Besides, I specifically said I was talking about _all_ SCSI devices, not just USB ones.
yes, for the second sentence, this is made clear now.
Quoted 11 lines
Quoted 7 lines
Quoted 4 lines
It doesn't have to be
correlated with the vendor, the product, the SCSI level, the transport, or anything else.yes. the sheet for design recommended cypress chips state all ATACB and ATA-Security. i would be make no sense to implement different behaviuors in chips for the same purpose.
That's what Cypress does, sure. But who says that other vendors have to copy Cypress? For the most part they don't. Neither does T10.
they dont copy cypress, they want to reduce costs, processes and resulting "standards" should be compatible, therefore.
Quoted 4 lines
As for whether it makes no sense -- you have your point of view. Business people have a very different point of view; to them it might make excellent sense, to help secure a competitive advantage.
:D i'm no business man. i am a generalist and i just want to lock my external hdd.
Quoted 4 lines
Alan Stern
-
tom schorpp
Quoted 5 lines · Patrick Mansfield
The scmd/cdb is not available until we call
scsi_get_command()in the request function. So you would have to add a field intoscsi_request, set it in sg (in bothsg.cblock/scsi_ioctl.c, test via sd and sg when you are done), and add the field inscsi_cmnd, and set scmd one inscsi_init_cmd_from_req().
Once Mike finally reposts his patchkit scsi_request should be gone and block SG_IO or sg should send down a struct request. Which already has a cmnd pointer embedded.
Quoted 13 lines · Patrick Mansfield
Quoted 8 lines · Matthew Dharm
Okay, what am I missing?
Looking at that patch, it looks to me like if
sg.cset a flag in the SCSI command block thenscsi_core.ccould use that flag in the test to determine if the LUN should be masked-in.HOWEVER, I keep hearing that the changes will be extensive. What am I missing?
Quoted 7 lines
Not extensive AFAICT ...
The scmd/cdb is not available until we call
scsi_get_command()in the request function. So you would have to add a field intoscsi_request, set it in sg (in bothsg.cblock/scsi_ioctl.c, test via sd and sg when you are done), and add the field inscsi_cmnd, and set scmd one inscsi_init_cmd_from_req().
i'll wait for maintainers decisions before touching code.
Quoted 10 lines
But as far as black listing, it does seem like a better solution in that user apps do not need special code.
Do the devices that require it (well so far) have useable vendor + model strings or usb id's?
-- Patrick Mansfield
most no name boxes use brigde manu id's although cypress claims on web this was not allowed (here the older A-brigde chip, model go-usb2):
Bus 004 Device 003: ID 04b4:6830 Cypress Semiconductor Corp. USB-2.0 IDE Adapter Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x04b4 Cypress Semiconductor Corp.
idProduct 0x6830 USB-2.0 IDE Adapter
bcdDevice 0.01
iManufacturer 56 Cypress Semiconductor
iProduct 78 USB2.0 Storage Device
iSerial 100 DEF1092E5AC4
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x88 EP 8 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
tom1:~#
Quoted 11 lines · thomas schorpp
Bus 004 Device 003: ID 04b4:6830 Cypress Semiconductor Corp. USB-2.0 IDE Adapter Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0bMaxPacketSize0 64
idVendor0x04b4Cypress Semiconductor Corp.
idProduct0x6830USB-2.0 IDE Adapter
So this is a USB to ATA/ATAPI bridge?
Can we trigger black listing based on the above vendor/product values? i.e. can you check for these values in usb-storage slave_configure code?
I am ATA ignorant ... how does this thing pass multi-lun values to the ATA side? Is it just effectively not allowed in ATA?
Per earlier email, datasheet is here:
On page 13 of datasheet:
Sounds like this device has special snooping of cdb[1], so if it sees 0x24 in there it looks for an embedded ATA command, and translates and sends that to the underlying device, so we can never black list based on the device that we are using to send the SG_IO ioctl.
Yeh, some other hardware might want lun inihibit in the future, and that could still be added back, but IMHO black list is better.
-- Patrick Mansfield
Alan Stern
maintainerQuoted 13 lines · Patrick Mansfield
Quoted 11 lines · thomas schorpp
Bus 004 Device 003: ID 04b4:6830 Cypress Semiconductor Corp. USB-2.0 IDE Adapter Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0bMaxPacketSize0 64
idVendor0x04b4Cypress Semiconductor Corp.
idProduct0x6830USB-2.0 IDE Adapter
Quoted 4 lines
So this is a USB to ATA/ATAPI bridge?
Can we trigger black listing based on the above vendor/product values? i.e. can you check for these values in usb-storage
slave_configurecode?
Yes. The patch below illustrates how. You'll have to change the name of the sdev flag to something sensible...
I firmly believe this is the wrong approach, however. It's a specific solution to a general problem. I would much prefer to add a new flag to struct request.
Quoted 2 lines
Yeh, some other hardware might want lun inihibit in the future, and that could still be added back, but IMHO black list is better.
I'd say it's inevitable. And it may even end up being standard-based, not vendor/product based.
Alan Stern
---
drivers/usb/storage/scsiglue.c +7 -0
@@ -185,6 +185,13 @@ static int slave_configure(struct scsi_dif (us->flags &US_FL_NOT_LOCKABLE ) sdev->lockable =0 ; +/* SCSI-ATA pass-thru whitelist for Cypress chip */ +if (le16_to_cpu (us->pusb_dev->descriptor.idVendor) == +USB_VENDOR_ID_CYPRESS && +le16_to_cpu (us->pusb_dev->descriptor.idProduct) == +USB_PRODUCT_ID_CYPRESS_CY7C68320 ) + sdev->ata_passthru =1 ; +/* this is to satisfy the compiler, tho I don't think the * return code is ever checked anywhere. */ return 0 ;
drivers/usb/storage/usb.h +4 -1
@@ -169,7 +169,10 @@ extern void fill_inquiry_response(struct#define scsi_lock (host) spin_lock_irq(host->host_lock) -/* Vendor ID list for devices that require special handling */ +/* Vendor/Product ID list for devices that require special handling */ #define USB_VENDOR_ID_GENESYS 0x05e3/* Genesys Logic */ +#define USB_VENDOR_ID_CYPRESS 0x04b4/* Cypress Semiconductor */ +#define USB_PRODUCT_ID_CYPRESS_CY7C68320 0x6830 +#endif
Quoted 10 lines · Alan Stern
Quoted 2 lines · Patrick Mansfield
Can we trigger black listing based on the above vendor/product values? i.e. can you check for these values in usb-storage
slave_configurecode?Yes. The patch below illustrates how. You'll have to change the name of the sdev flag to something sensible...
I firmly believe this is the wrong approach, however. It's a specific solution to a general problem. I would much prefer to add a new flag to struct request.
We have the specific problem of a device being reported as scsi-2 compliant when it is not.
Stepping back a bit ...
usb-storage should pass through the scsi level, we should not require special handling (adding back inhibit lun support or a new black list option) for compliant hardware.
So, do we have a usb-storage problem or non-compliant hardware here? I did not find the answer in previous emails.
That is, is usb-storage forcing scsi-2 when the device tells us it is scsi-3 compliant, or is the hardware reporting devices are scsi-2, yet requiring non-LUN value in cdb[1]?
A method that can reliably and easily set some black list value for the hardware in question will to lead to fewer questions in the future as to why an SG_IO command is getting LUN values set in cdb[1].
If this is a hardware problem I'm not opposed to adding back support for the ioctl and AFAIUI a new struct request flag.
-- Patrick Mansfield
Alan Stern
maintainerQuoted 9 lines · Patrick Mansfield
We have the specific problem of a device being reported as scsi-2 compliant when it is not.
Stepping back a bit ...
usb-storage should pass through the scsi level, we should not require special handling (adding back inhibit lun support or a new black list option) for compliant hardware.
Quoted 6 lines
So, do we have a usb-storage problem or non-compliant hardware here? I did not find the answer in previous emails.
That is, is usb-storage forcing scsi-2 when the device tells us it is scsi-3 compliant, or is the hardware reporting devices are scsi-2, yet requiring non-LUN value in cdb[1]?
I think we may have both. However I don't know how this Cypress chip reports itself. A system log showing the INQUIRY data would be very helpful.
It's quite possible that usb-storage no longer needs to force the scsi-level to 2. No one has recently tested what would happen without it. Matt probably has the best selection of devices for testing...
There is one problem we have with devices that report themselves as SCSI-3 or SCSI-4 but hang when they receive a REPORT LUNS command. That's easily handled by making usb-storage set the NOREPORTLUN flag. Maybe that's all we need to do.
Alan Stern
Quoted 7 lines · Alan Stern
Quoted 3 lines
That is, is usb-storage forcing scsi-2 when the device tells us it is scsi-3 compliant, or is the hardware reporting devices are scsi-2, yet requiring non-LUN value in cdb[1]?
I think we may have both. However I don't know how this Cypress chip reports itself. A system log showing the INQUIRY data would be very helpful.
We were told in prior emails that it actually reports a level of zero (i.e. no compliance with any SCSI standard). My original proposal was just not to modify the CDB[1] for this case if we could get the INQUIRY passed through unmangled.
Quoted 8 lines
It's quite possible that usb-storage no longer needs to force the scsi-level to 2. No one has recently tested what would happen without it. Matt probably has the best selection of devices for testing...
There is one problem we have with devices that report themselves as SCSI-3 or SCSI-4 but hang when they receive a REPORT LUNS command. That's easily handled by making usb-storage set the NOREPORTLUN flag. Maybe that's all we need to do.
If you could try this out, I'd be grateful.
Thanks,
James
Alan Stern
maintainerQuoted 10 lines · James Bottomley
Quoted 8 lines
It's quite possible that usb-storage no longer needs to force the scsi-level to 2. No one has recently tested what would happen without it. Matt probably has the best selection of devices for testing...
There is one problem we have with devices that report themselves as SCSI-3 or SCSI-4 but hang when they receive a REPORT LUNS command. That's easily handled by making usb-storage set the NOREPORTLUN flag. Maybe that's all we need to do.
If you could try this out, I'd be grateful.
I tried the patch below on several combinations of SCSI levels and device types. It seems to do exactly what we want; for reads I always saw READ(10) and for MODE SENSE I saw either the 6- or 10-byte form, depending on the device type and USB subclass value.
The question remains whether pass-thru will now work and whether the patch will mess up some existing non-compliant device that currently works okay. The only way to know is by trying it out. Matt and Timothy, that's up to you.
Alan Stern
---
drivers/usb/storage/scsiglue.c +3 -20
@@ -94,23 +94,6 @@ static int slave_configure(struct scsi_d* the end, scatter-gather buffers follow page boundaries. */ blk_queue_dma_alignment (sdev->request_queue, (512 -1 )); -/* Set the SCSI level to at least 2. We'll leave it at 3 if that's -* what is originally reported. We need this to avoid confusing -* the SCSI layer with devices that report 0 or 1, but need 10-byte -* commands (ala ATAPI devices behind certain bridges, or devices -* which simply have broken INQUIRY data). -* -* NOTE: This means /dev/sg programs (ala cdrecord) will get the -* actual information. This seems to be the preference for -* programs like that. -* -* NOTE: This also means that /proc/scsi/scsi and sysfs may report -* the actual value or the modified one, depending on where the -* data comes from. -*/ -if (sdev->scsi_level <SCSI_2 ) - sdev->scsi_level =SCSI_2 ; -/* According to the technical support people at Genesys Logic, * devices using their chips have problems transferring more than * 32 KB at a time. In practice people have found that 64 KB
@@ -159,10 +142,10 @@ static int slave_configure(struct scsi_d/* Some devices report a SCSI revision level above 2 but are * unable to handle the REPORT LUNS command (for which * support is mandatory at level 3). Since we already have -* a Get-Max-LUN request, we won't lose much by setting the -* revision level down to 2. The only devices that would be +* a Get-Max-LUN request, we won't lose much by not using +* REPORT LUNS. The only devices that would be * affected are those with sparse LUNs. */ - sdev->scsi_level =SCSI_2 ; + sdev->sdev_target->no_report_lun =1 ;/* USB-IDE bridges tend to report SK = 0x04 (Non-recoverable * Hardware Error) when any low-level error occurs,
include/scsi/scsi_device.h +2 -1
@@ -161,7 +161,8 @@ struct scsi_target {unsigned int channel;unsigned int id;/* target id ... replace * scsi_device.id eventually */ - unsigned long create:1; /* signal that it needs to be added */ + unsigned int create:1; /* signal that it needs to be added */ + unsigned int no_report_lun:1; /* do not use REPORT LUNS */char scsi_level;void *hostdata;/* available to low-level driver */ unsigned long starget_data[0 ];/* for the transport */
drivers/scsi/scsi_scan.c +1 -0
@@ -1078,6 +1078,7 @@ static int scsi_report_lun_scan(struct s* support more than 8 LUNs. */ if ((bflags &BLIST_NOREPORTLUN ) || + starget->no_report_lun || starget->scsi_level <SCSI_2 || (starget->scsi_level <SCSI_3 && (!(bflags &BLIST_REPORTLUN2 ) || shost->max_lun <=8 )) )
include/scsi/scsi_device.h struct scsi_target { · line 168
Quoted 13 lines · Alan Stern
===================================================================
include/scsi/scsi_device.h +2
-1@@ -161,7 +161,8 @@ struct scsi_target {unsigned int channel;unsigned int id;/* target id ... replace * scsi_device.id eventually */ - unsigned long create:1; /* signal that it needs to be added */ + unsigned int create:1; /* signal that it needs to be added */ + unsigned int no_report_lun:1; /* do not use REPORT LUNS */char scsi_level;void *hostdata;/* available to low-level driver */ unsigned long starget_data[0 ];/* for the transport */
Alan,
Instead of adding a new bit field to scsi_target could we utilize bflags in the scsi_target. Currently we have sdev_bflags in the scsi_device which we are not utilizing. We could remove sdev_bflags and add a bflags to scsi_target
In the usb slave configure we could "or" in BLIST_NOREPORTLUN.
Then in the function scsi_get_device_flags we could reference the scsi_target bflags instead of sdev_bflags.
The bflags check in scsi_scan.c for BLIST_NOREPORTLUN could stay the same and we would not have two flags for a similar no report luns check.
-andmike
--
Michael Anderson
[email protected]
Alan Stern
maintainerQuoted 7 lines · Mike Anderson
Alan,
Instead of adding a new bit field to
scsi_targetcould we utilize bflags in thescsi_target. Currently we havesdev_bflagsin thescsi_devicewhich we are not utilizing. We could removesdev_bflagsand add a bflags toscsi_target
Quoted 7 lines
In the usb slave configure we could "or" in
BLIST_NOREPORTLUN.Then in the function
scsi_get_device_flagswe could reference thescsi_targetbflags instead ofsdev_bflags.The bflags check in
scsi_scan.cforBLIST_NOREPORTLUNcould stay the same and we would not have two flags for a similar no report luns check.
That's a good idea. Except that we should keep sdev_bflags while adding target_bflags.
I see there's a comment in scsi_probe_lun:
/*
* Get any flags for this device.
*
* XXX add a bflags to Scsi_Device, and replace the
* corresponding bit fields in Scsi_Device, so bflags
* need not be passed as an argument.
*/
Does that need to be updated?
There are several other flags in scsi_device that are duplicates of things in bflags:
lockable BLIST_NOT_LOCKABLE use_10_for_ms BLIST_USE_10_BYTE_MS use_192_bytes_for_3f BLIST_MS_192_BYTES_FOR_3F skip_ms_page_8 BLIST_MS_SKIP_PAGE_08 skip_ms_page_3f BLIST_MS_SKIP_PAGE_3F no_start_on_add BLIST_NOSTARTONADD retry_hwerr BLIST_RETRY_HWERROR
Maybe I've missed some. Then there are flags which aren't used any more, like BLIST_INQUIRY_36 (although for backward compatibility we should try to keep them). Note also that some of these flags apply to individual LUNs while others apply to entire targets.
There's a good reason for storing these flags in the device or target. If they're available only in the blacklist database then drivers can't adjust them for specific devices. Ideally, once that structures have been set up and the blacklist flags copied into them, there will be no need to refer back to the original database entry.
The whole situation is thoroughly disorganized. If you would like to rearrange everything, you've got my support.
Alan Stern
PATCH 1/1 writable scsi_level [was: [Merging ATA passthru] on integrating SMART/ATA-Security in usb-storage driver]
In reply to James BottomleyQuoted 11 lines · James Bottomley
Quoted 7 lines · Alan Stern
Quoted 3 lines
That is, is usb-storage forcing scsi-2 when the device tells us it is scsi-3 compliant, or is the hardware reporting devices are scsi-2, yet requiring non-LUN value in cdb[1]?
I think we may have both. However I don't know how this Cypress chip reports itself. A system log showing the INQUIRY data would be very helpful.
Quoted 14 lines
We were told in prior emails that it actually reports a level of zero (i.e. no compliance with any SCSI standard). My original proposal was just not to modify the CDB[1] for this case if we could get the INQUIRY passed through unmangled.
Quoted 8 lines
It's quite possible that usb-storage no longer needs to force the scsi-level to 2. No one has recently tested what would happen without it. Matt probably has the best selection of devices for testing...
There is one problem we have with devices that report themselves as SCSI-3 or SCSI-4 but hang when they receive a REPORT LUNS command. That's easily handled by making usb-storage set the NOREPORTLUN flag. Maybe that's all we need to do.
This patch may add some flexibility. It allows /sys/class/scsi_device/<hcil>/device/scsi_level to be written. It won't help during scanning but will indirectly allow people to get the functionality of SG_FLAG_LUN_INHIBIT back (via writing a number greater than 3 into scsi_level).
The patch is against lk 2.6.15-rc3
Changelog:
- make sysfs scsi_level attribute writable
- fix bug in sdev_rw_attr macro (but can't use it because scsi_device::scsi_level is a char)
Doug Gilbert
drivers/scsi/scsi_sysfs.c2615rc3sl renamed from drivers/scsi/scsi_sysfs.c +22 -2
@@ -322,7 +322,7 @@ { \ struct scsi_device *sdev; \ sdev = to_scsi_device(dev); \ - snscanf (buf, 20, format_string, &sdev->field); \ + sscanf (buf, format_string, &sdev->field); \ return count; \ } \ static DEVICE_ATTR(field, S_IRUGO | S_IWUSR, sdev_show_##field, sdev_store_##field);
@@ -375,12 +375,32 @@ sdev_rd_attr (device_blocked, "%d\n"); sdev_rd_attr (queue_depth, "%d\n"); sdev_rd_attr (type, "%d\n"); -sdev_rd_attr (scsi_level, "%d\n"); sdev_rd_attr (vendor, "%.8s\n"); sdev_rd_attr (model, "%.16s\n"); sdev_rd_attr (rev, "%.4s\n"); static ssize_t +sdev_show_scsi_level (struct device *dev, struct device_attribute *attr, char *buf) +{ + struct scsi_device *sdev; + sdev = to_scsi_device(dev); + return snprintf (buf, 20, "%d\n", (int)sdev->scsi_level); +} + +static ssize_t +sdev_store_scsi_level (struct device *dev, struct device_attribute *attr, + const char *buf, size_t count) +{ + struct scsi_device *sdev; + int val; + sdev = to_scsi_device(dev); + sscanf (buf, "%d\n", &val); + sdev->scsi_level = val; + return count; +} +static DEVICE_ATTR(scsi_level, S_IRUGO | S_IWUSR, sdev_show_scsi_level, sdev_store_scsi_level); + +static ssize_t sdev_show_timeout (struct device *dev, struct device_attribute *attr, char *buf) { struct scsi_device *sdev;
Re: [usb-storage] [Merging ATA passthru] on integratingSMART/ATA-Security in usb-storage driver
In reply to Patrick MansfieldQuoted 3 lines
... is usb-storage forcing scsi-2 when the device tells us it is scsi-3 compliant, or is the hardware reporting devices are scsi-2, yet requiring non-LUN value in cdb[1]?
The very newest devices that pass info thru mask xE0 of cdb[1] may be reporting SCSI zero, especially when the cable is not SPI & especially when Peripheral Device Type (mask x1F of byte 0 of Inquiry data) is nonzero.
Quoted 2 lines
We were told in prior emails that it actually reports a level of zero (i.e. no compliance with any SCSI standard)
People dispute what zero means in byte 2 of SCSI Inquiry data. Here are five widely disseminated opinions:
a) T10 s1-r17b: "Version is unspecified. (Use this code if you are implementing to this document - it is not published, yet.)"
b) T10 s1-r17b: "does not claim compliance to the ISO or ECMA versions of SCSI".
c) T10 s2-r10l.pdf: "might or might not comply to an ANSI-approved standard"
d) T10 s2-r10l.pdf: "does not claim compliance to the ISO or ECMA versions of SCSI".
e) SFF sff8020i.pdf: [mask x07] "must contain a zero to comply with this version of the Specification"
See that? Often, the very same document disagrees with itself.
Nowadays, the SFF heresy has grown to where T10 simultaneous publishes two or more distinct definitions of Inquiry - the SPC definition and the MMC definition.
SPC Inquiry data bytes 58 and following now have "version descriptor" definitions that let a device that zeroes byte 2 say more, in theory. I haven't actually seen anyone populate those fields in a mass market product?
Quoted 1 line
...
I'd think that everyone should accept that trying to reclaim mask xFF in the last CDB byte and mask xE0 of CDB byte 1 is rude ... I'm not sure what rationally motivates those movements in device design that demand greater transparency of a pass thru SCSI host.
Quoted 4 lines · Matthew Dharm
I've been recommending this flag to people as recently as 6 months ago
(i.e. the last time someone asked me). It comes up 2-3 times a year.The last time it came up, the device set
SCSI_2.
OK ... if you send a patch to add it back I'll look it over ... but it needs to be clean; I'm betting it needs a huge amount of changes that would thread through both SCSI and block (so Jens will need to ack it too).
James
Quoted 6 lines · Matthew Dharm
I just realized this plan has a problem...
The reported SCSI level of a device is mostly garbage, but not always. I've seen 0, 1, 2, 3, and
0xffall reported. HOWEVER, the reported value seems independent of what devices have vendor-specific commands (and thus need the CDB[1] not messed with).
But it is only a problem for devices that require us to set values in cdb[1] that conflict with the scsi spec, not for all devices that have vendor specific commands.
Do the devices in question that don't want the LUN in cdb[1] report as scsi-3 or later? If so we can still pass through the scsi level and it would work fine. Yeh, if we later hit scsi-2 devices that want it we have a problem.
-- Patrick Mansfield
Quoted 6 lines · Matthew Dharm
Quoted 4 lines · James Bottomley
What happens if you prevent USB mangling the
scsi_level? I think, for the most part, we would handle 0 in about the same way as we handle 2. However, we could gate the if around the CDB[1] mangling as
Quoted 7 lines
Quoted 3 lines
if (
scsi_level!=SCSI_UNKNOWN&&scsi_level<=SCSI_2)which should fix your problem, I think.
A long time ago, usb-storage didn't mangle the
scsi_level. And almost nothing worked. Without a SCSI level, 6-byte commands get sent; only 10-byte commands will do.
Yes, that was long ago. Haven't things improved?
(For example, I seem to recall adding stuff like use_10_for_{ms,rw} to make it possible for usb storage to tell the SCSI layer that it prefers 10-byte commands. Maybe no cheating with SCSI level is needed anymore?)
Andries
Quoted 8 lines · Timothy Thelin
The problem then is with vendor specific commands as SCSI core mangles those as well. The vendor specific command I had issues with is the "ATACB" ATA passthru cdb that cypress boards understand. CDB[1] is a signature byte that must be
0x24. Needless to say, that leading 2 gets masked off to a 0, and the drive aborts the ATACB. Now cypress could have been smarter about designing their cdb, but they wern't, and so there really needs to be a way to tell SCSI core "hands off the cdb".
If this issue is real, you can use ub with that device for now.
-- Pete
Quoted 13 lines · Pete Zaitcev
Quoted 8 lines · Timothy Thelin
The problem then is with vendor specific commands as SCSI core mangles those as well. The vendor specific command I had issues with is the "ATACB" ATA passthru cdb that cypress boards understand. CDB[1] is a signature byte that must be
0x24. Needless to say, that leading 2 gets masked off to a 0, and the drive aborts the ATACB. Now cypress could have been smarter about designing their cdb, but they wern't, and so there really needs to be a way to tell SCSI core "hands off the cdb".
Quoted 4 lines
If this issue is real, you can use ub with that device for now.
-- Pete
-
hello Pete
nice idea :)
unfortunately it doesnt work with latest smartctl cvs on my usb2 drive, no smart functionality
tom1:/usr/src/sm5# ./smartctl -a -d scsi /dev/uba smartctl version 5.34 [i686-pc-linux-gnu] Copyright (C) 2002-5 Bruce Allen Home page is http://smartmontools.sourceforge.net/
Device: IC35L030 AVVN07-0 Version:
Device type: disk
Local Time is: Sat Nov 5 16:49:28 2005 CET
Device does not support SMART
Error Counter logging not supported
Device does not support Self Test logging
tom1:/usr/src/sm5#
hdparm cant work(?). not implemented.
tom1:/usr/src/sm5# sdparm -alv /dev/uba
/dev/uba: IC35L030 AVVN07-0
Read write error recovery [PS=0] mode page:
AWRE 0 [cha: n, def: 0, sav: 0] Automatic write reallocation enabled
ARRE 0 [cha: n, def: 0, sav: 0] Automatic read reallocation enabled
TB 0 [cha: n, def: 0, sav: 0] Transfer block
RC 0 [cha: n, def: 0, sav: 0] Read continuous
EER 0 [cha: n, def: 0, sav: 0] Enable early recover
PER 0 [cha: n, def: 0, sav: 0] Post error
DTE 0 [cha: n, def: 0, sav: 0] Data terminate on error
DCR 0 [cha: n, def: 0, sav: 0] Disable correction
RRC 0 [cha: n, def: 0, sav: 0] Read retry count
WRC 0 [cha: n, def: 0, sav: 0] Write retry count
RTL 0 [cha: n, def: 0, sav: 0] Recovery time limit (ms)Quoted 3 lines
Quoted 3 lines
Format (SBC) mode page not supported
Rigid disk (SBC) mode page not supported Verify error recovery (SBC) mode page not supported
Caching (SBC) [PS=0] mode page:
IC 0 [cha: n, def: 0, sav: 0] Initiator control ABPF 0 [cha: n, def: 0, sav: 0] Abort pre-fetch CAP 0 [cha: n, def: 0, sav: 0] Caching analysis permitted DISC 0 [cha: n, def: 0, sav: 0] Discontinuity SIZE 0 [cha: n, def: 0, sav: 0] Size (1->CSS valid, 0->NCS valid) WCE 0 [cha: n, def: 0, sav: 0] Write cache enable MF 0 [cha: n, def: 0, sav: 0] Multiplication factor RCD 0 [cha: n, def: 0, sav: 0] Read cache disable DRRP 0 [cha: n, def: 0, sav: 0] Demand read retension priority WRP 0 [cha: n, def: 0, sav: 0] Write retension priority DPTL 0 [cha: n, def: 0, sav: 0] Disable pre-fetch transfer length MIPF 0 [cha: n, def: 0, sav: 0] Minimum pre-fetch MAPF 0 [cha: n, def: 0, sav: 0] Maximum pre-fetch MAPFC 0 [cha: n, def: 0, sav: 0] Maximum pre-fetch ceiling
Quoted 8 lines
Quoted 8 lines
skipping rest as field position exceeds mode page length=12 Control mode page not supported
XOR control (SBC) mode page not supported
Protocol specific logical unit mode page not supported Protocol specific port mode page not supported Power condition mode page not supported Informational exceptions control mode page not supported Background control (SBC) mode subpage not supported
tom1:/usr/src/sm5#
device is in locked state, ata-security.
hmm, could someone supply me a sdparm commandline and data to test unlock (if supported), pls ? im not through with all the specs from T10.org yet and they want money for more docs.
thx,
tom
Re: [usb-storage] [Merging ATA passthru] on integratingSMART/ATA-Security in usb-storage driver
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
The problem then is with vendor specific commands as SCSI core mangles those as well. The vendor specific command I had issues with is the "ATACB" ATA passthru cdb that cypress boards understand. CDB[1] is a signature byte that must be
0x24. Needless to say, that leading 2 gets masked off to a 0, and the drive aborts the ATACB. Now cypress could have been smarter about designing their cdb, but they wern't, and so there really needs to be a way to tell SCSI core "hands off the cdb".
I may be remembering this "could have been smarter" choice was conscious.
This design work was done in Boise by ISD, later acquired by the Cypress San Diego people? I didn't work for them, but I knew some of the time. At the time people didn't want opaque pass thru to work, only fully transparent pass thru. People looked around for some bits that most fragile-because-opaque pass thru schemes stomp on, and found mask xE0 in CDB byte 1.
The push against making ATA pass thru too easy came from the debates over whether to encode storage requests as ATA or SCSI or USB or a mix or all three. At the time we were advocating SCSI & deprecating ATA, because ATA thru USB had reached the market first without allowing for RMB ATAPI thru USB. The revolutionary purely USB encoding that a solution like ub.ko allows had no traction at all.
Another analogous theoretical possibility we deprecated at the same time was devices that simultaneously accepted both CBI & BBB encodings of SCSI. Again the issue was the hosts that might have neglected to rapidly adopt SCSI thru BBB, and thus implicitly RMB support, if ATA thru CB had also been a mass-produced option.
I can't remember if the '\x24' = '$' = U.S. dollar sign pun was significant.
Certainly SCSI thru BBB worked well enough that the efforts to step further forward lost impetus. The fact that ATA, while lacking RMB support, includes encodings for purportedly useful requests that SCSI lacks, such as SMART, gathered no significant attention.