From: Mathieu Fluhr <mfluhr@nero.com>
To: Phillip Susi <psusi@cfl.rr.com>
Cc: jgarzik@pobox.com, linux-ide@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: READ SCSI cmd seems to fail on SATA optical devices...
Date: Mon, 13 Nov 2006 19:56:00 +0100 [thread overview]
Message-ID: <1163444160.27291.2.camel@de-c-l-110.nero-de.internal> (raw)
In-Reply-To: <4558BE57.4020700@cfl.rr.com>
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 ;)
>
> > The burn process works like a charm, no problems at all. But it seems
> > that there are some slight problems with the READ scsi cmd:
> > Inside our software, we have a verification routine that will make a
> > sector-by-sector verification to check that everything that has been
> > written is OK.
> >
> > The problem is that, on SATA devices controlled by libata, on some big
> > files (like for example a 600 MB file) the READ command seems to fail
> > and outputs garbage (not 1 or 2 bytes diff, but the whole buffer).
> > -> This problem does not come out everytime, and each time on
> > different sectors.
> >
>
> I'm not sure what you mean by "on some big files" as the sg interface
> has no notion of files; you're just reading the disk sector by sector,
> as you said earlier. Also by fail do you mean that the request returns
> an error status? If so then the read buffer will not be valid.
I said 'some big files', as the problem is not reproducable everytime.
It occurs most of the time with large files.
The request does not return an error code (no sense key I mean), and it
is working as if everything would have work fine.
>
>
next prev parent reply other threads:[~2006-11-13 18:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-13 16:19 Mathieu Fluhr
2006-11-13 18:49 ` Phillip Susi
2006-11-13 18:56 ` Mathieu Fluhr [this message]
2006-11-13 19:32 ` Arjan van de Ven
2006-11-14 15:45 ` Mathieu Fluhr
2006-11-14 17:24 ` Tejun Heo
2006-11-15 15:19 ` Mathieu Fluhr
2006-11-15 16:04 ` Tejun Heo
2006-11-15 16:17 ` Phillip Susi
2006-11-15 16:20 ` Arjan van de Ven
2006-11-15 16:28 ` Alan
2006-11-14 2:02 ` Tejun Heo
2006-11-14 10:08 ` Mathieu Fluhr
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=1163444160.27291.2.camel@de-c-l-110.nero-de.internal \
--to=mfluhr@nero.com \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=psusi@cfl.rr.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®