I already posted this in another thread but for anyone in the future that has this problem, I have (I think) found a solution to this problem for cdrecord 2.01 with the LG GSA-5120D and (other similar era LG external drives I suspect). Use the parameter -ts=32768 with cdrecord 2.01. This limits the scsi transfers to 32768 bytes as I understand it and my experiments with plscsi showed that this drive did not like the READ_BUFFER command with transfers >32768 bytes.
Example: cdrecord -v -dev=0,0,0 -ts=32768 -speed=4 -blank=all <- blanks a 4x cd-rw cdrecord -v -dev=0,0,0 -ts=32768 -speed=4 file.iso <- writes the iso to the cd-rw Note that k3b can be taught to use -ts=32768 in its configuration with the user parameters tab. It looks like I can also use the /etc/cdrecord.conf to set this but haven't tried yet. Thank you very very much to Alan Stern for his help in figuring this out. I will report back if anything else is still not working while using this drive. garnet On Fri, 2005-05-20 at 14:49 -0400, Alan Stern wrote: > Hin-Tak, I want to refer you to this thread which started with > > http://marc.theaimsgroup.com/?l=linux-usb-users&m=111633747808908&w=2 > > This looks like exactly the same sort of problem that you had, although > with a different kind of drive. > > > On Fri, 20 May 2005, Garnet Ulrich wrote: > > > Alan, some more fun with plscsi. Here is some output. Seems any > > READ_BUFFER with length > 0x8000 is bad with this drive (except for > > coincidentally the 0xfbfe and maybe other values I haven't stumbled > > upon) you chose (randomly?) earlier. > > > > When I try > 0x8000, plscsi hangs and usb is reset etc.. I power cycle > > the drive to reset for the next test. Also of note is that I was able > > to burn a ~260M ISO to a DVD using growisofs and it seemed to be OK. > > Burnt at a steady ~2x and didn't spew any scsi errors. > > > > I'm learning a lot and I may be getting somewhere. Thank you. Anything > > else you can suggest I mess with (especially if it helps anyone else)? > > All that springs to mind at the moment is to try some more tests to see if > 0x8000 really is the boundary. My guess is that this represents the point > at which some bug in the USB interface firmware shows up, not a problem > with the drive itself. > > At some point maybe I'll be able to find the location in cdrecord where it > decides the transfer length to use with the READ BUFFER commands. > Reducing it to 32768 ought to be enough to get your device working. > > 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
