delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2002/10/08/00:01:56

From: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
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: <BDD73AE8AEE3EF438E07420C2600E9F65C918A AT qtiexch0 DOT qgraph DOT com>
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?

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019