Message-ID: From: "Sisco, Michael" To: "'sandmann AT clio DOT rice DOT edu'" Cc: "Djgpp (E-mail)" 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) Content-Type: text/plain; charset="iso-8859-1" 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 (414) 566-7894