lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [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

View attachment "patch" of type "text/plain" (829 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ