From owner-freebsd-scsi Mon Nov 27 06:41:07 1995 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA03794 for freebsd-scsi-outgoing; Mon, 27 Nov 1995 06:41:07 -0800 Received: from hda.com (hda.com [199.232.40.182]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA03785 for ; Mon, 27 Nov 1995 06:41:01 -0800 Received: (from dufault@localhost) by hda.com (8.6.11/8.6.9) id JAA04871; Mon, 27 Nov 1995 09:35:05 -0500 From: Peter Dufault Message-Id: <199511271435.JAA04871@hda.com> Subject: Re: kern/820: scsi tape problems To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 27 Nov 1995 09:35:04 -0500 (EST) Cc: mark@linus.demon.co.uk, julian@ref.tfs.com, freebsd-scsi@freebsd.org In-Reply-To: <199511270904.KAA05088@uriah.heep.sax.de> from "J Wunsch" at Nov 27, 95 10:04:44 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1619 Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk > > This allowed to me to successfully read the tape (yes, my tape drive > > really did take >100s to read that block!). > > Peter? Do you remember our discussion about SCSI adaptor timeouts? > > We should bring this up again in freebsd-scsi. I could bury out the > old mails. Host adapter timeouts or transaction timeouts? I have mail on transaction timeouts and on my "TODO someday soon" list, and I don't think it applies in this case - we talked about both retrying "forever" for a "device is in the process of becoming ready" error and to delay a bit (where "a bit" gets longer between each retry) instead of doing an immediate retry - I don't think we talked about something that takes an unexpectedly long amount of time (100s for a read of a tape block) and that we (think we) can't abort. This case was a transaction that timed out, and then we tried to abort it (I'm not sure what the 1542 firmware does when you tell it to abort a transaction - I don't know if it does a BUS DEVICE RESET or what, and I don't have a 1542 manual) and we apparently then decided our host adapter was dead when it couldn't abort that transaction in four seconds. So there are two problems here, one general and one 1542 specific: 1. It would be nice to be able to tune the timeouts on a device by device basis for when you have a device with an unusually long timeout; 2. That "abort transaction" / "host adapter is hosed" branch needs some fixing. -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267