virtual drive errors

[Pavel Sukhoy]

On Thu, 08 Apr 2010 14:20:32 +0300, Andriy Gapon <avg at icyb.net.ua> wrote:
> on 08/04/2010 13:24 Markus Wild said the following:
>> Hello Andriy,
>> 
>>> Looking at cdcheckmedia and at the logged READ TOC (0x43) SCSI
>>> command errors (as reported by Markus) I see the following problem.
>>> Even if cdsize() call at the beginning of cdcheckmedia() succeeds, a
>>> subsequent failure of cdreadtoc() throws us to 'bailout' label which
>>> is past the code that sets d_mediasize.
>>>
>>> I think that the following patch should help with this situation (and
>>> possibly other cases with READ TOC problems):
>> 
>> This fix indeed fixes the problem (there are still all the failure logs
>> about the READ TOC/PMA/ATIP commands, but in the end, the mount
>> succeeds now, whereas before it failed), thanks a lot! Now, perhaps a
>> silly question: why would the READ TOC commands fail over the SCSI-USB
>> bridge to start with? I'm normally (if I'm not trying to use the
>> virtual USB cdrom) using ATAPI cdroms, and haven't seen any comparable
>> TOC problems with those...
> 
> I am slightly confused.
> Does the same happen wth physical SCSI-USB bridge?
> Or it happens only with virtual/emulated CD drive?

It seems only SCSI-USB drives fails. I tried to use external usb (ATAPI)
CD/DVD-Drive, and it works without mounting errors on 8.0- and 7.3-RELEASE
, I had read errors only with virtual USB drives.

kernel messages (maybe it helps) - mounting External drive:

kernel: umass4: <USB2.0 External Mass Storage Device, 
class 0/0, rev 2.00/1.58, addr 3> on usbus4
kernel: umass4:  8070i (ATAPI) over Bulk-Only; quirks = 0x0000            
                     
kernel: umass4:4:4:-1: Attached to scbus4

mounting Virtual drive:

kernel: umass3: <Intel(R) Multidevice, class 0/0, rev 
2.00/0.01, addr 2> on usbus4
kernel: umass3:  SCSI over Bulk-Only; quirks = 0x0000
umass3:3:3:-1: Attached to scbus3

> If the latter, then I'd guess that this is just how the emulator works.
> Thank you for testing!

-- 
With best regards,
Pavel Sukhoy.