Date: Tue, 13 Apr 1999 20:31:18 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) Cc: scsi@FreeBSD.ORG Subject: Re: timed out while idle? Message-ID: <199904140231.UAA07250@panzer.plutotech.com> In-Reply-To: <199904140154.SAA53879@silvia.hip.berkeley.edu> from Satoshi - Ports Wraith - Asami at "Apr 13, 1999 6:54: 4 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Satoshi - Ports Wraith - Asami wrote...
> * 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.
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904140231.UAA07250>