[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4559FBCF.9050203@gmail.com>
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
View attachment "patch" of type "text/plain" (829 bytes)
Powered by blists - more mailing lists