On Thu, 5 Feb 2004, Andy Polyakov wrote:
> > usb-storage: Command READ DISC INFORMATION (10 bytes)
> > usb-storage: 51 00 00 00 00 00 00 00 24 00 00 00
> > usb-storage: Bulk command S 0x43425355 T 0xac Trg 0 LUN 0 L 36 F 128 CL 12
> > usb-storage: Bulk command transfer result=0
> > usb-storage: usb_stor_transfer_partial(): xfer 36 bytes
> > usb-storage: usb_stor_bulk_msg() returned 0 xferred 34/36
> ^^^^^ This appears
> to be the firmware deficiency. Unit promised 36 bytes, while only 34 were
> available for transfer...
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.
So the command was completed successfully. But the sg driver, seeing
that the status information was present, mistakenly concluded that there
must have been _some_ error -- otherwise why retrieve the status? You can
see this in the log produced by cdrecord-ProDVD:
> cdrecord-ProDVD: Input/output error. read disk info: scsi sendcmd: no error
> CDB: 51 00 00 00 00 00 00 00 24 00
> status: 0x2 (CHECK CONDITION)
> Sense Bytes: 70 00 00 00 00 00 00 0A 00 00 00 00 00 00 00 00
> Sense Key: 0x0 No Additional Sense, Segment 0
> Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0
I believe the CHECK CONDITION status here comes from the sg driver, which
includes these lines in sg_new_read():
if (hp->masked_status || hp->host_status || hp->driver_status)
hp->info |= SG_INFO_CHECK;
hp->driver_status was set because the usb-storage driver did transfer the
sense data. I don't know if cdrecord-ProDVD uses the info field instead
of checking masked_status. If it does, that would explain part of the
problem.
> > usb-storage: -- unexpectedly short transfer
>
> It does make a number of exceptions prior this for a number of commands,
> most notably REQUEST_SENSE, INQUIRY, MODE_SENSE... Well, I'm not really
> in position to judge, but if exception list is really necessary, then
> consider adding not only READ DISC INFORMATION(0x51), which causes this
> particular trouble, but also GET PERFORMANCE(ACh), READ FORMAT
> CAPACITIES(23h), READ TOC(43h), READ DVD STRUCTURE(ADh) ... Actually
> it appears that it would be easier to compose the non-exception list...
The only problems were with READ DVD STRUCTURE (0xad) which the device
didn't understand (invalid field in CDB), and MODE SELECT(10) (invalid
field in parameter list). I don't know what was wrong about the READ DVD
STRUCTURE command, but in any case neither of these seems to have been a
show-stopper.
> > Andy Polyakov wrote:
> >
> > Version with dinfo[32]
> > ==============
> > [EMAIL PROTECTED] dvd+rw-tools-5.16.4.8.5]$ ./test2 /dev/scd0
> > 00 22 00 01 01 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 23 05 40
> > 00 00 00 00 00 00 00 00
> > ==============
> And this one uses READ DISK INFORMATION with length parameter used by
> growisofs.
>
> > What does *this* mean?
>
> This means that there is no further need for me to assure that growisofs
> works not because it ignores errors [as Joerg implies], but because it
> does things differently.
>
> To wrap up. My initial assumption that it was hardly a firmware
> deficiency was wrong. It is a firmware bug: unit apparently sends less
> information than promised (the second number in above printout should be
> 0x20(*) and 0x20 is the number which I observed uncounted number of
> times in different units). Could Linux USB implementation have managed
> it with more grace? I'm not really in position to judge, but maybe.
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.
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.
Alan Stern
-------------------------------------------------------
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
