kern/103602: drive gets wedged on READ CD CAPACITY if no disc
is in
Scott Long
scottl at samsco.org
Tue Mar 13 21:45:43 UTC 2007
Scott Long wrote:
> Thomas Quinot wrote:
>> SCSI guys,
>>
>> kern/103602 is a long-standing issue with a Sony DVD drive that has a
>> strange behaviour (failing to attach and causing an interrupt storm).
>>
>> One aspect of this PR was that an ATAPI command timing out was not
>> correctly reported by the ATAPI/CAM SIM to the XPT layer. This has been
>> fixed in atapi-cam.c rev. 1.49.
>>
>> Now we have a second issue: if there is no disc in the drive, it
>> times out a READ CD CAPACITY (and any subsequent retry, even if a disc
>> is then inserted in the drive), instead of returning an appropriate
>> error (the expected behaviour would be a NOT READY sense key and a
>> MEDIUM NOT PRESENT ASC). A TEST UNIT READY command seems to behave
>> properly (reporting the appropriate error if no disc is present,
>> reporting no error and resetting the drive to a proper state if
>> one is).
>>
>> The timeout causes the unit to fail to attach at boot time if no disc is
>> present. How should we deal with this situation? One possible option is
>> to make sure that we first issue a TEST UNIT READY at attach time prior
>> to issuing READ CD CAPACITY, and not issue the second command if the TUR
>> returned a NOT READY status.
>>
>> The traces below show how the drive behaves in response to TEST UNIT
>> READY and READ CD CAPACITY in various cases. Complete boot messages are
>> available in the PR history.
>>
>> Thomas.
>>
>
> I'm confused. CAM actually sends a READ_CAPACITY command to the drive,
> not a READ_CD_CAPACITY command. Are you saying that issuing both a
> READ_CAPACITY and a READ_CD_CAPACITY to an empty Sony drive results in
> the same bad behavior?
>
> Re-arranging the probe process to issue a TUR first is tricky. I'd
> rather not do it if possible.
>
Actually, I take that back, adding a TUR phase isn't as hard as I
thought. I'd like to know if doing a READ_CD_CAPACITY makes a
difference, though.
Scott
More information about the freebsd-scsi
mailing list