Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
On Thu, Feb 01, 2007 at 03:21:25PM -0500, Douglas Gilbert wrote: My point is that the linux block layer and scsi mid level should get out of the business of putting hard limits place. Why? Both of them never have been in the business of putting hard limits in place. We currently have a hard limit in place because the storage for the cdb is allocated statically. This is a desin decision done more than ten years ago that we're slowly trying to fix. Second we have a facility to allow LLDDs limit the size of the cdb they receive. It's not mandatory in any way, but very useful for those smart HBAs that can't deal with larger dbs due to hardware limitations. - 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
Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
Mark Lord wrote: For example, I think all existing ATAPI drives only speak 12-byte packet protocols, and so if we tell SCSI we're good for 16-byte, then won't the SCSI layer suddenly start sending us READ_16 and the like? Speaking strictly about the device, IDENTIFY PACKET DEVICE data page tells us whether the device supports 12-byte or 16-byte CDBs. No need to guess. Some host controllers only support 12-byte, but I think that most should support 16-byte. Jeff - 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
Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
Tejun Heo wrote: SCSI always uses the smallest command it can use, so we're safe. Most other commands are issued directly from the userland and it's their responsibility not to feed disallowed commands to a device (or we need more advanced filter). Anyways, this has never been guaranteed because the limit is host wide. So, I'm for setting it to 16. Jeff, what do you think? Like I just noted in another email, the limit is really on the /device/ side. In theory the user could plug in a 16-byte ATAPI device and a 12-byte ATAPI device to the same host. We should be able to safely raise the limit to 16-byte for most host controllers. Note I said most. The bitch will be figuring out which host controllers do not like 16-byte CDBs. Jeff - 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
Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
Mark Lord wrote: Tejun Heo wrote: Anyways, this has never been guaranteed because the limit is host wide. But until very very recently, host wide meant just a single device for libata. I was just assuming we did all of the fiddling to ensure a minimal value there for some real reason. But, yes, now we have PATA (2 drives per host), and PMP (many more drives per host), so just maxing out the limit seems sensible. No, we can't just assume that all host controller CDB FIFOs (if indeed that's the implementation) support 16-byte CDBs. Gotta do a controller-by-controller check. There are both /host/ and /device/ limits. Jeff - 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
Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
Jeff Garzik wrote: Mark Lord wrote: For example, I think all existing ATAPI drives only speak 12-byte packet protocols, and so if we tell SCSI we're good for 16-byte, then won't the SCSI layer suddenly start sending us READ_16 and the like? Speaking strictly about the device, IDENTIFY PACKET DEVICE data page tells us whether the device supports 12-byte or 16-byte CDBs. No need to guess. Some host controllers only support 12-byte, but I think that most should support 16-byte. Out of curiosity, does ATA controllers which don't allow 16byte CDB actually exist? It's transferred using PIO protocol anyway. -- tejun - 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
Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
Jeff Garzik wrote: Tejun Heo wrote: SCSI always uses the smallest command it can use, so we're safe. Most other commands are issued directly from the userland and it's their responsibility not to feed disallowed commands to a device (or we need more advanced filter). Anyways, this has never been guaranteed because the limit is host wide. So, I'm for setting it to 16. Jeff, what do you think? Like I just noted in another email, the limit is really on the /device/ side. In theory the user could plug in a 16-byte ATAPI device and a 12-byte ATAPI device to the same host. We should be able to safely raise the limit to 16-byte for most host controllers. Note I said most. The bitch will be figuring out which host controllers do not like 16-byte CDBs. Well, it's not any worse than what we're currently doing. We don't set host cdb len limit according to the host. We set it to the largest value among the attached devices. So, if there is a 12 byte only controller out there and if you connect 16 byte ATAPI device to it, you're screwed already and will continue to be screwed after the change. Note that raising host cdb limit to 16 doesn't make anybody issue 16 byte cdb to the device. The only unconditionally allowed 16 byte cdb is ATA_16 which is executed by libata SAT and thus doesn't pass through the host. -- tejun - 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
Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
Tejun Heo wrote: Jeff Garzik wrote: Mark Lord wrote: For example, I think all existing ATAPI drives only speak 12-byte packet protocols, and so if we tell SCSI we're good for 16-byte, then won't the SCSI layer suddenly start sending us READ_16 and the like? Speaking strictly about the device, IDENTIFY PACKET DEVICE data page tells us whether the device supports 12-byte or 16-byte CDBs. No need to guess. Some host controllers only support 12-byte, but I think that most should support 16-byte. Out of curiosity, does ATA controllers which don't allow 16byte CDB actually exist? It's transferred using PIO protocol anyway. That's why I think that most PATA controllers are likely safe, since it is just more twiddling signals directly to the device. We have to be more careful, ironically, with the smart controllers. They are more likely to keep the CDB contents in a FIFO or other silicon buffer somewhere, as temporary storage during a DMA - buffer - device transfer of the CDB contents. Any first-gen SATA-emulating-PATA controller is instantly under suspicion, because they are not truly twiddling signals but emulating such by building FIS's under the hood. Jeff - 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
Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
On Thu, 2007-02-01 at 04:54 -0500, Jeff Garzik wrote: Agreed... but that doesn't make it the /right/ thing to do ;-) The logic behind the current code, which limits to the maximum size allowed by an attached device on the port, is mainly to leverage the SCSI layer as a filter for bad CDB lengths. IOW, it's called being lazy ;-) But you're requesting code changes in the SCSI layer because of this incorrect usage. max_cdb is supposed to be the *host* limit. The mid layer finds out and respects device limits separately from this. James - 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
Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
James Bottomley wrote: But you're requesting code changes in the SCSI layer because of this incorrect usage. max_cdb is supposed to be the *host* limit. The mid layer finds out and respects device limits separately from this. I never requested any such thing. Jeff - 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
Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
James Bottomley wrote: On Thu, 2007-02-01 at 04:54 -0500, Jeff Garzik wrote: Agreed... but that doesn't make it the /right/ thing to do ;-) The logic behind the current code, which limits to the maximum size allowed by an attached device on the port, is mainly to leverage the SCSI layer as a filter for bad CDB lengths. IOW, it's called being lazy ;-) But you're requesting code changes in the SCSI layer because of this incorrect usage. max_cdb is supposed to be the *host* limit. The mid layer finds out and respects device limits separately from this. To be more pedantic: actual_max_cdb = min(MAX_COMMAND_SIZE, host_limit) Since the host is a bridge, that could be a limit on near side (i.e. PCI (unlikely)) or the outer side (i.e. transport initiator (port)). In modern HBAs the host_limit is likely to be greater than 16, to allow for advanced SBC and OSD commands. However currently MAX_COMMAND_SIZE (defined in scsi/scsi_cmnd.h) is 16. It is the ATAPI _transport_ that has the 12 byte cdb limit *** (at least according to MMC-5 rev Annex A; is S-ATAPI any better?). Other MMC transports referred to in MMC-5 are SPI, SBP(IEEE 1394) and USB mass storage; and no mention is made of cdb length limits for them. Since ATAPI is the dominant transport for cd/dvd drives, MMC doesn't define any commands over 12 bytes in length, but both SPC (which MMC should honour) and SSC-3 (think tape drives, ATAPI connected) do. My point is that the linux block layer and scsi mid level should get out of the business of putting hard limits place. Why? Since kernel limits are at best necessary but not sufficient, the upper layers still need to be able to cope with errors associated with that limit. So why have the limit? Does the kernel do analysis to find out whether a USB connected DVD drive has a USB to ATAPI bridge externally? I don't think so. There is a role to fetch information that may act as a guide when a ULD has a choice of commands to build (e.g. sd deciding between READ(10) and READ(16)). Let the cdb size bottleneck (or whatever) report an error and upper layers that are impacted, including user space programs, can act accordingly. If the kernel really wants to offload complexity to the user space, the kernel needs to get out of the business of trying to foresee errors. It needs to get better at coping with errors and if possible adapting its behaviour. *** not the host nor the device Doug Gilbert - 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
Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
Douglas Gilbert wrote: It is the ATAPI _transport_ that has the 12 byte cdb limit *** (at least according to MMC-5 rev Annex A; is S-ATAPI any better?). Then the spec is wrong. 1) The transport does not limit the CDB size. 2) The ATAPI device limits the CDB size, and it exports this limit via IDENTIFY PACKET DEVICE. It can be either 12 or 16 bytes. 3) In some rare cases, the host controller silicon may limit CDB size. Jeff - 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
Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
Mark Lord wrote: In an ideal world, we would use the existing ATA_12 opcode to issue 12-byte ATA passthrough commands for libata ATAPI drives from userspace. But ATA_12 happens to have the same SCSI opcode value as the older CD/RW BLANK command, widely used by cdrecord and friends. So, to achieve ATA passthru capability for libata ATAPI, we have to instead use the ATA_16 opcode: a 16-byte command. SCSI normally disallows issuing 16-byte commands to 12-byte devices, so special support has to be added for this. Introduce an allow_ata_16 boolean to the scsi_host struct. This provides a means for libata to signal that 16-byte ATA_16 commands should be permitted even for 12-byte ATAPI devices. There are companion patches submitted separately to add ATAPI ATA_16 capability to libata. Signed-off-by: Mark Lord [EMAIL PROTECTED] I might have missed the discussion but can't we just set host-max_cmd_len to 16 unconditionally? libata is emulating a SCSI device anyway and, from SCSI's POV, the situation is that any libata ATAPI device can do both 12 and 16 byte commands while some of them only allow allow ATA_16 for 16 byte command. Also, it's not like host-max_cmd_len gives any guaranteed protection against CDB length. Being a 'host' limit, it's set to the highest number in the host. In that respect, it should be set to 16 too. All ATA hosts can do 16 byte CDBs. Thanks. -- tejun - 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
Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
Tejun Heo wrote: Mark Lord wrote: .. So, to achieve ATA passthru capability for libata ATAPI, we have to instead use the ATA_16 opcode: a 16-byte command. SCSI normally disallows issuing 16-byte commands to 12-byte devices, so special support has to be added for this. I might have missed the discussion but can't we just set host-max_cmd_len to 16 unconditionally? Sure thing, if you and Jeff are happy with that, then lets do it. I just kind of assumed that the complexity in ata_set_port_max_cmd_len() was there for some kind of reason. For example, I think all existing ATAPI drives only speak 12-byte packet protocols, and so if we tell SCSI we're good for 16-byte, then won't the SCSI layer suddenly start sending us READ_16 and the like? Cheers - 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
Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
Mark Lord wrote: Tejun Heo wrote: Mark Lord wrote: .. So, to achieve ATA passthru capability for libata ATAPI, we have to instead use the ATA_16 opcode: a 16-byte command. SCSI normally disallows issuing 16-byte commands to 12-byte devices, so special support has to be added for this. I might have missed the discussion but can't we just set host-max_cmd_len to 16 unconditionally? Sure thing, if you and Jeff are happy with that, then lets do it. I just kind of assumed that the complexity in ata_set_port_max_cmd_len() was there for some kind of reason. For example, I think all existing ATAPI drives only speak 12-byte packet protocols, and so if we tell SCSI we're good for 16-byte, then won't the SCSI layer suddenly start sending us READ_16 and the like? SCSI always uses the smallest command it can use, so we're safe. Most other commands are issued directly from the userland and it's their responsibility not to feed disallowed commands to a device (or we need more advanced filter). Anyways, this has never been guaranteed because the limit is host wide. So, I'm for setting it to 16. Jeff, what do you think? -- tejun - 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
Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
James Bottomley wrote: .. In SCSI, we're very careful only to use large commands where necessary, so even for a 2TB array, you only see 16 byte commands for sectors beyond 2TB. This essentially means that the capacity (and we do a careful READ_CAPACITY(10) and only move on to READ_CAPACITY(16) if we're told to) limits the command size. Very cool, James. - 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
Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices
Tejun Heo wrote:
Anyways, this has never been guaranteed because
the limit is host wide.
But until very very recently, host wide meant just a single device
for libata. I was just assuming we did all of the fiddling to ensure
a minimal value there for some real reason.
But, yes, now we have PATA (2 drives per host), and PMP (many more
drives per host), so just maxing out the limit seems sensible.
So, I'm for setting it to 16. Jeff, what do you think?
This patch sets libata to always accept CDB lengths up to 16 bytes.
With this change, ATA_16 passthrough commands can now be passed into
libata for ATAPI devices. There is a separate related patch already
pending to actually implement ATA_16 for ATAPI inside libata.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
--- old/drivers/ata/libata-core.c 2007-01-31 19:55:53.0 -0500
+++ linux/drivers/ata/libata-core.c 2007-01-31 19:57:15.0 -0500
@@ -1577,20 +1577,6 @@
snprintf(desc, desc_sz, NCQ (depth %d/%d), hdepth, ddepth);
}
-static void ata_set_port_max_cmd_len(struct ata_port *ap)
-{
- int i;
-
- if (ap-scsi_host) {
- unsigned int len = 0;
-
- for (i = 0; i ATA_MAX_DEVICES; i++)
- len = max(len, ap-device[i].cdb_len);
-
- ap-scsi_host-max_cmd_len = len;
- }
-}
-
/**
* ata_dev_configure - Configure the specified ATA/ATAPI device
* @dev: Target device to configure
@@ -1771,8 +1757,6 @@
}
}
- ata_set_port_max_cmd_len(ap);
-
/* limit bridge transfers to udma5, 200 sectors */
if (ata_dev_knobble(dev)) {
if (ata_msg_drv(ap) print_info)
@@ -5689,7 +5673,7 @@
shost-max_id = 16;
shost-max_lun = 1;
shost-max_channel = 1;
- shost-max_cmd_len = 12;
+ shost-max_cmd_len = 16;
}
/**
-
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
