All of lore.kernel.org
 help / color / mirror / Atom feed
From: Douglas Gilbert <dougg@torque.net>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Tejun Heo <htejun@gmail.com>, linux-ide@vger.kernel.org
Subject: Re: [PATCH] libata: fix ATA passthrough handling for ATAPI devices
Date: Sat, 21 Oct 2006 17:18:14 -0400	[thread overview]
Message-ID: <453A8E96.9040702@torque.net> (raw)
In-Reply-To: <453A7F6B.1010205@pobox.com>

Jeff Garzik wrote:
> Douglas Gilbert wrote:
>> The 16 byte CDB that Tejun is talking about is the
>> ATA PASS THROUGH (16) SCSI command. That is valid to
> 
> I'm talking about the changes to the implementation, which appear to
> mistakenly allow 16-byte CDBs through to the ATAPI device, even if it
> only supports 12-byte CDBs.
> 
> I am quite aware of the ATA passthru SCSI command.  Heck, the spec had
> input from me.  I'm talking about something different.

This is what I saw, with the new ATA subsystem in
lk 2.6.19-rc1:

[root@sas ~]# lsscsi -H
[0]    sata_nv
[1]    sata_nv
[2]    sata_nv
[3]    sata_nv
[4]    pata_amd
[5]    pata_amd
[6]    mptsas
[7]    aic94xx

[root@sas ~]# lsscsi
[1:0:0:0]    disk    ATA      ST380013AS       3.18  /dev/sdb
[4:0:0:0]    disk    ATA      ST380011A        8.01  /dev/sda
[5:0:1:0]    cd/dvd  HL-DT-ST DVD-ROM GDR8163B 0L23  /dev/scd0

[root@sas ~]# sg_sat_identify --packet /dev/scd0 -vv
open /dev/scd0 with flags=0x802
    ATA pass through (16) cdb: 85 08 0e 00 00 00 01 00 00 00 00 00 00 00 a1 00
ATA pass through (16): transport error: Host_status=0x05 [DID_ABORT]
Driver_status=0x00 [DRIVER_OK, SUGGEST_OK]
ATA pass through (16) failed

[root@sas ~]# sg_sat_identify --packet --len=12 /dev/scd0 -vv
open /dev/scd0 with flags=0x802
    ATA pass through (12) cdb: a1 08 0e 00 01 00 00 00 00 a1 00 00
ATA pass through:  Fixed format, current;  Sense key: Illegal Request
 Additional sense: Invalid command operation code



The above were attempts to send IDENTIFY PACKET DEVICE
to the PATAPI cd/dvd drive via the ATA PASS THROUGH
(16 and 12) commands respectively. The first one caught
my attention. Why did it fail with a DID_ABORT?

Whatever the reason both responses are wrong. The second
one is wrong because
  - the cd/dvd drive does support that opcode (the error
    should be either not ready or incompatible format), or
  - it didn't do the ATA PASS THROUGH (12) properly

>> The only clash between MMC and SATL SCSI opcodes is
>> with opcode 0xA1: BLANK in MMC and ATA PASS THROUGH (12)
> 
> Ok, so the answer is, yes there is a clash, and thus this change will
> remove the ability for working-today setups to use BLANK.
> 
> In order to avoid breaking working setups, a method must be found which
> tells the SATL to not filter out the ATA passthru commands.

Or, as a temporary solution, if the device is ATAPI
carrying a SCSI command set with pdt=5 then:
  1) opcode 0xa1 goes straight through (i.e. BLANK)
  2) opcode 0x85 works as defined by sat-r09.pdf
     (implements the ATA PASS THROUGH (16) SCSI command)

>> This is all about being able to send ATA commands to
>> ATAPI devices that are valid for PACKET devices, examples:
>>     IDENTIFY PACKET DEVICE
>>     SET FEATURES
>>     IDENTIFY DEVICE (should abort command + set signature)
>>     DEVICE RESET
>> and I assume there are others.
> 
> I am quite aware of the purpose of ATA passthru :)

... and I do comparative analysis of SAT layers and
send bug reports.

Doug Gilbert

  reply	other threads:[~2006-10-21 21:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-20  5:09 [PATCH] libata: fix ATA passthrough handling for ATAPI devices Tejun Heo
2006-10-21 19:16 ` Jeff Garzik
2006-10-21 20:00   ` Douglas Gilbert
2006-10-21 20:13     ` Jeff Garzik
2006-10-21 21:18       ` Douglas Gilbert [this message]
2006-10-21 21:40         ` Jeff Garzik
2006-10-21 23:11           ` Douglas Gilbert
2006-10-23  2:55             ` Tejun Heo
2006-10-23 13:58               ` Douglas Gilbert
2006-11-01  2:03 ` Jeff Garzik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=453A8E96.9040702@torque.net \
    --to=dougg@torque.net \
    --cc=htejun@gmail.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-ide@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.