Message-ID:	<BDD73AE8AEE3EF438E07420C2600E9F65C918E@qtiexch0.qgraph.com>
From:	"Sisco, Michael" <mdsisco AT qtiworld DOT com>
To:	"'sandmann AT clio DOT rice DOT edu'" <sandmann AT clio DOT rice DOT edu>
Cc:	"Djgpp (E-mail)" <djgpp AT delorie DOT com>
Subject:	Re: Int 0x22???
Date:	Wed, 9 Oct 2002 13:29:03 -0500
MIME-Version:	1.0
X-Mailer:	Internet Mail Service (5.5.2656.59)
Reply-To:	djgpp AT delorie DOT com

Thanks for your response. Hopefully this information will clear things up a
little.

> > 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 pasted an error log from another problem that we were having and edited
it to provide what I thought was the useful information about our current
problem. Probably rather naive of me to think that no one out there would
take the time to actually look at the values from the dump. Here is an
ACTUAL dump from the problem at hand.

Int 0x22 at eip=3e3f; flags=3287
eax=00000000 ebx=00110710 ecx=0007d8f0 edx=00000000 esi=425ec73a
edi=0000005b
ebp=00110768 esp=001106f4 cs=a4 ds=ac es=ac fs=cc gs=bc ss=ac error=0000

I don't know if that provides any more useful information or not.

> Is it one you wrote from pure assembly, or does it use the wrappers?
It uses the wrappers (_go32_dpmi_chain_protected_mode_interrupt_vector).

> Protected mode only, or a real mode hook also?
Protected mode only. We tried installing both, but this was giving us other
fits.

> Do you keep interrupts disabled?
I'm not sure I understand. The first line of our interrupt handler is
disable();
and the last line is enable(); if that's what you mean. We are also issuing
the
EOI command to the interrupt controller just before re-enabling interrupts,
i.e.
   outportb(0xa0, 0x20);
   outportb(0x20, 0x20);

   enable();

> What version of cwsdpmi?
CWSDPMI V0.90+

> What CPU (speed/type)?  Motherboard chipset?
Pentium III 850MHz. Intel 82443BX, 82371 chipsets.

> Are you making any calls in the interrupt handler?
No - we have been specifically careful to not make any libc or system calls
within the interrupt handler.

Some additional information. We have what I think is an unrelated problem,
but
the symptoms may provide some insight. Our UART (actually a DUART) is part
of
a PCI board that we have designed in-house. There are other possible sources
for the interrupt that the PCI board generates to the CPU. When two or more 
of these sources "overlap" (i.e. a second interrupt is generated while we
are
processing the first one) the system will hang. We believe that this is
caused
by the fact that the board fails to release the PCI bus when there is still
an
interrupt that has not been serviced. As I said, I don't beleieve that this
is
related to the original problem that I wrote about, but I wanted to provide
as
much detail as I can.

Also, I have done some timing tests to make sure that we are not spending
too
much time within our interrupt handler. The handler executes for somewhere
between 2 and 3 microseconds approximately 1200 times per second, so less
than
1% of our time is spent in the interrupt handler.

Thanks again for taking the time to look into this.

Michael

Michael D. Sisco
Software Engineer
QTI - Integration Team
<mailto:Michael DOT Sisco AT qtiworld DOT com>
(414) 566-7894

- Raw text -