From: Charles Sandmann Newsgroups: comp.os.msdos.djgpp Subject: Re: Int 0x22??? (DJGPP and CWSDPMI) Date: Mon, 07 Oct 2002 22:30:31 CDT Organization: Rice University, Houston TX Lines: 43 Message-ID: <3da25157.sandmann@clio.rice.edu> References: NNTP-Posting-Host: clio.rice.edu X-Trace: joe.rice.edu 1034048772 27051 128.42.105.3 (8 Oct 2002 03:46:12 GMT) X-Complaints-To: abuse AT rice DOT edu NNTP-Posting-Date: 8 Oct 2002 03:46:12 GMT X-NewsEditor: ED-1.5.9 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com > message generates a series of interrupts to tell us that there is data > available in the UART. We read and display this data before sending out > the next poll command. > This all works very well for a while. After somewhere between 0 and 15 > minutes, the program will crash with the following error (example): > Int 0x22 at eip 31ee0; flags=1234 > eax=00000030 ebx=00000000 ecx=0000000c edx=00000000 > esi=0001a44a edi=00000000 ebp=00000000 esp=00002672 > cs=18 ds=38 es=af fs=0 gs=0 ss=20 error=0000 I believe I've seen this error reported before. It does seem to be from CWSDPMI. I may have entered an analysis in a previous post/email - but I don't remember now. CS points to the ring 0 selector but EIP doesn't make sense in that context (32-bit on a 16-bit selector?) So something's corrupt. It may be due to some nasty nested interrupts, or a chip bug. > I don't understand this error indication. Int 0x22 isn't really an > interrupt vector at all. It simply specifies the return address > to be used when an application terminates. I'm not certain how our > application could have generated this interrupt. Also, the format > of the error display leads me to believe that this report might be > coming from CWSDPMI (see FAQ section 12.2). > If we run this test several times, we get the same result, but at > different eip values. I have traced all of these eip values and find > them to be valid points within the test loop that we are running. The > fact that the error is happening at different points in our loop leads > me to believe that our problem has something to do with our interrupt > handler, but I can't put my finger on it. Is it one you wrote from pure assembly, or does it use the wrappers? Protected mode only, or a real mode hook also? Do you keep interrupts disabled? What version of cwsdpmi? What CPU (speed/type)? Motherboard chipset? Are you making any calls in the interrupt handler?