OSDev.org

Don't know : it's to early for me to talk about multi-tasking ;D

Just remember when in multitasking stage..if there's errors...check you IDT code just in case...

Okydoky, nice advice !

Never mind that...Code Slasher just told me you need to cli!

This isn't something I've actually tried out, but judging from most of the documentation I've read you won't receive another IRQ until you send an EOI to the pic(s) after receiving the first one.

So the sti/cli pair is not, strictly speaking, needed. This brings its own problems though, and do you really need the hassle for the sake of 2 cycles?

This is an interesting point of view... and needs some tests to know if the EOI is sufficient to stop other interrupts while the system is executing one.

I think that you have to be aware of documentation, because theory and practice may differe : let's see my problem : I have a kernel that works on one computer and not on one other, but they are both i386 arch's (so with same components... in theory). I can't explain myself why it works on one and why it reboots and the other, it's just so and I have to find out a code that permits my kernel to work on both machines, that's all (folks)!

Actually it brings up more than just one point. Seeing as the sti/cli pair used by most people occurs inside the ISR then there is still the opportunity for another interrupt to happen before the iretd (Minimal opportunity, but over time it would happen). This would mean that you'd be nesting interrupts anyway sooner or later. Perhaps what's actually need here is to take the EOI or sti outside the ISR that way you can be certain to be only one interrupt dee,p but that just shifts the issue to somewhere else as you still need to get back to the calling code. Think I see away around it, but I'll have to do some checking to be sure.

It's not a hugely important issue, so long as the interrupt that sets up the nesting issue doesn't interfere with the stack above where it's called (Ie alter the CS:IP for the original IRETD) the nesting will resolve itself, but I prefer to have the stack in a determinate state as much as possible.

I did some testing and STI/CLI in interrupts is not nessasary. No IRQs happen till a outportb( 0x20, 0x20 ); happends.

okay, I'll try to remember this when I will need it.

Tom wrote:No IRQs happen till a outportb( 0x20, 0x20 ); happends.

Not quite... higher-priority IRQs will still happen. If you receive an IRQ 6 and wait for a second, you will still receive timer (IRQ 0) and keyboard (IRQ 1) interrupts in the mean-time. Note that the slave PIC is cascaded on IRQ 2, so the order of priorities goes:

(highest)
0
1
8
10
11
12
13
14
15
3
4
5
6
7
(lowest)

If 0 is the highest....why did the PIT wait for my IRQ1 handler to finnish?

Did you do STI from inside your handler? The CPU effectively does CLI before it executes your handler, so it ignores and interrupts that occur in the mean-time. When you do IRET, it restores the previous EFLAGS from the stack, thereby setting the interrupt flag to what it was before.

I didn't STI or CLI...I just saved the registers...and printed a message when IRQ 1 was fired...and IRQ 0 waits for the EOI.