From owner-freebsd-scsi Tue Apr 13 19:33:40 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 2340814BD2; Tue, 13 Apr 1999 19:33:37 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id UAA07250; Tue, 13 Apr 1999 20:31:18 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904140231.UAA07250@panzer.plutotech.com> Subject: Re: timed out while idle? In-Reply-To: <199904140154.SAA53879@silvia.hip.berkeley.edu> from Satoshi - Ports Wraith - Asami at "Apr 13, 1999 6:54: 4 pm" To: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) Date: Tue, 13 Apr 1999 20:31:18 -0600 (MDT) Cc: scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Satoshi - Ports Wraith - Asami wrote... > * From: "Kenneth D. Merry" > > * The reason the timeout is as high is it is now is because of some devices > * (zip drives?) that spin down their media and then spin back up when they > * get a command. > * > * It takes them a little bit to spin up, so that's why the timeout is as long > * as it is. > > I see. > > * As far as figuring out whether something came back between 15 and 60 > * seconds, probably the only way to do that would be to timestamp each CCB as > * it is sent down to the controller. It can be done, but is it really worth > * it? > > No, I was just curious if I can know if it's safe to shorten in on our > site. I guess I can just try and see. Yeah, I think you can safely do that. You may be able to get away with cranking it down to 10 seconds or so. > * If it is still responding. In most cases that I've seen a BDR will cause > * the drive to wake up and start functioning again. > > Sorry, I meant by analyzing the logs. I guess I don't know what > happened if I just see a "timed out while idle" followed by a > crash.... Right, it's hard to say how the rest of the system will respond. Sometimes, if it happens on your swap drive, you'll see something that goes like "swap_pager: indefinite wait buffer" or something like that. > Speaking of which (gosh, you should hate this), I have another > question. When CAM invalidates a pack, is there some way to get it > back short of rebooting? I tried "camcontrol rescan" which does seem > to find it (judging from "camcontrol devlist") but I still can't > access it ("device not configured"). There's no way to get it back without rebooting. Rescanning won't help you, since that finds devices that have appeared, changed or gone away. Your device hasn't done that, it has stopped responding. It's dead. If you think it should be done otherwise, talk to the author of the da(4) driver. :) (no, it's not me) Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message