Mail Archives: djgpp/2001/08/30/23:00:04
> 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?
- Raw text -