Mail Archives: djgpp/2002/10/09/16:03:02
> 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.
This error is in the 32-bit code segment, but you seem to be running
CWSDPR0.EXE (since it's running at ring 0). I don't see anything here
which gives a good hint of where to look next.
> > 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).
These aren't reentrant. And they have some overhead. And chaining takes
a lot of overhead (needs to call back to real mode). It's much better if
you just hook the interrupt and do cleanup yourselves. Even better if you
do it from your own wrapper ...
> > 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.
Ouch. Try removing the enable (and the disable). The enable would let a
second interrupt hit the wrapper before the first one was clear.
> 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+
r5? Image size?
> > 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.
Right now with the wrappers, a second interrupt nested would be dismissed
by the wrapper and never get an EOI.
Strongly recommend setting instead of chaining, and don't enable unless
you write your own assembly interrupt handler which is completely
reentrant. If you must chain due to other devices on the same
interrupt, custom code which returns if it is yours and only chains
if it isn't would be recommended.
> 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.
As long as it runs without seeing problems, I suspect the problem may be
something like timer interrupts happening at exactly the wrong place,
or serial, timer, nested-serial reflected from real mode while exiting
timer interrupt ... something like that.
> Thanks again for taking the time to look into this.
Good luck and let me know how it goes.
- Raw text -