Date: Mon, 18 Oct 1999 19:14:09 +0200 (CEST) From: Søren Schmidt <sos@tuden.freebsd.dk> To: mjacob@feral.com Cc: gallatin@cs.duke.edu (Andrew Gallatin), sos@freebsd.org, alpha@freebsd.org Subject: Re: workaround for ata driver woes on alpha Message-ID: <199910181714.TAA00441@tuden.freebsd.dk> In-Reply-To: <Pine.BSF.4.05.9910180702290.14549-100000@semuta.feral.com> from Matthew Jacob at "Oct 18, 1999 07:26:35 am"
next in thread | previous in thread | raw e-mail | index | archive | help
It seems Matthew Jacob wrote: > No, lengthening the timeout, while possibly correct for trying to achieve > the same length of timeout on alpha as in i386, will *never* solve window > problems- it just makes them more infrequent which is, in fact, far more > dangerous to an OS than the outright panic (why? Think about it- if you > make a problem just *rare* instead of really going away, you curse the > platform it occurs on with an aura of unreliabilty so that people are just > too uneasy to depend on it...)..... Well, the problem is that I didn't use hz to get the right timeout (there the patch is correct) I missed that one sorry. There could be a window problem, but it is highly unlikely that an ATA disk is going to respond with an interrupt after the timeout happend, but its not impossible. > I would recommend hanging requests off the softc in a list (if it's more > than one per ata instance) or just as a pointer *which gets nulled if > untimeout is called* so that splbio protection can offer mutex exclusion > on the callout vs. the IDE interrupt thread looking through the currently > active list. If ad_interrupt runs and calls untimeout on an already > active callout it will make the callout thread not find anything to > whine about (but only if the callout thread knows where to looK). You > should note that this would still be problematic if there ever were > identical request block pointers. Also, IMO, using a timeout per I/O > request is a heavy load for a system unless you need the precise accuracy. > I prefer a general periodic timer per device instance and timeout counts > for all active commands for that device. > > Soren- this is your stuff isn't it- what have we misunderstood? This all needs more thought, I've just not had the time yet to do more about it. Hopefully when I return from FreeBSDCon I'm have a little more time for this... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@freebsd.org) FreeBSD Core Team member To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910181714.TAA00441>