"Jim Leonard" <spamtrap@[EMAIL PROTECTED]
> wrote in message
news:1183651460.770925.288960@[EMAIL PROTECTED]
> On Jul 5, 1:17 am, "Rod Pemberton" <spamt...@[EMAIL PROTECTED]
> wrote:
> > Is the *entire* IRQ 2 routine wrapped in CLI/STI also?
>
> No, it's not. Should it be? The interrupt handler is called by a
> hardware interrupt, and I was under the impression that, on entry to
> an interrupt handler, processor interrupts are disabled as if CLI were
> called. At the end of my handler is an EOI (to tell the PIC the
> hardware interrupt has been serviced), and then IRET, which I thought
> set the interrupt flag again. Am I misunderstanding something?
>
No.
Sorry, my mistake. I should have asked if interrupts were disabled (IF
cleared) for the entire routine. I wrapper my IRQ routines with CLI/STI
because they go through a trap gate. This shouldn't affect you. I was
considering that interrupts might be enabled for part of the IRQ routine,
and that it might be a problem.
Anyway, Ben thinks it might work better with interrupts enabled. It's
worth
a shot. I usually try all combinations anyway. :-) Helps to learn new
stuff - even if painful...
The problem I experienced with my personal OS was corruption of static or
shared data. Since my IRQ routines were becoming quite large, I enabled
interrupts for non-critical ****tions of the routines. I wanted to find
out
if the OS became more responsive or less so. It seemed to be slightly
more
responsive. So, I left it. Unfortunately, there was one pointer which
absolutely needed to remain unchanged until each IRQ routine exited. Of
course, allowing interrupts meant that the pointer was overwritten with a
new value with every interrupt. Since the data pointed to at that time
was
non-critical, it appeared that things were working properly, but it
wasn't.
Rod Pemberton
|
