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. 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. 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?
Alan, I am a much happier user right now. Thank you for all your help thus far. If you would like me to run any more tests that would be useful to anyone, I'm very willing to do what I can. garnet On Fri, 2005-05-20 at 14:48 -0400, Alan Stern wrote: > On Tue, 10 May 2005, Joerg Schilling wrote: > > > Any SCSI transport error code that will be mapped to SCG_FATAL in > > scsi-linux-sg.c would be OK - or of course a new error code in case you > > grant me > > that this error code will not change within the next years. > > > > Of course, if you introduce new error codes, you need to inform me to allow > > me > > to extend the adaption layer between Linux and libscg to be correct. > > The errors will be indicated by host_status = DID_ABORT or DID_ERROR. > These are not new codes; they've been in use for years. DID_ABORT will > occur when the command times out and the kernel's SCSI midlayer aborts it. > DID_ERROR will occur when there is a low-level USB transport error. > Right now scsi-linux-sg.c:scg_send() doesn't appear to test for either > code explicitly; it probably should. > > Up to now the Linux sg driver hasn't returned either of these codes > correctly. When either sort of error occurs, the error handler > automatically attempts to recover. The status code sent back to your > program has been the result from the error recovery, not the result of the > original command. I'm working with the SCSI developers now to fix this. > > Are there any types of error for which it would be appropriate for the > SCSI error handler to automatically retry the command (for instance, if > there wasn't enough free space in the host adapter driver's queue), or > would you prefer to see every sort of error returned immediately to the > program? > > > Well, I hope I don't tell you a secret when I direct you to > > ftp://ftp.berlios.de/pub/cdrecord/alpha/ > > I downloaded the current source, but I can't find any spot where the > program issues READ BUFFER commands. Can you tell me where to look? Or > should I have downloaded the ProDVD source instead? > > > If yes (which means you do not need to power cycle the drive in order to > > make > > it woke again), the Linux USB drivers seem to have the possibility to > > recover from the problem. > > Yes. There's a patch awaiting approval which should take care of this. > It causes the usb-storage driver to do a USB port reset whenever an error > occurs, rather than a mass-storage class-specific reset (which is less > powerful) -- it's like doing a bus reset instead of a device reset. In > fact it's almost the equivalent of unplugging the USB cable and plugging > it back in. Many devices respond to this sort of reset better than they > do to the other one, and this is the kind of reset Windows does when it > encounters a USB error. > > > Recent tests by Garnet Ulrich have shown that his CD/DVD device fails > whenever a READ BUFFER command requests a transfer longer than 32768 > bytes. This clearly is not the result of a bug in the usb-storage driver > and it probably is not a problem with the drive either, since it reports a > total buffer capacity just under 2 MB. Most likely this comes from a bug > in the firmware of the USB interface chip attached to the drive. > > Alan Stern > -- garnet ulrich ccie #11928 ------------------------------------------------------- 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
