From: "Charles Sandmann" Newsgroups: comp.os.msdos.djgpp Subject: Re: Help! Date: Thu, 30 Aug 2001 20:45:37 Organization: Aspen Technology, Inc. Lines: 45 Message-ID: <3b8ea5f1.sandmann@clio.rice.edu> References: <68C4CF842BD2D411AC1600902740B6DA02CDC54C AT mcoexc02 DOT mlm DOT maxtor DOT com> NNTP-Posting-Host: dcloan.hou.aspentech.com X-Trace: selma.aspentech.com 999225738 10614 10.32.115.107 (31 Aug 2001 02:42:18 GMT) X-Complaints-To: postmaster AT aspentech DOT com NNTP-Posting-Date: 31 Aug 2001 02:42:18 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 > I am getting an error very sporadically when servicing an interrupt. It > also only seems to happen on fast machines >300 Mhz. > > Int 0x22 at eip=11f7 flags=3002 > eax=0x00000000 ebx=0000010e ecx=001bd30c edx=0000258e esi=0000005a > edi=00000000 > ebp=00134760 esp=0000236e cs=2b ds=ff es=ff fs=117 gs=10f ss=33 error=0000 > > Can anyone provide a clue as to what this means? Stack problem? cs=2b is a CWSDPMI internal descriptor, so you are inside the DPMI provider. Int 0x22 means that it believes that you made a protected mode 0x22 call (which would be really bad if passed to real mode and it captures it to warn you). The instruction at eip=0x11f7 inside CWSDPMI isn't an interrupt 0x22 (this is _user_interrupt_return according to the link map). It is an intersegment call gate. The esp is in the o_tss (utils tss) which I would not expect - like we have somehow had an exception or interrupt inside the DPMI provider (which shouldn't happen). I'm sort of rusty on the tss swaps but this looks funny. So, is CWSDPMI's code corrupted (overwritten?) or is the the call gate selector overwritten to point to something in the interrupt table? It's really hard to tell with a quick analysis. The contents of the other registers may give some hints of where we have been. > I have written the handler in C, which I read is a bad idea, but I locked > the entire app into memory, because I actually do not want ANY virtual > memory. I develop test code for testing various controllers (CMD, Promise, > Intel, Via, etc..) with various hard disks. The only problem with handlers in C (if locked in memory) is our wrappers may not be reentrant, and there may be a narrow window when exiting to have them smash their own stack if another interrupt comes in. > I will write the handler in asm if I really need to, but I am hoping I don't > have to. Many of the programmers today don't speak assembly and there are > only two people in my group capable of it, so if I can leave it in C, I > would prefer it. Also, we don't have a lot of experience with the AT&T > style assembly. This is a hard call. Since the problem is infrequent and only on fast machines, I suspect a very narrow window which usually isn't hit. How many different interrupts are being hooked? Roughly what frequency do they fire? Is is only a particular type of machine?