Messages in this thread |  | | | Date | Wed, 1 Nov 2006 19:31:32 +0100 | | From | Jens Axboe <> | | Subject | Re: SCSI over USB showstopper bug? |
| |
On Wed, Nov 01 2006, Joerg Schilling wrote: > Jens Axboe <jens.axboe@oracle.com> wrote: > > > > > > 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. > > Then someone should change the source to match this statements. > > From a report I have from the k3b Author, readcd and cdda2wav only work > if you add a "ts=128k" option.
Then please file (or have him/her file) a proper bug report. It may be a usb specific bug, or it may just be something else.
-- Jens Axboe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |