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. 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. 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. 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. This isn't the fault of cdrecord, it isn't the fault of the kernel, and it isn't the fault of the CD-RW drive. It is the fault of the USB interface chip attached to the drive. Alan Stern ------------------------------------------------------- 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_id=7412&alloc_id=16344&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
