From: "Charles Sandmann" Newsgroups: comp.os.msdos.djgpp Subject: Re: Help! - INT x22 problem. Date: Mon, 3 Sep 2001 21:17:24 Organization: Aspen Technology, Inc. Lines: 37 Message-ID: <3b93f364.sandmann@clio.rice.edu> References: <68C4CF842BD2D411AC1600902740B6DA02CDC559 AT mcoexc02 DOT mlm DOT maxtor DOT com> NNTP-Posting-Host: dcloan.hou.aspentech.com X-Trace: selma.aspentech.com 999573278 23420 10.32.115.107 (4 Sep 2001 03:14:38 GMT) X-Complaints-To: postmaster AT aspentech DOT com NNTP-Posting-Date: 4 Sep 2001 03:14:38 GMT X-NewsEditor: ED-1.5.8 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com > > Quick recommendations without a lot of analysis: > > 1) Try hooking instead of chaining (hook is faster) > > 2) Try getting rid of the disable/enable calls (in wrapper?) > > 3) If all else fails let's look at wrapper code details > > 1) Will try if #2 does not solve. I would hate to hook just in case > another card is utilizing the same IRQ (like video or something). Or am I > misinterpreting your hook idea? If you chain, it will end up calling the original handler (which in this case is the default one DPMI provides - which reflects the interrupt to the DOS/BIOS real mode handler). It adds quite a bit of overhead and mode swaps to reflect back to the real mode handler. This puts a limit on your interrupt frequency, and allows each one to take much longer, so you can end up with nested interrupts. Chaining is safer but much slower. Many devices don't work properly sharing interrupts - so if you are sure you aren't sharing it's better to not chain. > 2) Currently testing. I removed disable/enable calls from all of my ISR's > and it seems to be working. Just curious, but any ideas why? Am I > overriding some enable function in the DPMI wrappers by doing the enable > early? The wrapper keeps interrupts disabled and only enables them on the final exit. It isn't reentrant (actually it tries to be, by ignoring the interrupt, but failures happen). By enabling interrupts early you allow a second interrupt to overwrite the first one's stack, so the first one returns to the wrong place. We need to fix the wrappers to recognize when they are already on their own stack and completely test the nested-ness. It's an ugly fix (gopint.c) - hand codeded assembler that must do address fixups at run time. I'm not exactly sure what's needed. It may be because of interrupts inside the chained handler... Some day... > Thanks yet again, and I am once again truely impressed by the DJGPP/CWSDPMI > team. Glad this seemed to fix it.