Date: Mon, 28 Sep 1998 10:46:13 -0600 (MDT) From: "Justin T. Gibbs" <gibbs@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 Message-ID: <199809281646.KAA15183@narnia.plutotech.com> In-Reply-To: <xzphfxs767m.fsf@bergelmir.ifi.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <xzphfxs767m.fsf@bergelmir.ifi.uio.no> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809281646.KAA15183>