Date: Tue, 13 Apr 1999 18:54:04 -0700 (PDT) From: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) To: ken@plutotech.com Cc: scsi@FreeBSD.ORG Subject: Re: timed out while idle? Message-ID: <199904140154.SAA53879@silvia.hip.berkeley.edu> In-Reply-To: <199904140122.TAA06901@panzer.plutotech.com> (ken@plutotech.com) References: <199904140122.TAA06901@panzer.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* From: "Kenneth D. Merry" <ken@plutotech.com>
* 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.
* 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....
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").
* That'll be more helpful. At least you'll be able to (hopefully) see exactly
* which line caused the panic.
Ok.
Satoshi
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?199904140154.SAA53879>