Date: Mon, 25 Oct 1999 12:13:08 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Nate Williams <nate@mt.sri.com> Cc: Warner Losh <imp@village.org>, arch@freebsd.org Subject: Re: Racing interrupts Message-ID: <Pine.BSF.4.05.9910251206390.27785-100000@semuta.feral.com> In-Reply-To: <199910251902.NAA14532@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 25 Oct 1999, Nate Williams wrote: > > > : This does nothing for threads that were active at the time of the > > > : interrupt. In this case, either the hardware is sane enough to continue to > > > : provide some rational non-faulting access (in the case of memory mapping), > > > : or you have to design a framework such that when the interrupt occurs, and > > > : the nexus driver now knows how to remap any memory mappings so that a safe > > > : non-faulting (if nonsensical) access can occur. Then some additional > > > : mechanism which notifies the actual node driver that things have changed > > > : will be invoked. > > > > > > Hmmm. I could do this, but do not know of any way of mapping I/O > > > ports sanely. The problem appears to be driver busy waits for bits to > > > > I/O instructions don't cause faults if the port doesn't exist, right? They > > just are /dev/null for writes and return nonsense for reads. > > How do you differentiate between 'good' reads and 'nonsensical' reads? That's the node driver's problem. > > > I suppose that if a driver is polling an I/O port, and it knows it's on a > > bus where this I/O port can go away, it should check for other status, no? > > Heck, you shouldn't have drivers poll forever anyway. > > Agreed, but these sort of assumptions exist today, and re-writing the > driver is non-trivial, and adds additional complexity, especially since > FreeBSD doesn't have the infrastructure to deal with these kinds of > changes (yet). > > 1) How do you recognize 'garbage'? Again, this isn't the main point. The main point is that if the h/w resource is invalidated, node drivers have to know how to check for this (and leave enough headroom to do so), and the system can't panic because somebody physically changed something (other than the power switch, duh). > 2) What do you do when you determine a piece of hardware is gone/bad? "Bad" hardware is a separate issue, really. But if a piece of hardware goes, and there is some kind of notification by some other controlling hardware, it's just sloppy architecture to not make use of that information. If there is no notification, then you lose (and either should get better h/w or accept a wedged system). > 3) What about dependencies? (If the disk is bad, do you unmount the FS, > flush the buffers, etc...?) That's already handled (mishandled, actually) in CAM by the pack invalidation code. > > Error handling is *HARD WORK*, and it's difficult to make a generic > infrastructure to deal with all of the different kinds of errors that > may occur. > > It's alot easier to use the standard FreeBSD approach to the problem. > "You've got broken hardware, fix it and FreeBSD will work better." :( Then FreeBSD will never be a serious server solution, and I for one would quit wasting my time on a Linux wannabe. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9910251206390.27785-100000>