Re: ch timeouts

["Matthew Jacob" <lydianconcepts%gmail.com@localhost>]

Let's see if I got this right- you uncovered the problem of
"overlapped commands attempted" because the original command timed
out?

IMO, such as it is, a timeout is the host's problem. Therefore, the ch
driver, if it sees a command time out, has to assume that state on the
changer has been lost- the changer may or may not still be working on
the command. A stateful device like a tape drive or a changer probably
should follow the sequence of ABORT TASK -> TARGET RESET after a
command timeout.

On Mon, Feb 4, 2008 at 2:45 PM, John Nemeth <jnemeth%victoria.tc.ca@localhost> 
wrote:
>     The media changer timeout is too short when removing media from a
> data transfer element, as the operation may require an implicit tape
> rewind.  I plan on fixing this by bumping the timeout to 10 minutes for
> this operation.
>
>     However, this uncovered a second problem for me.  Although my
> changer will usually correctly abort the command when it is retryed
> with an "Overlapped Commands Attempted" error, it has a nasty tendency
> to lockup, requiring a power cycle.  I'm pondering if I should create a
> quirk for my changer to not retry commands or if people have other
> suggestions on how to handle it?
>