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 | 0 comments |
headers
Patro, Sumant | 1 Feb 2007 01:41

RE: Re: [PATCH] scsi: megaraid_{mm,mbox} init fix for kdump

The patch is specific to kdump scenario.
What I see in the log is cmd timeout(s) and is not related to the patch.

--Sumant

-----Original Message-----
From: linux-scsi-owner <at> vger.kernel.org
[mailto:linux-scsi-owner <at> vger.kernel.org] On Behalf Of Matthias Urlichs
Sent: Wednesday, January 31, 2007 9:50 AM
To: linux-scsi <at> vger.kernel.org
Cc: linux-kernel <at> vger.kernel.org
Subject: Re: [PATCH] scsi: megaraid_{mm,mbox} init fix for kdump

On Fri, 05 Jan 2007 07:10:09 -0800, Sumant Patro wrote:

>         This command clears the pending commands in the adapter
>         and re-initialize its internal RAID structure.
>         Without this change, megaraid driver either panics or fails to
>         initialize the adapter during kdump's second kernel boot
>         if there are pending commands or interrupts from other devices
>         sharing the same IRQ.

Nice. Is there a chance that this patch will also fix the regression
I've noticed (today, unfortunately) on (at least one) Dell server?

FWIW, here's the relevant LSPCI output and kernel logs:

0d:0e.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID (rev 07)
        Subsystem: Dell Unknown device 0002
        Flags: bus master, stepping, 66MHz, medium devsel, latency 64,
(Continue reading)

Permalink | Reply | 0 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 | 0 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 | 0 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 | 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 | 0 comments |
headers
James Bottomley | 1 Feb 2007 02:51
Favicon

RE: [PATCH] - export scsilun_to_int

On Wed, 2007-01-31 at 15:54 -0700, Eric Moore wrote:
> static int
> +mptscsih_cmp_scsilun(struct scsi_lun * lun1, struct scsi_lun * lun2)
> +{
> +       int i;
> +
> +       for (i = 0; i < 8 ; i++)
> +               if (lun1->scsi_lun[i] != lun2->scsi_lun[i])
> +                       return 1;
> +
> +       return 0;
> +}

what's wrong with

memcmp(lun1->scsi_lun, lun2->scsi_lun, 8)

rather than introducing a wrapper?  The compiler can even optimise
memcmp for a fixed size nicely.

James

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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 | 1 comment |
headers
Matthias Urlichs | 1 Feb 2007 08:01
Picon

Re: [PATCH] scsi: megaraid_{mm,mbox} cmd timeout

Hi,

Patro, Sumant:
> What I see in the log is cmd timeout(s) and is not related to the patch.
> 
Ouch.

Any ideas what causes my problem? It's a regression; I tested Ubuntu
Dapper and Edgy install CDs, and it's not worked since the latter.

I can pinpoint the change that triggers the problem more closely if
necessary.

--

-- 
Matthias Urlichs   |   {M:U} IT Design  <at>  m-u-it.de   |  smurf <at> smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
My father was a God-fearing man, but he never missed a copy of the
New York Times, either.
		-- E.B. White
Permalink | Reply | 0 comments |

Gmane