linux-kernel - Re: READ SCSI cmd seems to fail on SATA optical devices...

lists.openwall.net		lists / announce john-users owl-users popa3d-users / xvendor oss-security / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4
Open Source and information security mailing list archives

Looking for a web hosting provider? Try DreamHost (enter the promo code WAIVE to waive the $49.95 setup fee)

[<prev] [next>] [<thread-prev] [thread-next>] [month] [year] [list]

Date:	Wed, 15 Nov 2006 02:24:31 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Mathieu Fluhr <mfluhr@...o.com>
CC:	Arjan van de Ven <arjan@...radead.org>,
	Phillip Susi <psusi@....rr.com>, jgarzik@...ox.com,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: READ SCSI cmd seems to fail on SATA optical devices...

Mathieu Fluhr wrote:
> On Mon, 2006-11-13 at 20:32 +0100, Arjan van de Ven wrote:
>> On Mon, 2006-11-13 at 19:56 +0100, Mathieu Fluhr wrote:
>>> On Mon, 2006-11-13 at 13:49 -0500, Phillip Susi wrote:
>>>> Mathieu Fluhr wrote:
>>>>> Hello,
>>>>>
>>>>> I recently tried to burn some datas on CDs and DVD using a SATA burner
>>>>> and the latest 2.6.18.2 kernel... using NeroLINUX. (It is controlling
>>>>> the device by sending SCSI commands over the 'sg' driver)
>>>>>
>>>> Please note that the sg interface is depreciated.  It is now recommended 
>>>> that you send the CCBs directly to the normal device, i.e. /dev/hdc.
>>> Of course for native IDE devices, we are using the /dev/hdXX device, but
>>> for SATA devices controlled by the libata, this is not possible ;)
>> for those there is /dev/scd0 etc...
>> (usually nicely symlinked to /dev/cdrom)
> 
> Hummm as we are _writing_ to devices, I think that using /dev/sgXX with
> SG_IO is better no?

The recommended way is using SG_IO to /dev/srX (or /dev/scdX).

> ... and the problem is not in accessing the device itself (this is
> working like a charm) but understanding why a SCSI READ(10) cmd
> sometimes fails as a ATA-padded READ(10) cmd - as discribed in the Annex
> A of the MMC-5 spec - ALWAYS works.
> -> I would suspect somehow a synchronisation problem somehow in the
> translation of SCSI to ATA command...

Can you try the attached patch and see if anything changes?

-- 
tejun

diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index 2dc3264..fa82151 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -286,6 +286,7 @@ static int sg_io(struct file *file, requ
 	 * fill in request structure
 	 */
 	rq->cmd_len = hdr->cmd_len;
+	memset(rq->cmd, 0, BLK_MAX_CDB);
 	memcpy(rq->cmd, cmd, hdr->cmd_len);
 	if (sizeof(rq->cmd) != hdr->cmd_len)
 		memset(rq->cmd + hdr->cmd_len, 0, sizeof(rq->cmd) - hdr->cmd_len);
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index d2c02df..080c2ed 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -410,6 +410,7 @@ int scsi_execute_async(struct scsi_devic
 		goto free_req;
 
 	req->cmd_len = cmd_len;
+	memset(req->cmd, 0, BLK_MAX_CDB);
 	memcpy(req->cmd, cmd, req->cmd_len);
 	req->sense = sioc->sense;
 	req->sense_len = 0;