On Fri, 20 May 2005, Garnet Ulrich wrote: > Just a quick update. Given that the problem occurs with transfers > greater than 32768, I tried using cdrecord with the -ts=32768 parameter > to limit the largest transfer to one that wouldn't choke my LG > GSA-5120D. cdrecord 2.01 seems to be working OK this way. I blanked a > cd-rw and wrote an iso back to it successfully.
Great! Looks like you've solved your problem. This will probably work with Hin-Tak's drive too. > I wonder if some kind > of special "driver" could be written to recognize this drive at > connection time and report back to applications (cdrecord or even kernel > dvd-ram code) that the largest supported transfer is only 32768? I > don't know who all the players are that would make this happen > (kernel/scsi/usb/usb-storage/distromakers) or if it is bad idea. It's a bad idea. I'm sure the drive supports larger transfers than 32 KB. Only the READ BUFFER command fails (well, maybe WRITE BUFFER would fail too). But regular reads and writes are almost certainly okay. Furthermore we don't want to have a special driver just to accomodate a quirk present in only a handful of individual drives. Can you imagine if every misbehaving device had to have its own driver?! Lastly, the kernel doesn't report back to applications what the largest supported transfer length is. In fact, the kernel doesn't know. Applications have to get that information from the drive itself. > I am > just concerned that I have now seemingly addressed this issue for > cdrecord but that I may run up against similar problems with other > software. For example, should I be worried that the kernel support for > using dvd-ram in this drive may also try a >32768 transfer and I won't > have a handy dandy -ts option to fix it? It wasn't the kernel that tried to do the > 32768-byte transfer, it was cdrecord. In general the kernel tries to stay out of the way and let programs like cdrecord do what they want. It's up to the program to make sure it does the right thing. 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
