Alan Stern <[EMAIL PROTECTED]> wrote:
> On Sat, 21 May 2005, Joerg Schilling wrote:
>
> > In this case, it is obviously a non-compliance of the USB SCSI
> > implementation.
> > Libscg asks the SCSI driver for the maximum DMA size. If the driver returns
> > a value that is bigger than the maximum suppoted value, users of libscg
> > will
> > fail.
>
> > libscg uses the official interface of the Linux kernel to query the maximum
> > DMA size. If the kernel returns an unsuitable value, it is not a problem
> > caused by cdrecord.
>
> J�rg, you just don't understand.
Are you sure that it's not you who didn't understand?
> The kernel will return to libscg the maximum DMA size the _kernel_ can
> handle. It doesn't return the maximum DMA size the _device_ can handle.
> Indeed, the kernel has no way to know what that size is, especially when
> the device is broken as these two are.
The interface I use has been defined by Douglas Gilbert and he did tell me
that the number it retuns is related to the specific device. I never did
like this interface and I did even make better proposals to no avail.
I would say that we now have to live with this interface.
What cdrecord does, is to ask the kernel to allow for more DMA.
The kernel either returns an OK (if there are enough resources), or an error
code in case that the intended number was too big. If the driver knows for
any other reason to limit the number it needs to do. This has already
explicitly discussed for old ISA SCSI adaoptors that are limited to 32kB and
it is for the same reason true for USB in case USB has problems with more than
32k.
> Furthermore, there was nothing wrong with the DMA size. The device is
> obviously able to handle large DMA transfers when executing a READ(10) or
> WRITE(10) command. The problem occurred during a READ BUFFER command, and
> the problem was not a DMA overflow/underflow. The problem was that the
> device violated the USB transport protocol.
OK, so if really there are other USB devices (or ATA<->USB bridges) that
support more than 32k, then the problem is indeed not related to the kernel
and only the hang up problem later on could be fixed.
> To put it another way, yes, this is non-compliance of the USB SCSI
> implementation. But it is non-compliance of the _device's_
> implementation. You seem to have difficulty accepting this fact.
I don't have difficulties to accept facts....
The problem is that as long as it is hard to get complete enough error
information, I need to take any possible problem into account.
J�rg
--
EMail:[EMAIL PROTECTED] (home) J�rg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id344&op=click
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users
