adaptec 2940u/uw dump card state ends

Don Lewis truckman at FreeBSD.org
Fri Jan 23 18:15:48 PST 2004


On 23 Jan, Jesse Guardiani wrote:
> Don Lewis wrote:
> 
>> On 22 Jan, Jesse Guardiani wrote:
>>> Jesse Guardiani wrote:
> 
> [...]
> 
>>>> (ch0:ahc0:0:2:1): SCB 0xe - timed out
>> 
>> Just a guess ... maybe the changer mechanism requires a longer time than
>> what the driver thinks.  At the top of /usr/src/sys/cam/scsi/scsi_ch.c
>> there is the following:
>> 
>> /*
>>  * Timeout definitions for various changer related commands.  They may
>>  * be too short for some devices (especially the timeout for INITIALIZE
>>  * ELEMENT STATUS).
>>  */
>>           
>> static const u_int32_t  CH_TIMEOUT_MODE_SENSE                = 6000;
>> static const u_int32_t  CH_TIMEOUT_MOVE_MEDIUM               = 100000;
>> static const u_int32_t  CH_TIMEOUT_EXCHANGE_MEDIUM           = 100000;
>> static const u_int32_t  CH_TIMEOUT_POSITION_TO_ELEMENT       = 100000;
>> static const u_int32_t  CH_TIMEOUT_READ_ELEMENT_STATUS       = 10000;
>> static const u_int32_t  CH_TIMEOUT_SEND_VOLTAG               = 10000;
>> static const u_int32_t  CH_TIMEOUT_INITIALIZE_ELEMENT_STATUS = 500000;
>> 
>> I think these times are milliseconds.  The scsi command that you are
>> using may be using one of these timeouts: CH_TIMEOUT_MOVE_MEDIUM,
>> CH_TIMEOUT_EXCHANGE_MEDIUM, or CH_TIMEOUT_POSITION_TO_ELEMENT (I'm not
>> very familiar with changers).  These appear to be set to 100 seconds, so
>> if your changer takes longer than this, the driver will time out the
>> command before the changer indicates that it is finished.  Try bumping
>> these up and rebuild your kernel.  They should probably be tunable ...
> 
> Hmmm...
> 
> 
> The device works absolutely perfectly after that first timeout. Do you still
> think it's a timeout issue? Personally, I'm leaning toward it being a problem
> with termination because I _believe_ this autoloader is an 8 bit device.

My first guess would not be termination.  I would think that a
termination problem would muck up data transfers and would affect all
attempts to use the changer.

How long is the time from when you issue the changer command to when the
driver coughs up this error?  I'm not familiar with this drive/changer
combination, but the DDS changer that I use takes a lot longer to swap
tapes if the tape currently in the drive is wound all the way to the
end, because the drive first has to rewind it before it can unload the
tape.  Subsequent tape changes won't take as long if the tape currently
in the drive is still at the beginning ...

How is the changer connected to the 2940u/uw?  If you are using an eight
bit cable, you'll want to configure the 2940u/uw to terminate the upper
8 bits of the bus but not the lower 8.

> Unfortunately, I don't understand the problem, so I don't really know how to
> fix it. :( Maybe some googling will help.

Always worth a try ...


More information about the freebsd-scsi mailing list