Date: Thu, 15 Aug 1996 23:34:03 +0200 (MET DST) From: J Wunsch <j@uriah.heep.sax.de> To: freebsd-scsi@freebsd.org Cc: count@key.hole.fi Subject: Re: Pioneer CD changer problem Message-ID: <199608152134.XAA02748@uriah.heep.sax.de> In-Reply-To: <199608152112.OAA23181@freefall.freebsd.org> from "Justin T. Gibbs" at "Aug 15, 96 02:12:33 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
As Justin T. Gibbs wrote: > > The current way of timeout > >handling sucks rocks, all timeouts are wild guesses, and there's no > >way to centrally maintain them. Each and every call to > >scsi_scsi_cmd() specifies its own idea of what timeout might be > >appropriate. > > Do you have any ideas on handling this better? Alas not. Otherwise, i would certainly have started a discussion about this here. > Has anyone researched if > there is any kind of status information we can retrieve so we can > dynamically adjust timeout length? I think we first need a bomb-proof way to recover from bus device resets and bus resets. (Right now, i think they almost always end up in a catastrophic breakdown of the affected bus.) Then, the adapter drivers could try to reset the device or bus after a timeout, and could notify the caller of the timeout. The type driver might decide to bump its own idea of a useful timeout, or decide to warn the user of the particular slow device. sysctl might be a good way to adjust some `base timeout' values. Just tossing ideas around... -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608152134.XAA02748>