Date: Sun, 18 Mar 2001 00:23:34 -0700 From: Warner Losh <imp@harmony.village.org> To: Bruce Evans <bde@zeta.org.au> Cc: John Baldwin <jhb@FreeBSD.ORG>, Matthew Jacob <mjacob@feral.com>, arch@FreeBSD.ORG Subject: Re: man pages t Message-ID: <200103180723.f2I7NY948714@harmony.village.org> In-Reply-To: Your message of "Sun, 18 Mar 2001 15:23:40 %2B1100." <Pine.BSF.4.21.0103181501580.25882-100000@besplex.bde.org> References: <Pine.BSF.4.21.0103181501580.25882-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSF.4.21.0103181501580.25882-100000@besplex.bde.org> Bruce Evans writes: : This is a good bad example. It's too late to disable interrupts in the : interrupt handler, because the handler might not be called until long : after the hardware asserts an interrupt (a delay of 20 msec is not : impossible, especially in -current). Even for fast interrupts? On other hardware for the job I have now we see indications that 20ms might not be unreasonable a delay (we have interrupts going off 22x a second, which is really more like 45ms, and we seem to be missing interrupts on a heavily loaded system). : > No, I don't know why. Just wanted to show : > an example that needed it, not for syncronization, but to assume total : > control of the CPU and to make everyone else wait while I do my : > semi-time critical hardware frobbing. : : You should know better :-). : : A device where you start i/o in a non-interrupt-driven way and have to : continue the i/o within a certain time would give a better example. True. But all I had was the example at hand :-). This is real hardware with a real FreeBSD device driver. : In your example, if missing the window would be fatal, to work under : FreeBSD you need to use a fast interrupt handler under FreeBSD-4.x : or better (fast interrupt handlers are broken in -current), and : arrange for all other fast interrupt handlers combined to not break : the window (this probably involves not having any other active ones). I use a fast interrupt handler :-). I thought that disabling all interrupts kept even other fast interrupt handlers from running. And that was the difference between splhigh() and disable_intr(). The window is actually fairly large to get things going (something on the order of 500 longwords in the fifo, which gives a latency of something like 5ms since the frames come in every 33ms (60 fields a second is 30 frames a second and the data is squirted out such that 500 longwords is just under 5ms of data). We had all kinds of problems with 4.0 and non-fast interrupts on slow machines. On fast (600MHz+) machines we could likely get away with non-fast interrupts, but I haven't bothered to recode it since those are the only CPUs that the client can obtain for the boards in question (don't ask me why, I long since gave up trying to argue with them). : If missing the windows wouldn't be fatal, then just use a normal : interrupt handler and recover from errors. Fast interrupt handlers : are too hard to use to use routinely. Agreed. They should be easier. But with enough patience and skill, they can be used when you gotta have the response time. I've found that fast interrupts work out best when you have just a circular buffer of stuff and you don't need to do selwake from the interrupt handler (I'm not even sure you are allowed to do selwake from a fast interrupt handler). Warner 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?200103180723.f2I7NY948714>