Hello, Daniel.
Daniel Beichl wrote:
>> Okay, I've been thinking about it for some time. I think I know what's
>> going on now. Those authentication related commands are issued by
>> invoking ioctls on the device node. The cdrom driver receives the
>> ioctls and issues respective SCSI commands for it. All those DVD auth
>> commands either transfer or receive data from the device and thus
>> specifies certain data direction when they're issued. libata selects
>> command protocol accordingly.
>>
>> It's all good and dandy till now but the problem is that those commands
>> can be issued with data length of zero! This is allowed by the SCSI MMC
>> standard and used to probe whether the command succeeds or not before
>> taking further actions. When this happens, libata chooses command
>> protocol according to the data direction, but has to feed 0-length data
>> to the DMA engine. It seems sata_sil dma engine barfs if that happens.
>> Can you please add the following code snippet at the head of
>> atapi_xlat()?
>>
>> if (!nodata && !qc->nbytes) {
>> printk("XXX forcing PIO for 0 length data cdb %02x\n",
>> scmd->cmnd[0]);
>> dump_stack();
>> using_pio = 1;
>> }
>>
>> Also, do you mind cc'ing [EMAIL PROTECTED]
>>
>>
> Hi Tejun,
>
>
> i inserted the code snippet you mentioned to atapi_xlat() in libata-scsi.c
> and the dvd authentication succeeds.
>
> Please see the attached dmesg file for the generated stack dumps.
Good to know it works. :-)
> The question is whether this is the right place to fix it, as this seems
> to limit all
> drivers to pio if a zero data length command is transferred.
> It would make more sense to me if the individual driver decides this by
> performing a similar check in the check_atapi_dma function implemented
> by the
> individual driver. I did this for the sata_sil driver in the attached
> patch.
The thing is that those commands don't transfer any data at all, so it
doesn't really matter whether the data phase is specified as DMA or PIO.
ATA_PROT_ATAPI degenerates into ATA_PROT_ATAPI_NODATA if there is no
data to transfer (in ATA spec they share the same protocol state machine
and the data request status bit dictates what actually happens).
I think this actually should be fixed in the cdrom driver. It shouldn't
issue data command with 0 data length with data protocol. Can you test
whether the attached patch works? Also, it seems we'll need to add a
WARN_ON() in sr such that bugs like this can be caught more easily.
Thanks.
--
tejun
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index b36f44d..5a5639d 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -1533,7 +1533,10 @@ void init_cdrom_command(struct packet_co
memset(buf, 0, len);
cgc->buffer = (char *) buf;
cgc->buflen = len;
- cgc->data_direction = type;
+ if (len)
+ cgc->data_direction = type;
+ else
+ cgc->data_direction = CGC_DATA_NONE;
cgc->timeout = CDROM_DEF_TIMEOUT;
}
