From owner-freebsd-scsi@FreeBSD.ORG Fri Jan 23 18:15:48 2004 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0A2C16A4CE for ; Fri, 23 Jan 2004 18:15:48 -0800 (PST) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0943243D3F for ; Fri, 23 Jan 2004 18:15:42 -0800 (PST) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i0O2FY7E068846; Fri, 23 Jan 2004 18:15:39 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200401240215.i0O2FY7E068846@gw.catspoiler.org> Date: Fri, 23 Jan 2004 18:15:34 -0800 (PST) From: Don Lewis To: jesse@wingnet.net In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-scsi@FreeBSD.org Subject: Re: adaptec 2940u/uw dump card state ends X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2004 02:15:48 -0000 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 ...