>From [EMAIL PROTECTED] Thu Feb 5 23:05:03 2004
>The drive was asked for 36 bytes and only returned 34. So far as the
>low-level USB and SCSI transfer goes, that's legal -- the device is only
>obligated to transfer as much data as it has available.
>> > usb-storage: Bulk data transfer result 0x1
>> > usb-storage: Attempting to get CSW...
>> > usb-storage: clearing endpoint halt for pipe 0xc0008280
>> > usb-storage: usb_stor_clear_halt: result=0
>> > usb-storage: Attempting to get CSW (2nd try)...
>> > usb-storage: Bulk status result = 0
>> > usb-storage: Bulk status Sig 0x53425355 T 0xac R 2 Stat 0x0
>> ^^^ "Command
>> Passed (good status)," right?
>Yes. A shorter-than-expected reply is not an error or a failure.
>What then happened was that usb-storage, seeing the short transfer, asked
>the drive for its status (REQUEST SENSE) and the drive returned no errors.
And there exactly is the bug (which is most likely in usb-storage but
definitely in the Linux kernel:
In case of _only_ a DMA size error, a request sense must not be
issued by the driver.
If you are the maintainer of this piece of software, please fix this.
>There's nothing wrong with the USB implementation. The scsi-generic
>implementation may be questionable, since it returns a CHECK CONDITION
>indicator that did not actually come from the device. But the correct
>information is available in the masked_status and driver_status fields;
>it's only necessary to use them.
This id definitely wrong: It is wrong to issue a REQEST SENSE when there
was a DMA underrun.
>If cdrecord-ProDVD is changed to recognize that info = SG_INFO_CHECK does
>not indicate an error when masked_status = 0, and if it can cope with 34
>bytes of data for READ DISC INFORMATION when the device says there should
>be 36, things ought to work. It would be interesting to see the output
>from dinfo with [32+2]; if the last byte is 0 then there are no OPC
>entries and the missing two bytes shouldn't matter.
libscg cannot be changed or otherwise it will stop working at all.
This problem _needs_ to be fixed in the Linux kernel, and it should be done
as fast as possible.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni) If you don't have iso-8859-1
[EMAIL PROTECTED] (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
