headers
Tejun Heo | 1 Feb 2007 01:27
Picon

Re: [PATCH] libata: fix translation for START STOP UNIT

Mark Lord wrote:
> Robert Hancock wrote:
>> I'd love to, but unfortunately nobody seems to have come up with a way
>> of doing this in Thunderbird that keeps it from mangling whitespace 
> 
> Yup, major nuisance.  I have to fire up Kmail whenever I'm posting patches,
> and then go back to Thunderbird again afterwards.

A much better solution with thunderbird is using external editor
extension.

http://globs.org/articles.php?lng=en&pg=2

Install the extension.  Configure it with your favorite editor.
Thunderbird won't do a thing about your message if you turn off
linewrap.

	 For example, this line starts with a tab and a space and (double tab)		is very long and I'm writing in emacs
fired up from thunderbird. (double space)  

Cheers.

--

-- 
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tejun Heo | 1 Feb 2007 01:33
Picon

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 <mlord <at> pobox.com>

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
(Continue reading)

Permalink | Reply | 36 comments |
headers
Mark Lord | 1 Feb 2007 01:42
Picon
Favicon

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-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 32 comments |
headers
James Bottomley | 1 Feb 2007 01:44

Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices

On Thu, 2007-02-01 at 09:33 +0900, Tejun Heo wrote:
> 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.

This looks like a much better proposal to me.

James

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
James Bottomley | 1 Feb 2007 01:48

Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices

On Wed, 2007-01-31 at 19:42 -0500, Mark Lord wrote:
> 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?

The SCSI parameter max_cdb is supposed to reflect the host, not the
device.  This is for the nutcase of connecting a > 2TB array to say a
qla1280 ... the mid-layer and the device can both go beyond 2TB but the
HBA can't (being limited to 12 byte commands).

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.

James

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tejun Heo | 1 Feb 2007 01:48
Picon

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?
(Continue reading)

Permalink | Reply | 20 comments |
headers
Gary Hade | 1 Feb 2007 01:49
Picon
Favicon

Re: [2.6.18,19] SATA boot problems (ICH6/ICH6W)

On Wed, Jan 31, 2007 at 07:44:43PM +0900, Tejun Heo wrote:
> Gary Hade wrote:
> > Some of my random thoughts:
> > There does appear to be this invalid assumption that 0xFF status 
> > always implies device-not-present.  The status register access 
> > restrictions in ATA/ATAPI-7 V1 5.14.2 include the statement "The 
> > contents of this register, except for BSY, shall be ignored when 
> > BSY is set to one." which the code does not honor.  There is apparently 
> > past experience that 0xFF status implies device-not-present for some
> > controllers (the odd clowns :) but I have no idea how common these are.
> 
> The 0xff is the value we get when there is no device present and the
> motherboard manufacturer forgot to pull down the ATA bus.  It's not very
> uncommon in cheap PATA world and, following the weird tradition, some
> SATA controllers choose to emulate 0xff if there is no device attached
> (link not established).  Not sure how many of them does it but intel's
> SATA chipset is one of them, so we're pretty much stuck with it.
> 
> ie. In many P/SATA setups, your patch would add 2 extra secs of waiting
> for empty ports.
> 
> > We obviously can't get rid of the check but since we cannot clear
> > the read-only status register and there appears to be no specification 
> > dictated upper limit on how long it should take for a software reset to 
> > complete it just seems like we need to wait long enough to support the 
> > slowest known device which may be the GoVault.
> 
> Agreed but still hesitant to ack the patch.  :-)
> 
> I'm gonna work on parallel probing for libata.  I think we can easily
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Lord | 1 Feb 2007 01:53
Picon
Favicon

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-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Mark Lord | 1 Feb 2007 02:01
Picon
Favicon

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 <mlord <at> pobox.com>
---
--- old/drivers/ata/libata-core.c	2007-01-31 19:55:53.000000000 -0500
+++ linux/drivers/ata/libata-core.c	2007-01-31 19:57:15.000000000 -0500
 <at>  <at>  -1577,20 +1577,6  <at>  <at> 
 		snprintf(desc, desc_sz, "NCQ (depth %d/%d)", hdepth, ddepth);
 }

-static void ata_set_port_max_cmd_len(struct ata_port *ap)
-{
-	int i;
-
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mark Lord | 1 Feb 2007 02:04
Picon
Favicon

Re: [PATCH] libata: fix translation for START STOP UNIT

Tejun Heo wrote:
> 
> A much better solution with thunderbird is using external editor
> extension.
> 
> http://globs.org/articles.php?lng=en&pg=2

Brilliant!  Installed, and now tested (the max_cmd_len patch posting).

-ml
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |

Gmane