From: Jens Axboe <jens.axboe@oracle.com>
To: Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de>
Cc: arjan@infradead.org, schilling@fokus.fraunhofer.de,
linux-kernel@vger.kernel.org
Subject: Re: SCSI over USB showstopper bug?
Date: Wed, 1 Nov 2006 16:31:28 +0100 [thread overview]
Message-ID: <20061101153128.GM13555@kernel.dk> (raw)
In-Reply-To: <4547e164.k3W0GpiCAd3p3Tkh%Joerg.Schilling@fokus.fraunhofer.de>
On Wed, Nov 01 2006, Joerg Schilling wrote:
> Arjan van de Ven <arjan@infradead.org> wrote:
>
> > On Tue, 2006-10-31 at 23:08 +0100, Joerg Schilling wrote:
> > > Hi,
> > >
> > > it looks as if SG_GET_RESERVED_SIZE & SG_SET_RESERVED_SIZE
> > > are not in interaction with the underlying SCSI transport.
> > >
> > > Programs like readcd and cdda2wav that try to get very large SCSI
> > > transfer buffers get a confirmation for nearly any SCSI transfer size
> > > but later when readcd/cdda2wav try to transfer data with an
> > > actual SCSI command, they fail with ENOMEM.
> > >
> > > Correct fix: let sg.c make a callback to the underlying SCSI transport
> > > and let it get a confirmation tfor the buffer size.
> > >
> > > Quick and dirty fix: reduce the maximum allowed DMA size to the smallest
> > > max DMA size of all SCSI transports.
> >
> > real good fix:
> >
> > use SG_IO on the device directly that checks this already
>
> From looking into the source, this claim seems to be wrong.
The block layer SG_IO entry point does what Arjan describes - it checks
the queue settings, which must match the hardware limits. It needs to,
since it won't accept a command larger than what the path to that device
will allow in one go. The SCSI sg variant may be more restricted, since
it should handle partial completions of such commands.
--
Jens Axboe
next prev parent reply other threads:[~2006-11-01 15:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-31 22:08 SCSI over USB showstopper bug? Joerg Schilling
2006-10-31 22:18 ` Arjan van de Ven
2006-10-31 23:51 ` Joerg Schilling
2006-11-01 15:31 ` Jens Axboe [this message]
2006-11-01 18:25 ` Joerg Schilling
2006-11-01 18:31 ` Jens Axboe
2006-11-06 16:00 ` Joerg Schilling
2006-11-06 16:07 ` Jens Axboe
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=20061101153128.GM13555@kernel.dk \
--to=jens.axboe@oracle.com \
--cc=Joerg.Schilling@fokus.fraunhofer.de \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=schilling@fokus.fraunhofer.de \
/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