Date: Tue, 12 Aug 1997 21:31:57 -0500 (CDT) From: Doug Ledford <dledford@dialnet.net> To: aic7xxx list <aic7xxx@FreeBSD.org> Subject: Recent patch to aic7xxx.c Message-ID: <Pine.LNX.3.95.970812212044.17122A-100000@dledford.dialnet.net>
next in thread | raw e-mail | index | archive | help
OK...the patch I sent to the list doesn't work (among other things, there was a typo in the patch). I thought I was runnign on the patch when I sent it, but as it turns out, I wasn't because of my not recompiling the kernel since I last re-installed the source code. As a result, my INSTALL variable in the top level Makefile was not properly set and the kernels I was compiling were going into never never land. In any case, I worked on the patch before I finally had to get some sleep today, and now that I'm back up, I'll be working on it some more tonight. When I'm happy with it, then I'll send it back to the list. It appears as though a few things in the linux header source code are incorrect (for instance, placing your bottom half handler on the task queue tq_immediate does not cause your bottom half handler to get run immediately when you exit your interrupt as it should, so I had to switch over to tq_scheduler, which works because the scheduler is run at the end of all interrupt contexts and the end of all syscalls as well as on the timer interrupt, which is often enough to provide reasonably quick running of the bottom half). There is one problem though, the bottom half handler is atomic with respect to itself, and it is pre-empted by incoming interrupts, so the last testing has indicated that as a result of very heavy interrupt load, the interrupt routine can start to starve the bottom half handler and keep it from finishing in time to avoid SCSI timeouts from the mid-level code. I'll be working later tonight on speeding up the running of the bottom half handler in order to solve that problem and see if I can't stop the abort/reset cycles it causes. I'm not sure, but Dan mentioned he already had a spin lock mechanism in place to solve the same problem that this would solve (although it doesn't have the benefit of reducing interrupt latency as well as over all time spent with interrupts off) so it may end up being that it is easier to solve the problem that way (with less chance of breakage as well) than to do things this way. We'll see how the bottom half handler goes tonight, but if I can't make it pump the commands out fast enough to avoid timeouts, then it won't end up getting used anyway. ***************************************************************************** * Doug Ledford * Unix, Novell, Dos, Windows 3.x, * * dledford@dialnet.net 873-DIAL * WfW, Windows 95 & NT Technician * * PPP access $14.95/month ***************************************** * Springfield, MO and surrounding * Usenet news, e-mail and shell account.* * communities. Sign-up online at * Web page creation and hosting, other * * 873-9000 V.34 * services available, call for info. * *****************************************************************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.95.970812212044.17122A-100000>