From owner-freebsd-scsi Mon Sep 28 09:53:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA10686 for freebsd-scsi-outgoing; Mon, 28 Sep 1998 09:53:01 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA10676 for ; Mon, 28 Sep 1998 09:52:58 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id KAA15183; Mon, 28 Sep 1998 10:46:13 -0600 (MDT) Date: Mon, 28 Sep 1998 10:46:13 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199809281646.KAA15183@narnia.plutotech.com> To: dag-erli@ifi.uio.no (Dag-Erling C. Sm?rgrav ) cc: scsi@FreeBSD.ORG Subject: Re: mt fsf 1 times out Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-BETA (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > > The problem is that 'mt fsf 2' from the beginning of the tape (or 'mt > fsf 1' after 'mt rewind; mt fsf 1' to seek past /) takes more than an > hour, and I get a timeout after precisely one hour (give or take five > seconds). What I get is the usual "timed out while idle", followed by > a "Power on, reset, or bus device reset occurred", followed by the > tape rewinding (much faster than it can wind forward)... This seems > consistent with the code (saspace() in sys/cam/scsi/scsi_sa.c calls > scsi_space with a timeout of 60*60*1000 ms) I would suggest simply uping the timeout in the kernel and using mt normally. The timeout in general is a known problem. The plan is to run tape operations expected to take a while with no timeout, add support for the XPT_ABORT_CCB CAM function code, handle signals in the sa ioctl routine, and send an abort if the user ^C's mt. mt will also be modified to take an optional timeout (which would then be passed into the ioctl) so that scripts running without human supervision can handle error conditions. I do not know if I will be able to get all of the CAM hooks for this completed before 3.0R, but I will try. The ch driver would benefit from this interface too. > OBTW, I browsed through some of the CAM code while researching this > and I have to hand it to you guys, it's such *beautiful* code... :) Thanks! -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message