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
next prev parent 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.